[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 was CDA documents containing information, it would be necessary for the mobile app developer to understand the clinical act model of CDA with its act statements, entities, roles, relationships, etc. They would need to be familiar with the specific CDA templates (for example, C-CDA templates) used with the 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 would be expected to directly address areas of ambiguity or over-complexity 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 immediately in favor or FHIR?
Many FHIR advocates would likely argue that this is ultimately what should and will happen. But even the most ardent FHIR advocates would agree that needs 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 and/or whether its popularity will lead to widespread adoption independent of government regulations, incentives, and penalties.
Even setting aside timing and pace of adoption questions, not everyone is of the view that FHIR's purported claim to be capable of replacing any previous HL7 standard is practical, even if theoretically/technically correct. Some would argue that even longer-term, FHIR may ultimately prove to be utilized in the more narrow contexts where it is uniquely well-suited (e.g. APIs for personal health application development) and not in the current use-cases where HL7 messaging or CDA documents currently dominate.
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, C-CDA - the focus for 2015 appears to be in 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
