FHIR: meet #CDA

CDA (Clinical Document Architecture) is undeniably the most successful HL7 version 3 standard. It’s being used very widely around the world for representing clinical data, and is one of the core standards for many jurisdictions – like Meaningful Use in the US. Obviously, if FHIR is to succeed, then it needs to have some way of doing what CDA does now (and including all the good thinking that has gone into CDA).

Another reason to start thinking about CDA is that the next FHIR connectathon at the January Working Group Meeting next year is going to have FHIR documents as one of the themes, so it makes sense to start thinking about how this all works.

However, before we start to think about FHIR does CDA, let’s take a step back and think about the overall ‘patterns’ we use when moving Health Care data around – we can think of these as ‘paradigms of exchange’ (a term coined by Grahame Grieve I think).

We can think of 4 distinct paradigms:

  • REST services, which have been the majority of what we’ve talked about thus far. These are useful for light-weight, real-time exchanges, and have become almost ubiquitous on the web for access to large, shared systems like Facebook, Twitter and Google.
  • Messages. These are intended to ‘transfer state’ between applications – e.g. when a PAS (Patient Administration System) wishes to inform other applications within the enterprise that a patient has been admitted. Once the recipient system/s have been updated, then the message can be discarded (other than for audit purposes).
  • Documents are intended to convey a summary at a point in time – generally a clinical summary. For example a Discharge Summary from a Hospital or a Referral from one provider to another. A Document is intended to be stored indefinitely.
  • Other Services (which can be REST or SOAP) which are also real-time interactions (generally) but where there is more significant business logic that should be performed by the server (and we’ve talked about a few possibilities in the context of our XDS discussions).

FHIR is intended to be used across all these paradigms, re-using the resources that contain the content and Documents are no exception. (btw Rene Spronk has an excellent  post that goes into more details about Messages vs Documents)

So what is a document? Well, CDA defines the following characteristics of Documents (thanks to Bob Dolin):

  • Persistence. A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.
  • Stewardship. A clinical document is maintained by a person or organization entrusted with its care.
  • Potential for authentication. A clinical document is an assemblage of information that is intended to be legally authenticated.
  • Wholeness. Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
  • Human readability. A clinical document is human readable.

The FHIR representation of a document is actually quite simple:

  • It is a collection of all the resources that make up the document contents (strictly it can just reference those resources, but we’ll come to that)
  • The resources are contained in a bundle (atom feed) that has a specific tag (http://hl7.org/fhir/tag/document)
  • There is a specific resource – the composition resource that contains the ‘header’ information about the document – quite similar in fact to the DocumentReference that we are already familiar with. The composition establishes the ‘context’ of the document – what, why, when and who.

And that’s about it!

Ok, maybe there’s a bit more to be said….

Another way to think of a FHIR document is that it is like an object graph, rooted in the composition resource, with all the resources linked together by the various resource references between them. And this visualization shows how the references that comprise the resources can either be located within the bundle, or stored remotely with a reference to it in the document – wherever makes sense. However, most times including them in the bundle is going to be the simplest way to represent a document, and it does make signing easier.

The following diagram shows how you could have a simple document – maybe a clinical note and a list of medications. The document also contains the author and the patient (subject).

fhir document (2)

Some notes about this diagram:

  • The composition is the ‘starting point’ of the document. It is directly analogous to the CDA header.
  • The ‘subject’ and ‘author properties of the composition point to a Patient and a Practitioner resource respectively.
  • The ‘notes’ section is represented by a reference to an Observation resource
  • The ‘medications’ section points to a List resource, that in turn points to a couple of medication resources. (There’s actually a wee bit more complexity about medications – but that can wait for another post).

The following diagram shows how the example would appear as a real XML document.


<feed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.w3.org/2005/Atom">
    <title>A sample FHIR document</title>
    <id>urn:uuid:500bee81-d973-4afe-b592-d39fe71e38</id>
    
    <updated>2013-05-28T22:12:21Z</updated>     <!-- Time the bundle was built -->
    <!-- Author is required by the Atom spec. FHIR doesn't use it-->
    <author>
        <name>Doctor Dave</name>
    </author>
    <!-- This tag specifies unambu=iguously that this is a FHIR document bundle -->
    <category  term="http://hl7.org/fhir/tag/document" scheme="http://hl7.org/fhir/tag" />

    <entry>
        <title>Progress note for Patsy Pregnant by Doctor Dave</title>
        <!-- the 'cid' protocol means this is a new composition -->
        <id>cid:1046bb61-c258-44e5-96a5-a5bae6b180fe@orionhealth.com</id>
        <updated>2013-05-28T22:12:21Z</updated>
        <content type="text/xml">
            <Composition xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Progress note...</div>
                </text>
                <instant value='2013-06-06T12:30:00'/>  <!-- the time this document was created -->
                <!-- What type of document is this - eg Discharge Summary, referral, Consultation note -->
                <type>
                    <coding>
                        <!-- Using an XDS system? hmmmm... -->
                        <system value='http://fhir.org.nz/xds#documentType'/>
                        <code value='pn'/>
                        <display value="Progress Note"/>
                    </coding>
                </type>
                <status value="final"/>
                <confidentiality>
                    <system value='http://fhir.org.nz/xds#confidentiality'/>
                    <code value='n'/>
                    <display value="Normal"/>
                </confidentiality>
                <!-- Who the document is about. The patient with the ID of sample -->
                <subject>
                    <reference value='http://hl7.org.nz/fhir/Patient/patsypregnant'/>
                    <display value="Patsy Pregnant"/>
                </subject>
                <author>
                    <reference value='http://hl7.org.nz/fhir/Practitioner/drdave'/>
                    <display value="Doctor Dave"/>
                </author>
                <!-- The document sections - the observation and the medication list -->
                <section>
                    <content>
                        <reference value='cid:100@orionhealth.com'/>
                        <display value="Clincial Observation"/>
                    </content>
                </section>
                <section>
                    <content>
                        <reference value='cid:110@orionhealth.com'/>
                        <display value="Medication List"/>
                    </content>
                </section>
            </Composition>
        </content>
    </entry>

    <entry>
        <title>The clinical note</title>
        <id>cid:100@orionhealth.com</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <Observation xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">This is a record of my consult...</div>
                </text>
                <name>
                    <coding>
                        <system value='http://fhir.org.nz/xds#obsType'/>
                        <code value='pn'/>
                        <display value="Progress Note"/>
                    </coding>
                </name>
                <status value="final"/>
                <reliability value="ok"/>
                <!-- All the other details of the Observation (ie progress note) here -->
            </Observation>
        </content>
    </entry>

    <entry>
        <title>The medication list</title>
        <id>cid:110@orionhealth.com</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <List xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Current list of medications</div>
                </text>
                <mode value="working"/>
                <entry>
                    <item>
                        <reference value='http://hl7.org.nz/fhir/MedicationPrescription/medsample1'/>
                        <display value="Medication 1"/>
                    </item>
                </entry>
                <entry>
                    <item>
                        <reference value='http://hl7.org.nz/fhir/MedicationPrescription/medsample2'/>
                        <display value="Medication 2"/>
                    </item>
                </entry>
            </List>
        </content>
    </entry>
    
    <entry>
        <title>Medication1</title>
        <id>http://hl7.org.nz/fhir/MedicationPrescription/medsample1</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <MedicationPrescription xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Medication 1</div>
                </text>

                <!-- All the other details of the Medication here -->
            </MedicationPrescription>
        </content>
    </entry>

    <entry>
        <title>Medication2</title>
        <id>http://hl7.org.nz/fhir/MedicationPrescription/medsample2</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <MedicationPrescription xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Medication 2</div>
                </text>
                
                <!-- All the other details of the Medication here -->
            </MedicationPrescription>
        </content>
    </entry>

    <entry>
        <title>The subject of the document - Patsy Pregnant</title>
        <id>http://hl7.org.nz/fhir/Patient/patsypregnant</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <Patient xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Patsy Pregnant</div>
                </text>
                <!-- All the other details of Patient here -->
            </Patient>
        </content>
    </entry>
      
    <entry>
        <title>The document author - Doctor Dave</title>
        <id>http://hl7.org.nz/fhir/Practitioner/drdave</id>
        <updated>2013-05-28T22:12:21Z</updated>
        
        <content type="text/xml">
            <!-- Sample content only -->
            <Practitioner xmlns="http://hl7.org/fhir">
                <text>
                    <status value="generated"/>
                    <div xmlns="http://www.w3.org/1999/xhtml">Doctor Dave</div>
                </text>
                <!-- All the other details of Practitioner here -->
            </Practitioner>
        </content>
    </entry>

</feed>

Notes:

  • This is the bare minimum required for the document to validate – which it does at the moment – in real life there’s a lot more that would be needed if it is to make sense to the recipient
  • All of the codes are made up
  • The reference are all consistent (or should be) but they don’t point to ‘real’ resources
  • Not all of the resources have a text element – and they should
  • All the resources are included in the bundle
  • Most of the resources are new resources (they have an ID that starts with ‘cid:’) with the exceptions of the medications, subject and author, which already exist

Well, that’s all for this post (overly long as usual). There’s a ton of other stuff to talk about, like:

  • The details of the composition resource – looks kind of important.
  • What’s the difference between referencing an existing resource, and creating a new one in the document? And what if I want the server to store that new resource outside of the document (Like a new Condition)?
  • How does the DocumentReference resource relate to this?
  • How do you render the document text?
  • How should I store a document?
  • Are there recommendations for moving documents around?
  • How can you extract resources from the document to update a local repository?
  • Where do contained resources come into this?
  • How do I update a document?
  • How I choose between referencing the content resources over just referencing them? (hint: do you think versions are important?)
  • How can I sign a document?
  • What about CCDR (Consolidated CDA),CCD and CCR?
  • And then there are CDA templates…
  • How would you convert between CDA and FHIR documents?
  • Will FHIR documents replace CDA, or is there another possible future?

To be continued…

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

7 Responses to FHIR: meet #CDA

  1. Josh Mandel says:

    Quick comment about the language you use to describe FHIR REST vs. “Messaging”:

    You write that messages “are intended to ‘transfer state’ between applications.” Well okay, but “state transfer” is exactly the purpose (and build into the acronym) of REST, too!

    In my view we should think of FHIR’s REST API as the default, simple, straightforward, well-understood way to transfer state.

  2. Messaging works well when you need to do more than a simple “update” – i.e. you need a more “tuned” service. REST is also typically real-time, while Messaging isn’t necessarily. Messaging allows more complex behaviors (e.g. update mode rather than snapshot). Messaging typically places more responsibility on the server than on the client in terms of what actually gets changed and how.

    Not exactly concise, but I think those are the main differences.

  3. Pingback: Saying ‘No’ with FHIR: The List resource | Hay on FHIR

  4. Your HISO's on FHIR says:

    If it can’t be easily defined perhaps it’s time to abandon the messaging paradigm. FHIR and messaging is really only one for the completists.
    I would also ditch the services paradigm. The resources paradigm, with documents as a complex resource, are where the efforts should be focussed – and that seems to be what’s happening.
    (On the other hand, if you wanted more paradigms, then what about CICS FHIR or CODASYL FHIR or any number of awful things.)

  5. dattachandan says:

    Thanks for this helpful overview post David.

    I am looking at it more from an implementer’s eye.

    The FHIR example and the analogies to CDA described in the article are helpful. It would be helpful to see what would be the equivalent CDA document from this FHIR resource representation.

    Also I see that there’s a wide range of tools for validation both for FHIR and CDA. I am keen to implement automated mappers between the two formats. I see the validation business rule as an inverse transform of the mapping process that a translator block in a ESB has to implement. What do you think are the challenges to this? Why are there no mapping tools available that can take advantage of the schema+schematron validation rules in both the FHIR and CDA representations and convert between these two formats seamlessly. For example, the AU NEHTA CDA has these schematron validators defined for the Diagnostic_Imaging_Report CDA (https://www.digitalhealth.gov.au/implementation-resources/ehealth-reference-platform/clinical-documents-integration-toolkit). I think there are schematron validators for FHIR as well (not for this particular document type maybe).

  6. Pingback: Simple Builder: Library and Documents | Hay on FHIR

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: