In the October 2025 release of Oracle Integration (release 25.10), we have added several new features in the Healthcare Edition to enhance reliability, improve developer productivity, and improve standards support. These include:

  • Batch processing of files with multiple HL7 messages 
  • Guaranteed order delivery for HL7 messages 
  • Support for HL7 CDA documents

 

HL7 Batch Processing

To greatly reduce the amount of work the developer must do to process files with multiple HL7 messages, we have added a new operation to the healthcare action in the developer pallet. You can now choose the Split payload into chunks operation, which processes a batch of HL7 messages for you. We support batch files in the following two formats:

  1. Using the standard FHS/BHS file and batch header segments and then closing the file with BTS/FTS batch and file trailer segments
  2. A sequential message with no headers where each new message starts with an MSH segment.

 

 

This operation requires you to pass in a binary or file reference to it, which could be, for example, a binary reference (if you receive your file as an attachment to a REST API call), a file reference received back from the FTP adapter (if you read your file from an FTP server), or even a file server reference (if you read your file from Oracle Integration’s built-in File Server).

Regardless of which type of reference you pass in, the healthcare action automatically splits the messages into chunks of messages that can be processed in a reasonable manner. In this release, chunk sizes are 1 MB or 1000 messages, whichever comes first. In a future release, we plan to allow you to set the criteria that defines the chunk size.

The Match and translate inbound message operation in the healthcare action has also been enhanced to work with this chunking of messages. You can now pass your chunk of messages into Match and translate inbound message, and it returns an array of translated HL7 messages ready for you to process in the usual way.

The following image shows Match and translate inbound message being called on a chunk of messages. We then loop through the array of translated messages to call a child integration to process each message.

 

Summary and key points regarding the new debatch feature:

  • A batch file containing many raw HL7 messages can now be processed by the healthcare action using the Split payload into chunks operation.
  • Chunks are either 1 MB or 1000 messages in size.
  • You can pass the resulting chunk into the healthcare action’s Match and translate inbound message operation, and it returns an array of translated messages.
  • The messages returned from Match and translate inbound message are grouped by message type. For example:
    • If your file contains 2000 messages with a mix of A04 and A08 messages:
      • the first chunk has the first 1000 messages in it
      • this chunk may have a mix of both A04 and A08 messages
      • the output of Match and translate inbound message is an array within an array of grouped messages
      • the outer array holds the groups, in this case group 1 (index one of the outer array) has all the A04 messages and group 2 (index two of the outer array) holds all the A08 messages
      • within each group element there is an array of all the translated messages in that group

Sample Project

You can download a sample project that demonstrates how to use the new debatch features. The folder also contains a sample batch file to use. To use the sample project, run the integration named REST_HL7-Chunk-Call-Child and attach the sample batch data file to the body of the REST call.

Download link: https://drive.google.com/drive/folders/1p53L5hoWtfy6YJuSBID3U4pe8m1zPAO2

 

Guaranteed Order Delivery

Starting with release 25.10, Oracle Integration now guarantees that HL7 messages are delivered in the order in which they were received from the source system. This first in-first out (FIFO) pattern ensures that the downstream system receives messages in the order intended by the sending system.

Oracle Integration achieves this capability by putting all outbound HL7 messages marked for delivery in a persistent queue, which it reorders before sending. These queues are defined by the developer when modeling their integration, but are fully managed by the Oracle Integration runtime to be reliable and persistent for guaranteed delivery.

To use this new feature, you must ensure it is enabled in two places – first, in your MLLP/HL7 trigger and secondly, in each of your MLLP/HL7 invokes.

 

The image above shows the MLLP/HL7 trigger wizard. As you can see, the option to enable guaranteed order delivery is available there. This can be disabled if direct delivery to an endpoint is required. In this case, outbound messages are not reordered through a queue as described above.

 

In the image above, you can see the second place where you must configure this feature. This time, we are showing the MLLP/HL7 invoke step where the integration is sending an outbound HL7 message. Here, the developer must choose the queue to use to reorder and send outbound messages for delivery. Delivery queues are defined in your integration project (see the image below).

 

 

There are a couple of limitations that you should be aware of that come with this new feature. First, when you create an MLLP/HL7 trigger that has guaranteed order delivery enabled, this tells the Oracle Integration runtime to track this parent integration and any child integrations instances so that any HL7 invokes that are done in any child integrations are marked for ordered delivery. At this point we are only supporting synchronous child integration invocations. This means that all child integrations you call from your MLLP trigger integration must be defined with a return value (that is, they are synchronous).

Second, we do not support the parallel action in child integrations that are called from an MLLP/HL7 trigger integration that has guaranteed order delivery enabled.

Sample Project

To demonstrate this new capability, you can download this simple Oracle Integration project file, which contains a very simple integration that shows how to configure ordered delivery.

Download link: https://drive.google.com/drive/folders/13cOyAzgXrCSQ7BGQFx0v3d54ElkYSrzR

 

HL7 CDA Document Support

To support HL7 CDA documents in Oracle Integration, we have added the following new features:

  • CDA Schema Upload: You can now upload a CDA schema to the Schemas section of the Healthcare tab of your Oracle Integration project.
  • Define a CDA Document: Define a CDA document based on your uploaded schema for use in your integrations.
  • Healthcare Action: The healthcare action now supports CDA documents, enabling you to use the Match and translate inbound message and Translate to outbound message operations with CDA documents.

With these enhancements, you can now process CDA documents in Oracle Integration in the same manner in which you process HL7v2 documents.

For example:

  1. You can receive a CDA document into Oracle Integration and use Match and translate inbound message to validate the document against a CDA schema you have uploaded. You can then call Convert message reference to document, and the contents of the CDA document are available as a variable in your integration pipeline.
  2. You can generate a new CDA document, which conforms to a schema you have uploaded by mapping data into that structure in your integrations. You can then call Translate to outbound message on that structure to generate a compliant CDA XML document to be sent downstream.

 

Upload a CDA schema into Oracle Integration.

In this image, we are uploading the Australian government-defined CDA schema with extensions and defining the ClinicalDocument element as the root element of the structure. Next, we are defining the ClinicalDocument as a type called ADHA Patient Summary.

 

Define an instance of this schema for use in your integrations.

 

In this image, you can see we are defining a document called ADHA Patient Summary that we use in our integrations to receive and send CDA documents at runtime. In this document definition you can see that we have chosen the schema definition from the previous example, we have chosen the ADHA PaitentSummary that we defined, and we have configured an identification expression and value to use at runtime to match incoming CDA documents.

In essence, if we receive a CDA document at runtime that conforms to this schema AND has the LOINC code 34133-9 (Summary of episode note), it matches to our ADHA PatientSummary and can be loaded as a variable into our integration pipeline.

Lastly, we have also provided the ability for you to optionally upload a schematron file when you define your document (it’s not shown in the image above, but it is available in the product). This schematron, if provided, will be used at runtime to perform data validation of the contents of your document in addition to schema validation. 

In summary, Oracle Integration now supports both inbound (receive and process) and outbound (create and send) CDA documents that you can read and manipulate in your integration flows like any other supported message type.