Currently Azure Logic Apps does not support HL7 using the Microsoft built eco-system of connectors. Implementing Azure Logic Apps within a health setting would be hard when the majority of systems use one of the HL7 data standards for interoperability. However, Azure Logic Apps does support other approaches, either through ported BizTalk functionality, or logic apps code extensibility, to enable HL7 support.
This article aims to highlight some options to think through HL7 interoperability using Azure Logic Apps, and details a specific solution that was used and implemented in a real-world commercial environment.
Health Level Seven (HL7) is a set of international standards for transferring clinical and administrative data between healthcare systems. HL7 provides guidelines and a framework for the integration, exchange, and retrieval of electronic health information (EHI). It ensures that healthcare information systems can communicate with one another efficiently and accurately.
This article deals with the HL7 2.7 standard which is a specific flat file structure with the usual records, delimiters and complexities around needing to convert it into a data format that is easy to transform.
HL7 FHIR is a standard that supports the modern interchange of HL7 data using XML or JSON as the underlying data structure which provides support for REST based services. This article does not deal with FHIR, but it would make sense for any modern HL7 solution to review the using FHIR.
For this article, we need to have a basic understanding of flat file structures and the HL7 ADT messages. ADT stands for Admit, Discharge and Transfer, but represents the possible set’s of message that cover health business events. For example, ADT01 is Admit, ADT02 is Transfer, ADT03 is Discharge, ADT04 is Register and so on. Each ADT message is made up of reusable segments (records) that can be used across the ADT message types. For example there is Message Header Segment (MSH), Patient Identification Segment (PID) and more.
Azure Logic Apps standard has many features and connectors that can enable the quick and easy integration of systems. There is support for many specific systems via the connectors, that most of the time it will be very easy to find one. See references for link to list of connectors.
There will be scenarios when an out of the box action or connector will not be adequate, and you will need to use other approaches. Some other approaches supported by Logic Apps extensibility where we might consider implementing HL7 functionality could be as follows:
Feature options:
Most HL7 systems use a single endpoint/connection to process all ADT message types. If this model was implemented using Logic Apps, then that workflow would be responsible for detecting the ADT type and then processing the different messages appropriately.
If there was a workflow per ADT type, then each ADT could be operationally managed easily using out of the box workflow enabling/disabling, along with minimising changes to all ADT processing.
Azure Logic Apps supports the same flat file XSD assembly and disassembly functionality that BizTalk Server was based on. It is a very compelling no code option that supports the conversion between a flat file and an XML representation. This same functionality used within Logic Apps can serve the function of converting a HL7 flat file into an XML document. The HL7 standard is quite comprehensive and therefore the XSD documents required to support the standard are many. If the HL7 implementation varies slightly from the standard, updating the XSD’s is required.
The other option is to build the code from scratch in .NET which is more work, but you can have more control over performance, support and variations to the standard easily and generate JSON instead of XML.
The last consideration is to determine on where the HL7 logic should reside. This is driven mainly by the level of reuse required. The HL7 logic could be used within:
The level of reuse required by out implementation is to reuse it across multiple workflows within a single Logic Apps Standard Tenant.
This meant that using custom code extensions was a suitable level of reusability without needing anything more complicated.
Microsoft announced Preview support for Custom Code in Azure Logic Apps Standard in 2023(see references for article). This feature enables developers to write custom logic in .NET code within a Function App. That Function App can then be called from within the Azure Logic App workflow. To do this, you will need to use the “Call a local function in this logic app” action.
The referenced article show more details about this, but the code needs to be in the form of a Function. If you use the VS Code Logic App workplace, some boiler code is created that can be used to get going quickly.
Initially when this solution was built, we used .NET 472. We found that our performance in high concurrency was causing the environment to start giving 503’s. On investigation we found the following for our .NET component.
We need to refactor the component to use less reflection, but something we could do quickly was upgrade it to .NET8. ON doing this we noticed a significant drop in allocated memory.
.NET 8 has been supported in Logic Apps Standard since 2024 so upgrading the underlying .NET library would not be an issue.
Implementing HL7 interoperability in Azure Logic Apps requires careful consideration of architectural choices, including whether to use a single HL7 onramp or separate endpoints per ADT type, how to handle HL7 disassembly, and where to implement the core HL7 logic. By leveraging Azure Logic Apps' extensibility features, particularly custom code extensions, organizations can overcome the platform’s lack of native HL7 support while maintaining flexibility and control.
Our approach demonstrated that integrating HL7 within Azure Logic Apps using .NET 8 custom code extensions provides a scalable and reusable solution. This method ensures high performance, simplified maintenance, and better adaptability to variations in HL7 standards. With proper exception handling, testing, and deployment strategies, this approach can enable seamless interoperability between healthcare systems while leveraging the power of Azure cloud services.
As healthcare organizations continue their digital transformation journey, solutions like this will be crucial in bridging the gap between modern cloud-based integration platforms and established healthcare messaging standards. By combining Azure Logic Apps with custom code extensibility, enterprises can achieve robust HL7 integration while benefiting from Azure’s scalability, security, and manageability.