Get FHIRed Up

‐

 

By Barry P. Chaiken, MD, MPH

Although I’m a physician, not a technology expert, I’m jazzed about the FHIR® (Fast Healthcare Interoperability Resources) specification. Organizations struggle to share patient information with each other due to data structure and definition incompatibilities. This lack of interoperability forces physicians to treat patients without the benefit of a complete patient record, which leads to duplicate testing, unnecessary procedures, misdiagnoses, and medical errors.

HL7’s release of the proposed FHIR standard (Welcome to FHIR, 2015) attempts to unlock the data within electronic medical records (EMR) and make it available for other applications to utilize. The current CCD and CCD-A data standards lack the richness and flexibility inherent in FHIR, and therefore represent only a first step in making data interoperable and useful in other systems.

Power of FHIR

Two key characteristics of FHIR make the standard so powerful: data types and metadata. As data types are defined and represented in a common way, they represent a single data element (e.g., blood pressure). Metadata then provides a descriptive context and characteristic to the data element. This allows the element to be managed, processed, and routed. Think of running an Internet search: Each Web page contains metadata that describes the page’s content, which is how search engines like Google® or Bing® know what pages to show us in response to our queries. In the case of a data element like blood pressure, the metadata may suggest that the results need to be routed to Dr. Chaiken for review.

Data points, forms, images, and unstructured text make up a patient’s EMR. Because EMRs were designed to mimic the pages of a paper record, the information they contain remains trapped within those “pages.” Without the FHIR standard, extracting a data point and understanding its meaning can be very difficult.

Free the data

FHIR’s ability to isolate and describe data elements frees the data from the monolithic clinical database. Using an application program interface (API) to access the data, innovative developers can create standalone applications that utilize FHIR-enabled data elements to deliver information to patients and clinicians independent of the EMR. Rather than having the data imprisoned by the predetermined structure, workflow, and user interface of the EMR and other clinical systems, applications can be developed that satisfy the specific needs of both clinical staff and patients.

The HL7 organization effectively describes how to think about data element storage and exchange. If a medical record is thought of as a large folder with folders within folders, proximal to other folders, then a patient’s medical information is stored on pages within those many folders. To review that information in paper records, someone must search through the folders and the pages inside to get to the information required. That approach might work well for a human, who can determine which folder to look in (e.g., to find a patient’s weight, a human knows to look in the vital signs folder and then scan the folder’s pages for the correct data element). For a digital system, though, access is not that easy—these systems do not have the analytical power of the human brain. Instead, they require specific instructions about where to find the data element and what characteristics are associated with the element (e.g., the date on which a patient’s weight was measured).

The API acts as the file clerk for FHIR-enabled data, allowing digital systems to dictate interaction with the data elements. These include:

  • Search: Find the data element based on criteria that include the specific data element and other characteristics associated with it (e.g., most recent weight)
  • Read: Retrieve the data element selected by the search function and report the results
  • Create: Add a new storage location (e.g., folder) to the EMR for storage of similar, newly acquired data elements
  • Update: Add a new data element with related descriptors to a folder (e.g., location) for storage
  • Delete: Remove an entire set of data elements from storage (i.e., virtually remove it while really identifying it as “do not open”)
  • Operation: Perform an action or procedure on data elements in one or more locations and produce a summary record

Composition, messaging, services

In addition to this “clerk” API activity, FHIR offers other useful and flexible functionality. It uses composition to bring together a set of healthcare-related information and assemble it into a single document, one that includes meaning and context and assigns responsibility to the person assembling the information. Rather than actually containing the content, composition provides the structure for delivering the information in a bundle, where the first data element is the composition. Therefore, composition acts to decipher the content and turn it into an understandable format. To illustrate, think of the periodic table of the elements. Without the structure of the table (i.e., composition)—which orders the elements based upon their number of protons—the elements would be listed randomly and would not have much meaning.

Messaging and services deliver additional functionality to the FHIR standard. Messaging provides communication between two digital systems. Per HL7, “the message serves to notify the receiver that the event occurred as well as provide the details about any existing data that was modified or new data that was created” (Welcome to FHIR, 2015). For example, such messaging may indicate that a patient was discharged or a lab order was filled. Services, meanwhile, act as a simpler type of messaging and provide a response to requests for data elements. Such functionality offers the prospect of great utility in clinical decision support. Services could be applied to data element requests (e.g., prescribing penicillin) with a question about the data element (e.g., is the patient allergic to penicillin?)

The richness of our personal interactions with technology—e.g., easy-to-use and intuitive apps for smartphones and tablets—essentially does not exist in healthcare. FHIR opens the door to an infinite number of useful applications that will completely change our use of healthcare information technology by unlocking that data from monolithic data structures and storage systems. These tools will improve clinical workflow, patient-clinician interactions, and patient use of healthcare applications. This is why this doc is jazzed!

 

 

Barry Chaiken is the chief medical information officer of Infor and has more than 20 years of experience in medical research, epidemiology, clinical information technology, and patient safety. He is board certified in general preventive medicine and public health and is a fellow, former board member, and chair of HIMSS. As founder of DocsNetwork, Ltd., Chaiken worked on quality improvement studies, health IT clinical transformation projects, and clinical investigations for the National Institutes of Health, UK National Health Service, and Boston University Medical School. He is currently an adjunct professor of informatics at Boston University’s School of Management. Chaiken may be contacted at barry.chaiken@infor.com.

References

Welcome to FHIR®. (2015, October 24). Retrieved from http://hl7.org/fhir