Background
In today’s modern healthcare delivery landscape, information is power. With the advent of Big Data, wearable technologies, and precision medicine, people and organizations are collecting and creating health information at an ever increasing rate. “Convergence of digital health interoperability, wireless sensors, imaging technology and genomics will transform the way that healthcare is practiced, its efficiency and effectiveness” (Benson & Grieve, 2016). In other words, people are collecting more health data than ever before which can lead to better, and qualitatively different, healthcare.However, all of the information in the world cannot improve healthcare if it cannot be accessed in a meaningful way by those who need it when they need it. The Office of the National Coordinator for Health Information Technology (ONC) argues that “there is much work to do to see that every individual and their care providers can get the health information they need in an electronic format when and how they need it to make care convenient and well-coordinated and allow for improvements in overall health” (Office of the National Coordinator for Health Information Technology, 2014). As we stand now, patients and physicians are not able to consistently or conveniently access relevant health information at the point of care. And this is not only the case when a patient is visiting a new facility: “even across the systems within an organization, interoperability is often awkward and slow.” (Committee on Engaging the Computer Science Research Community in Health Care Informatics; National Research Council, 2009).
To address this, we look to interoperability – getting the right information to the right person when they need it, regardless of where or how it is stored. “Modern healthcare depends on teamwork and communication. Interoperability is needed to provide information when and where required, facilitate quicker and more soundly based decision making, reduce waste by cutting out repeated work and improve safety with fewer errors” (Benson & Grieve, 2016). In other words, interoperability gives us hope that through information we can improve the quality of health care while reducing costs.
At its core, interoperability is getting data from one place and putting it in another. For example, there are several home cholesterol measuring devices on the market. Some of these can upload your readings to your smartphone using Bluetooth, which allows you to easily track your cholesterol levels over time and empower you, the patient, with information. You could even share your readings with your doctor to help them better manage your care. Moving this data from one software platform, such as an app on your phone, to another, such as your electronic medical record (EMR), is the heart of interoperability.
Unfortunately, getting your readings to your doctor might not be as easy as it seems like it should be. Your doctor probably uses an EMR which is able to store your cholesterol readings in one easy to access place. But what if your cholesterol tracker only measures your total cholesterol – an amalgam of your HDL, LDL, and triglycerides? Your doctor’s EMR might only be able to store these values as their individual components – how should your total cholesterol be allocated between the three? Should your measurements perhaps be recorded in a free text field? While free text might make a convenient catch-all solution, “using unstructured data limits the use of computer aided applications” (Topaz, et al., 2016). For example, if a future doctor runs a report on your HDL values, will they think there are no cholesterol measurements available because the HDL fields are empty? Or, worse, will they make clinical decisions based on inaccurate guesses of what your HDL values were thought to have been?
This brings us to the observation that electronic health information is “not sufficiently standardized to allow seamless interoperability, as it is still inconsistently expressed with vocabulary, structure, and format, thereby limiting the potential uses of the information to improve health and care.” (Office of the National Coordinator for Health Information Technology, 2014). That is, data stored in one place doesn’t always mean the same thing when stored in another. For example, the term “cholesterol” might mean different things across different software platforms. The Office of the National Coordinator (ONC) goes on to assert that an important building block on the path to constructing an “interoperable health information infrastructure” is developing “core technical standards” for terminology and vocabulary (Office of the National Coordinator for Health Information Technology, 2014). If total cholesterol, for example, is defined in a specific and consistent manner across different technology platforms, the information is more portable. It can move easily and without ambiguity between platforms.
FHIR
Several efforts have been made over the years to introduce an industrywide interoperability standard. Health Level Seven International (HL7), for example, has developed data standards which are “widely accepted and implemented broadly” (Kasthurirathne, Mamlin, Kumara, Grieve, & Biondich, 2015). Broad adoption of a standard is an important feature if it is to lead to interoperability – it’s easy to bring information together if people already agree on its structure and format. HL7 version 2 was released in 1989 and “met with widespread acceptance and adoption,” although it was rough and needed revision, in particular needing a more consistent design (Kasthurirathne, Mamlin, Kumara, Grieve, & Biondich, 2015). HL7 version 3 attempted to fix this in 2005, but in the process created an complex, overambitious, difficult to use standard (Kasthurirathne, Mamlin, Kumara, Grieve, & Biondich, 2015). Nothing to date has enabled the uniform seamless transfer of health information that would so greatly benefit health care systems in the United States and worldwide.In an effort to address these shortcomings and develop a useful and widely-adopted standard, HL7 created the Fresh Look Task Force in 2011 (Mandel, Kreda, Mandl, Kohane, & Ramoni, 2016). From this emerged the Fast Healthcare Interoperability Resources (FHIR) data standard, created by Grahame Grieve and then transferred to HL7 in March 2012 (Brull, 2013). “HL7 Fast Healthcare Interoperability Resources (FHIR) is an emerging open standard for the exchange of electronic healthcare information” (Solbrig, et al., 2017). In other words, FHIR has the potential to become this sorely needed core technical standard identified by the Office of the National Coordinator (ONC).
In FHIR, “the HL7 version 3 standard was totally overhauled, with the developer in mind.” (Marcheschi, 2016). In other words, FHIR was developed by looking at what third parties had and were making and then building a data standard around that (Grieve, 2017). “Despite being derived from HL7 version 3 semantic, which has been acknowledged inadequate acceptance (sic) by vendor community, it promises fast implementation by software developers” (Marcheschi, 2016). FHIR was built by learning from past mistakes and building on past knowledge in order to promote adoption of the standard by software developers and technology companies.
Towards this end, “FHIR aims to reduce implementation complexity without sacrificing information integrity.” (Kasthurirathne, Mamlin, Kumara, Grieve, & Biondich, 2015). That is, it is a robust standard which is built on high standards of quality, not merely popularity of use. And, as it is an open standard published by Health Level Seven International (HL7) under a Creative Commons license, anybody is free to use it as part of their personal or commercial software. The FHIR data standard offers us hope of interoperability by creating a robust, open source platform for software developers to create linkages between different information silos.
An important component of linking data stored in different places are pieces of software called Application Programming Interfaces (APIs). APIs enable data to be transferred from one software platform to another. Using APIs as a conduit, we can theoretically build vast interoperable software networks empowering doctors and patients with information. However, if data is not standardized – if it doesn’t mean the same thing in different places – APIs are of limited utility.
FHIR was designed from the ground up with APIs in mind. Specifically, FHIR has aimed “to follow RESTful principles as much as possible” (Benson & Grieve, 2016). The RESTful paradigm is “a set of design constraints, methods, and architectures that leads to scalable, reliable, easy to use interfaces” (Benson & Grieve, 2016). Many popular internet APIs are RESTful, including Google, Twitter, and Facebook (Benson & Grieve, 2016). FHIR’s embracing of RESTful API practices is just one example of how FHIR was designed keeping software developers and the large-scale exchanging of data in mind.
To illustrate the utility of a FHIR based API, Kasthurirathne et. al. built an API which enabled the movement of data between the Substitutable Medical Apps and Reusable Technology (SMART) Growth Chart App, which used FHIR data standards, and OpenMRS, which did not. The resulting FHIR API acted as a crosswalk, extracting OpenMRS data and converting it to use FHIR standard data definitions. SMART Growth Chart App was then able to use this OpenMRS data to build charts tracking a child’s growth. This successful implementation “highlighted the value of moving towards a domain independent and standards based API that supports interoperability as part of the core OpenMRS architecture and how doing so significantly reduced the time and effort required to support standardized data exchange” (Kasthurirathne, Mamlin, Kumara, Grieve, & Biondich, 2015). The authors’ conclusions were that replacing OpenMRS’s legacy API with a FHIR API made it easier to construct data exchanges with other software platforms, and that this should be OpenMRS’s first step towards fully adopting FHIR data standards.
Another strength of FHIR is its extensibility. FHIR can be easily extended because it “defines a collection of ‘resources’ that ‘can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives.’” (Solbrig, et al., 2017). In other words, if FHIR does not yet meet their data needs, third party developers can extend FHIR by creating new resources which can be readily integrated into the FHIR corpus. For example, Hochheiser et. al. wanted to use a FHIR data model to study cancer phenotypes. Cancer phenotype data resources had not yet been defined in FHIR, but the researchers were able to build “the extension of FHIR resources to model cancer concepts such as tumors, as necessary for the required multi-level representation of cancer phenotypes” (Hochheiser, Castine, Harris, Savova, & Jacobson, 2016). In other words, the researchers were themselves able to build the cancer phenotype resources that they needed and consequently extended FHIR’s functionality.
Going Forward
FHIR is under active development as a powerful new tool towards achieving interoperability. However, it is not there yet. The creator of the original FHIR draft standard and active leader in its ongoing development, Grahame Grieve, estimates that a full electronic health record (EHR) product is still 18 months away (Grieve, 2017). There are important features not yet in production, such as prescription medication interactions (Grieve, 2017).The Argonaut Project was launched in 2014 to help address these gaps (Miliard, 2017). It’s an initiative by private sector companies to “advance industry adoption of modern, open interoperability standards” (Health Level Seven International, 2017). It aims to “rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology based on Internet standards and architectural patterns and styles” (Health Level Seven International, 2017). In other words, healthcare information companies are coming together to promote the FHIR standard towards the industry goal of interoperability. Industry leading companies are participating in this project including Epic, athenahealth, McKesson, Beth Israel Deaconess Health System, and Boston Children’s Hospital (Miliard, 2017). Since it is an Open Source standard, any entity can adopt and extend FHIR for private or commercial uses, so long as they remain within the terms of HL7’s copyright.
As the copyright holder, HL7 has an interest in promoting the adoption of FHIR as an industry standard. Towards this end, they encourage the extension of the standard by third parties to better suit their particular needs, so long as one of two conditions are met. The first condition allows third parties to opt to share their extensions with HL7 and incorporate them into FHIR standard. If they choose to do this, they must supply HL7 with “a written release of unrestricted world rights to use a specification as the basis for development of an HL7 Protocol Specification” (HL7 Governance and Operations Manual, 2017), meaning that the extensions will be governed by HL7 copyrights and regulations going forward and ergo be made freely and publicly available as part of FHIR. Alternatively, If the third party does not opt to share their extensions, they must mark “any additions, omissions, or other modifications to the HL7 Protocol Specifications” and make sure they are “clearly identified to end-users” (HL7 Governance and Operations Manual, 2017). In other words, they can create, use, and sell privately developed extensions, but they must clearly display to end-users that these changes are not part of the FHIR standard. These conditions are in place to preserve the integrity of the FHIR standard and to enable HL7 to maintain its position as “an official source of the most current and accurate versions of the HL7 Protocol Specifications” (HL7 Governance and Operations Manual, 2017). Data standards lose their utility if their specifications are not publicly available in a centralized location.
While these governance protocols are well-intended to maintain the integrity of the FHIR standard, they might not go far enough. Paolo Marcheschi points out that “the extensions have also a downside because the danger is to have a lot of different extensions implemented in different ways, by different organizations.” (Marcheschi, 2016). And Mandel et. al. agrees by pointing out that “diverse organizations may produce incompatible profiles that lead to fragmented semantics and serious interoperability challenges” (Mandel, Kreda, Mandl, Kohane, & Ramoni, 2016). For example, a large company could hypothetically adopt the use of FHIR in its health information products. It would then likely want to extend the standard to better suit its own needs, which it would be required to mark to the end-users as separate from the FHIR standard, as designated in the HL7 Governance regulations. However, this company would be under no obligation to ever integrate these extensions into the FHIR standard and, without this check, the two data standards would gradually diverge. At scale, with every large player extending FHIR in an effort to differentiate itself, the FHIR implementations could potentially become incompatible over time, and any interoperability progress would be lost.
The FHIR community is aware of this. It is recognized that “with respect to semantic fragmentation, community consensus for FHIR profiles will be key for the successful deployment of substitutable apps.” (Mandel, Kreda, Mandl, Kohane, & Ramoni, 2016). That is, people and a strong community are the key to create an interoperable data platform which does not diverge over time. Grahame Grieve puts it eloquently when he says, “The rocket science is not building the software. The rocket science part is building a community around the software. First comes community, and second is the technology standard” (Grieve, 2017).
“Advanced precision medicine and oncology applications need more than ever, simple and immediate solutions that we can implement right away leveraging actual standards” (Marcheschi, 2016). Together, we can work to become the change the healthcare industry so desperately needs. We can rally behind FHIR, a standard where interoperability and the enabling of technology is a foundational value.
Works Cited
Benson, T., & Grieve, G. (2016). Principles of Health Interoperability: SNOMED CT, HL7 and FHIR (3rd ed.). London: Springer-Verlag.
Brull, R. (2013, Mar 26). 5 Things to Know About HL7 FHIR. Retrieved Apr 6, 2017, from Health Standards: Expanding Conversation on Healthcare Technology: http://healthstandards.com/blog/2013/03/26/hl7-fhir/
Committee on Engaging the Computer Science Research Community in Health Care Informatics; National Research Council. (2009). Computational Technology for Effective Health Care: Immediate Steps and Strategic Directions. (W. W. Stead, & H. S. Lin, Eds.) Washington, DC: The National Academies Press.
Grieve, G. (2017, Apr 7). Inventor of FHIR and FHIR Product Director at HL7. (A. McCollam, Interviewer)
Health Level Seven International. (2017, Feb 27). Welcome to the Argonaut Project. Retrieved Apr 12, 2017, from Argonaut Wiki: http://argonautwiki.hl7.org
(2017). HL7 Governance and Operations Manual. Health Level Seven International. Ann Arbor, MI: Health Level Seven International.
Hochheiser, H., Castine, M., Harris, D., Savova, G., & Jacobson, R. S. (2016, Sep 15). An information model for computable cancer phenotypes. BMC Medical Informatics and Decision Making, 16(121).
Kasthurirathne, S. N., Mamlin, B., Kumara, H., Grieve, G., & Biondich, P. (2015, Oct 7). Enabling Better Interoperability for Health Care: Lessons in Developing a Standards Based Application Programing Interface for Electronic Medical Record Systems. Journal of Medical Systems, 39(182).
Mandel, J. C., Kreda, D. A., Mandl, K. D., Kohane, I. S., & Ramoni, R. B. (2016, Feb 17). SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. Journal of the American Medical Informatics Association, 23, 899-908.
Marcheschi, P. (2016, Nov 4). Relevance of eHealth standards for big data interoperability in radiology and beyond. La Radiologia Medica.
Miliard, M. (2017, Feb 21). Argonaut Project building on success with FHIR implementation guide. Healthcare IT News.
Office of the National Coordinator for Health Information Technology. (2014). Connecting Health and Care for the Nation: A 10-Year Vision to Achieve an Interoperable Health IT Infrastructure. Washington, DC: Office of the National Coordinator for Health Information Technology.
Solbrig, H. R., Prud'hommeaux, E., Grieve, G., McKenzie, L., Mandel, J. C., Sharma, D. K., & Jiang, G. (2017, Feb 16). Modeling and validating HL7 FHIR profiles using semantic web Shape Expressions (ShEx). Journal of Biomedical Informatics, 90-100.
Topaz, M., Seger, D. L., Goss, F., Lai, K., Slight, S. P., Lau, J. J., . . . Zhou, L. (2016, Feb). Standard Information Models for Representing Adverse Sensitivity Information in Clinical Documents. Methods of Information in Medicine, 151-157.
