In this blog series, I will show you how to create a simple custom EHR to HL7 FHIR integration using the latest Microsoft tech stack. The series is divided into three parts. In this first article, I will introduce you to the HL7 FHIR standard and the .NET 5 framework – what they are and why I use them. In the second post, I will share how to integrate Patients, and in the final part, I will describe how to integrate Patient Observations (blood tests).

INTRODUCTION

If you are developing healthcare software, you are bound to be asked whether your software supports electronic health record (EHR) integration. Most EHR vendors offer a variety of integration pathways into their EHR system. These vary in terms of requirements, technology, and the specific information available from each. Many EHRs also have their own third-party apps, which may offer information and specific capabilities to organisations that wish to integrate with their EHR.

EHR integration can be achieved using HL7 FHIR. Here are some of the benefits:

• The specification is free to use; unlike other HL7 standards, which were not freely available until 2013, the specifications for FHIR are 100% accessible without a login or any restrictions.
• It supports RESTful architecture: REST APIs make sharing simpler and easier; they provide additional tools to easily communicate with the data source in different ways, such as GET, POST, PUT, and DELETE commands.
• Data sharing is made simple with FHIR as every resource is linked with a unique identifier.
• FHIR is developer-friendly; it employs many modern web technologies that developers are already familiar with, such as HTTPS, REST, XML, JSON, ATOM, and OAuth.
• It is fast and easy to implement; developers can have a simple interface up and running in just a few days. Using the best integration engine, this can be done even faster.
• FHIR is built on the concept of resources; these resources have a common definition and method of representation, a common set of metadata, and a human-readable component.
• FHIR is well-suited for mobile use since it utilises technologies that mobile devices readily and easily support, such as HTTP REST and JSON.
• FHIR is an open-source standard with a large community of experts who are willing to help you with complex problems.

Now, let’s dive into more details and why it is sensible to combine the HL7 FHIR standard with the .NET 5 framework.

HL7 FHIR AND .NET 5

What do you need to know about the HL7 FHIR standard? Here is a short overview of the HL7 FHIR standard and development tech stack.

About the HL7 standard

Health Level 7 (HL7*) is a set of standards which outline the international requirements for APIs intended to transfer administrative data between healthcare-related software applications. The organisation behind the standards, Health Level Seven International, is a not-for-profit founded in 1987 with a mission to advance global health interoperability. For more information, visit the introductory guide to the HL7 standards.

What does FHIR stand for?

Fast Healthcare Interoperability Resources (FHIR*) is a set of standards for APIs that outlines the data formats and elements the APIs must possess to exchange EHRs from one application to another. The FHIR standards were created in 2012 by Health Level Seven International as a response to the market need for more efficient health data exchange processes. For more information, check out HL7's FHIR resources.

Why is FHIR important?

Currently, the predominant method for exchanging clinical data between healthcare applications is known as HL7v2, and it presents us with serious challenges. Organisations spend huge amounts of money per HL7v2 interface, not to mention the cost of licensing fees for the implementation and use of integration engines. Why do we need an integration engine? Here’s why:

HL7v2 is not an open standard. You need to be a member of the HL7 organisation and pay fees to be allowed to use their content commercially. HL7v2 is also an outdated standard. It was developed in the late 1980s, in a period when a lot of things we take for granted today didn’t even exist – mobile phones, emails, etc.

This resulted in the widespread “I’ll just do it my way” approach, which caused an outburst of HL7v2 variants – or as I like to describe it: “Welcome to the jungle!”

Given the issues above, FHIR does offer many improvements compared to previous standards:

• Open source: this is a big improvement and the primary effort in making healthcare integration more transparent and accessible. Putting it out in the open has created a large and engaged community including developers, vendors, and enterprises.
• RESTful: REST-based design is significantly beneficial. An API that adheres to the principles of REST does not require the client to know anything about the structure of the API. Rather, the server needs to provide whatever information the client requires to interact with the service.
• Good documentation: Being uniquely driven by the RESTful API approach, it enforces good documentation as a by-product.
• Supports modern web standards: XML, JSON, HTTP, Atom, OAuth, REST – these are the underlying technologies that FHIR leverages. All of them are battle-tested and have been proven at scale and with strong security requirements.
• Extensible: extensibility within the RESTful context ensures that additions can be easily made to cover specific use cases without impacting the core models.
• Composable: composability ensures that almost any request can be assembled using core models or resources and associated extensions.
• Human readability: every resource includes a human-readable text representation using HTML as a fallback display option. This is particularly important for complex clinical information where many systems take a simple textual or document-based approach.

Security

FHIR is not a security protocol, nor does it define any security-related functionality. However, FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere. All exchanges of production data should be secured using Transport Layer Security (TLS), for example HTTPS.

FHIR defines a Security Label infrastructure to support access control management. FHIR may also define a set of resources to administer access control management but does not define any at present. Users/clients must be authenticated to use FHIR; for web-centric use cases, OAuth is recommended, for which an OAuth profile will be needed in turn.

Why do I use .NET 5?

I am from the .NET world and because of that, my natural choice is to use the Microsoft tech stack. With version 5, it has become an open-source framework, available on GitHub, with a cross-platform runtime. We can build and execute .NET 5 applications on Windows, Linux, or even Mac OS X. Version 5 also incorporates these .NET Core functionalities and benefits:

• Supports all key platform features for .NET Core, Xamarin, and .NET Framework
• Open source and community-oriented
• Fast, scalable, and high performance
• Support for future updates to Visual Studio Code, Visual Studio 2019, Command Line Interface, and Visual Studio for Mac
• Support for platform-specific features like Windows Forms and Windows Presentation Foundation (WPF) on Windows side-by-side installations
• Smarter deployment and packages
• Small project files

Supported by all these features of HL7 FHIR and .NET, I started looking for a suitable library based on this technology. And I found it! It is an excellent Firely .NET SDK library.

Firely .NET SDK

Firely .NET SDK is the official support SDK for working with HL7 FHIR on the Microsoft .NET platform. Firely is the original author of and main contributor to the official HL7 FHIR reference implementation for Microsoft .NET. The SDK fully supports the latest release of the FHIR spec R4 (published January 2019). This library provides:

• Class models for working with the FHIR data model using POCO’s XML and JSON parsers and serialisers
• A REST client for working with FHIR-compliant servers
• Helper classes for working with specification metadata and generating differentials
• Validator to validate instances against profiles
• Evaluation of FHIR path expressions

The documentation for the Firely SDK is available here.

In the next post, we will look into FHIR Patient resources, the development environment, solution architecture, etc.

ADDITIONAL RESOURCES

HL7 FHIR
HL7 FHIR resources
HL7 FHIR Restful API specification

* HL7® and FHIR® are registered trademarks of Health Level Seven International.