<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
RSS Feed

Architecture | Matjaz Bravc |
29 June 2021

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).


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.


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.


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.


HL7 FHIR resources
HL7 FHIR Restful API specification

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

Matjaz Bravc

Senior Developer

Matjaz is a Senior Software Engineer with more than 15 years of experience in designing and developing scalable applications in an Agile manner. His experience ranges across various fields and technologies (mostly Microsoft stack), and he is an expert .NET developer with strong backend C# development experience. His expertise also includes mission-critical distributed systems with a strong focus on object-oriented programming, microservice architecture, data warehouse design, and test-driven development. Matjaz likes to spend his free time away from the computer, with hobbies such as scuba diving, canoeing, standup paddling, and mountain biking.


From This Author

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2



  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture