The Arrival of True Interoperability and
What it Means for Healthcare

This document details how Carefluence adopted FHIR® to facilitate True Interoperability in a healthcare ecosystem.


This white paper discusses Carefluence software architecture and the architect’s view of True Interoperability for Healthcare, how the Carefluence platform successfully implemented FHIR® for the benefit of healthcare communities.


Journey into Healthcare Interoperability

This section discusses the need for True Interoperability, integration choices, and shows how the Carefluence platform evolved over time to support Internet of Interoperable Things™ Services.

About Carefluence

The team behind Carefluence has had its initial experience rooted in the area of Electronic Health Records and Revenue Cycle Management. After more than 15 years of experience in the healthcare technology arena, they experienced firsthand the need for a streamlined interoperability solution for community healthcare. The Carefluence platform was produced for healthcare interoperability to support the sharing of data with Hospitals, HIEs, Registries and Clearing Houses.

Carefluence is enriched with a decade of healthcare knowledge of physicians, payers, practices, hospitals and the allied technologies to support the creation of vast repositories of patient data. With each EHR implementation, the Carefluence team had learned how to capitalize on the data to make better decisions and improve outcomes. Integrations with other systems have broadened the understanding of interoperability and its practical challenges.

Interoperability Challenges

Most community healthcare systems functioned at the point of care but often failed to share their data easily with others, either due to their technology, infrastructure, or network. During the very early stages, the Carefluence team knew that the root of interoperability challenges was not with data formats or the evolving HL7 standards, but with the missing ‘best-practices’ in integrations with other systems within the healthcare industry. This has often resulted in customizing integrations and maintaining them constantly in laborious detail. Undoubtedly, these kinds of integrations are still popular throughout the healthcare industry and create tightly coupled connections from one point to another. The Carefluence product aims at making these integrations more consistent and simpler to maintain.

The Spark: Creation of the Hub

In early 2013, Carefluence developed a community hub on top of its platform for a hospital in order to connect all the clinics within the hospital community and share the patient data back and forth. When designing the Carefluence software for this community hub, it was important not to develop a limited point-to-point integration. A flexible interoperability option was necessary for future integrations and for all the systems within the hospital community to maintain low maintenance and shortened lead-times to go live.

One of the key components of the Carefluence Community Hub platform was to provide its own Open Application Programming Interfaces (APIs). The Carefluence OpenAPI stack facilitates integrations at the EHR vendor-level to maintain every version change of the EHR and deploy the changes as hub plugin versions compatible with each connected EHR version. The Carefluence OpenAPI enables the development of health IT applications for the community benefits that are not directly covered by EHRs. The goal was always to provide a true value of interoperability, such as the ability to simultaneously access different systems, no matter how the data is stored. Carefluence’s value proposition is to make interoperability available at the point of care and to meet users where they are with a special emphasis on availability, even on a mobile infrastructure.

Catching FHIR® and the Internet of Interoperable Things™ Services

In early 2014, the Carefluence team was introduced to HL7 FHIR® and evaluated the FHIR® roadmap with Graham Grieves, architect-developer of FHIR®, at HIMSS 2014. From this conversation, it was apparent that discontinuing the development of its own APIs and adopting FHIR® was beneficial to the future of Carefluence’s OpenAPI and its platform’s applications. Today the Carefluence OpenAPI is a production ready platform and a living example of a complete FHIR® implementation in its core strategy towards the Internet of Interoperable Things™ around any healthcare system or medical device.


About Carefluence OpenAPI Platform

The Carefluence OpenAPI platform adopted HL7 FHIR® in its core strategy to offer innovative solutions as Internet of Interoperable Things™ Services around any healthcare system or medical device.

The FHIR® Standard has brought a resource approach to the Carefluence OpenAPI platform’s information model (For example; Patient, Condition, Procedure, or Immunization), which is more granular than any other standard and fast to learn, develop, and implement solutions.

Carefluence OpenAPI Platform

Components of Carefluence OpenAPI Platform

This section briefly discusses all of the components that make up the Carefluence platform to support Internet of Interoperable Things™ Services.

  1. OpenAPI Portal: Web based application to manage the Carefluence platform completely online. These features include the Healthcare Community Management, Clinical dataset exchange options, OpenAPI authorization management, FHIR® Transformer with HL7 mapper, SMART on FHIR® client, Sandbox Environment, Resource Server search, and Patient data viewer.
  2. Authorization Service: Web-based SMART authorization and resource retrieval service developed on oAuth2.0 specification.
  3. RESTful Resource API: Healthcare data (For example; Patient, Condition, Procedure, or Immunization) is securely hosted as resources on a web server. All these resources can be searched and operations such as update, create or delete are implemented as specified by FHIR® DSTU2 standards.
  4. FHIR® Transformer: Server side component that takes CCDA or HL7 V2 messages as input and convert them into FHIR® resources accessible via RESTful Resource API.
  5. Embeddable Viewer plugin: A default embeddable patient data viewer is provided and can be customized using CSS and XSLT.
  6. HL7 Interface Engine plugin: Add-on modules to use with Mirth connect or Intersystems cache as the HL7 interface engine.
  7. OpenAPI database: Database agnostic storage for the Carefluence platform that is tested with MS SQL server and Cache. Based on the Carefluence implementation strategy, there is an option to choose Oracle, MySQL, or PostgreSQL.
  8. Authorization database: MS SQL server Data store to manage oAuth tokens and client application registrations with their authorization status.

Supporting Meaningful Use Stage 3 OpenAPI requirements for EHRs

At the heart of the Carefluence OpenAPI platform, HL7 FHIR® DSTU2 standard is rooted and adopted completely to offer Internet of Interoperable Things™ Services. EHR companies can license the Carefluence OpenAPI platform and configure it to work seamlessly to meet Meaningful Use Stage 3 requirements as listed below:

  1. OpenAPI allows other health IT applications to make read only data requests for patient health information that is part of the Common Clinical Data Set.
  2. API interface will utilize the requirements set forth in §170.315(d)(1) Access Control and Authorization and §170.315(d)(9) Trusted Connection to securitize external connections to verify requests originate from trusted and authorized sources, and provide for privatized responses.
  3. HIT is responsible per §170.315(d) (2) Auditable Events or §170.315(d) (10) Auditing Actions on Health Information to audit events associated with external API access.
  4. API interface would allow a request for “all” the patient data, or specific “by specific data category”. Available data via the API interface is limited by the data defined by the Common Clinical Data Set.
  5. Supports CCDA, HL7 messages import via OpenAPI.
  6. Provides technical documentation of API that would include, at a minimum, API syntax, function names, required/optional parameters and their data types, return variables and types/structures, exceptions and exception handling methods and their return types.

Implementation of Internet of Interoperable Things™ Services

The following diagram is a representation of the implementation of Carefluence and Internet of Interoperable Things™ Services. This is a real-world implementation of accessing patient data from EHR and providing, in real-time, evidence-based clinical decision support for that particular patient.

Implementation of Internet of Interoperable Things™

Actors in the Implementation of Internet of Interoperable Things™ Services

In the current implementation of evidence-based clinical decision support, Carefluence has the following actors. The Carefluence OpenAPI platform with HL7 FHIR® DSTU2 standard was used to accomplish the complete use case.

  1. ModuleMD EHR was enhanced to add the following capabilities:
    • Included Carefluence FHIR® server as a native FHIR® component and implemented limited resources to be searched or queried from any SMART on FHIR® client. This feature helped the ModuleMD® EHR to connect with Carefluence OpenAPI platform and respond to read requests for Patient, Condition, Procedure, Practitioner and Appointment resources.
    • From the clinical summary of a patient chart, a CCDA is sent to the Carefluence OpenAPI platform. A trigger automatically launches the FHIR® transformer component of the Carefluence OpenAPI platform. This results in the conversion of the segments of CCDA into an equivalent FHIR® resources.
    In both the cases, the patient data from the EHR was instantly made available for other connected SMART apps.
  2. SMART on FHIR® Applications were developed to connect with Carefluence OpenAPI platform to authorize and access the patient data from the EHR and retrieve the corresponding suggestions from the Rules Repository authored with another SMART on FHIR® app called Carefluence Process Modeler.
    • Carefluence Patient Portal app: single patient record from EHR and suggestions corresponding to that patient
    • Carefluence CDS app: evidence-based clinical decision support for multiple patients and full search capability on all supported FHIR® resources
  3. Carefluence OpenAPI platform is an essential actor in the middle of all the Internet of Interoperable Things™ Services (For more details, refer to the Components of Carefluence OpenAPI Platform).

Concluding Remarks

This section discusses the value of using the Carefluence OpenAPI platform and the benefits of implementing FHIR® standards to provide true interoperability with Internet of Interoperable Things™ Services

  1. Carefluence OpenAPI platform adopted HL7 FHIR® standards as its core interoperability strategy. Besides supporting backward compatibility with HL7 V2 and CCDA formats, everything will be normalized as appropriate FHIR® resource. This standard brought simplicity and flexibility to the Carefluence platform. The word Fast in FHIR® truly means fast; faster to learn, develop, and implement. Carefluence was able to successfully adopt the FHIR® standard within just one year.
  2. Developing Health IT applications with Carefluence OpenAPI platform is quicker and deployment lead times are shorter too.
  3. The SMART on FHIR® application paradigm is followed while connecting with the Carefluence OpenAPI platform and therefore applications are substitutable and quick to integrate.
  4. The Carefluence journey into interoperability and experience with EHR implementations has helped develop a real world use case implementation of evidence-based clinical decision support.
  5. The Carefluence team is progressive and committed to exploring the development of SMART Applications around any healthcare system or medical device.
Any use of FHIR® within this document is the registered trademark of Health Level Seven International.