Playing with FHIR

By September 25, 2019 No Comments
Playing with FHIR

Playing with FHIR

FHIR Background

HL7’s Fast Healthcare Interoperability Resources (FHIR) specification is a standard for the structure and exchange of healthcare information.  FHIR provides a structured approach to express a broad range of common clinical concepts from Patient and Doctor to claim and clinical quality measure as a set of atomic “resources”.  The standard is free to use.  It leverages existing standards that fuel today’s web-based interoperability, such as JSON, HTTP, OAuth and RESTful APIs. HL7 relies on input from a broad range of stakeholders to establish and refine the standard which recently reached a milestone with publishing of v4.0.0, the first normative version of the standard.  Additionally, CMS is embracing FHIR in the form of public-facing FHIR APIs (e.g. BlueButton 2.0, Data at the Point of Care) while promoting its use to support interoperability (see 21st Century Cures Act and related federal rules).

FHIR Connectathon 22

A small team from Bellese recently traveled to Atlanta for the HL7 FHIR Connectathon 22.  Every quarter HL7 hosts a FHIR “Connectathon”.  The purpose of the a Connecthaton is to test emerging and draft positions of the FHIR standard by implementing and testing them in software.  The efforts are divided into many tracks, each focused on a different segment of the FHIR spec or use case.

Connectathon 22 was just held over a weekend (9/14 & 15/19)  in Atlanta with over 400 attendees and 30 tracks. Bellese attended and participated in the Clinical Reasoning Track (includes measure specification and computation).  In this track our focus was to implement and thereby validate the not-yet-standardized $import function (see Bulk FHIR Standard) to support the use case where a provider or vendor submits bulk FHIR data in support of clinical quality measure calculation.

Our effort 

The Bellese team built a simple proxy server (available on GitHub) that accepted bulk FHIR data per the emerging standard them made the many individual API calls to another, existing FHIR server to store each element of the bulk data file.  In support of this, we worked with other track members to build a flexible and high performance solution. Late Saturday afternoon a break-out session and follow-up discussion led to changes in the proposed standard.

Our solution solution was flexible enough to accommodate these changes with little to no code changes. The performance of the solution caused some pleasant problems in our testing. The $import draft standard includes specification of how the receiving server should communicate progress of the asynchronous process.  While the solution supported this specification, our tests with a 25 MB data file could never prove that we adhered. The server routinely replied immediately and correctly indicated the $import was complete. The solution was so fast; it was never “in progress”.


It was exciting to be part of an international standards-making process that embraced the “fail fast” and “learn by doing” mantras. We’re looking forward to being part of future Connectathons as we work with CMS to modernize their systems.