The DataTypes specification indicates that a DV_TEXT instance should be for a single fragment of text with a particular format. DV_PARAGRAPH is intended to aggregate multiple instances of DV_TEXT to form a composite fragment of text with different paragraphs amd formats.
This has proven to unwieldy to use and although it may be possible when implementing a text editor it is not so easy when importing text from other sources such as messages and CDA documents.
Is it possible for DV_TEXT to be used in a way that supports multiple paragraphs and formatted text without the overhead of composing multiple instances within DV_PARAGRAPH?
I was certainly not suggesting CDA markup. As indicated above, I was thinking more like HL7 V2 FT escape characters or subset of markdown if it was markup at all.
+1 for allowing newline and tabs.
If we want more markup the only way to do this is DV_PARSABLE. The application must have some information to choose the correct parser/viewer for the given markup.
Of course this is a common need to be able to add some markup on text (bold, italic, header, etc.). And I think it would be great to have some minimal markup on DV_TEXT. And if we go in that direction we must agree upon one kind of markup to be able to parse/view data in a consistent way. Next question then is if it possible to agree on some markup codes for:
Lists (ordered, unordered)
But this is to being able to constraint it on archetypes or to be able to put it on data instances? I see the first thing problematic, but the second one I'm not sure it cannot be achieved with a regex constraint
Let's progress this to a CR, and we will determine the exact fix there.
I think the requirements are to be able to:
include varying amounts of formatting, newlines etc in runtime text
archetype the field to be:
no newlines / tabs
text / newlines / tabs (i.e. essentially plain text paras)
any formatting according to syntax X
I'm not inclined to just say that we assume the formatting syntax X is 'markdown', because markdown is a moving target.
We discussed about this item on the SEC meeting.
Some implementers are using DV_PARSABLE to add markup based formatting to text.
Nobody seems to be using DV_PARAGRAPH.
The issue of using DV_PARSABLE is needs a type change on current archetypes for apps to be able to record formatted text on current DV_TEXT nodes.
Current DV_TEXT.formatting applies to the whole DV_TEXT.value, not to internal words or phrases.
Adding "formalism" (same semantics as DV_PARSABLE.formalism) attribute to DV_TEXT and removing "formatting" can be a solution, "formalism" can be used to state a media type like "text/plain" or "text/html" or some markdown mime type like "application/x-yaml" or "text/yaml" (these options should be constrained to avoid using binary mime types)
No need of further archetyping to specify what is allowed, allow newlines, tabs, other formatting characters and styling like bold, italic, etc. using markup or markdown in the DV_TEXT.value.
DV_TEXT.formalism value should be given at runtime.