We discussed about this item on the SEC meeting.

Context:

• 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.

Possible solution:

• 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.

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.

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

+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:

• Bold

• Italic

• Lists (ordered, unordered)

• Header

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.