View source for HL7 FHIR: An Agile and RESTful approach to healthcare information exchange

A review of Bender, D., & Sartipi, K. (2013, June). HL7 FHIR: an Agile and RESTful approach to health information exchange. In ''2013 IEEE 26th International Symposium on Computer-Based Medical Systems (CBMS)'' (pp. 326-331). IEEE.
==Introduction==
The authors note that [[Health information technology|HIT]] [[Interoperability|Interoperability]] is valuable economically, to public safety, and clinically, and state that successful HIT requires it. They note that interoperability requires consistent standards to be implementable and cost effective. Much has been invested in efforts towards interoperability, but compared to other industries, HIT is far behind. [[HL7|HL7]] has been incrementally and iteratively developing a new standard named (FHIR), though, geared toward "usability and fitness for purpose", using "today's industry best practices for complex systems design"<ref name="article">Bender, D., & Sartipi, K. (2013, June). HL7 FHIR: An Agile and RESTful approach to healthcare information exchange. In ''2013 IEEE 26th International Symposium on Computer-Based Medical Systems (CBMS)'' (pp. 326-331). IEEE. http://dx.doi.org/10.1109/CBMS.2013.6627810</ref>.

==Related Work==
This section briefly reviews the scope of other research around the [[HL7|HL7]] standards, namely, HL7v2, HL7v3, and FHIR, and functionally related standards such as [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus (ESB)], [[DICOM]], [http://en.wikipedia.org/wiki/Mirth_Connect Mirth], and others.

==Interoperability Standards in Healthcare==
===Health Level 7 (HL7) ===
This section is an introduction to the organization HL7; its history is briefly covered, as well as its work on standards development.
===HL7 Version 2===
The history and shortcomings of HL7v2 are covered. Introduced in 1989, HL7v2 is an "ad hoc"<ref name="article" /> protocol which is usually customized at the local level and therefore is not readily useful for universal integration; it <nowiki>"lack[s] . . . a formal ontology"</nowiki><ref name="article" />, so meanings of field definitions and terms are not universal and must be negotiated between interface participants.  
===HL7 Version 3===
Six years on, HL7v3 was introduced; it has no backward compatibility with HL7v2 and its operational paradigm is completely different. By comparison HL7v3 is highly complex and difficult to implement; the documentation is dense and reference code examples are nonexistent; the "standards are not directly implementable"<ref name="article" />. HL7v3 is based on HL7's [http://www.hl7.org/implement/standards/rim.cfm Reference Information Model (RIM)], a complex class model describing relationships and interaction among a variety of entities. Because it is intrinsic to HL7v3, thorough knowledge of the model is necessary to implement the standard. Further, the standard presumes only a subset of the model will be used for a given implementation, meaning that there is essentially no chance of a universally-compatible implementation. A number of high-profile and expensive attempts to implement HL7v3 interfaces have failed, according to the authors.
===Representational State Transfer (REST) ===
This section describes REST interfaces. "RESTful architectures" are currently "the dominant information abstraction" of the web due to features of the [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] protocol: HTTP is stateless, meaning it is not designed to maintain idle connections, and is not centralized; hypertext allows for linking any number of a variety of resources together. REST takes advantage of these characteristics in several ways. It uses the existing command methods of the HTTP protocol, uses only stateless transactions, represents information organization like a web server directory structure, and uses [http://en.wikipedia.org/wiki/XML XML] and [http://en.wikipedia.org/wiki/JSON JSON] to represent data structures. Because the data structures are simplified in comparison with heavy models like the HL7 RIM, development of REST interfaces can be done quickly, and software clients can be fairly small and fast, suitable for less-powerful devices with slower or more expensive data connections. As the authors note, "the meaning of the data in an application is defined at a higher level"<ref name="article" />, so that meaning need not be encoded in an application client or in the data stream.
===Agile Methods===
"[http://en.wikipedia.org/wiki/Agile_software_development Agile Methods]" is a set of practices for developing software that focus on user needs, collaboration, and responsiveness to change. By delivering software as soon as it's usable and getting it into the hands of users &mdash; and crucially, by getting and acting on the users' feedback &mdash; the software can be put to the test under real-world conditions right away, and the design of the software can change to conform to real need, instead of being constrained to a potentially flawed interpretation of the need.
==FHIR: Fast Healthcare Interoperability Resources==
FHIR was initiated in response to, among other pressures, HL7v3's failure to gain eligibility for meaningful use funding under the 2009 [http://en.wikipedia.org/wiki/Health_Information_Technology_for_Economic_and_Clinical_Health_Act HITECH Act]. FHIR is being developed using RESTful architecture and existing, popular internet standards.
===FHIR Development Process===
In contrast to the earlier HL7 standards, FHIR is being developed not using the ad-hoc approach of HL7v2 nor the rigid model of HL7v3, but rather the incremental and iterative agile development methods described above. 
===FHIR Artifacts===
This section describes the design philosophy of objects in the FHIR standard. A number of rules or recommendations are presented that aim to establish requirements for object, or resource, attributes. At the time the article was written, 32 of a future expected "approximately 150"<ref name="article" /> resources have been defined in the standard so far. FHIR's resource types can be compared to HL7v3's "Common Message Element Types" but there are substantially fewer defined for FHIR thus far.
===Criticism of FHIR===
The authors note that resource types and communication methods are defined by FHIR, but entity relationships are not; they suggest that this could lead to future problems with interoperability. They point out that "resource aggregations", their associated behaviors, and their relationship to document entities are not yet defined in FHIR. This suggests that the relationship between FHIR and the [[Clinical Document Architecture]] is not well-defined, but the authors are not clear on this point.
===A hybrid approach===
The authors suggest that FHIR takes an ideal approach that bridges a gap between the highly localized HL7v2 development model and the overwhelmingly global HL7v3 model. That said, they express concern that neither the ontology nor the mapping of FHIR entity mapping to the RIM is clearly defined. They question the need for mapping to the RIM because "there are few if any real-world implementations of HL7 v3"<ref name="article" />, suggesting that they feel the usefulness of the RIM is constrained to HL7v3.
==Conclusion==
The authors restate the ground that the article covered. They reemphasize that the standard specification is incomplete but express optimism and confidence that it will provide for improvements in healthcare IT interoperability in future.
==Reviewer Impression==
The article was quite interesting. The sections regarding the history of HL7 standards and describing the technologies and practices being used to specify and implement FHIR are fascinating for their historical and technical content.

However, I found in the latter half of the article, that is, the section entitled "'''FHIR: Fast Healthcare Interoperability Resources'''", many definitions were missing; a vaguely attributed quotation was given without citation; the reasoning was difficult to follow; and as a consequence the conclusions were not particularly convincing. Additionally, the tone of this section seemed overwhelmingly pessimistic and negative toward FHIR, in contrast with the rest of the paper which seemed neutral but optimistic.

In any case, this section was so disjointed in content and tone compared with the clearly-written first half that I concluded that the authors likely did not collaborate closely on the final product.

I ultimately regard this paper as a good overview of the history of HL7 standards and how they have impacted the industry, and also a good introduction to the FHIR standard, but suggest the reader take the second half with a grain of salt.
==References==
<references/>

[[Category:Reviews]]
[[Category:Interoperability]]
[[Category:HIE]]
[[Category:HI5313-2015-FALL]]