Understanding FHIR and its Development!
Below is an excerpt from a paper that I wrote for one of my cybersecurity and networking courses in university.
FHIR, or the Fast Healthcare Interoperability Resources, is a data exchange standard that has recently seen much implementation and adoption within the healthcare community. It is a newly emerging international specification that is sponsored by Health Level Seven International (HL7), which is the de facto interoperability standards for data transfer of clinical and administrative data for healthcare providers. Although these standards are not necessarily government sponsored or spear-headed, HL7 rose in a time of need among fragmented healthcare information technology products and worked to provide set of interoperable standards for data transfer, especially among the various vendors of Electronic Health Records (EHRs) (Chinniah & Muttan, 2012). HL7, the parent organization provides a framework and relevant standards for exchange, integration, sharing and retrieval of electronic health information; although they weren’t seen as the go-to interoperability organization due to the fragmented and disjointed EHR vendors on the market, there was a need to formulate a method that would allow for data exchange among different healthcare systems. FHIR makes it attempts to be the next step in the evolution of standards to promote interoperability, and not just adding more standards to an already overburdened system.
Some of the other standards and methodologies that HL7 utilizes are messaging specifications, and an exchange model for clinical document, i.e HL7 v2 and v3. With the advent of FHIR, it brings specifications for medical summaries and overall provides granular data packets that allow for interoperable exchange through different healthcare information technologies. As a result, it no longer transfers entire documents like HL7’s v2 and v3 offered, but now a physician will be able to request just one piece of information instead of multiple fragmented documents. This allows for more efficient workflows because the entire health information exchange allows for a granular data element to be utilized instead of entire documents that will often contain more information that is required and leads to more obscurity and difficulty in isolating the key facts requested (Ahier, 2015). The data standards allow easy sharing of clinical information that can help minimize the effects of isolated and variable healthcare systems (Chinniah & Muttan, 2012). It is the spiritual successor of HL7’s v3 messaging protocol, a protocol that was followed by poor market penetration, adoption, and overall became a failure. As a result, FHIR was developed around the flaws of v2 and v3 in that it was not a complex standard, it utilized small batch code pushes that led to efficient and short development lifecycles, and lastly it became a free implementation tool for people to use (aside from joining HL7). It definitely doesn’t help that HL7 v2 was developed in the late 80’s and continues to see use today. Because of the modern capabilities now, v2 and even v3 faced a lot of additional modifications with additional logic to accommodate for the changes in the base out-of-the-box experience. This led to an explosion of HL7 variants as well as no consistent and “standard” way in data exchanges even for something that was supposed to promote interoperability, which was another factor into the development of FHIR. It desperately needed a better and more modern approach to integration and interoperability for healthcare specific uses (Balachandran, 2015).
FHIR, on the other hand is a newer standard that emphasizes simplicity and flexibility that avoids the difficult learning curve that other interoperability standards i.e HL7 are plagued with and it can leverage modern API technologies for user interface integration. FHIR is composed of reusable “resources” that can be assembled and related into a message or a document. These resources contain a minimum set of data elements that will be used to address different use cases as needed throughout a healthcare setting. These minimum set of data elements allows for “off-the-shelf” interoperability and provides a minimalist approach with simplicity and efficiency that allows for different healthcare organizations to adopt and implement quickly (R. A. Bloomfield, Polo-Wood, Mandel, & Mandl, 2017). Because these resources are granular objects, the implementers and users are able to essentially assemble them together into flexible working systems that can be used for a variety of contexts from mobile phone apps, cloud communications, data security, EHR-based data sharing, and even server communication between large institutional healthcare providers (HL7 Organization, n.d.)! These standards, including HL7, all ride on top of the application layer (layer 7) in the OSI stack meaning it can allow implementers to utilize these resources without the necessity of knowing learning the model and modeling itself in the lower stacks. With all that in mind, FHIR provides a very flexible standard for data exchange and an API for EHRs. Although it may not be pushing technology forward, healthcare information technology is starting to catch up with the other industries in which IT plays a large role in, though there are various reasons, when it comes to technology medicine has always been behind the learning curve or has always been a few steps behind as evidenced by the multiple cybersecurity attacks with ransomware that have occurred in the past two to three years.
Regardless, these software standards and technologies that many have taken for granted in other online industries are finally appearing in healthcare (Munro, 2014). Additionally, FHIR resources require a section that allows for human readability as a base level of interoperability, such that even if the data source itself may not be interoperable between systems, there allows some form of ability to understand and analyze the information that is being exchanged. However, this can pose a security risk because it does display private health information, which has been considered measures in privacy and security with OAuth and OpenID to ensure that there are levels of defense and obscurity before someone is able to intercept these data packets (R. Bloomfield, 2016). With any newer technology especially still as a work in progress, security is a constantly evolving landscape so FHIR does still have its kinks that need to be worked out but it does provide much more security features than v2 or v3 provided. Additionally, by leveraging modern HTTPS based authentication and authorization capabilities, FHIR can effectively be used outside of intra-systems without much more risk. The resources provide a very basic set of structure data that can be utilized and presented it in highly meaningful ways that are conducive towards healthcare provider workflows. The resources are the most basic form that is utilized by FHIR, the reason that FHIR has received much positive acclaim is because of the flexibility in how healthcare systems can bundle these resources together to help formulate documents that are wholly relevant for their purpose in being requested through a series of URLs that are associated with each resource.
FHIR is more than just a standard, it offers tools to assemble and present these resources in a way that can enhance the context or meaning of the information all while making it interoperable and available as needed to provide the most effective care as possible and attempting to help make it more efficient in terms of time and costs. However, FHIR doesn’t have to only be used from the provider’s side of things, it can also be used to add to the patient experience and engagement through creation of innovative applications or cloud-based services that can help remind patients of medications, track simple vital signs and what not! By having the ability to bundle the resources together, the organizations are able to create “documents” that are sent as an ATOM feed (web calls) to be signed, authenticated etc. The messages are another layer above with a collection of resources and documents that can be used to request or respond to behaviors and are event driven. These messages are used to help manage medical records through manipulations of documents or the records (Praxent, 2012) and will typically contain a header, an event type, patient identification, visit identification and many more fields. The messages differ from the documents because messages require a specific trigger event that initiates communication and the sending of a message whereas a document can be generated and requested as needed without a specific situation. The messages themselves are broken up into several message types with even more trigger events associated with each message type, this illustrates just how vast and flexible FHIR can be in the healthcare system, but it also means there can be a slight learning curve in knowing how to correctly apply each one. One downside is that it can become resource and request intensive very quickly especially due to the granular resource model that FHIR utilizes. FHIR is meant to cut down on the unnecessary information that was often included in the larger HL7 messages, however, if that much information does need to be requested, that means vast bundling of various FHIR resources which can make the response potentially freeze up due to the vast amount of processing.
It is important to note that interoperability is something that does occur in the current healthcare environment, however, the interoperable components of medicine are utilizing private APIs to share data with specific applications and these APIs are often resolved for use within the same vendor’s products. An example is a patient is injured and unconscious while on a trip and is sent to a hospital in another city that uses an entirely different electronic health records system, the current medical professionals would not be able to access or even easily request for past medical history or procedures since the information has no way of easily being exchanged because the EHRs could be utilizing two completely different APIs. FHIR could be used to fix this problem by embracing a public API that can offer a unified approach in sharing data with different applications and software products. A public API wouldn’t only be used for EHRs but can essentially be used and applied throughout health IT systems to support value-added services. It helps facilitate data sharing through common APIs and interfacing, but it can also control the amount of information and data that is being presented instead of opening a faucet and receiving a gamut of data, most of which may not necessarily be applicable in a certain use-case.
Some of the technologies that FHIR utilizes are an HTTP-based RESTful protocol, HTML and CSS for more fluid user interface integration, a choice of JSON or XML data representation, more secure authorization with OAuth and XML-based web feeds with ATOM for collections (Munoz et al., 2011)(Munro, 2014). By utilizing popular, modern web technologies, there is not much onboarding time when healthcare systems are bringing on new developers. FHIR has been likened as the “HTML” of healthcare that revolves around clinical care and modeling but does not require experts at implementing its details, it focuses around the ease of implementation. As a result, many hope that FHIR will spread and become a quickly adopted and implemented standard in healthcare. One of the most significant contributions to FHIR is the transition into using the HTTP-based RESTful protocols, which is an architectural framework on how to connect systems and how communication between a front-end interface and backend database will interact. This allows for fast performance, reliability and scalability through reusing resources that are managed and updated without necessarily affecting the system as a whole (Chinniah & Muttan, 2012). Another great feature is support for both XML and JSON, despite the advances in medicine, the technologies that support the clinical practices are more often old than not and using legacy hardware may not support JSON which is why XML is still so widely used in medicine. One thing to note is that the resources are defined in an XML structure, however, FHIR is able to instantiate the responses in XML or JSON depending on what the interface accepts. REST has proven to be useful because it can create a new instance of data that can be manipulated without necessarily changing the original state of that data, this allows for “asynchronous” communication between a user and a server which provides quick and efficient responses (Kramer, 2015).
Though the technical specifics are pushing the boundaries and limits of healthcare information technology, one of the strongest driving forces is the fact that it addresses real needs in the market and it isn’t just another technological concept that never sees the daylight. Aside from the clear benefits towards improving medical care and access, FHIR was built around being able to enable people to make and save money, an ever-increasing public health issue. Though FHIR is still in its early adoption stages, many believe that the impact will help to drive interoperability prices down as an open-source and freely available standard and help raise expectations in regards to the capabilities of healthcare information technology (Quinn, 2014). With the flexibility and efficient access to relevant and accurate data for the providers and patients alike, FHIR has the potential to bring about needed changes in how medicine is provided.
Ahier, B. (2015). FHIR and the future of interoperability | Healthcare IT News. Retrieved March 27, 2017, from http://www.healthcareitnews.com/news/fhir-and-future-interoperability
Balachandran, M. (2015). Introduction to FHIR | The Datica Academy. Retrieved March 27, 2017, from https://datica.com/academy/introduction-to-fhir/
Bloomfield, R. (2016). Implementing SMART on FHIR at Duke Health SMART / FHIR at Duke.
Bloomfield, R. A., Polo-Wood, F., Mandel, J. C., & Mandl, K. D. (2017). Opening the Duke electronic health record to apps: Implementing SMART on FHIR. International Journal of Medical Informatics, 99, 1–10. https://doi.org/10.1016/j.ijmedinf.2016.12.005
Chinniah, P., & Muttan, S. (2012). HL7 standard based Hospital Information System. International Journal of BioSciences …, 5(7), 32–39. Retrieved from http://search.ebscohost.com/login.aspx?direct=true&profile=ehost&scope=site&authtype=crawler&jrnl=09743987&AN=79346354&h=5foVhfnT2wZMcoGVcfUiObkDaWhmMTksvb7klv0D1qbiAkVXp%2B1r8aUwJi%2Fi5TsZHBeNaAK4p5%2Bb%2FHZU77mluw%3D%3D&crl=c
HL7 Organization. (n.d.). Summary – FHIR v3.0.0. Retrieved March 27, 2017, from http://www.hl7.org/implement/standards/fhir/summary.html
Kramer, E. (2015). FHIR DevDays 2015 – introduction to FHIR. Retrieved March 27, 2017, from https://www.slideshare.net/ewoutkramer/fhir-devdays-2015-introduction-to-fhir
Munoz, J., Low, T. Y., Kok, Y. J., Chin, A., Frese, C. K., Ding, V., … Heck, A. J. R. (2011). The quantitative proteomes of human-induced pluripotent stem cells and embryonic stem cells. Molecular Systems Biology, 7(550), 1–13. https://doi.org/10.1038/msb.2011.84
Munro, D. (2014). Setting Healthcare Interop On Fire. Retrieved March 27, 2017, from https://www.forbes.com/sites/danmunro/2014/03/30/setting-healthcare-interop-on-fire/#1de9c9cff2ba
Praxent. (2012). HL7 MDM Message–Medical Document Management – Corepoint Health. Retrieved March 27, 2017, from https://corepointhealth.com/resource-center/hl7-resources/hl7-mdm-message
Quinn, J. (2014). Introduction to FHIR. HL7 International. Retrieved from http://gforge.hl7.org/svn/fhir/trunk/presentations/20