Infor Healthcare

« | Main | »

Interoperability standards: Fit for Purpose

October 12, 2017

Interoperability Beyond Barriers: Second blog in a series

HL7 FHIR© is a standard that can solve all our interoperability woes. It does absolutely everything. It uses Internet protocols that allow us to securely communicate with systems both inside and outside of our networks. It provides a multitude of interoperability paradigms, including: messaging, documents, services for service oriented architectures, and of course the exalted API (Application Programming Interface). It defines both the transmission protocols (REST and SOAP) and the content format (JSON, XML, and even RDF (Resource Description Format)). It pretty much is the culmination of all the lessons learned during the development of most of the clinical interoperability standards up until today. So, we’re done, right? Interoperability is solved. Now all we must do is implement it.

Since I’m writing another blog on the topic, you’ve probably guessed it is not quite so simple. There are a lot of factors that go into choosing a standard. Just because there’s a standard that looks like it does it all doesn’t make it the right choice for every job. FHIR does make a compelling case, given all the things it supports. But, as you probably know, there is a lot more that goes in to deciding what makes a standard Fit for Purpose.

The factors to consider

Before you even start to consider standards, be sure you understand the problem you’re trying to address. Don’t start with the technology or the next shiny new object. Instead, start with defining and understanding your use case. Who are the users and stakeholders? What are the needs and requirements? Only after clearly defining your use case and business objectives should you consider the tools you should apply to accomplish them.

Once the project is defined, there are several factors one needs to consider before choosing standards to meet the goals. (Please note that for this post, I will be referring to both standards and specifications as standards). Fortunately for us, the US Office of the National Coordinator for Healthcare IT (ONC) releases a yearly review of standards called the Interoperability Standards Advisory (ISA). The ISA reviews the standards from the viewpoint of the ONC to help guide future policy and regulations as they relate to standards. This viewpoint may not entirely translate to the needs of a healthcare organization, but it can help get things started. While this review is US centric, many of the findings can apply elsewhere in the world. The ONC is currently looking for comment on their draft 2018 “Reference Edition” by November 20. I encourage everyone to review the draft and provide comment back to the ONC.

For healthcare organizations looking for a standard to meet a specific interoperability need, the ISA may be a good place to get some insight, but I would propose some additional factors to consider:

  • Users and stakeholders. Who are the actors and what method of interaction best works for their systems of use (e.g. enterprise server, mobile, device, etc.)
  • Workflow requirements. In what way do the users and stakeholders need to interact? Is there a particular interoperability paradigm (push/pull, pub/sub, messages, documents, complex workflows) that is required?
  • Do you currently have a large investment in HL7 v2 messaging? Does it make sense to rip and replace? What is the cost/benefit of change? Is a change required or can I employ a solution to help bridge the gap between standards?
  • System capabilities. This, being in line with investment, is about what your current systems support. Do these systems support your preferred standard? If not, there are options to assist you (more on that below).
  • Ease of implementation. How difficult is it to implement? Not all standards are easy to understand or implement. Some offer too much “openness” and are left to interpretation, which could lead to a large variability in how they are implemented and could leave systems nearly non-interoperable.
  • Evidence of success. Has the standard been used for this purpose before? This is in line with maturity of a standard, but is specific to the use case. If the use case is cutting edge, it may not be possible to find a standard that is mature.
  • Are large volumes of transactions or many communicating actors a requirement and if so, how well does the standard enable systems to handle that?

A review of standards

Now that we have some factors for use standards consideration, let’s look at some common clinical standards used today that have some functional overlap. Which standard should be chosen? That depends on the use case. Note that this review is at a high level and that each standard has strengths and weaknesses in different domains, not to mention that there are implementation guides for standards that may provide a better solution. Note that there are always exceptions to the general observations.

Benefits and drawbacks of HL7 messaging (HL7 v2)

  • Mature, well understood, and commonly used for intra-enterprise messaging
  • Good for large volume data transactions (optimized parsers, low encoding character overhead)
  • Trigger and action based collections of information where trading partners and systems are largely pre-established with externally managed or implied authentication/authorization schemes.
    • Limited use beyond the enterprise for such areas as lab orders and results, public health, and sometimes wrapped in APIs for a specific purpose (e.g. IHE)
  • Largely limited to push transactions (limited query or subscription capability widely supported in major systems)
  • Certain transactions required for CEHRT (Certified EHR Technology under the Meaningful Use program)

Benefits and drawbacks of documents (C-CDA)

  • Good for external communication of a predefined set of information (e.g. visit summary, full clinical summary, discharge notes, etc.)
  • Patient identity is managed externally (e.g. in an HIE)
  • C-CDA is a requirement for CEHRT (CCD, Discharge Summary and Referral Note containing the Common Clinical Data Set)
  • Support metadata and human readability
  • Complex standard with wide amount of interpretation leading to quality issues
  • Not ideal for large volume data transactions (document size and complexity increases processing requirements)
    • Largely used for data push workflows to data repositories or sent via Direct (data source determines what data is provided), which can lead to too much data or not the right data
  • When being used in on-demand workflows, document creation can cause latency due to the size and complexity of the information included in a complete document

Benefits and drawbacks of FHIR

  • Uses the “language” of cloud-based technologies (JSON/REST, XML/SOAP)
    • Easier to manage interoperability across the Internet
    • Supports interoperability with web apps, mobile apps and devices
  • Supports object level data access in the form of resources (as opposed to documents and messages, which often contain numerous types of data in one transaction)
  • Supports messaging and document paradigms
  • Enables organizations to interoperate clinical, financial, and operational data more easily with one standard
  • Accelerates development with relatively fast development time, simplicity (easy for implementers to understand), and availability of tooling (JSON & FHIR frameworks)
  • Offers more holistic query capabilities across all resources
  • Supports metadata and human readability
  • Supports flexible workflows
  • Enables the receiver to retrieve what is needed through APIs (with proper access controls)
  • Lacks scalability for large volume data transactions as the standard has been developed historically focused on granular transactions (A proposal by Grahame Grieve and the FHIR community intends to address this in the future version).
  • Lacks maturity regarding real world use—many lessons remain to be learned in its use.

All or nothing?

So, which standard should be chosen? Is this an all or nothing option?

As FHIR gains use, we will see more systems supporting it and the maturity of the standard improve. The level of support each system will have for the standard will vary and take some time to increase. Some systems may never support FHIR, because what works now meets the requirements and there is little benefit to replacing everything, and that may lead to a digital divide among your system. So, the choice of a standard becomes even more difficult.

All systems using the same standards or even the same version of standards that a healthcare organization needs to interconnect is not right around the corner. The picture gets even more complex with devices and mobile apps. Fortunately, there are opportunities to bridge this digital interoperability divide. With solutions like the Cloverleaf Integration Suite, healthcare organizations can enable systems speaking with many different specifications to interoperate. Infor also will be releasing a new product, called FHIR Bridge, that will specifically address enabling legacy and traditional clinical systems, often speaking HL7 v2 and C-CDA, to connect into a FHIR-based ecosystem and vice versa. This solution will come with pre-built adapters to enable communication across systems for several continually growing use cases.

Let Infor and Cloverleaf help you bridge the digital interoperability divide. Feel free to contact us for more information.

“FHIR® is the registered trademark of HL7 and is used with the permission of HL7.”

Corey Spears, Director of Healthcare Interoperability Standards for Infor Healthcare

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *



About this Blog

Infor's healthcare experts are on hand to share relevant information that matters to Infor healthcare customers.

- See more at: About the authors

Follow

RSS Feed
By Email
Facebook
LinkedIn
Twitter
YouTube