Representing narrative text in a CDA message. plaintext vs. html

Suranga_Kasthurirat1 · June 28, 2014, 8:57pm

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

···

–
Best Regards,
Suranga

Suranga_Kasthurirat1 · June 29, 2014, 7:10pm

Hi there,

FYI, more discussion on this matter are now happening at :

https://talk.openmrs.org/t/whats-the-best-way-to-represent-narrative-text-in-cda-messages/358/4

···

On Sat, Jun 28, 2014 at 4:57 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

Best Regards,
Suranga

–

Justin_Fyfe · June 30, 2014, 2:06am

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

···

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–
Best Regards,
Suranga

Suranga_Kasthurirat1 · June 30, 2014, 2:29am

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

···

On Sun, Jun 29, 2014 at 10:06 PM, justin.fyfe@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–
Best Regards,
Suranga

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Suranga_Kasthurirat1 · June 30, 2014, 4:52am

Hi,

My apologies, I need to clarify something else.

Is it normal practice to have html tables etc. in CDA ? Will HTML content work for all clients ?

···

On Sun, Jun 29, 2014 at 10:29 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

On Sun, Jun 29, 2014 at 10:06 PM, justin.fyfe@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–
Best Regards,
Suranga

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Justin_Fyfe · June 30, 2014, 12:47pm

No problem,

There are some good examples on the NIST website which show this type of text entry (technically these are MU documents but still good for showing the concept): http://cda-validation.nist.gov/cda-validation/downloads.html . One example of this (truncated for space):

…

Technically the content that appears in the text of a section isn’t HTML, it is a StructDoc.Text (content of type “text/x-hl7-text+xml”) whose structure is defined in NarrativeBlock.xsd. Some implementation frameworks such as MDHT and Everest will expose it as an ED as a convenience however the content should still contain elements defined in that schema (also, technically in XML terms elements here will appear in “urn:hl7-org:v3” namespace and not http://www.w3.org/1999/xhtml). I know in Everest we had fixed this in 1.3 for C# and were working on incorporating it into Java, in preparation for the Sherpas framework stuff.

The odd part is the text element of each entry is an ED which means you could put HTML in there (technically) however I’ve always seen either a reference, plaintext or just StructDoc.Text elements there (well, I should say implementers don’t change the namespace as I mentioned before). The good news is that StructDoc.Text shares the same element local names as HTML however it is more restrictive.

Another good route is to read the CDA.xsl that is shipped with most samples and see what they support rendering. Generally I find C32 and CCD ones good for this purpose as most vendors have implemented those templates and they usually serve as a basis of other templates like XPHR, EDR, etc.

Cheers

-Justin

···

On Monday, June 30, 2014 12:52:52 AM UTC-4, Suranga Kasthurirathne wrote:

Hi,

My apologies, I need to clarify something else.

Is it normal practice to have html tables etc. in CDA ? Will HTML content work for all clients ?

On Sun, Jun 29, 2014 at 10:29 PM, Suranga Kasthurirathne sura...@openmrs.org wrote:

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

On Sun, Jun 29, 2014 at 10:06 PM, justi...@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–
Best Regards,
Suranga

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Type	Substance	Reaction	Status
Drug Allergy	Penicillin	Hives	Active

Suranga_Kasthurirat1 · June 30, 2014, 9:13pm

Justin, those NIST templates were a goldmine.

And I finally realized that what i’m calling HTML is StructDoc.Text

I have one more question.

How do I know which sections are interested in which type of structure ? for example, I saw,

<item>HEENT: All normal to examination.</item>

<item>Heart:  RRR, no murmur.</item>

<item>THORAX &amp; LUNGS:  Clear without rhonchi or wheeze.</item>

and

Colonoscopy due to rectal bleeding.

Where can I check which of these formats ( vs ) is best for which section ? is that something I get to pick on my own ?

The same goes to the use of StructDoc.Text oriented tables. what defines the structure / columns of the tables ? is there a prescribed structure ?

Thanks and Best regards,

Suranga

···

On Mon, Jun 30, 2014 at 8:47 AM, justin.fyfe@ecgroupinc.com wrote:

No problem,

There are some good examples on the NIST website which show this type of text entry (technically these are MU documents but still good for showing the concept): http://cda-validation.nist.gov/cda-validation/downloads.html . One example of this (truncated for space):

…

…
   <thead>
    <tr>
     <th>Type</th>
     <th>Substance</th>
     <th>Reaction</th>
     <th>Status</th>
    </tr>

   </thead>
   <tbody>
    <tr ID="ALGSUMMARY_1">
     <td ID="ALGTYPE_1">Drug Allergy</td>
     <td ID="ALGSUB_1">Penicillin</td>

     <td ID="ALGREACT_1">Hives</td>
     <td ID="ALGSTATUS_1">Active</td>
    </tr>
…
  <act classCode="ACT" moodCode="EVN">
…

…

Technically the content that appears in the text of a section isn’t HTML, it is a StructDoc.Text (content of type “text/x-hl7-text+xml”) whose structure is defined in NarrativeBlock.xsd. Some implementation frameworks such as MDHT and Everest will expose it as an ED as a convenience however the content should still contain elements defined in that schema (also, technically in XML terms elements here will appear in “urn:hl7-org:v3” namespace and not http://www.w3.org/1999/xhtml). I know in Everest we had fixed this in 1.3 for C# and were working on incorporating it into Java, in preparation for the Sherpas framework stuff.

The odd part is the text element of each entry is an ED which means you could put HTML in there (technically) however I’ve always seen either a reference, plaintext or just StructDoc.Text elements there (well, I should say implementers don’t change the namespace as I mentioned before). The good news is that StructDoc.Text shares the same element local names as HTML however it is more restrictive.

Another good route is to read the CDA.xsl that is shipped with most samples and see what they support rendering. Generally I find C32 and CCD ones good for this purpose as most vendors have implemented those templates and they usually serve as a basis of other templates like XPHR, EDR, etc.

Cheers

-Justin

On Monday, June 30, 2014 12:52:52 AM UTC-4, Suranga Kasthurirathne wrote:

Hi,

My apologies, I need to clarify something else.

Is it normal practice to have html tables etc. in CDA ? Will HTML content work for all clients ?

On Sun, Jun 29, 2014 at 10:29 PM, Suranga Kasthurirathne sura...@openmrs.org wrote:

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

On Sun, Jun 29, 2014 at 10:06 PM, justi...@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–
Best Regards,
Suranga

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

For more options, visit https://groups.google.com/d/optout.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Justin_Fyfe · June 30, 2014, 9:29pm

Hi Suranga,

As to what columns to have in your table and the thead, tbody and tfoot data, it is whatever is deemed clinically relevant. is used by systems to show data that they can’t interpret (i.e. can only display) or that can’t be encoded properly to the user. The type of data structure (in the relationship) will hint to the type of text structure to use.

So, the answer is; it really is up to you and how you want to convey content in text. From what I’ve seen lots of implementations will use

and reference a for each entry as it maps quite nicely to pretty much any data (observations, allergies, surgeries, etc.). I’ve also seen some vendors just use lists for conveying a series of steps or ordered procedures done within an encounter, and free-text when data is unstructured like free-text notes. You can combine them if you like and put lists in tables or tables in lists as well J …

It really depends on the quality of the input data (I always say garbage-in garbage-out ;)), and how the users will find the data most useful. In the past I’ve found it useful to generate a couple of CDA documents with several different styles of text for various sections (example: vital signs section as a list, table with 3 columns, table with 4 columns, etc.) and then have a clinically focused person look at them (apply the CDA.xsl of course so they are looking at HTML) as they can really tell you what representation best fits a particular type of data.

Hope that helps!

Cheers

-Justin

···

Justin, those NIST templates were a goldmine.

And I finally realized that what i’m calling HTML is StructDoc.Text

I have one more question.

How do I know which sections are interested in which type of structure ? for example, I saw,

HEENT: All normal to examination.

Heart: RRR, no murmur.

THORAX & LUNGS: Clear without rhonchi or wheeze.

and

Colonoscopy due to rectal bleeding.

Where can I check which of these formats ( vs ) is best for which section ? is that something I get to pick on my own ?

The same goes to the use of StructDoc.Text oriented tables. what defines the structure / columns of the tables ? is there a prescribed structure ?

Thanks and Best regards,

Suranga

On Mon, Jun 30, 2014 at 8:47 AM, justin.fyfe@ecgroupinc.com wrote:

No problem,

There are some good examples on the NIST website which show this type of text entry (technically these are MU documents but still good for showing the concept): http://cda-validation.nist.gov/cda-validation/downloads.html . One example of this (truncated for space):

…

Technically the content that appears in the text of a section isn’t HTML, it is a StructDoc.Text (content of type “text/x-hl7-text+xml”) whose structure is defined in NarrativeBlock.xsd. Some implementation frameworks such as MDHT and Everest will expose it as an ED as a convenience however the content should still contain elements defined in that schema (also, technically in XML terms elements here will appear in “urn:hl7-org:v3” namespace and not http://www.w3.org/1999/xhtml). I know in Everest we had fixed this in 1.3 for C# and were working on incorporating it into Java, in preparation for the Sherpas framework stuff.

The odd part is the text element of each entry is an ED which means you could put HTML in there (technically) however I’ve always seen either a reference, plaintext or just StructDoc.Text elements there (well, I should say implementers don’t change the namespace as I mentioned before). The good news is that StructDoc.Text shares the same element local names as HTML however it is more restrictive.

Another good route is to read the CDA.xsl that is shipped with most samples and see what they support rendering. Generally I find C32 and CCD ones good for this purpose as most vendors have implemented those templates and they usually serve as a basis of other templates like XPHR, EDR, etc.

Cheers

-Justin

On Monday, June 30, 2014 12:52:52 AM UTC-4, Suranga Kasthurirathne wrote:

Hi,

My apologies, I need to clarify something else.

Is it normal practice to have html tables etc. in CDA ? Will HTML content work for all clients ?

On Sun, Jun 29, 2014 at 10:29 PM, Suranga Kasthurirathne sura...@openmrs.org wrote:

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

On Sun, Jun 29, 2014 at 10:06 PM, justi...@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Type	Substance	Reaction	Status
Drug Allergy	Penicillin	Hives	Active

Suranga_Kasthurirat1 · July 1, 2014, 4:00am

Hey there,

Thank you, it does very much

So in a nutshell, I understand that the decision is up to us, to display the data in the most relevant and useful way.

I think i’ll try to use the table-ish approach for any section that includes a history, or basically, may contain multiple records / occurrences - my argument being that even where we may not have a specific need for multiple columns, it would be easier to expand on them when they may become necessary or more descriptive later ?

···

On Mon, Jun 30, 2014 at 5:29 PM, Justin Fyfe justin.fyfe@ecgroupinc.com wrote:

Hi Suranga,

As to what columns to have in your table and the thead, tbody and tfoot data, it is whatever is deemed clinically relevant. is used by systems to show data that they can’t interpret (i.e. can only display) or that can’t be encoded properly to the user. The type of data structure (in the relationship) will hint to the type of text structure to use.

So, the answer is; it really is up to you and how you want to convey content in text. From what I’ve seen lots of implementations will use
and reference a for each entry as it maps quite nicely to pretty much any data (observations, allergies, surgeries, etc.). I’ve also seen some vendors just use lists for conveying a series of steps or ordered procedures done within an encounter, and free-text when data is unstructured like free-text notes. You can combine them if you like and put lists in tables or tables in lists as well J …

It really depends on the quality of the input data (I always say garbage-in garbage-out ;)), and how the users will find the data most useful. In the past I’ve found it useful to generate a couple of CDA documents with several different styles of text for various sections (example: vital signs section as a list, table with 3 columns, table with 4 columns, etc.) and then have a clinically focused person look at them (apply the CDA.xsl of course so they are looking at HTML) as they can really tell you what representation best fits a particular type of data.

Hope that helps!

Cheers

-Justin

From: Suranga Kasthurirathne [mailto:surangak@openmrs.org]
Sent: Monday, June 30, 2014 5:14 PM
To: justin.fyfe@ecgroupinc.com
Cc: openhie-shr@googlegroups.com
Subject: Re: Representing narrative text in a CDA message. plaintext vs. html

Justin, those NIST templates were a goldmine.

And I finally realized that what i’m calling HTML is StructDoc.Text

I have one more question.

How do I know which sections are interested in which type of structure ? for example, I saw,

HEENT: All normal to examination.

Heart: RRR, no murmur.

THORAX & LUNGS: Clear without rhonchi or wheeze.

and

Colonoscopy due to rectal bleeding.

Where can I check which of these formats ( vs ) is best for which section ? is that something I get to pick on my own ?

The same goes to the use of StructDoc.Text oriented tables. what defines the structure / columns of the tables ? is there a prescribed structure ?

Thanks and Best regards,

Suranga

On Mon, Jun 30, 2014 at 8:47 AM, justin.fyfe@ecgroupinc.com wrote:

No problem,

There are some good examples on the NIST website which show this type of text entry (technically these are MU documents but still good for showing the concept): http://cda-validation.nist.gov/cda-validation/downloads.html . One example of this (truncated for space):

…
…
  <table border="1" width="100%">
   <thead>
    <tr>
     <th>Type</th>
     <th>Substance</th>
     <th>Reaction</th>

     <th>Status</th>
    </tr>
   </thead>
   <tbody>
    <tr ID="ALGSUMMARY_1">
     <td ID="ALGTYPE_1">Drug Allergy</td>

     <td ID="ALGSUB_1">Penicillin</td>
     <td ID="ALGREACT_1">Hives</td>
     <td ID="ALGSTATUS_1">Active</td>
    </tr>
…

…

…

Technically the content that appears in the text of a section isn’t HTML, it is a StructDoc.Text (content of type “text/x-hl7-text+xml”) whose structure is defined in NarrativeBlock.xsd. Some implementation frameworks such as MDHT and Everest will expose it as an ED as a convenience however the content should still contain elements defined in that schema (also, technically in XML terms elements here will appear in “urn:hl7-org:v3” namespace and not http://www.w3.org/1999/xhtml). I know in Everest we had fixed this in 1.3 for C# and were working on incorporating it into Java, in preparation for the Sherpas framework stuff.

The odd part is the text element of each entry is an ED which means you could put HTML in there (technically) however I’ve always seen either a reference, plaintext or just StructDoc.Text elements there (well, I should say implementers don’t change the namespace as I mentioned before). The good news is that StructDoc.Text shares the same element local names as HTML however it is more restrictive.

Another good route is to read the CDA.xsl that is shipped with most samples and see what they support rendering. Generally I find C32 and CCD ones good for this purpose as most vendors have implemented those templates and they usually serve as a basis of other templates like XPHR, EDR, etc.

Cheers

-Justin

On Monday, June 30, 2014 12:52:52 AM UTC-4, Suranga Kasthurirathne wrote:

Hi,

My apologies, I need to clarify something else.

Is it normal practice to have html tables etc. in CDA ? Will HTML content work for all clients ?

On Sun, Jun 29, 2014 at 10:29 PM, Suranga Kasthurirathne sura...@openmrs.org wrote:

Justin,

This helps VERY much. Do you have a sample message with these components that we could use for future reference ?

Would really love to have one handy !!!

On Sun, Jun 29, 2014 at 10:06 PM, justi...@ecgroupinc.com wrote:

Hello,

I’m not sure if this helps, but lots of the instances that I’ve seen for narrative text in entries 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:

Where #obs123 references an element with ID of obs123 in the section (could be a table, a row in a table, or anything). I think all of the elements in StructDoc.Text allow for an xs:ID attribute named “ID” to be assigned. In any case, I think it reasonable to expect that text would either point to (or be) text or something with media type text/x-hl7-text+xml (just like the section text).

Cheers

-Justin

On Saturday, June 28, 2014 4:57:33 PM UTC-4, Suranga Kasthurirathne wrote:

Hi Derek et. al,

I’d like to get your opinion on the best way to represent OpenMRS data in a CDA document.

Disclaimer : we don’t have a sample CDA message populated with actual data to compare our work against. We’re using the CDA validators, and trying to get a better understanding of what valid messages would look like based on CCD message samples that we do have.

Now, consider a section such as ‘chief complaint’. As per LOINC codes, this would have a narrative result, so I would ideally represent it in plaintext format (and not html format ?)

In what event should we represent textual data in html format ? Assuming that some sections (such as those which deal with history) would have multiple entries to represent, is there some sort of guideline to decide which approach would be used to represent which data ? for example, I’d imagine that lab data would be represented as html content…

–

Best Regards,

Suranga

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.