IEC-62304-software-by-Revolve-Healthcare-mian.webp

HL7 FHIR: Foundations in the
architectural context

6 min read

Contents

The Fast Healthcare Interoperability Resources (HL7 FHIR) standard describes how healthcare information can be exchanged between different computer systems. Seeing how already some 30% of the world’s data is generated by the healthcare industry – and a lot of it is highly sensitive – it’s no wonder this standard came into existence. Let me try to explain why it’s important andhow it works from a software developer’s perspective.

The common language for healthcare data exchange

Communication is everything. Would you imagine our world with no possibility to communicate with each other? Definitely, we wouldn’t be in the same place we are now, and it’s enough to say that we, as humankind, are still working on improving this skill (we’ve even written a whole article about the importance of good communication between software engineers and bioinformaticians).

We know how to use languages because they all are structured systems. Processors know how to execute a set of instructions that varies depending on architecture. Moving on to the world of high-level software development, there’s, for instance, the Auth0 protocol, which is about passing users’ identities (mostly) from a provider to other systems. We also have well-documented REST APIs that – for documentary purposes – may use OpenAPI specification, and thanks to that, the API consumers know how to authenticate to and communicate with it.

It makes sense that there’s also a standard in the healthcare world for information exchange. This standard is HL7 FHIR – pronounced “fire” – and it recently (2019) got a big update. It’s now way more mature and easier to implement than it used to be. And it’s a good thing it exists because we’re all much more concerned about everything that has to do with healthcare these days.

HL7 FHIR was created by Health Level Seven International (HL7), a healthcare standards organisation,and its key point is interoperability, serving the purpose of facilitating the exchange of patient data (EPR – Electronic Patient Record).

The FHIR standard consists of a lot of resources grouped into five levels

  1. Level 1 – Foundation. This level includes resources like the Questionnaire, its Responses, or a structure that embraces other resources (List).

  2. Level 2: supporting implementation and bindings to external specifications. While using FHIR resources to increase and improve interoperability, we can reference (with the help of CodeSystem resource)values to other specifications that will provide a meaningful description of a value, e.g.pointing out that we’re dealing with kilograms or meters. It’s not only about SI (International System of Units) symbols though. We can describe our data as a disease, a mental state, a heart rate or a question about a person’s stress level. Those definitions can be found in terminology systems like SNOMED or LOINC. Moreover,you can define your own public system. Also, this level defines the Exchange module that answers how others, especially healthcare applications, can communicate with your system.

  3. Level 3: linking to real-world concepts in the healthcare system. It provides resources such as Patient or Organisation.

  4. Levels 4 and 5 provide even more varied resources to facilitate record-keeping and data exchange for the healthcare processes.

Resource representation

Everything in FHIR can be expressed as JSON, XML, or RDF.

You can find an example of a questionnaire here. It’s worth noticing that the whole document is self-descriptive. For instance, item 1.1.1.1 defines an answerValueSet referring to an external terminology system that specifies three possible answers (yes / no /don’t know). Another question is described by one of the SNOMED database values pointing to an angina disorder. Some questions are conditional (property enableWhen), and some are grouped or nested.

It’s also possible to express an intention of how the question should be displayed by a set of extensions, e.g.we can define that we want to have radio buttons in a vertical orientation, like so:

     "extension": [
       {
         "url": "http://hl7.org/fhir/StructureDefinition/questionnaire-itemControl",
         "valueCodeableConcept": {
           "coding": [
             {
               "system": "http://hl7.org/fhir/questionnaire-item-control",
               "code": "radio-button",
               "display": "Radio Button"
             }
           ],
           "text": "Radio Button"
         }
       },
       {
         "url": "http://hl7.org/fhir/StructureDefinition/questionnaire-choiceOrientation",
         "valueCode": "vertical"
       }
     ],

It’s a demanding task to describe properly and in detail how our system thinks about its own data or (like in the example above) what its expectations regarding data acquisition are. But it’s definitely worth the effort because other parties will be able to interpret our data more accurately and, potentially, link them with their own.

Cloud implementation

The FHIR specification documents the RESTful API and the search engine that a compliant system should follow and implement in order to be understood by other healthcare systems (FHIR-based).

Luckily, all of the big cloud providers support the FHIR standard in one way or another. Let’s take a look at the AWS approach. AWS delivers, within AWS Solutions Implementations, a fully-fledged solution for FHIR-based systems as a CloudFormation template with an exhaustive overview of it.

It’s worth noticing that the architecture of such a solution is not trivial. In the case of AWS, it looks like this:

A diagram illustrating an AWS-proposed solution for FHIR implementation

AWS-proposed solution for FHIR implementation (source).

The solution stores all unstructured FHIR resources on AWS S3 and all structured ones in DynamoDB–from where they are redundantly streamed to the Elasticsearch engine.

Another thing is how the solution validates the correctness of FHIR documents that are sent to the RESTful API – a very important step in the system since it’s one of the things that ensure data integrity. AWS engineers have decided to use an open-source 3rd-party implementation of the FHIR specification created by the Java community – HAPI FHIR, which is the product of Smile CDR. In my opinion, it’s also the most reliable tool we can use to validate (FHIR) resources, recommended even in the FHIR docs. Other tools (mostly NPM packages) that I tried aren’t trustworthy – their results may not be correct in regard to the FHIR specification.

See the AWS GitHub repository for this solution.

Partial support

If we want to be fully compliant with FHIR, we have to use a solution like the one described above. FHIR resources are cumbersome and arbitrary, and – most likely – they don’t reflect your full system’s domain – it’s a data projection. The data represents the system’s domain from the perspective of healthcare’s common language, but it doesn’t model your processes or business requirements, nor does it constitute a business’s competitive value.

Actually, the FHIR API is just a complicated CRUD system. We can say that making software able to exchange FHIR information isn’t the goal in itself, but rather it’s a matter of having a generic domain in terms of Eric Evans’ Domain-Driven Design. Thus, probably, this part of the architecture will be separate and redundant in relation to the main application, and the data that goes there will eventually be consistent (consistent between the FHIR system working alongside the main one and receiving data from it).

But is it the only way? Sometimes the requirement is to have some data that can be exported in a common predictive format like FHIR. That data can be patient records, observations (laboratory data or vital signs), or questionnaire responses (e.g. stress level monitoring).

On the other hand, the requirement can be to import some data in a well-known format like FHIR. Imagine a situation where your system processes patients’ observations – temperature, pulse, weight, and blood pressure – to determine the risk of developing disease X. Your input comes from several clinics and hospitals, all being FHIR-compliant.

In both cases – exporting and importing of data – your application has to adapt to the common language and use a pattern like Anti-corruption Layer or Open-Host Pattern but may not necessarily need a full-fledged FHIR API.

Summing up

FHIR is a step in a good direction, trying to embrace healthcare language and its requirements while aiming for interoperability with the great support of cloud providers. But as always, there are two sides to the coin.

At the moment of writing this article, the current version of the standard is R4 (4.0.1), and version R5 is being developed (4.6.0). With every new version, some relying parties will lose compatibility with it and thus with the systems implementing it.

Besides, the FHIR specification is just a block of text, and specific implementations can vary from each other. What can help is relying on well-known external implementations, like HAPI (which I mentioned before) or SMART Health IT, the goal of which is that “an innovative app developer can write an app once, and expect that it will run anywhere in the healthcare system”.

Some differences that serve particular business purposes can also be a problem. Sometimes the interoperability isn’t necessary business-wise, as pointed out by Joseph Kvedar, M.D., the vice president of connected health at Partners HealthCare in Boston:

I work for a healthcare provider – it’s in our best interest to keep your data from going to a provider down the street. It’s in Epic’s best interest to keep your data unique so you don’t switch to Cerner. Until we see the quality of care suffer massively or see revenues drop because patients are not coming to us because of interoperability, it’s nice to have.

Joseph Kvedar, M.D.

Category:

Tags:

You may also like