Jump to James' Intro to FHIR Video Lesson
If you are someone who delivers healthcare services or products, you’ve probably heard about FHIR, the free and open standard for health interoperability created by the HL7 standards development organization. With FHIR’s expanding international role in solving challenges and creating opportunities within the healthcare information space, it is time to take serious notice. And, who better to learn from than someone who was part of its origin story—and who eats, sleeps, and breathes FHIR? In this recent webinar, Smile Digital Health CTO and HAPI FHIR project lead James Agnew shares the story of the standard from its humble beginnings to its current role in powering the exchange of health data for organizations around the globe. Here are a few highlights from his fascinating deep dive into the components, features, use cases, and future of FHIR.
FHIR Starter
To understand FHIR, you need to understand its roots. In the early 2000s, James was tasked with aggregating patient result data from two hospitals into a web portal. In the context of present-day technological capabilities, this sounds like child’s play. However, at the time, basic technology was a barrier to achieving interoperability in healthcare. Even having a page reload in the web portal when new patient data became available presented a significant challenge. The technology was not usable by modern approaches to building applications–especially those that could work on a phone, tablet, or across distributed mobile networks.
FHIR was created as a response to these old technologies–a fresh attempt to build a standard that meets the modern needs for data and interoperability but is accessible and straightforward enough to be embraced by developers, implementers, and users. To that end, FHIR stands for Fast Healthcare Interoperability Resources, with “fast” referring to it being fast to adopt and implement. This is key, as the easier a standard is to follow, the more stakeholders will adopt it–and the more valuable the specification becomes in terms of being able to create interoperable solutions.
The FHIR Manifesto
In developing a resource that could stand up to what the future brings, FHIR creators learned from past mistakes. In doing so, they drafted the FHIR Manifesto–a set of principles to guide their decision-making process.
The first precept is that FHIR should remain implementer focused and targeted at the developers who are building the healthcare solutions, rather than the clinicians who are using them. The other half of this guideline is that the resource must be implementable and workable–not an easy task when the standards need to be both iterative and normative.
A second principle is to ensure that the standard is well-tested. A big part of the FHIR process is constant testing by the community of developers who work together to try out ideas–and ultimately prove or reject them.
A standard that considers every use scenario can become very bloated. So, a third tenet mandates that implementers only include common scenarios. Central to this is FHIR’s 80:20 rule, which sets out that something cannot be accepted into the core specification unless it would be useful to and used by 80 percent of systems around the world.
Being open is a fourth principle–and as James puts it, “FHIR is open like crazy.” Organizations can use FHIR in their applications for free, regardless of whether they are building an open source software or a proprietary commercial one.
Finally, it has to be easy to adopt, which means it must be simple and quick to get up and running. As James notes, “I've seen an organization with capable developers who are great at what they do but have never heard of FHIR and, within a matter of weeks, they've got it up and running.”
FHIR in Action
FHIR itself has five components–a robust data model, a RESTful API, open source tools, a network of servers across the globe, and a collaborative community of implementers–that work in conjunction to form a scalable, useable, and interoperable system for healthcare.
With over 150 different resources, the FHIR data model can be used to describe almost anything related to health data. Each of these resources has a specific purpose—for example, a patient resource can include items like hospital or family doctor visits, observations, and diagnostic reports. Following the implementer focus and open principles of the manifesto, FHIR’s resources are inherently readable and presented on a publicly accessible website. Programmers can use their mouse to hover over any concept on the page for more details and click on that item to learn everything about it. James likens this web of information to Wikipedia, where users can access additional information through related links.
Not only is resource navigation simple, but data types are also very flexible and allow for many different use cases. For example, the concepts of dates and time are paramount when modeling healthcare data. FHIR can capture these two widely used data types at every level of precision. That said, the data model also accommodates uncommon scenarios through resource extensions to add functionality that does not fit into the 80:20 rule.
Some features lend themselves to usability and adoptability. Narratives, a type of resource that offers human-readable versions of structured data, are important when data is sent to consumers who are running different software. When a new system receives data that it does not understand, it can still display the narrative to humans who are not FHIR experts, allowing them to roughly interpret the clinical data for a basic level of interoperability.
Resource identifiers–for patients, devices, specimens, or a myriad of other items–are another way to allow for true semantic interoperability. Machine processable identifiers utilize a set of agreed-upon reusable codes so that the same code used by the individual creating the data is understood by the individual receiving it. As with a narrative, a human display name can be included with the identifier to allow a person to understand it.
James Agnew also reviews the beneficial features of FHIR’s REST API data exchange mechanism that performs basic CRUD (create, read, update and delete) operations. Of particular note is the delete function. In the health records domain, no one ever destroys data, so FHIR performs what is called a logical delete. This operation does not erase the data–instead, it changes a flag on the resource so it no longer appears in search results. An added benefit of this function is that data from different points in time remains discoverable.
Another feature worth mentioning is the search API, which is central to any complex health care application. Many search parameters are built into Smile’s HAPI FHIR. However, in the real world, users often want to define their own. FHIR allows for these cases, as well as gives the option to turn off search parameters.
Even with so many features, FHIR is intended to be a base platform for interoperability. Jamesremarks that the FHIR specification is not specific enough to be plug and play, because almost nothing in FHIR is mandatory. He adds that even something as obvious as a patient resource having a name is not necessarily a given in every scenario–and cites the example of an unconscious person arriving without identification at an emergency department. FHIR is extremely loose, which makes it great for flexibility, but it gets trickier when building interoperable software with particular scenarios to solve. This is where an implementation guide (IG)–a “mini specification” that constrains the FHIR specification for some specific use–can be put into action.
The Future of FHIR
James introduces four IGs that are significant for their present and future value in the healthcare space. The first, the US Core Implementation Guide, was developed to allow a base level of interoperability in the United States. The initial use case was for allowing apps–primarily phone apps–to connect to emergency medical records. The IG is thorough in terms of resources and is being used as the basis for various national EHR implementation guides.
The International Patient Summary (IPS) implementation guide project takes this one step further. Led by Europe, but truly global in scope, the aim is to come up with a bare minimum record offering a snapshot of someone's health that could follow them across country borders. Agnew likens this to an ATM card for health.
The third example relates to the hot topic of consumer access, which is the future of connected healthcare. The Carin Alliance in the US is building a set of technical and policy frameworks to enable consumer-directed data exchange. They have defined an IG that would create the technical specifications for consumers to access, use, and share their data. While Carin is US-based, Smile is a member and James has high hopes that this concept can head north to Canada.
Finally, there is the Gravity Project which examines the inequities that exist in our healthcare system. Access to health data often determines outcomes, so the IG's scope is to develop the technical mechanisms to recognize and track the social determinants of health, as well as incorporate them into health records. James acknowledges that creating data standards is not going to solve all of the imbalances in healthcare, but he views measuring the problem as a solid first step towards developing a solution.
With every EHR vendor, government, university, hospital, and healthcare organization around the world that implements the FHIR standard, James sees one more data source where the expectation is that, even if the data models are not the same, there is a similar base understanding and protocol. As the adoption of FHIR spreads, we get closer to a future where a standard becomes the standard–and true interoperability in healthcare can be achieved on an international scale.
Watch James' Intro to FHIR Video Lesson (parts 1-3) below.
