Build HL7 healthcare integrations with Standard workflows in Azure Logic Apps (preview)

Applies to: Azure Logic Apps (Standard)

Important

This capability is in preview and is subject to the Supplemental Terms of Use for Azure Previews.

To build automated integrations for healthcare systems or migrate from BizTalk Server to Azure Logic Apps, use the HL7 built-in connector operations in Standard logic app workflows. This connector lets your healthcare organization continue to use their existing healthcare solutions and create new healthcare integrations in Azure Logic Apps.

This guide shows how to use the HL7 connector operations in Standard workflows. In this guide, the examples use the Azure portal, but you can create Standard workflows with these operations in Visual Studio Code.

Healthcare integrations with Azure Logic Apps

Healthcare organizations are complex businesses with different departments that work together. For example, hospitals have areas like admissions, doctors, nursing stations, laboratories, and billing. Each area produces and uses various kinds of data. For example, this information includes patients, medical procedures, medications, and billing charges, which multiple departments must often share. Healthcare systems face major challenges in providing efficient ways for departments to exchange this data with each other.

The Health Level 7 (HL7) protocol v2.x family defines widely adopted messaging standards across clinical systems such as EHR, LIS, RIS, and HIS. The protocol facilitates communication by providing data exchange standards across healthcare apps. These standards eliminate or reduce custom interface programming and program maintenance.

Despite modern standards such as Fast Healthcare Interoperability Resources (FHIR), HL7 v2.x continues to dominate in real-time clinical workflows, such as admission, discharge, and transfer (ADT), lab results handling, and billing processing, for the following key reasons:

Reason Description
Interoperability backbone HL7 v2.x is deeply embedded in existing clinical systems.
Acknowledgment support ACK/NACK patterns help ensure delivery confirmation critical for patient safety and auditability.
Low complexity Text-based, predictable segments simplify development and maintenance versus more complex service-based protocols.

Common HL7 message types include:

Conceptual diagram shows common HL7 message types such as ADT, ORM, ORU, EFT, and EPR.

  • ADT: Admission, discharge, and transfer
  • EPR: Electronic patient record
  • ORM: General order message
  • ORU: Unsolicited observation results
  • DFT: Detailed financial transaction

Connector technical reference

The HL7 connector operations are available in all Standard workflows.

Operations

Operation Type Description Parameters
Encode HL7 Action Convert XML to a flat file. - Message to encode: The HL7 message to encode. Required, String
- Header to encode: The HL7 header to encode. Required, String
Decode HL7 Action Convert a flat file to XML. Message to decode: The HL7 message to decode. Required, String

Supported and unsupported behaviors

Support level Behavior
Supported - v2.X message handling with validation up to v2.6 and BizTalk schema releases up to v2.6.
- Individual message processing.
- Acknowledgment parsing for versions 2.4, 2.5, and 2.6.
- Only need to upload message schema.
- Z segments support requires updating schema with Z segments node.
Unsupported - Batch messages processing.
- ACK generation and ACK support for versions lower than 2.4.
- MSH overrides and partner specific configuration.
- Z segments support without schema updates. Dynamic discovery isn't supported.

Prerequisites

  • HL7 flat file schema and all the BizTalk schemas referenced by your HL7 schema.

    You must upload all these schemas to your integration account. However, unlike BizTalk Server, you don't need to upload the following common schemas:

    • Message headers: MSH_25_GLO_DEF.xsd
    • Acknowledgments: ACK_24_GLO_DEF.xsd and ACK_25_GLO_DEF.xsd

    The following example shows the ADT_A01_231_GLO_DEF.xsd schema and the following dependencies:

    • datatypes_21.xsd
    • segments_21.xsd
    • tablevalues_21.xsd

    Screenshot shows integration account with HL7 schemas.

  • A Standard logic app resource and workflow to use for your healthcare integration. See Create Standard logic app workflows in Azure Logic Apps.

    The HL7 connector doesn't have triggers, so you can use any trigger that works for your scenario.

    This guide uses the Request trigger named When an HTTP request is received. You can then add HL7 connector actions.

Limitations

In this release, the following limitations apply:

  • The HL7 connector requires that you upload your schemas to an integration account.

  • This implementation supports only single message processing.

Add an Encode HL7 action

Follow these steps to add the Encode HL7 action and set up the necessary parameters:

  1. In the Azure portal, open your Standard logic app resource. Open your workflow in the designer.

  2. If your workflow doesn't have a trigger, follow the general steps to add the trigger that best suits your scenario.

    This example continues with the Request trigger named When an HTTP request is received, for example:

    Screenshot shows Azure portal, Standard workflow designer, and Request trigger.

  3. Follow the general steps to add the HL7 built-in connector action named Encode HL7.

  4. On the designer, select the added action, if not selected. In the action pane, provide the following information:

    Parameter Required Value Description
    Message to encode Yes <message-to-encode> The HL7 message content to encode.
    Header to encode Yes <header-to-encode> The HL7 message header to encode.

    For example:

    Screenshot shows Encode HL7 action parameters.

  5. Save your workflow. On the designer toolbar, select Save.

Add a Decode HL7 action

Follow these steps to add the Decode HL7 action and set up the necessary parameters:

  1. In the Azure portal, open your Standard logic app resource. Open your workflow in the designer.

  2. If your workflow doesn't have a trigger, follow the general steps to add the trigger that best suits your scenario.

    This example continues with the Request trigger named When an HTTP request is received, for example:

    Screenshot shows the Azure portal, Standard workflow designer, and Request trigger.

  3. Follow the general steps to add the HL7 built-in connector action named Decode HL7.

  4. On the designer, select the added action, if not selected. In the action pane, provide the following information:

    Parameter Required Value Description
    Message to decode Yes <message-to-decode> The HL7 message content to decode.

    For example:

    Screenshot shows the Decode HL7 action parameters.

  5. Save your workflow. On the designer toolbar, select Save.

BizTalk migration notes

Since the first BizTalk Server release, Microsoft provides support for healthcare scenarios. BizTalk Server helps organizations develop business processes across healthcare computer systems by using Microsoft BizTalk Accelerator for HL7 (BTAHL7), the HL7 standard, and the Minimal Lower Layer Protocol (MLLP) for messaging.

BizTalk Server uses a disassembler pipeline to split HL7 messages into header, body, and custom segments. Azure Logic Apps exposes these messages as fixed outputs. This behavior simplifies HL7 message handling by avoiding multipart message complexity unless the number of parts varies.

The following table compares BizTalk Server with Standard logic app workflows in single-tenant Azure Logic Apps:

Aspect BizTalk Server Standard workflows
Pipeline disassembly Separates header, body, and custom segments. Action outputs directly provide structured values.
Schemas HL7 schemas + global header or ACK schemas uploaded. Upload HL7 message schemas and dependencies. Doesn't require header or ACK common schemas.
ACK handling Generation and parsing through pipeline components. Parsing for HL7 ACK/NACK (2.4–2.6). Generation isn't supported.
Z segments Supported through schema customization. Supported when Z segments exist in uploaded schema, but without dynamic discovery.