Support newlines and formatting in DV_TEXT


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?




Heath Frankel
May 15, 2015, 12:15 AM

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.

Bjørn Næss
June 8, 2015, 6:37 AM

+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

Diego Bosca
June 8, 2015, 6:43 AM

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

Thomas Beale
June 8, 2015, 12:01 PM

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.

Pablo Pazos
August 30, 2017, 1:28 PM

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.

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.


Heath Frankel