Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, June 19, 2012

Convergence: CEDD, CIMI, IHE, FHIR, hData, HL7, mHealh and ONC

How does it all fit together? If you've been following CIMI, HL7's CDA Release 3FHIR, and mHealth Workgroup initiative, ONC's many S&I Framework projects, IHE's mHealth profile and all the other standards activity going on, surely you've run into the problem shown below:

The volume of the information stream coming out of these projects is huge.  Keeping up with all of these projects requires a staff and budget that is much bigger than I have available to me, so I haven't been to all of the meetings, attended all of the calls, or paid attention to all that is going on. But I have managed to understand enough about what is going on to sort of figure out how some of it COULD fit together.

Knowing the history behind things helps.  The S&I Framework CEDD is based in part on the HITSP C154 Data Elements, with a slightly different twist.  That set of data elements comes from various CDA  documents created by HITSP and based on HL7 CCD, and IHE PCC profiles.  Coming out of that same body of work is the CDA Consolidation Guide.  And a good bit of it hearkens back to the HL7 Claims Attachments.

The CIMI work is informed by work in HL7 on Detailed Clinical Models, as well as work in ISO, and in OpenEHR.  Those communities have cross-pollinated pretty well, although you'll find some observers indicate otherwise.  A lot of the CIMI work will, I expect, also be informed by the Intermountain Clinical Element Models, which show a marked influence from CCD and HL7 Patient Care Models.

FHIR will be creating resources for many of the very things that CIMI will be creating "detailed clinical models" for.  What FHIR doesn't cover directly can be covered by it's built-in extension mechanism.  And unlike CIMI and an attention to all the detail, FHIR will only be addressing the most commonly needed or implemented data elements.

On the CDA Release 3 front, Structured Documents has moved away from defining clinical content, in deference to allowing clinically related workgroups in HL7 to use their own models in RIM-based healthcare statements.  They are also moving towards XHTML in content, something which FHIR has already adopted.  An FHIR has a resource aggregation model that supports documents as well as messages and services.  The actual XML for CDA Release 3 is defined by the HL7 XML ITS, but it could be readily transformed to the FHIR format if the R3 Document was sufficiently well-defined.  I expect the most significant efforts of Structured Documents as related to FHIR will be on defining the "document" resource.

On the transport side, we have the IHE mHealth Profile based in part on, and being harmonized with hData.  This profile builds on the IHE XDS Metadata which is presently part of Direct and Exchange.  ONC's RHEx Project also seems to be building from hData.  And finally, FHIR has a RESTful protocol which is also being harmonized with hData.

Fitting it all Together
So we have three streams in which convergence could occur.  On the content side, is how we model clinical information.  CIMI and OpenEHR are building models for that that go into great detail, probably much more detail than many systems know how to deal with today.  This can readily fit into FHIR over time, and is largely compatible with CDA Consolidation efforts given the great deal of cross pollination and common ancestry that has appeared.  I see CDA Consolidation templates being dominant in the near and mid-range future, with movement towards FHIR Resources over the mid- to long-term.

On the document side, it isn't clear whether CDA or FHIR will win out.  I suspect that FHIR will become dominant in the messaging and service space first, before eclipsing CDA in the longer term.

Finally, the RESTful transport will become some variant of hData, with the document model possibly evolving from the IHE mHealth profile and XDS Metadata (being restated a bit more RESTfully).

It's a way it COULD happen.  Your mileage may vary.  However, if we do manage to converge these streams, it could be very powerful.