Helping healthcare catch FIHR

The human body is a network of interoperating systems that have to work together seamlessly.

Genetics is our operating system (OS). Epigenetics, nutrition, hormones, enzymes, vitamins, exercise, lifestyle, et cetera are our OSI layers and protocols. A person's health span (defined as the healthy productive time before the onset of age-associated decline) depends on how smoothly our OS, OSI layers, and protocols work together. Successful healthcare is about preventing diseases and slowing decline to achieve a great health span. Success in this work requires collecting data, analyzing it, and assuring that the healthcare systems we put in place are working together as well as our bodies themselves. As a longtime developer of healthcare IT solutions, this metaphor of body-as-network makes it much easier for me to explain the importance of healthcare data.

ExtraHop can go one step further and provide the monitoring and analytics to make enormous gains in the value we can extract from this data, especially as we transition to FHIR, the new standard for healthcare data exchange.

What Is FHIR?

FHIR (pronounced "fire") stands for Fast Healthcare Interoperability Resources. FHIR is the latest interoperability standard that has emerged from the non-profit Health Level Seven (HL7) organization to enable secure electronic sharing of healthcare data. FHIR incorporates the best features from previously developed HL7 standards using modern paradigms for data transfer, and current security standards to solve clinical and administrative problems in a practical way. FHIR defines provenance or origin of data and security event resources suitable for tracking the origins, authorship, history, status and source of resources.

FHIR uses four main paradigms for communicating health data: REST APIs, Messages, Documents, and Services. FHIR is differentiated from previous standards in many ways, but the two root differences that make it so revolutionary are:

• Security: All production health data exchanged using FHIR is required to be secured using TLS/SSL. This makes it much more secure than previous HL7 standards.
• Resources: FHIR uses standardized data formats and elements, collectively called "Resources." A Resource is the smallest possible unit of transaction in FHIR, with a known identity providing meaningful data.

FHIR is suitable for use in a wide variety of contexts, including mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and more. FHIR is open source, free, scalable and flexible.

Why a New Standard? Because Healthcare Is Changing Rapidly

Let's back up for a moment and talk about why we need a new healthcare data exchange standard at all.

On March 23, 2010, President Obama signed the Affordable Care Act (ACA), effecting huge changes in health insurance, patient's rights, Medicare and Medicaid payments, and many other aspects of healthcare. This caused a rise in the number and complexity of Electronic Health Record (EHR) implementations. In 2015, requirements around improving quality and lowering costs and paying physicians based on "value not volume" forced EHR vendors to address the lack of interoperability between the EHRs.

EHRs now must be able to support various payment models, including value based payments, bundled episode-based payment, case rate, package pricing and episode-of-care payment, so that the providers can be reimbursed. This resulted in an urgent need to change the existing model to remedy EHRs' complete lack of interoperability.

The HL7 organization decided to turn to other industries to look for ideas for improving interoperability. What they found pointed strongly to the use of RESTful APIs. HL7 FHIR combines the best features of HL7 Version 2 (V2), HL7 V3, and Clinical Document Architecture (CDA), while leveraging the latest web service technologies and concepts.

Based on their findings, HL7 International decided to use popular, open, and accessible technologies for their next standard. For that reason, FHIR uses a modern web-based suite of Application Programming Interface (API) technology, including an HTTP-based RESTful protocol, HTML and Cascading Style Sheets (CSS) for user interface integration, a choice of JSON or XML for data representation, OAuth for authorization and Atom for results.

The API is the "hook" that enables EHRs to communicate interactively, and in a standardized way, with apps and eventually even between the different EHRs. This model enables rich data visualization well beyond the capabilities of any existing EHR. Since apps will require access to the patient health system data, they must pass the tests for efficacy, accuracy, utility, safety, privacy, and security. APIs have been made available for a variety of programming methods including C#, Java, Javascript, Objective C, and Delphi.

To the track the development of this new standard, FHIR Connectathons were established very early on to verify specification approaches and continue at HL7 workgroup meetings.

What is Interoperability, and Why Does it Matter in Healthcare?

Interoperability, in the context of healthcare, means the ability of systems that store and use data to exchange that data with other systems without compromising the security or fidelity of the data, and without an undue amount of effort.

For the purposes of our FHIR discussion, interoperability requires making use of the following paradigms for data storage and exchange:

1. REST: Use of small lightweight exchanges with low coupling between systems
2. Messages: To allow communication between multiple resources in a single exchange
3. Documents: Allows persistence when data spans multiple resources
4. Services: Allows the use of custom service if the standard service does not fit the requirement

Basic Terms and Concepts in FHIR

Resource: The basic building block or a modular component in FHIR is a Resource. Resources define behavior and meaning, have a known identity and location, are the smallest possible unit of transaction, and provide meaningful data that is of interest to healthcare. Resources will be limited to 100 to 150 in total but can be extended if needed for optionality and customization, they are similar to an HL7 V2 segment.

Resources are data formats and elements, essentially a structured model of a JSON or XML object. Each object will have its own Universal Resource Identifier (URI) with a unique identifier like a Medical Record Number (MRN). Every resource consists of an Identifier, Human Readable summary, Extension, Contained Resources, Metadata, Resource content and Tags. Human readability will allow the data to be viewed in a standard web browser, even if none of the structured data is able to be imported into the receiving system. Resources may also be combined into a Resource Bundle, a collection of multiple resources and even full-message exchanges.

There are various categories of resources that can be used in FHIR, including:

• Clinical (Medications, Diagnostics, Observations or other General objects)
• Identification (Individuals, Groups, Entities, Devices)
• Workflow (Patient Management, Scheduling, Workflow #1 and #2)
• Administrative (Attribution, Workflow)
• Infrastructure (data payloads such as documents, message headers specifying source and destinations, Composition, Query, Profiles, Value Sets, Information tracking, Documents and Lists, Structure, Exchange)
• Conformance (Terminology, Content, Operations Control, Misc)
• Financial (Support, Billing, Payment, Other)

Additionally, the FHIR specification defines a set of Data Types that are used for the resource elements. There are two categories of data types:

• simple or primitive types, which are single elements, and
• complex types, which are re-usable clusters of elements.

Clinical Documentation Architecture (Reaffirmation) (CDA(R)) specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients, e.g: Discharge Summary, Imaging Report, Admission & Physical, Pathology Report etc. Different Reaffirmation versions are applicable based on the type of CDA section.

Draft Standard for Trial Use (DSTU): this term denotes versions of FHIR that are being tested but should not be considered finalized, as opposed to "Normative Versions" that are standardized after extensive testing.

Why do we need FHIR when we already have HL7?

HL7 V2 is a well-established standard that works within institutions to connect applications. However, it is a legacy standard with unique syntaxes and custom tools that have caused an explosion of HL7 variants resulting in problems of data integration between systems and institutions over time. HL7 V2 also has no requirements for privacy, security or authentication. HL7 V2 is also limiting to modern devices and apps that are trying to make use of the vast trove of stored patient data in a meaningful manner. Lack of security and interoperability have caused HL7 V2 limitations to become a barrier to patient engagement.

HL7 V3, though based on a reference model, was overly complex to implement and did not have the backwards compatibility with HL7 V2. Hence HL7 V3 was dead on arrival and was not going to help anyone in healthcare make money or save money, nor to meet the Centers for Medicare and Medicaid Services' (CMS) new mandatory bundled payments model, called Medicare Access and CHIP Reauthorization Act (MACRA), starting in 2018. This is a significant rule with fundamental changes for Medicare that is related to the merit-based Incentive Payment System (MIPS). MIPS consolidates components of the Physician Quality Reporting System (PQRS), the Value-based Payment Modifier (VM), and the Medicare Electronic Health Record (EHR) Incentive Program. MACRA mandates interoperability that HL7 V2 and V3 were unable to provide. FHIR will step in to fill this requirement.

The HL7 Clinical Document Architecture (CDA) is an interoperable content standard to help organizations exchange clinical data. CDA takes a document approach, providing the ability to group related content about the patient into a single document format.

In contrast, FHIR presents discrete elements of information, for example - individual lab results, demographic information, medications and more – as data representations called Resources. Discrete resources in FHIR offer much greater potential for interoperability than the CDA document approach.

What will change in healthcare with FHIR?

EHRs have done their job of collecting and storing the healthcare data. With FHIR, as patients move around the healthcare ecosystem, their electronic health records will be available to support automated clinical decision support and other machine-based processing, also the data will be structured and standardized. Given the embedded nature of HL7 V2, the transition with FHIR will not happen overnight. The healthcare market will ultimately decide the success of FHIR and whether FHIR survives or coexists with older standards.

What are the different FHIR workflows in healthcare?

1. Communications between applications: Initially a broker may be needed for the applications, like the interface engine that acts as a middleware between different applications that may still use HL7 versions.
2. Patient engagement: FHIR will be used to provide patients with timely data and alerts using REST standard.
3. Link the different EHRs: FHIR will make it so that all patient data stored in many different data repositories like Health Information Systems (HIS) and Picture Archiving Communication System (PACS) can be liberated and made available to different departments within and outside the healthcare facility.
4. Vendor Neutral Archive (VNA) or Vendor Neutral Repository: Eventually the goal is to be able to store patient data documents and images or potentially any file of clinical relevance in a standard format with a standard interface, such that they can be accessed in a vendor-neutral manner by other systems. This will allow applications to solve creative workflow problems.

How Is FHIR Being Developed?

FHIR is still being developed by HL7, the second Draft Standard for Trial Use (DSTU2) became available in 2015, the first normative edition is planned for 2017 and the second normative edition in 2018. This will be a big step towards population health management. Major EHR vendors like Athenahealth, Cerner and Epic have agreed to support an early effort at implementation, known as the Argonaut Project, that will be important for the open API requirements for Meaningful Use Stage 3.

SMART on FHIR is a project that started in 2010, funded by The Office of the National Coordinator for Health Information Technology (ONC), to build an app platform for healthcare allowing innovation, creative use of data within the EHR, enabling third party plug-in apps and support apps to be chosen by clinicians. SMART on FHIR specs provide means for healthcare organizations or developers to access discrete clinical data—such as medications, problems, lab results, immunizations and patient demographics.

What Interoperability Means for Population Health and Healthcare Costs

According to the Center for Disease Control and Prevention (CDC) 2016 data, chronic diseases and conditions are responsible for 7 of 10 deaths each year, and treating people with chronic diseases accounts for 86% of our nation's health care costs.

An enormous amount of healthcare effort and cost goes toward just a few chronic diseases and conditions, including heart disease, stroke, cancer, type 2 diabetes, hypertension, obesity, arthritis, Alzheimer's Disease and other dementias, multiple sclerosis (MS), Lou Gehrig's Disease (ALS), asthma, oral health, cystic fibrosis and chronic obstructive pulmonary disease (COPD). in spite of a barrage of prescription medications administered, invasive surgical procedures performed, declaring war on cancer in 1971 and completing the Human Genome Project in 2003, there is no strategy that seems to be working to reduce the number of deaths and cost attributable to these chronic diseases. Unless we understand the root cause of a disease, a treatable disease can become a chronic and progressive lifelong condition. Interoperable healthcare data systems will play a vital role in understanding the root causes of the most costly and deadly diseases.

Can the new healthcare laws, "Value Not Volume" based payments and EHR interoperability in healthcare help in changing the current healthcare conditions?

Yes, I think there is a fair chance. Many of the adverse incentives in healthcare have changed substantially for the better.

Am I Optimistic About Future Positive Changes in Healthcare?

I have been working for the last few years in healthcare applications. Before that I was working in basic research labs, analysing many health related experiences, passionately staying current with many nutrition, health and healthcare topics.

Throughout all this, I could see the limitations of siloed data in healthcare and patient care. Diseases and chronic health conditions are typically treated as if they are just affecting the different parts and organs, not considering the overall impact on the entire human body, and thereby missing the interconnections that complete the picture. Both human health and healthcare data face the same problem, they are both siloed. We need a more holistic approach.

In the near future we will be able to look at the interconnections of the human body and also in healthcare data in their entirety. This will enable us to paint a complete picture for both. Then it will be the time to make use of tons of EHR healthcare data and perform data analytics in a meaningful manner to improve the human health, streamline workflows and reduce the cost of healthcare.

So am I optimistic about the future of healthcare as interoperability increases? Yes!

What makes ExtraHop Great for Monitoring FHIR?

The ExtraHop wire data analytics platform can already perform real-time analytics for the entire healthcare ecosystem by parsing many protocols, such as HL7, DICOM, TELNET, HTTP, XML, SSL, FTP and many more L3, L4 and L7 protocols. That means our platform is already prepared for when FHIR becomes the interoperability standard in 2017 to 2018. ExtraHop already supports many interoperable technologies. Our bundles are in JSON format and ExtraHop already supports Application Inspection (AI) triggers, alerts, javascript, Python and RESTful APIs.

FHIR is implemented on top of HL7 and the HTTPS (HTTP Secure) protocol. FHIR is expected to be secured using TLS/SSL. FHIR data will be structured as JSON or XML and standardized. FHIR is for interoperability where we will have access to all healthcare storage systems like HIS and PACS.

In other words, FHIR is being built on technologies that are already well-supported by the ExtraHop platform.

ExtraHop, with protocol metrics for FHIR, will open the door to so many possibilities with FHIR and the apps-based health IT. ExtraHop can drill down into all metrics collected from HL7, DICOM, TELNET, XML, SSL, HTTP along with FHIR, and can connect the dots needed to use that data to address complex human health questions.

Using ExtraHop in conjunction with FHIR will allow IT departments to break free from EHR data silos and get the full clinical value out of each patient's health data. In doing so, ExtraHop can help in shifting healthcare from a reactive process to a proactive and preventive model. ExtraHop can bridge the current gap between healthcare's siloed data by creating meaningful predictive insights from the entire structured data by providing a single source of truth.

The increase in interoperability and reduced friction in sharing healthcare data will open the floodgates to enormous improvements in healthcare and disease prevention, and ExtraHop can be a key enabler in these improvements. Just a few possibilities include:

• Identifying the root cause of diseases in patients and populations using disease condition patterns and analytics with a drill down approach
• Identifying the comorbidities associated with the worst health outcomes by alerting on the coexistence of multiple high risk conditions in a patient, even if these conditions are being tracked in separate data silos.
• Recommendations for prescription medications and invasive surgical procedures based on the efficacy, absolute risk reduction and health benefits rather than based on the relative risk reduction, to shift towards outcomes-based pricing.
• Identifying nosocomial (originating in a hospital) infections including sepsis
• Democratization of healthcare data, liberating electronic health records data so that data cannot be cherry picked by a few to make false claims, but data will be widely available for anyone to do research and analysis upon it.
• Creating apps or bundles to address various healthcare issues

A good app or a bundle, distributed widely, can transfer ideas, functionality, workflow and could reshape healthcare IT overnight! In my mind, that's the potential power ExtraHop has to accelerate a positive transformation in healthcare.

Want to learn more about how ExtraHop provides healthcare organizations with insights from wire data that can dramatically improve both doctor and patient experiences? Explore the HL7 analytics scenarios in our free, online demo.

Further Reading on FHIR, HL7, and healthcare data analytics:

• What is FHIR?
• Step-by-Step Guide to HL7 Analytics
• Six Ways ExtraHop Enables Real-Time Healthcare Systems