Working with multiple standards for Health

I've been doing some reconsidering over the summer about the existing profiles and use of health standards in Canada, standards like HL7 v2, v3 and CDA. Primarily, v2 is used for ADT (Admission, Discharge and Transfer), but that's a huge chunk of workflow. The reason HL7 v2 is used so pervasively in Canada is because the clinical systems in use in hospitals (Cerner, Epic, Meditech, etc) use v2. At the time the current blueprint for electronic health record adoption was planned, there was an expectation that the U.S. would undergo a process of migration to HL7 v3, and that never happened, and this has left us with a foundation built around HL7 v3 Messaging and its core principles, with a thick transformation layer between this foundation and clinical systems in hospitals.

Obviously, this creates a space of impedance mismatch where continuity of service is put at risk. As a way of mitigating this risk, v3 Messaging is augmented with a companion specification, CDA, the Clinical Document Architecture, which promises to supports health documents like Continuity of Care, Health Questionnaires and Care Plans, as well as business cases using CDA to handle data in migration. Again, in the U.S., HL7 CDA has been used as an alternative to v3 Messaging to support exchange of health information, and in Canada we may benefit from following that path, but if we do, we should be aware that this path is probably morphing as we speak into a thing called "C-CDA using HL7 FHIR XML".

As discussed here and elsewhere, FHIR is a successor standard to all three HL7 standards, providing support for JSON and REST which have not been previously available, as well as the ability to essentially re-implement CDA using a similar XML standard. FHIR has a lot of potential in Canada and abroad in order to enable mobile health applications, but in order to design an build these applications, we need to reconsider the iEHR architecture on which we are currently building.

To that end, I have a number of suggestions:

1. Foster communication between systems using like standards: for instance, we have invested substantially in communicating clinical information between clinical systems in hospitals and the foundation layer of Labs, Pharmacies and Diagnostic Imaging; but can we find quick wins through improved intercommunication amongst the domains in the foundation, or between the enterprise systems that use v2 natively?
2. Create an adaptation layer supporting lightweight secure access: this is where FHIR may play a part, used to expose high value information across the enterprise. The danger in providing an incomplete picture is that people will take it for a complete picture; because FHIR is rooted in extension, composition and aggregation, it may provide a way to build a fuller picture of longitudinal patient information.
3. Registries like Provider, Client and Location should provide more comprehensive Identity Assurance; again, this really means removing continuity gaps within the services available to a patient, thus providing the history of interactions which is a necessary part of guaranteeing identity.
4. Create an application layer that supports developing mobile and web applications that can connect directly to the resources exposed in step 2.

This last step is what I have been reconsidering. As a document standard, CDA has had some success as a technology for mobile health in the U.S., under the auspices of Meaningful Use; however, a mobile health application built to natively use HL7 FHIR JSON and XML, even during the early adoption phase, would still be a solid target for reuse, and it is this capability for reuse that I find compelling, more than using HL7 FHIR to build new registries, repositories, or even greenfield projects. Simply put, if you build a health app using HL7 FHIR as an interface specification, you may still need to perform server side adaptation, but more than likely you would anyway. The benefit from doing so is that you are constructing a stationary target, and that is invaluable.