What's the best way to represent narrative text in CDA messages

Hi there,

@vaibhavhp and I are trying to represent OpenMRS data in CDA format. The problem is that we don’t have sample messages to compare our efforts against. We do have validators, but the validators are not concerned with how the Observation values are formatted in the CDA message :-1:

Consider this situation.

(1) Looking at the different types of CDA sections, I find two basic groups - (a) Sections such as ‘chief complaint’ where you’d be concerned only with the very latest observation value and (b) sections that deal with history, were you’d need to have all the data irrespective of how old they are.

Now, whats the best way to represent narrative text for these ?

Looking at the CCD example we have, it seems that RI uses either plaintext or html for this purpose. For complex textual data such as lab results, it uses html format (in fact, it creates a nice table for us)

So what should be our best bet ? Perhaps,

(a) For a single text answer, just write it in plaintext form (b) For multiple answers, generate an html table with some additional info such as dates, etc ?

What do your clinicians @burke @paul or @janflowers think :smile:

I would be very cautious about assumptions about manipulating content for rendering. Simple HTML (e.g., <p>, <b>, <i>, <em>) are probably safe, but creating new tables may work for some clients and not for others.

Can’t you just render text as it was entered/saved? It sounds like you are suggesting combining text results? What’s the use case?

Hi,

I would definitely prefer to use plaintext format as well. Its just that RI seems to use html tables for representing complex lab results…

Lets put it this way. Lets say you have one slot, and need to represent two plaintext strings obtained from different encounters. How would you represent that ? perhaps obs_one_date : obs_one_text | obs_two_date : obs_two_text

So basically, i’m saying " to represent an obs in text, include the obs date [colon] value " is this a stupid idea ?

Re. the need for tables, I could see it coming useful for lab results, such as this.

Would appreciate any comments :smile:

Hi there,

Looking through the sections required for the APHP message, I note a number of examination results that expect text/narrative answers.

Example of these are :

NEUROLOGIC SYSTEM GENITALIA RECTUM HEART etc. etc.

Now, for these, i’d assume that you’d want to see results of all previous exams of this type for the current pregnancy. But since the OMRS data model doesn’t really allow you to identify previous and current pregnancies, you’d need to pull in all of them (unless you just take the results that fall into the last nine months or other specific date range, which could be set via a global property ?)

Plus, the section hasn’t a proper way to represent when the observation was made, which is a huge problem :frowning: So basically, i think that we’d need to represent both the observation date and the value in the tags.

To do this, how about using some sketchy xml ? Maybe,

<text>

<observation>
<date>When the obs occurred</date>
<value>result</value>
</observation>

<observation>
<date>When the obs occurred</date>
<value>result</value>
</observation>

<!-- repeat until done --> 

</text>

Are you working on support for a specific implementation of CDA?

So basically, i’m saying " to represent an obs in text, include the obs date [colon] value " is this a stupid idea ?

This doesn’t seem like narrative text to me. Seems like discrete data that you’re outputting to plain text. Why do that? Since OpenMRS has such rich, discrete data why not target CDA Level 3? Here’s an example lab result entry from C32 (encoded using an observation element):

<!-- These examples assume the default namespace is 'urn:hl7-org:v3' --> 
<observation classCode='OBS' moodCode='EVN'>
    <templateId root='2.16.840.1.113883.10.20.1.31'/>
    <templateId root='2.16.840.1.113883.3.88.11.83.15'/>
    <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.13'/>
    <code code='...' displayName='...' codeSystem='2.16.840.1.113883.6.1'
    codeSystemName='LOINC'/>
    <effectiveTime low value='...'/>
    <statusCode value='N'/>
    <value xsi:type="PQ" value="100" unit="g/dl"/>
    <interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"/> 
    <referenceRange>
      <observationRange>
        <text>M 13-18 g/dl; F 12-16 g/dl</text>
      </observationRange> 
    </referenceRange>
  </observation>
1 Like

Howdy @gmccallum ! nice to hear from you again ! :smile:

I’m wondering, do you have some good sample CDA messages that we could use for study ? at this point, we’ve just been unable to locate any. I’d agree that the example I came up with is not the best, would you be able to come up with one that we could use for reference ?

I’m taking to another CDA exprt on a separate forum, and he recommended that we narrative text in entries that are simply idrefs to parts of the StructDoc.Text of the section. So the section has the formatted bits and the entries simply point to them. For example you’d have an observation:

<observation>
   <!-- truncated -->
   <text>
      <reference value="#obs123"/>
   </text>

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything).

What would you think of this ?

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything).

What would you think of this ?

I sent you an example with that. But the reference to the section text element does not preclude the structured representation of the observation in xml.

Thank you everyone. This has been VERY helpful. In the very least, i’ve learnt CDA :smile: Given that this is GSOC, and that we need specific and achievable goals, I am going to propose the following.

For any section that is supposed to be a narrative description,

  1. if a single obs, we’ve have <text><paragraph></paragraph></text>
  2. if multiple obs, we’ll have one paragraph per observation

So basically, the use of narrative text will be an excuse to avoid using complicated entry tags. But here’s the downside : apparently NIST and meaningful use thinks that its ok to report this data, but NO observation date. So basically, we can report the obs value, but not when it occurred, not unless we switch to using <entry> tags. Is it ok to follow NIST guidelines and avoid reporting obs dates for step one ? or should we hack some modifications and report the obs date as well ?