[Category: Resources & Organizations; Original Post: 06-Feb-14]Fast Healthcare Interoperability Resources (FHIR, pronounced "fire"), is an emerging standard from HL7 that defines a RESTful web services for accessing similar information (although potentially even broader in scope) to that found in a CDA document.
Details about FHIR are outside the scope of CDA PRO at this time, and readers interested in learning more about FHIR would do well to start on the official HL7 FHIR documentation site.
The remainder of this article presents some aspects of FHIR from the perspective of those who, like most CDA PRO Knowledge Base readers, are currently involved with CDA and C-CDA implementation projects. The material below sacrifices technical precision and completeness and engages in some over-simplifications, to allow it to focus on a few key general concepts.
CDA and FHIR
FHIR is very flexible in terms of what it can represent. For purposes of the remainder of this article, we will assume that FHIR is being used to represent the same information that would normally be contained in a CDA or C-CDA document - although FHIR can be used more broadly.
CDA defines an XML representation for a complete clinical document.
FHIR defines APIs for access to information that could potentially be an entire document, but is more likely to be a granular subset (e.g. the equivalent a specific CDA section or even specific clinical acts).
Relative to CDA, FHIR is intended to be significantly simpler to understand and use for basic use-cases. For example, consider someone writing a mobile application for tracking an individual patient's medication.
If the input to that application is CDA documents, the mobile app developer needs to understand the clinical act model of CDA with its act statements, entities, roles, relationships, etc. They would need to be familiar with the CDA templates (for example, C-CDA templates) used with the specific CDA documents, sections, and entries to be processed. There might be significant variance in how medication entries might be presented and related to other clinical act statements.
With FHIR, the experience would be much closer to what the mobile app developer would intuitively expect in terms of using an API where the patient is identified and API call requests are made to retrieve their medication information. The RESTful API of FHIR with it's JSON formatted API call return data would be much more aligned with what a modern web/mobile application developer would want to work with, relative to XML parsing/processing required with CDAs. Finally, as FHIR was driven largely by lessons learned from the evolution and adoption challenges of CDA, it will likely address areas of ambiguity or over-complexity in CDA, to better achieve suitability to task for the mobile app developer's needs.
To learn more about the relationship of CDA, C-CDA and FHIR readers are directed to two resources"
Why Bother With CDA?
If FHIR is easier, more modern, and capable of representing everything in a CDA document and more - why not abandon CDA in favor or FHIR?
Many FHIR advocates would likely argue that this is ultimately what should and will happen. However, even they would say that this would need to be a gradual process. For all its relative complexity and oft-discussed shortcomings, CDA is a well-established standard supported by hundreds of commercial software products and thousands of provider-specific contexts. In the US, C-CDA has been mandated (with extensive financial incentives and possibly upcoming financial penalties) in Meaningful Use.
FHIR is still in development. It is not expected to be a finalized standard until at least 2016, and it remains to be seen if/when it will receive regulatory backing in the US and/or whether its popularity will lead to widespread adoption independent of government regulations, incentives, and penalties.
FHIR is intended to address all three primary paradigms of HL7 interoperability standards - messaging (as in HL7 v2 messaging), documents (as in CDA), and API calls (introduced in FHIR). In use-cases best suited to the API paradigm (like the personal mobile application scenario above), FHIR addresses a need not currently being met by established standards. Its path to adoption there is likely to be less challenging than the possible path to succeeding HL7 v2 and/or CDA - where there is thus more debate about FHIR's destiny.
Project Argonaut
In December of 2014, a consortium of leading EHR vendors, standards organizations involved with CDA and FHIR, and others - gathered to kick-off the "Argonaut Project" to help accelerate the practical adoption of FHIR. As outlined in the Argonaut Project Charter, a strong emphasis was placed in the agenda on completing the definition of FHIR specifications that allow FHIR to be used to convey the information mandated by MU2 for inclusion in C-CDA documents.
Thus, while the initial work on FHIR foused on use cases (such as PHR access) that were adjacent to those of CDA and C-CDA - an important focus in 2015 for those working on FHIR appears to be ensuring it is capable of addressing the core MU2 C-CDA use cases.
An Evolving Dynamic
This article will continue to be periodically updated as the market dynamics around FHIR and C-CDA evolve.
Other CDA PRO Know Articles Referenced In This Article
