Skip to main content

Exchanging Care Plans, Discharge Summaries, and other Unstructured Narrative Content

In an ongoing debate about the readiness of HIE for Medicaid Health Homes and other ACOs, one of the issues has been the need to exchange care plans. Unfortunately, I think people are hung-up on the concept of structured XML documents and structured data. Just because the document is structured and contains many areas of coded, structured data; should not be interpreted as though there cannot be sections of data that are unstructured narratives with limited structured elements describing the content such as date/time, author, and type of report.
Recently, we have gone so far as to add narrative data in several areas of the CCD where it can be supported. These include pathology reports, image studies, discharge summaries, and care plans. Part of the problem with exchanging this type of data is that the default stylesheet (XSLT) from HL7 for viewing a CDA R2 document, such as a CCD/C32, as an HTML document, does not display narrative data properly. Basically, it just needs to respect the carriage returns that are in the narrative section. This can be done by adding the following code to any stylesheet.
<xsl:template match="text()">
               <xsl:choose>
                              <xsl:when test="contains(.,'&#x0A;')">
                                             <pre>
                                                            <xsl:value-of select="."/>
                                             </pre>
                              </xsl:when>
                              <xsl:otherwise>
                                             <xsl:value-of select="."/>
                              </xsl:otherwise>
               </xsl:choose>
</xsl:template>
I have tested adding this code to multiple stylesheets from HL7, HIE vendors, and EMR vendors. So far, it seems to work well for all.

Another solution would be to insert XHTML breaks <br/> into the narrative data. This should be respected by all of the stylesheets used to view CCDs, but in reality older stylesheet versions from HL7 do not always seem to work properly with this solution either. So, many EMR implemented stylesheets, which are based on the older stylesheets, may not work properly with this solution. Furthermore, since the structure portion of the CCD, refers to the unstructured portion for this data, the structured portion will pick-up this XHTML coding inside of the narrative text. That may not work well for some systems that may try display the data in a form other than in HTML.
While there is no perfect solution using the current CDA schema, which would probably require a new version of the CDA that did not have the dependency between the structured sections and the XHTML sections, we have a workable solution, which simply requires some guidance to EMR vendors on upgrading their stylesheets for better document viewing. I'll keep posting updates on this solution as we work with EMR vendors to include it in thier stylesheets of use one that we provide.

Comments

  1. I work for a large health system and we are close to going live with our HIE. However, as we finish our testing, two of our partners' systems can't process/accept CDAR2/HIE 1.0 files that they retrieve from us. For some reason, our file type has changed from urn:ihe:pcc:xphr:2007 to CDAR2/HIE 1.0 in the last month. We use GE Centricity for our EMR and our partners are on Epic. I thought this article might be the answer but it is aimed more at formating. Any suggestions?

    ReplyDelete
    Replies
    1. We had a similar problem a few months back with the same EMR. We changed our logic to create groupings of document types that we want to treat the same. We use the groupings to force the deprication of older CCDs when a new one is posted to the provide and register web service. We also consolidate any document type in the grouping into the on-demand document.

      Delete

Post a Comment

Popular posts from this blog

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR) I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor". The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR. In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between providers This is the primary purpose of the HIE PUSH functionality

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to? There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to? How is this a problem? In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of