FHIR Revisited

by  Dugan MadduxDugan Maddux, MD, FACP & Dr. Ahmad SharifAhmad Sharif, MD, MPH
April 24th, 2018

Like a moth to a flame, we periodically have to take a close look at FHIR. As mentioned in the March 26 blog post, interoperability was the hot topic at HIMSS, and FHIR is at the blazing edge of interoperability.

As a quick reminder, FHIR is the acronym for Fast Healthcare Interoperability Resources. FHIR primarily defines standards for exchanging healthcare data elements. For over 30 years, Health Level Seven International (HL7) has been the standard for health data storage, but HL7 standard interfaces are cumbersome to build and expensive to maintain. In 2010 the HL7 organization started a workgroup to generate accessible, simple standards for software developers to use to retrieve, store, and share healthcare data. The “Fast” in FHIR is there because it’s fast to learn to use the standards and easy to start building apps to share data.

Usable data elements with FHIR

FHIR improves interoperability for providers by exchanging discrete data elements instead of big blobs of data. For example, a provider might receive a discharge summary from a hospital as part of a document exchange. HL7 standards enable transfer and capture of this summary as a Clinical Document Architecture or CDA standard document, but it remains an intact “data chunk” that’s hard to consume in the workflow. Somewhere buried in the document might be a list of allergies, but this discrete data cannot be easily extracted and placed in the allergy section of your EHR. FHIR resources create standards for allergies as a discrete data element, so when this data arrives in your EHR system it is easily presented in the proper place, and you can see it when you look at the allergy list.

The “resources” in FHIR are small, discrete data units that have a specific definition. For example, “patient” is a resource and the FHIR standard defines the data elements that make up a patient: first name, last name, age, sex, etc. The FHIR standard also defines how the data elements are stored and identified, and where they are located within the data repository.

Creating a data standard

Standard data definitions make it easy for developers to build apps that can move data among systems. Apps can easily interface with a data repository, ask for specific data, transfer the data, and hand it off to another system as recognizable data elements.

The analogy often used is that FHIR makes healthcare data more like travel data. If you go to a travel website to search for flights for a particular route on a particular day, the travel website will give you a list of all available flights that meet your criteria from multiple airlines. The airlines have agreed to store their route, time, and cost data in a standard way, and to make this data available when a valid request is made. The travel website app interfaces with multiple servers to collect the data and display it in a standard way for you to review.

In the same way, FHIR invites the development of apps to write data into systems as well as retrieve data from systems. This facilitates interoperability, supporting data flow among many data storage sources. Leveraging these standards, your EHR can accept data uploaded from patient wearable devices, from a pharmacy, or from a home health agency. Your patients can retrieve personal data from your EHR through secure apps that ask for, extract, and share data.

Fueling interoperability

FHIR standards and interoperability are also enabling the movement to let patients be more in control of their personal health data. This has been referred to as the “democratization” of healthcare data, which raises concerns for many healthcare organizations in their traditional way of operating and thinking. At various forums health systems express reluctance to make data easily accessible, in part because the data is complex and may not be easily managed by inpidual patients. Organizations are also worried about data privacy and security.

Is it possible to confirm that the right person has access to the data? Is it possible to balance tight security around who can access the data, but not so tight that it is impossible to get in?

Even with these valid security concerns, patient-control of personal health data is moving forward. The Office of Civil Rights supports patients in controlling their data and in taking responsibility for sharing their data. This is a sea change for big healthcare organizations that have traditionally been the data gatekeepers.

FHIR is a work in progress, and we will continue to live in a hybrid environment, part FHIR and part HL7 v2. Even though it is old (released in 1987), 95% of U.S. healthcare organizations use HL7 v2. It is the most widely used healthcare standard in the world. HL7.org notes that FHIR offers benefits, but that it is unclear how quickly organizations may migrate from HL7 v2 or v3 to FHIR. So they anticipate supporting all standards for a long time.

On the other hand, some key drivers may stoke the flames and push FHIR adoption along. Every day the pool of health care data per inpidual grows bigger and bigger. Providers need access to all the data in the workflow at the point of care, so this data needs to flow into the EHR in a usable way. Many patients are ready for control of personal data with the ability to share it among providers. FHIR is blazing a trail for rapid development of new apps that create value and extend the functionality of EHRs for providers and patients.

It may be time to sit back, toast some marshmallows, eat S’mores, and enjoy the FHIR. How do you feel about making it easier to access data? Is it time for patients to be custodians of their own data? Let us know what you think.

Dugan Maddux, MD, FACP, is the Vice President for CKD Initiatives for FMC-NA. Before her foray into the business side of medicine, Dr. Maddux spent 18 years practicing nephrology in Danville, Virginia. During this time, she and her husband, Dr. Frank Maddux, developed a nephrology-focused Electronic Health Record. She and Frank also developed Voice Expeditions, which features the Nephrology Oral History project, a collection of interviews of the early dialysis pioneers.

Dr. Ahmad Sharif, MD, MPH, is Sr. Vice President and Chief Medical Information Officer of Fresenius Medical Care North America. Dr. Sharif was instrumental in bringing innovative tools and technology, fostering cross functional collaboration, and establishing change management procedures as Fresenius Kidney Care’s VP of Clinical Health Information Technology. Dr. Sharif has extensive experience in health information technology, consulting with over 25 health systems across the country and abroad, implementing and optimizing electronic health records, clinical practice management and technology solutions for multi-facility large academic institutions and smaller community and critical access hospitals. He is a big proponent of user-centered design and is currently engaged in projects to improve clinical and operational outcomes by use of clinician focused technology solutions.


FHIR Revisited. (2018, April 24). Find-A-Code Articles. Retrieved from https://www.findacode.com/articles/fhir-revisited-33960.html

© InnoviHealth Systems Inc

Article Tags  (click on a tag to see related articles)

Publish this Article on your Website, Blog or Newsletter

This article is available for publishing on websites, blogs, and newsletters. The article must be published in its entirety - all links must be active. If you would like to publish this article, please contact us and let us know where you will be publishing it. The easiest way to get the text of the article is to highlight and copy. Or use your browser's "View Source" option to capture the HTML formatted code.

If you would like a specific article written on a medical coding and billing topic, please Contact Us.


innoviHealth Systems, Inc.
62 East 300 North
Spanish Fork, UT 84660
Phone: 801-770-4203 (9-5 Mountain)
free demo
request yours today
free subscription
for any budget

Thank you for choosing Find-A-Code, please Sign In to remove ads.