Is FHIR an Industry Disrupter?

I have a passion for innovation. Specifically, I love disruptive innovations — the kind that totally upends an industry, seemingly overnight. I’m talking about the kind of technology innovations that come along from time to time and change everything. We have been lucky to witness many in our lifetime — personal computers, digital photography, and the Internet to name a few. These technologies blow open new opportunities and change the status quo so quickly that vendors providing products and services in the old model are left in the dust. This happens largely because human present bias kicks in: it is easier to continue doing what works now (and is making money now), even though the game has changed entirely.

The computing industry is the world-record holder for disruptive innovations. Minicomputers in the 70s disrupted the mainframe computer market. The personal computer then disrupted the minicomputer market in the 80s. Entirely new, multi-billion dollar companies are created during disruptive innovation events, while at the same time, very large incumbent vendors are often pushed aside by the new kid in town.

At the core of disruptive innovations are incredible technology advancements — the kind that can move entire industries. The introduction of low-cost microprocessors by Intel led the way for the PC revolution. Another example is Netflix’s impact on the rented DVD market, and ultimately, the entire entertainment industry.

Often, disruptive innovations occur not just because of a single technological advancement, but a collection of them, all aligning at the same time. For instance, Netflix would not be possible without sufficient video-capable PCs, tablets, and mobile phones as well as the bandwidth available to stream movies and TV shows.

Healthcare should be an incredibly target-rich environment for disruptive innovations. The market is huge, making up nearly one-fifth of this country’s GDP. Healthcare is expensive, and we continue to pay more every year, yet get the same, or often less for our dollar. There are certainly many entrenched vendors in healthcare from large provider groups, to big insurance companies to big pharmaceutical firms protecting their turf.

But where are the disruptors?

In his blog article titled “Building a big health tech company,” Malay Gandhi does a great job of describing the rather lackluster results of investor attempts at “revolutionizing healthcare.” Innovation in healthcare is exceptionally challenging, and disruptive innovation in healthcare is rare indeed. During the last 5 years, over $17 billion of investor money has gone into healthcare startups, yet there are relatively few billion-dollar valuation companies that have been created during this time period. Gandhi goes on to point out that most of the market gain after healthcare “reform” went to existing incumbents. That’s right — large healthcare firms have seen their market values nearly double since 2011.

Because of the healthcare market’s size and expansiveness, it’s not surprising that many startups have focused on incrementalism, not revolutionism. It is much easier to take a small cut of a large number of transactions than tackle head-on the huge obstacles of true healthcare transformation. I agree completely with Gandhi when he states: “Health tech companies that want to be big will have to focus on making healthcare different, not just better.”

Are there any disruptive technology innovations on the horizon for healthcare? The kind that — once understood, matured, and partnered with other innovations — can break open the industry and enable disruption?

The answer is yes, and the HL7® FHIR® standard is exactly that. FHIR® has emerged as a key ingredient technology that enables disruptive innovation, but like other disruptive events, it will take a collection of technologies, practice changes, and new thinking to achieve real disruption in healthcare.

FHIR is a standard that deserves your attention and offers great advantages to future technology development efforts in healthcare. Below, you will find the reasons why FHIR is different than previous interoperability efforts and healthcare innovation challenges where you can begin applying FHIR today.

Healthcare Data Interoperability: A Historical Challenge.

Interoperability has always been a challenge, no matter the industry segment. However, many industries have conquered interoperability in ways that benefit both the consumer and the business. One can perform an ATM cash withdrawal nearly anywhere on the globe. Cell phone text messaging works everywhere today and is seamless across mobile carriers. Certainly, healthcare has challenges that are orders of magnitude more complex than these challenges, however, models do exist for solving these problems.

The Lack of Interoperability Hurts Everyone

The benefits of health data interoperability are too many to list here, but we encounter missed opportunities almost every day. Recently, I was informed by a colleague about yet another missed opportunity for interoperability. As of October 15th, the State of Massachusetts now requires that prescribing doctors and pharmacists utilize the new Massachusetts Prescription Awareness Tool (MassPAT). MassPAT collects dispensing information about patients who are prescribed drugs that are commonly abused. The goal is to help combat the opioid crisis.

Combating drug abuse in our state is very important, however, this new requirement means more work for doctors. Doctors are reporting that this additional step (which is outside of their EMR workflow) is taking an additional 3 to 5 minutes per patient. Since some medical providers might prescribe for 20 patients per day — this additional work can easily consume an extra hour plus per workday.

Lack of interoperability is increasing healthcare provider frustration. Doctors are frustrated and angry that their EMRs don’t help them do their jobs efficiently. A JAMA article sums up provider opinions of EMRs: “There is building resentment against the shackles of the present EHR; every additional click inflicts a nick on physician’s morale.”

It didn’t need to be this way. If we had basic healthcare data interoperability, the provider’s system could automatically perform the necessary reporting and abuse detection on behalf of the doctor.

Designing Workable Healthcare Standards is Hard Work

Interoperability opportunities abound, and we have been working on healthcare data interoperability since computers were able to be networked together. HL7 recently celebrated its 30th Annual Plenary Meeting in Baltimore, Maryland. A lot of effort has gone into HL7 standards over those thirty years, and there have been many lessons learned along the way. The healthcare domain is not only deep, but it is also wide too, which presents a considerable design challenge in terms of standards development. HL7 Version 2, the most widely implemented clinical interoperability standard today suffers from the challenge of “if you have seen one v2 interface, you have seen one v2 interface.” V2 implementations require lots of handholding and interpretation and custom logic to function correctly. HL7 worked to address this shortcoming of V2 with V3 and the Reference Information Model (RIM) by specifying, comprehensively, the healthcare interoperability domain to a degree that made working with V3 very complex.

In a video interview, Wes Rishel, former chair of HL7, Wes summarizes the challenges of developing V3 and also working with it, leading to some key design decisions that would end up heavily influencing FHIR. Wes describes working on V3 as “… we would bring a 4’x6’ chart to a meeting with everything in 10 point type…” and “…we ended up with a set of protocols that were very difficult to understand unless you were one of the priests of the model.”

The Benefits of a Fresh Approach

Anyone who has built a reasonably complex product has come to understand the enormous benefits of starting over. By starting over, I’m not talking about starting from scratch. Sometimes, when building a product, it makes sense to simply declare: “You know what? For us to continue working with what we have built isn’t going to work long term. Let’s take everything we learned, bring the things along that worked, and leave the things that didn’t work behind.” These are often very refreshing events for product development teams. Engineering teams I have led where we have done a “start over” have accomplished incredible feats as a result, resulting in entirely new and better products in very short timeframes. It is cleansing, and freeing and spurs all sorts of energy and enthusiasm.

This is what is happening with FHIR right now. FHIR addresses many of the interoperability issues that have stifled progress in the industry in the past, and people are excited to be working with something new.

What is FHIR and Why is it Better?

FHIR is a standard built by developers, for developers.

Target Support for Common Scenarios

FHIR stands for Fast Healthcare Interoperability Resources and is a next-generation standards framework by HL7. The specification can be found at this web site: http://hl7.org/fhir. The “resources” referenced in its name are the common building blocks that makeup healthcare, such as patients, medications, procedures, appointments, and claims. Participants in the standards process have agreed on these base definitions, which are straightforward and easy to understand. The FHIR development team has adopted the time-tested and engineer-approved 80% rule for resources: to only define and include concepts applicable to 80% of normal implementations. Adherence to the 80% rule is key to keeping the standard usable and not too overwhelming. At most, FHIR may eventually have around 150 resources as compared to thousands of unwieldy and difficult to recall concepts in other standards.

FHIR Has Built-In Extensibility

Ok, 80% is great — what about the remaining 20%? FHIR has an extensibility capability built into the standard that can only be described as beautiful (from this engineer’s perspective). Extensions are a normal part of working with FHIR. Extensions can be placed anywhere in the object model for FHIR, allowing incredible expressiveness in the standard.

Let’s have a look at one simple extension example. Below is an extension that describes an alias for an organization. An alias is something that not all systems might track, but at the same time, it is still very important for certain types of applications.

In this bit of XML, we see that there is a web URL and a valueString. At that URL, if you were to retrieve it with a browser, you will find a Structure Definition which describes the extension, again in XML format. This is a very important concept. What this means is that interoperability systems, as they are consuming resources, may encounter new extensions, and then have the means to understand them — immediately, on the fly. Healthcare systems that have the capability to then store an organization’s alias may then do so, or they may choose to simply ignore it.

FHIR’s extensibility design also means that extensions might be available publicly, encouraging re-use, thereby increasing interoperability. There are many extensions already defined at http://hl7.org/fhir/extensibility-registry.html. This design also means that healthcare organizations may use FHIR internally, and add site-specific extensions simply by making a Structure Definition available on an internal intranet site.

FHIR’s Focus Is On Implementers

It is not uncommon in the tech industry to have a collection of vendors get together, spend months defining a new standard, and then… nothing happens. The failure of standards adoption can be traced to numerous different factors. Such as changing priorities in an industry. Or, because the standards don’t address real development challenges. Or because those who set the standards don’t actually have responsibility for developing shipping products.

Not so with FHIR.

I have been incredibly impressed with not only the enthusiasm of the FHIR community but also the level of talent and expertise of the people I have interacted with who are working on the standard itself. Why has FHIR succeeded? Firstly, the specification itself is written for implementers and is easy to read and navigate. HL7 has done some amazing work to bring Agile software development principles to the task of building the standard. The FHIR community, because they are the ones working on developing systems (hands on the keyboard — writing code) are the people who show up to connectathons and HL7 meetings. Prognosticators and theoreticians need not apply. Finally, the process that the FHIR team uses to promote portions of the standard follows a FHIR Maturity Model (FMM) with 5 levels of maturity. If a part of the standard isn’t implemented and tested by independent systems and isn’t eventually used in production systems, well, it remains at lower maturity levels. If, on the other hand, it is widely adopted and used, it marches up the FMM ladder.

FHIR Is Free

Free? Yes, free. The healthcare industry has a history of declaring standards, and then stifling their growth with limiting access, requiring fees and loading up on licensing requirements. The fact that FHIR is free is a huge step forward.

You might think this is a small incremental step forward, but it’s not. Think of it this way: what do you typically do when you encounter a web site that requires a fee before you can proceed? Most of us just click on another web site. It’s a barrier to information — it’s a hassle. In the real world of engineering products, that “little” barrier is actually much higher. The fee must be paid for by the employer (with necessary management approvals), and a legal review and approval is likely required as well. What is the likelihood that your average developer is going to go through that hassle, especially when they might be in the research phase of an effort and just learning?

The FHIR spec is entirely available online and is free to use. The FHIR specification has been licensed under the Creative Commons Public Domain License, a license that permits “You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.”

FHIR Uses Modern Web Standards

FHIR makes extensive use of web technologies such as XML, JSON, RESTful APIs, OAuth, and others, making FHIR a healthcare data standard that lives and breathes in today’s modern system architectures.

A word about RESTful APIs. FHIR servers expose their capabilities via a Representational State Transfer Application Programming Interface. Using modern web technologies, this is the same style and kind of APIs that Facebook, Twitter, and Google offer their services to connect with third party applications. These APIs are very easy to learn and use, and they power many of the cool things you see on the Internet.

Human Readability Built In

One key learning from prior interoperability efforts was that the narrative in a message was exceptionally important. Meaning, the human-readable portion of a message was critical to understanding its contents. For one, it acts as an import method for implementers to quickly ask “What is in here?” without having to parse the machine-readable contents of the message. Additionally (and most importantly), there is enormous value in notes that have been generated by human brains that come from knowledge and many years of experience that are required to practice medicine. The FHIR standard includes a narrative section that is required for each resource.

Multiple Paradigm Support

Many people approaching the standard for the first time understand that a FHIR server’s capabilities are RESTful, and they assume then that FHIR is limited in scope to REST-style applications. Not true!

FHIR also supports other styles of use or other paradigm types. A FHIR server may also be used to support a document paradigm, which is quite common in healthcare when one system wants to send over a collection of resources about a patient (for example, a referral to a specialist that involves many medications, diagnoses, and procedures that make up the patient’s history). FHIR also supports the messaging paradigm which is also quite common in healthcare. Messages occur, often based on real-world events. For example, an appointment to see a patient is made, or a patient is discharged from the hospital. Finally, FHIR also fully supports the Service Oriented Architecture (SOA) paradigm.

Wonderful Community

FHIR’s strongest and most valuable asset is its community of like-minded healthcare professionals. I have had the pleasure to attend several HL7 meetings, and the people who participate in the standards process are top-notch. HL7 FHIR Connectathons, which are typically the Saturday and Sunday before a HL7 meeting is a sight to see, with over one hundred software developers attending. The FHIR community is exceptionally strong with not only Connectathons, but many publicly available test servers, chat groups, and also active participation on StackOverflow. In addition to the exceptional material on the HL7 FHIR web site, there are also many great blogs where you will find some fantastic information.

In Summary

This article introduced the background and some of the basics of FHIR. I didn’t yet touch on several other really interesting and compelling technical features of FHIR. I will leave those and other topics for future articles.

I started this article with a discussion of the nature of disruptive innovation in healthcare. There is no doubt that the nature of healthcare is changing — seemingly at once.

• Shared risk arrangements are requiring healthcare organizations to also share data in new and unique ways.
• Patients are demanding better healthcare experiences, and they are demanding their data in mobile applications.
• There is a movement toward transparency of information, especially in terms of what healthcare really costs, and why.
• The market is also seeing increased use of data analytics to help all participants in healthcare make better decisions.

FHIR will be a key new ingredient technology towards achieving these goals and enabling disruptive innovation in healthcare.

Where do we go from here?

If you work at a hospital, health plan, health IT vendor, or medical device manufacturer, FHIR is not something new that can be safely ignored. New technology initiatives should consider FHIR as a key architectural component of the solution. We will be seeing an increasing number of FHIR servers in production in the near future and the time to begin is now.

Steve Munini is Helios Software’s CEO and CTO. Connect with Steve on LinkedIn.