Oracle® Cloud

Using Oracle Integration for Healthcare in

Oracle Integration 3

F84764-09
February 2025
Oracle Cloud Using Oracle Integration for Healthcare in Oracle Integration 3,

F84764-09

Copyright © 2024, 2025, Oracle and/or its affiliates.

Primary Author: Oracle Corporation

This software and related documentation are provided under a license agreement containing restrictions on use and
disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or
allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit,
perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation
of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find
any errors, please report them to us in writing.

If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related
documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then
the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any
programs embedded, installed, or activated on delivered hardware, and modifications of such programs) and Oracle
computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial
computer software," "commercial computer software documentation," or "limited rights data" pursuant to the applicable
Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction,
duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle
programs (including any operating system, integrated software, any programs embedded, installed, or activated on
delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle
data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms
governing the U.S. Government's use of Oracle cloud services are defined by the applicable contract for such services.
No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not
developed or intended for use in any inherently dangerous applications, including applications that may create a risk of
personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all
appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its
affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle®, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be
trademarks of their respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used
under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo
are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open
Group.

This software or hardware and documentation may provide access to or information about content, products, and
services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all
warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an
applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss,
costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth
in an applicable agreement between you and Oracle.
Contents

1 Introduction to Oracle Integration for Healthcare

About HL7 1-1
Oracle Integration for Healthcare Support for HL7 and FHIR 1-1
Oracle Integration for Healthcare Restrictions 1-3
Quick Tour Through Oracle Integration for Healthcare Use Cases 1-3
Synchronize EMR Patient Updates in a FHIR Patient Repository and a Pathology
System 1-3
Synchronize Employee Information Between an HR Application and an EMR Application 1-5
Workflow to Use Oracle Integration for Healthcare 1-6
Provision Oracle Integration for Healthcare 1-7
Oracle Integration for Healthcare Videos and Live Labs 1-8

2 Create Oracle Integration for Healthcare Schemas and Documents

Create a New Healthcare Schema 2-1
Add a New Segment 2-3
Add a New Loop 2-4
Create a Custom HL7 Message 2-4
Edit or Clone an HL7 Message 2-7

3 Design an Integration with a Healthcare Action

Best Practices for Designing a Healthcare Integration 3-1
Create Trigger and Invoke Connections that Support the HL7 and FHIR Standards 3-5
Convert HL7 Messages with a Healthcare Action 3-5

4 Import FHIR Profile Packages

Import a FHIR Profile Package 4-1
Browse the Contents of the FHIR Profile Package 4-2

iii
5 Design Time and Runtime Overview of an Oracle Integration for
Healthcare Use Case
Use Case Overview 5-1
Overview of the Design-Time Messages 5-2
Overview of the Integration Receiving the Inbound HL7 Message During Runtime 5-3
Overview of the Integration Processing the Patient Updates During Runtime 5-6

iv
Preface
This guide describes how to use Oracle Integration for Healthcare.

Topics:
• Audience
• Documentation Accessibility
• Diversity and Inclusion
• Related Resources
• Conventions

Audience
This guide is intended for developers who want to use Oracle Integration for Healthcare.

Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at https://www.oracle.com/corporate/accessibility/.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My
Oracle Support. For information, visit https://support.oracle.com/portal/ or visit Oracle
Accessibility Learning and Support if you are hearing impaired.

Diversity and Inclusion

Oracle is fully committed to diversity and inclusion. Oracle respects and values having a
diverse workforce that increases thought leadership and innovation. As part of our initiative to
build a more inclusive culture that positively impacts our employees, customers, and partners,
we are working to remove insensitive terms from our products and documentation. We are also
mindful of the necessity to maintain compatibility with our customers' existing technologies and
the need to ensure continuity of service as Oracle's offerings and industry standards evolve.
Because of these technical constraints, our effort to remove insensitive terms is ongoing and
will take time and external cooperation.

Related Resources
See these Oracle resources:
• Oracle Cloud at http://cloud.oracle.com
• Using Integrations in Oracle Integration 3
• Using the Oracle Mapper with Oracle Integration 3
• Oracle Integration documentation on the Oracle Help Center.

5
 Conventions

Conventions
The following text conventions are used in this document:

Convention Meaning
boldface Boldface type indicates graphical user interface elements associated with an
action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for which
you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code in
examples, text that appears on the screen, or text that you enter.

6
1
Introduction to Oracle Integration for
Healthcare
Learn about how Oracle Integration for Healthcare provides support for HL7 in Oracle
Integration.

Topics:
• About HL7
• Oracle Integration for Healthcare Support for HL7 and FHIR
• Oracle Integration for Healthcare Restrictions
• Quick Tour Through Oracle Integration for Healthcare Use Cases
• Workflow to Use Oracle Integration for Healthcare
• Provision Oracle Integration for Healthcare
• Oracle Integration for Healthcare Videos and Live Labs

About HL7
Health Level Seven (HL7) provides standards for the exchange, integration, sharing, and
retrieval of health information between systems within and across healthcare providers. HL7
provides a delimited, flat file-based message structure. Messages are event-based (order
blood tests, receive test results, update patient information, and others). There is a
corresponding message for each event.
Health organizations typically include numerous healthcare systems to process different patient
administrative or clinical tasks, including billing, medication management, patient tracking, and
documentation. These systems communicate when they receive new information or need to
retrieve information. HL7 provides standards, guidelines, and methodologies for these systems
to communicate with each other. The standards allow for the interoperability of healthcare data
as it's shared and processed by different systems. This interoperability allows clinical and non-
clinical data to be shared more easily with the goal of improving patient care and health system
performance.

Oracle Integration for Healthcare Support for HL7 and FHIR

Oracle Integration for Healthcare enables you to create integrations that interact with
healthcare organizations that use HL7.
Oracle Integration for Healthcare provides the following capabilities:
• Available for use with Oracle Integration through installation of the Healthcare edition in the
Oracle Cloud Infrastructure Console. See Oracle Integration Editions in Provisioning and
Administering Oracle Integration 3.
• Supports HL7 version 2.
• Supports the following versions of the HL7 version 2 standard: 2.3.1, 2.4, 2.5.1, 2.5, 2.6,
2.7, 2.7.1, 2.8.1, 2.8, 2.8.2, and 2.9.

1-1
 Chapter 1
Oracle Integration for Healthcare Support for HL7 and FHIR

• Supports HL7 applications on different versions interacting with each other through Oracle
Integration for Healthcare.
• Supports the following FHIR profile packages that have been tested.
– US Core
– FHIR Canadian
– FHIR Australian
– FHIR UK
– FHIR iSiK
If you are unable to successfully import a profile package not shown in this list, see this
blog.
• Supports creating healthcare integrations in projects or in standalone environments
(outside of a project). See Design, Manage, and Monitor Integrations in Projects and
Create Healthcare Integrations in a Project in Using Integrations in Oracle Integration 3
• Supports common healthcare interoperability use cases, including:
– Transfer of care
– Inventory synchronization – employee medical record (EMR) and enterprise resource
planning (ERP)
– Payer/provider
– Modernization programs:
* Exposure of health data using Fast Healthcare Interoperability Resources (FHIR)
* Mobile applications
* Patient portal
– Update of a state immunization registry upon patient checkout
• Supports message standards and transport protocols commonly used in the healthcare
interoperability (integration) market:
– Supports the Minimal Lower Layer Protocol (MLLP). MLLP is a TCP-based standard
for sending and receiving HL7 messages. You configure the MLLP Adapter to receive
inbound (trigger) HL7 messages or send outbound (invoke) HL7 messages. See MLLP
Adapter Capabilities in Using the MLLP Adapter with Oracle Integration 3.
– Supports Fast Healthcare Interoperability Resources (FHIR). FHIR is a set of rules and
specifications for exchanging electronic healthcare data over the REST protocol in
XML or JSON format. You configure the FHIR Adapter to invoke FHIR resources (for
example, a patient resource, encounter resource, and others) in outbound messages
in Oracle Integration. See FHIR Adapter Capabilities in Using the FHIR Adapter with
Oracle Integration 3.
• Supports defining the connections to external systems with which to exchange HL7
messages.
• Supports designing and customizing the HL7 messages to exchange. See Create Oracle
Integration for Healthcare Schemas and Documents.
• Supports integrating and processing HL7 messages in integrations with the healthcare
action. The healthcare action converts inbound HL7 messages to XML format and
outbound messages from XML format to HL7 format. See Design an Integration with a
Healthcare Action.
• Supports tracking and monitoring HL7 integrations at runtime.

1-2
 Chapter 1
Oracle Integration for Healthcare Restrictions

• Supports retaining runtime data for 184 days when selecting the Production tracing level
during integration activation. See Activate an Integration in Using Integration Insight in
Oracle Integration 3

Oracle Integration for Healthcare Restrictions

Be aware of the following Oracle Integration for Healthcare restrictions.
• Oracle Integration supports HL7 version 2. HL7 version 3 is not currently supported.

Quick Tour Through Oracle Integration for Healthcare Use Cases

This section provides high level overviews of several Oracle Integration for Healthcare use
cases.

Topics:
• Synchronize EMR Patient Updates in a FHIR Patient Repository and a Pathology System
• Synchronize Employee Information Between an HR Application and an EMR Application

Synchronize EMR Patient Updates in a FHIR Patient Repository and a

Pathology System
This use case describes how an update to patient details in an employee medical record
(EMR) application is automatically propagated to a FHIR patient repository and a pathology
system through use of Oracle Integration for Healthcare.

1-3
 Chapter 1
Quick Tour Through Oracle Integration for Healthcare Use Cases

1. Patient details are updated in an EMR, which emits an HL7 ADT_A08 message. The
message is received by Oracle Integration and converted to a FHIR patient resource for
updating in a FHIR-enabled patient repository.
2. The integration continues and Oracle Integration translates an HL7 message from version
2.5 to version 2.3.1 and sends it to a pathology system for updating the patient records.

EMR Application Patient Updates

• A doctor updates details about a patient (for this example, a change in name) in an EMR
application. The updates are performed through use of an HL7 Update Patient Information
message (ADT_A08). The EMR application uses HL7 version 2.5.
• The EMR application emits the updated HL7 ADT_A08 message.
• An MLLP Adapter running inside the connectivity agent and configured as a trigger
connection in an integration receives the incoming message for processing.
• The HL7-formatted message is converted into an XML-formatted message by a healthcare
action in the integration.
The following updates are automatically made in parallel in the FHIR patient repository and the
pathology system:
• FHIR Patient Repository Updates
• Pathology System Updates

FHIR Patient Repository Updates

• The XML message is converted into a JSON-formatted, FHIR patient resource in the
integration.
• The FHIR patient repository is invoked with the FHIR Adapter. Based on the type of
patient, the following updates are applied in the FHIR repository:
– For an existing FHIR repository patient: The patient is updated with the name change
made in the EMR application.
– For a new patient: All patient details are added to the FHIR repository.

Pathology System Updates

Because the pathology system uses an earlier version of HL7 (2.3.1), the message must be
down-versioned from 2.5 to 2.3.1 for the message to be successfully processed.
• The ADT_A08 message is:
– Converted from XML format back to HL7 format by a healthcare action in the
integration.
– Down-versioned from HL7 version 2.5 to version 2.3.1.
• The MLLP Adapter running inside the connectivity agent and configured as an invoke
connection sends the down-versioned, HL7-formatted message to the pathology system,
where the patient details are updated.
An overview of design instructions for this use case is provided. See Design Time and Runtime
Overview of an Oracle Integration for Healthcare Use Case.

1-4
 Chapter 1
Quick Tour Through Oracle Integration for Healthcare Use Cases

Synchronize Employee Information Between an HR Application and an

EMR Application
This use case describes how a new employee hire added to a human resources (HR)
application is also automatically added as a patient in an employee medical record (EMR)
application. When this employee later receives a vaccination, the update made to the EMR
application is automatically propagated back to the HR application.

1. Start of onboarding a new employee. A new employee event is sent to Oracle Integration,
converted to an HL7 message, and sent to Mellennium.
2. Start of a new or updated employee vaccination record. A new HL7 vaccination message
event is sent to Oracle Integration, converted to Oracle PeopleSoft format, and sent to
Oracle PeopleSoft.

HR Application Employee Updates Synchronized in an EMR Application

Acme Hospital uses two applications to store information:
• An HR application (for this example, Oracle PeopleSoft) stores information about their
employees (for example, date of hire, job title, compensation details, and so on).
• An EMR application (for this example, Mellennium) stores internal health records pertinent
to employee jobs (for example, employee vaccination records, employee allergy records,
and so on). The EMR application uses HL7.
The following actions occur:
• A new employee is hired and added to the HR application.

1-5
 Chapter 1
Workflow to Use Oracle Integration for Healthcare

• The HR application update triggers a REST Adapter connection to start an integration

between the HR application and the EMR application.
• The HR application message is converted to an HL7-formatted, ADT_A04 message
(patient registration) by a healthcare action in the integration.
• An MLLP Adapter running inside the connectivity agent and configured as an invoke
connection sends the outbound message to the EMR application at Acme Hospital.
• The ADT_A04 message (patient registration) is automatically added to the EMR
application. The new employee is now available in both applications.

EMR Application Employee Updates Synchronized in the HR Application

Acme Hospital employees must periodically receive various vaccinations, allergy tests, and so
on.
• An Acme Hospital nurse administers an employee's annual vaccination and updates their
medical record in the EMR application.
• The EMR application emits an HL7 ORU_OR1 message (vaccination details message).
• An MLLP Adapter running inside the connectivity agent and configured as a trigger
connection in a second integration receives the incoming message for processing.
• The HL7-formatted message is converted into an XML-formatted message by a healthcare
action in the integration.
• A REST API call invokes the HR application and the employee's records are updated to
reflect their vaccination details.

Workflow to Use Oracle Integration for Healthcare

You follow a simple workflow to create integrations in Oracle Integration for Healthcare.

Note:
To follow this workflow, you must first select the Healthcare edition during Oracle
Integration instance provisioning. See Provision Oracle Integration for Healthcare.

Step Description More Information

1 Install the connectivity agent. Download and Run the Connectivity Agent
The MLLP Adapter runs directly in the Installer in Using Integrations in Oracle
connectivity agent to send and receive HL7 Integration 3
messages to and from MLLP endpoints.
2 Create adapter connections: • Create a FHIR Adapter Connection in
• If your use case requires invoking a Using the FHIR Adapter with Oracle
FHIR-based endpoint, create a FHIR Integration 3
Adapter connection. • Create an MLLP Adapter Connection in
• If your use case requires receiving Using the MLLP Adapter with Oracle
inbound (trigger) HL7 messages or Integration 3
sending outbound (invoke) HL7
messages, create an MLLP Adapter
connection.

1-6
 Chapter 1
Provision Oracle Integration for Healthcare

Step Description More Information

3 Create a healthcare schema and HL7 Create a New Healthcare Schema and Create
message. a Custom HL7 Message
You create a schema and then an HL7
message based on the schema to use in your
integration.
Note: You cannot use the healthcare action if
you have not first created at least one HL7
message (message definition).
4 Design an integration with your adapter Create Trigger and Invoke Connections that
connections and a healthcare action. Support the HL7 and FHIR Standards and
You select the HL7 message created in Step Design an Integration with a Healthcare
3 for conversion when you configure the Action
healthcare action.
5 Activate the integration. Activate an Integration in Using Integrations in
Once activated, you can run the integration. Oracle Integration 3

6 Monitor the integration. Monitor Integrations During Runtime and

Monitor Integrations in a Project in Using
Integrations in Oracle Integration 3

Provision Oracle Integration for Healthcare

Oracle Integration for Healthcare is available only as part of the Healthcare edition. It is not
included with the Standard or Enterprise editions of Oracle Integration. You can select the
Healthcare edition during Oracle Integration instance installation or change an existing
instance from the Standard or Enterprise edition to the Healthcare edition.
This table provides an overview of key installation, edition change, and billing information and
provides references to relevant documentation.

Subject Description See

Edition Features The Healthcare edition includes Oracle Integration Editions in
the same features as the Provisioning and Administering
Enterprise Edition, plus Oracle Oracle Integration 3
Integration for Healthcare.
Installation You select the Healthcare edition Create an Oracle Integration
during instance installation. Instance in Provisioning and
Administering Oracle Integration
3
Changing editions If your existing Oracle Integration Edit the Edition, License Type,
instance is already configured Message Packs, and Custom
with the Standard or Enterprise Endpoint of an Instance in
edition, you can change to the Provisioning and Administering
Healthcare edition. Oracle Integration 3
Note: Once you change to the
Healthcare edition, you cannot
change back to Standard or
Enterprise.
Billing Healthcare edition message See Monitor Oracle Integration 3
packs are billed at a higher price Instances in Provisioning and
than Standard or Enterprise. Administering Oracle Integration
3

1-7
 Chapter 1
Oracle Integration for Healthcare Videos and Live Labs

How Do I Know If My Instance Includes the Healthcare Edition

If your existing Oracle Integration installation does not currently consist of the Healthcare
edition, you see the following message when navigating through the user interface:
• When you select Healthcare in the left navigation pane

• When you click Healthcare inside a project

If you change this instance from the Standard or Enterprise edition to the Healthcare edition,
you can edit these pages.

Oracle Integration for Healthcare Videos and Live Labs

Interested in viewing Oracle Integration for Healthcare live demo videos or completing a
hands-on lab? Live demo videos show how to configure and run key Oracle Integration for
Healthcare features. Oracle LiveLabs provide you with access to Oracle's technologies to run
labs and workshops. See the following links for details.
• Healthcare live demo videos
• Oracle LiveLabs - Get Started with Healthcare

1-8
2
Create Oracle Integration for Healthcare
Schemas and Documents
You create a healthcare schema using a standard HL7 schema definition as a starting point. All
HL7 version 2 base schemas from version 2.3.1 onwards are supported and provided with
Oracle Integration. You can also customize the schema according to your needs. You then
create a document definition based on the schema. This document definition represents the
HL7 message to use in your integrations. You then select this document to convert when
configuring the healthcare action in your integration.

Topics:
• Create a New Healthcare Schema
• Create a Custom HL7 Message
• Edit or Clone an HL7 Message

Create a New Healthcare Schema

You can create a new HL7 schema based on a standard out-of-the-box HL7 message
definition and customize it to match your requirements.
You can create a schema in a project or a standalone environment (outside of a project).
1. To create a schema in a project:
a. In the navigation pane, click Projects.
b. Click the project in which to create the schema.

c. Click Healthcare .
d. In the Schemas section, click Add.
2. To create a schema in a standalone environment:
a. In the navigation pane, click Healthcare, then Schemas.
b. On the Schemas page, click Create.
3. Enter the following details.

Element Description
Name Enter a schema name.
Identifier This field is automatically populated with a unique schema identifier
based on your schema name. You can manually change this value, if
needed.
Description Enter an optional description of this schema.
Message standard View the message standard. Only HL7V2 is available and it cannot
be deselected. The message standard identifies the business
protocol to follow when exchanging messages between applications.

2-1
 Chapter 2
Create a New Healthcare Schema

Element Description
Message version Select the message version. HL7 V2 versions 2.3.1, 2.4, 2.5.1, 2.5,
2.6, 2.7, 2.7.1, 2.8.1, 2.8, 2.8.2, and 2.9 are supported.
Message type Select the message type. The types shown are based on the HL7 V2
version you selected.

For this example, ADT_A08 (update patient information) is selected.

4. Click Create.
The details page for your new HL7 message is displayed. The standard segments and
elements that come with the message type you selected are shown. A segment is a higher
level construct, consisting of a sequence of elements and composites. An element is the
smallest unit that represents a single data field of a primitive type, such as alphanumeric
text, integer, decimal, date, time, or binary. If you create a schema in a project, the project
name is displayed in the banner. For this example, the schema was created in a
standalone environment (outside of a project).

2-2
 Chapter 2
Create a New Healthcare Schema

You can customize the standard HL7 message. For example, the application with which
you are integrating may require another segment or loop. You can add new constructs
(such as new segments and loops) to a standard healthcare schema or edit existing
constructs within it.
5. If you want to create a new segment, see Add a New Segment.
6. If you want to create a new loop, see Add a New Loop.

Add a New Segment

According to your organization's requirements, you can add new segments to a standard
healthcare schema to customize it.
1. Hover over the row of a segment/element and click Actions , then New segment.
The Add new segment panel is displayed.
2. If you want to use the contents of an existing segment definition to create a new segment,
click Existing segment. This selection is useful when the contents of an existing segment
are similar to the one you want to create.
a. Expand Advance Search.
b. Search by the version number or schema name to use.
c. Begin typing the initial letters of the segment to show the available selections.
d. Select the segment.
e. Click Add.
f. Enter a name, description, and cardinality value. For example, if you enter [0..1], a
value of either zero or one is expected.
g. Click Add.
3. If you want to create a completely new segment without using existing information, click
New segment.
a. Enter a name, and click Add.
The Properties panel is displayed.
b. Enter a name, description, and cardinality value. For example, if you enter [0..1], a
value of either zero or one is expected.
c. Click Save.
4. If you want to perform additional customizations, hover over the row of the segment/
element and click Actions , then select to perform more customizations:

2-3
 Chapter 2
Create a Custom HL7 Message

• New child element: The smallest unit that represents a single data field of a primitive
type, such as alphanumeric text, integer, decimal, date, time, or binary.
• New child composite: A complex data type consisting of one or more elements.
• New segment: The next higher level construct, consisting of a sequence of elements
and composites.
• New loop: A container for a specific set of segments or child loops, which makes its
structure nested and hierarchical.

Add a New Loop

According to your organization's requirements, you can add new loops to a standard
healthcare schema to customize it. A loop is a container for a specific set of segments or child
loops, which make its structure nested and hierarchical.
1. Hover over the row of a segment/element and click Actions , then New loop.
The Add new loop panel is displayed.
2. Enter a name for the segment, and click Add.
3. Enter a cardinality value. For example, if you enter [0..1], a value of either zero or one is
expected.
4. Click Save.

Create a Custom HL7 Message

After you create a schema, you must create an HL7 message based on that schema for use in
your integration. The message represents a specific snapshot of a schema to use in an
integration. You later select the HL7 message for conversion into a supported format when you
configure the healthcare action during design of your integration.
You can create an HL7 message in a project or a standalone environment (outside of a
project).
1. To create a message in a project:
a. In the navigation pane, click Projects.
b. Click the project in which to create the message.

c. Click Healthcare .
d. In the HL7 messages section, click Add.
2. To create a message in a standalone environment:
a. In the navigation pane, click Healthcare, then HL7 messages.
b. On the HL7 messages page, click Create.
3. Enter the following details to create a new HL7 message definition.

Element Description
Name Enter a message name.
Identifier This field is automatically populated with the message name. You can
manually change this value.
Description Enter an optional description of this message.

2-4
 Chapter 2
Create a Custom HL7 Message

Element Description
Message standard View the message standard. Only HL7V2 is available and it cannot
be deselected. The message standard identifies the business
protocol to follow when exchanging messages between applications.
Message version Select the message version.
HL7 message versions 2.3.1, 2.4, 2.5.1, 2.5, 2.6, 2.7, 2.7.1, 2.8.1,
2.8, 2.8.2, and 2.9 are supported.
Message type Select the HL7 message type. The types shown are based on the
HL7 message version you selected.

4. Click Create.
The details page for your new message is displayed.

2-5
 Chapter 2
Create a Custom HL7 Message

5. Note that the message version and message type values you selected previously are
displayed. These cannot be changed.
The Message schema field shows Standard as the schema type by default. If you had
previously created custom schemas, they are also displayed for selection in the drop-down
list.
6. Select the schema to use or click Customize to display the Clone standard schema dialog
to create a new schema. For this example, the schema created in Create a New
Healthcare Schema is selected.
7. Click Save, and return to the HL7 messages page.
If you create a document in a project, the project name is displayed in the banner. For this
example, the document was created in a standalone environment (outside of a project).

The message is now available for conversion when you configure the healthcare action in
an integration. See Design an Integration with a Healthcare Action.

2-6
 Chapter 2
Edit or Clone an HL7 Message

Edit or Clone an HL7 Message

You can edit an existing message to associate a different schema. You can also clone an HL7
message to create a copy of it.

Edit an HL7 Message

1. To edit a message in a project:
a. In the navigation pane, click Projects.
b. Click the project in which to edit the message.

c. Click Healthcare .
d. Go to the HL7 messages section.
2. To edit a message in a standalone environment:
a. In the navigation pane, click Healthcare, then HL7 messages.
3. Hover over a message row to see the actions you can perform on a message.

4. Click Edit .
5. Edit the message's name and description, as necessary.

Note:
You cannot change the message standard or version.

6. Select the message schema to use. You can select the standard schema or one you
created.

7. Click Save.
This message is now available for selection when you configure the healthcare action in an
integration.

Clone an HL7 message

1. To clone a message in a project:
a. In the navigation pane, click Projects.
b. Click the project in which to clone the message.

c. Click Healthcare .
2. Go to the HL7 messages section.
3. To clone a message in a standalone environment:

2-7
 Chapter 2
Edit or Clone an HL7 Message

a. In the navigation pane, click Healthcare, then HL7 messages.

4. Hover over a message row to see the actions you can perform on a message.
5. Click Actions , then select Clone to clone the message.
The Clone Healthcare message panel opens.
6. Make any necessary updates, then click Clone.

2-8
3
Design an Integration with a Healthcare Action
Once you have created your schema and message, you can design an integration with a
healthcare action.

Topics:
• Best Practices for Designing a Healthcare Integration
• Create Trigger and Invoke Connections that Support the HL7 and FHIR Standards
• Convert HL7 Messages with a Healthcare Action

Best Practices for Designing a Healthcare Integration

Note the following best practices for designing an optimal healthcare integration.
• Build a Parent Routing Integration to Invoke Child Integrations that Process a Single HL7
Inbound Message
• Use a Lookup Function in the Mapper to Select the Child Integration to Invoke
• Add Fault Handling to Address Inbound Messages that are Not Selected in the Healthcare
Action
• Plan for Future Oracle Integration for Healthcare Updates

Build a Parent Routing Integration to Invoke Child Integrations that Process a Single
HL7 Inbound Message
You may design an integration that receives many different HL7 inbound message types. For
example:
• ADT_A05 (Pre-admit a patient)
• ADT_A08 (Update patient information)
• ADT_A09 (Patient departing - tracking)
As a best practice, build a parent routing integration that invokes child integrations that each
process a single HL7 inbound message type. For this example, create three child integrations.
Do not attempt to build a single integration with a routing action (for example, a for-each action
or switch action) to process each message.
Create your child integration with a REST Adapter trigger connection that can accept a binary
format as its request payload. Select the default application/octet-stream as the mime-type.
You pass the message-reference object that you get back from calling the healthcare action
into your child integration. See Overview of the Integration Receiving the Inbound HL7
Message During Runtime.

Use a Lookup Function in the Mapper to Select the Child Integration to Invoke
Use a lookup function in the mapper to select the child integration to invoke. Based on the
message and message type, the lookup function returns the name of the integration
(Integration Code) and the version of the integration (Integration Version) to invoke.

3-1
 Chapter 3
Best Practices for Designing a Healthcare Integration

In the lookup table, based on the specific inbound message received, a specific integration is
invoked.

Add Fault Handling to Address Inbound Messages that are Not Selected in the
Healthcare Action
A healthcare action is not designed to throw faults. You should design fault handling logic into
your integration to catch message faults. For example, assume you design the following
integration to receive inbound messages from an HL7 application:

In the healthcare action, you select the following two inbound message types for translation:
• ADT_A08 (Update patient information) version 2.5
• ADT_A08 (Update patient information) version 2.3.1

3-2
 Chapter 3
Best Practices for Designing a Healthcare Integration

Assume the healthcare action also receives an inbound ADT_A04 (Register a patient)
message from the HL7 application. Because this message type has not been selected in the
healthcare action, it cannot be translated into an Oracle Integration payload. The ADT_A04
message type is passed through the healthcare action, but fails in the subsequent map action
with errors.

As a best practice, add and design a switch action immediately after the healthcare action and
before the map action with the following branch logic:
• Route 1: If the message is not selected in the healthcare action, then address the fault in
that branch with your own fault handling logic. For example, add a notification action that
sends an email to the inbound HL7 application informing them that an unplanned message
was received.
• Otherwise: If the message is selected in the healthcare action, translate it into an Oracle
Integration payload, perform mapping, and call the child integration for further processing
and delivery to the outbound application endpoint.

Plan for Future Oracle Integration for Healthcare Updates

A common interface payload to use for the invocation from the handler integration to the child
(processor) integration is provided. This JSON document forms the contract between the
handler and the processor integrations.

<strong>{
"document-standard": "HL7V2",
"document-version": "2.3.1",
"document-type": "ADT_A01",

3-3
 Chapter 3
Best Practices for Designing a Healthcare Integration

"document-definition": "HL7V2_ADT_A01",
"message": [
{
"healthcare-message-reference": "clm:base64_meta.base64_payload1",
"message-tracking-id": "123"
},
{
"healthcare-message-reference": "clm:base64_meta.base64_payload2",
"message-tracking-id": "abc"
}
]
}</strong>

Use of this JSON message in your child integrations is not required. However, use of this
message enables you to take advantage of potential future features. The idea is that if you use
this JSON message as the contract in your child integrations now, change are not required in
the future. You do not need to create a new handler integration. The incoming HL7 message is
routed to the appropriate processor integration based on your routing rules. For this to work,
you need to build your integration using this JSON payload.
This payload provides metadata about the message and capability to also support batch
messages. You map this data using the data returned from the healthcare action when you call
the operation Match and translate inbound message. An example of this mapping is shown
below.

3-4
 Chapter 3
Create Trigger and Invoke Connections that Support the HL7 and FHIR Standards

Create Trigger and Invoke Connections that Support the HL7 and
FHIR Standards
You must create trigger (inbound) and invoke (outbound) connections to communicate with
applications that support the HL7 or FHIR standards.
• Create MLLP Adapter Connections
• Create a FHIR Connection

Create MLLP Adapter Connections

You can create MLLP Adapter trigger and invoke connections for integrations to communicate
with health care systems that use HL7 version 2. Separate adapter connections are required
for a trigger (incoming) and an invoke (outgoing).
• Trigger connection: The MLLP Adapter listens for and receives inbound HL7 messages
from an application.
• Invoke connection: The MLLP Adapter establishes a connection and sends outbound HL7
messages to an application.
See Create an MLLP Adapter Connection in Using the MLLP Adapter with Oracle Integration
3.

Create a FHIR Connection

You can exchange health care data using the FHIR standard in XML or JSON. You configure
the FHIR Adapter to allow FHIR resources (for example, a patient resource, encounter
resource, and others) to be used as outbound (invoke) messages in Oracle Integration. The is
similar to the REST Adapter, but with a FHIR-specific configuration experience.
As an alternative, you can also configure the REST Adapter to allow FHIR resources to be
used as inbound (trigger) and outbound (invoke) messages.
• See Create a FHIR Adapter Connection in Using the FHIR Adapter with Oracle Integration
3.
• See Create a REST Adapter Connection in Using the REST Adapter with Oracle
Integration 3.

Convert HL7 Messages with a Healthcare Action

You can convert a message to or from HL7 format with a healthcare action in an integration.
The healthcare action converts native inbound HL7 messages into Oracle Integration XML
payloads for use in your integrations and generates native HL7 messages from Oracle
Integration XML payloads to send to external applications that support HL7.

Note:
If your Oracle Integration instance does not include the Healthcare edition, you
cannot drag the healthcare action into an integration. See Create an Oracle
Integration Instance in Provisioning and Administering Oracle Integration 3.

3-5
 Chapter 3
Convert HL7 Messages with a Healthcare Action

1. To create an integration in a project:

a. In the navigation pane, click Projects.
b. Click the project in which to create the integration.
c. In the Integrations section, click Add if no integrations currently exist or + if
integrations already exist.
d. Click Create, then select Application or Schedule.
2. To create an integration in a standalone environment:
a. In the navigation pane, click Design, then Integrations.
b. Click Create, then select Application or Schedule.
3. Design your integration, including adding and configuring your connections. See Create
Trigger and Invoke Connections that Support the HL7 and FHIR Standards.
4. Add a healthcare action to the integration in either of the following ways:

• On the right side of the canvas, click Actions and drag the Healthcare action to
the appropriate location.

• Click at the location where you want to add the healthcare action, then select
Healthcare.
The Configure healthcare action call wizard is displayed.
5. Enter the following details:

Element Description
Name Enter a name.
Description Enter an optional descriptions for what this action
does.

3-6
 Chapter 3
Convert HL7 Messages with a Healthcare Action

Element Description
Operation Select an operation to perform:
• Convert message reference to document:
Use this operation to identify the incoming
message type and version. This operation
returns a reference to a translated message
and metadata needed to route the
integration to an appropriate child integration
to process the message. When you call the
operation, you need to specify a list of HL7
documents with which you want to match.
• Match and translate inbound message:
Use this operation to convert inbound HL7-
formatted messages into XML format.
Specify the documents you want this action
to receive. These are the documents that
you configured during design time. This
operation takes a raw HL7 message off the
wire, parses it, and matches it with the
document definition you select in the
Choose documents section. The message
is then converted to an Oracle Integration
XML payload.
• Translate to outbound message: Use this
operation to convert an XML payload
message to an outbound HL7 message.
Choose documents Select all the HL7 message definitions that you
This field is displayed if you select the Match expect to receive on the port number you
and translate inbound message operation. configured for your MLLP Adapter connection.
This integration receives and routes all
messages sent to that port number.
Documents that are not selected are ignored.
If you created the integration in a project, only
documents available in that project are visible for
selection.
Document Select the document to use.
This field is displayed if you select the Convert If you created the integration in a project, only
message reference to document or Translate documents available in that project are visible for
to outbound message operation. selection.

For example:
• If you select Match and translate inbound message, the selected ADT_A08
message document is converted from HL7 format to an Oracle Integration XML-
formatted message.

3-7
 Chapter 3
Convert HL7 Messages with a Healthcare Action

• If you select Translate to outbound message, the selected ADT_A08 message is

converted from an Oracle Integration XML message to an HL7-formatted message for
delivery to an external application that supports HL7.

3-8
 Chapter 3
Convert HL7 Messages with a Healthcare Action

• If you select Convert message reference to document, the message reference is

converted into a mappable payload. This operation returns the contents of the HL7
message as a variable in your integration that is ready to use in the business logic and
mapper of your integration. The variable appears on the source side of the mapper.

6. Click Finish.

3-9
 Chapter 3
Convert HL7 Messages with a Healthcare Action

7. Continue designing the remaining parts of your integration, including adding and
configuring your invoke connections.
Examples of using all three operations in a use case are provided. See Design Time and
Runtime Overview of an Oracle Integration for Healthcare Use Case.

3-10
4
Import FHIR Profile Packages
You can import FHIR profile packages into Oracle Integration. You then select the profile
package to use when configuring the FHIR Adapter in an integration.

Topics:
• Import a FHIR Profile Package
• Browse the Contents of the FHIR Profile Package
See Profile Definitions and Documentation.

Import a FHIR Profile Package

You can import a FHIR profile package into Oracle Integration and use the resource definitions
in that profile with the FHIR Adapter.
The HL7 FHIR standard defines a set of base resources (for example, patient and
observation). The standard base resources have generic definitions. FHIR profile packages
enables you to create customized resource definitions by specifying a set of constraints and/or
extensions on a base resource.
1. Import a FHIR profile into a project.
a. In the navigation pane, click Projects.
b. Click the project in which to import the FHIR profile package.

c. Click Healthcare .
d. In the FHIR profiles section, click Add.
2. Import a FHIR profile into a standalone environment.

• In the navigation pane, click Healthcare, then FHIR profiles.

3. Click Import.
The Import FHIR profile panel opens.
4. Enter the following details.

Element Description
Name Enter a FHIR profile package name.
Identifier This field is automatically populated with a unique FHIR profile
identifier based on your FHIR profile package name. You can
manually change this value, if needed.
Description Enter an optional description of this profile package.
Drag and Drop Click to select a TGZ file from your host or drag and drop a file into
the field. See Oracle Integration for Healthcare Support for HL7 and
FHIR for a list of tested profile packages.

5. Click Import.

4-1
 Chapter 4
Browse the Contents of the FHIR Profile Package

Import of the FHIR profile package occurs in the background and can take up to five
minutes.
Once imported, you can browse the contents of the profile package. See Browse the
Contents of the FHIR Profile Package.
The profile package is now available for selection when you configure the FHIR Adapter in
an integration. See Add the FHIR Adapter Connection to an Integration in Using the FHIR
Adapter with Oracle Integration 3.

Browse the Contents of the FHIR Profile Package

You can browse the contents of the imported FHIR profile package.
1. Browse a FHIR profile package in a project.
a. In the navigation pane, click Projects.
b. Click the project in which to browse the FHIR profile package.

c. Click Healthcare .
d. Go to the FHIR profiles section.
2. Browse a FHIR profile package in a standalone environment.

• In the navigation pane, click Healthcare, then FHIR profiles.

3. Click the FHIR profile package to browse.
The supported FHIR resources are shown.

4. Expand a resource and click View .

The segments and elements for the resource are displayed.

4-2
 Chapter 4
Browse the Contents of the FHIR Profile Package

5. Hover your cursor over a row and click View to view property details.

4-3
5
Design Time and Runtime Overview of an
Oracle Integration for Healthcare Use Case
This section provides an overview of key design-time and runtime component capabilities in
the healthcare use case that synchronizes EMR application patient updates with a FHIR
patient repository and a pathology system.

Topics:
• Use Case Overview
• Overview of the Design-Time Messages
• Overview of the Integration Receiving the Inbound HL7 Message During Runtime
• Overview of the Integration Processing the Patient Updates During Runtime
A quick tour of this use case is provided. See Synchronize EMR Patient Updates in a FHIR
Patient Repository and a Pathology System.

Use Case Overview

This use case provides a design-time and runtime overview of two integrations that perform the
following tasks.
The integrations are referred to as handlers and processors. The handler integration handles
all incoming HL7 messages for a given TCP/IP connection. The processor integration
processes each specific type of HL7 message.
• handleHL7_MLLP_6200_INBOUND: A parent integration that receives inbound HL7
messages from an EMR application. In this example, the EMR sends ADT_A08 (update
patient information) messages.
• processADT_A08: A child integration called by handleHL7_MLLP_6200_INBOUND to
process the inbound HL7 message and synchronize a FHIR patient repository and
pathology system with the same patient updates.
Both integrations are shown as successfully completed on the Instances page under the
Observe tab in the project.

5-1
 Chapter 5
Overview of the Design-Time Messages

Overview of the Design-Time Messages

This section provides a design-time overview of the HL7 messages used in this use case. This
use case is created inside a project.

1. The Healthcare tab for the project shows the available messages. A message is based
on an associated HL7 schema. The workflow is as follows:
• You create the schema and select the HL7 version, message version, and message
type to use.
• You create the message based on the schema.
• The message that you create is the HL7 message definition for the message that your
integration processes at runtime.
• You select the messages to use when configuring the healthcare action during
integration design.

As an example, the contents of the A08 Patient Update 2_5 message are as follows:
• HL7 version 2
• Message version 2.5
• Message type ADT_A08 (Update patient information)

5-2
 Chapter 5
Overview of the Integration Receiving the Inbound HL7 Message During Runtime

Overview of the Integration Receiving the Inbound HL7 Message

During Runtime
This section provides a runtime overview of key component responsibilities in the
handleHL7_MLLP_6200_INBOUND parent integration that receives the initial HL7 inbound
message from the EMR application. The EMR application was updated with patient details that
must also be automatically updated in a FHIR patient repository and pathology system.
• Receive and Convert the Inbound HL7 Message
• Invoke Child Integration

Receive and Convert the Inbound HL7 Message

1. The MLLP Adapter trigger connection (MLLPAdapter) listens for messages from an EMR
application that uses HL7. For this use case, the MLLP Adapter receives an HL7 Update
Patient Information message (ADT_A08) from the EMR application and starts the
integration.

5-3
 Chapter 5
Overview of the Integration Receiving the Inbound HL7 Message During Runtime

2. The logger action (logDebugMsg) logs the message to the debugger. A review of the
logger action in the activity stream shows the HL7-formatted message received from the
EMR application.

The message is then passed to the map and healthcare (translateHL7) actions. The
message is known as a healthcare message reference.

3. A view of the healthcare action configuration shows that the Match and translate inbound
message operation is selected. This operation converts the inbound HL7-formatted
messages selected in the Choose documents field to Oracle Integration XML-formatted
payload messages. The two messages selected for conversion were created during
design-time. See Overview of the Design-Time Messages.
Each message is based on an HL7 message schema that you want to process. For this
example, two different HL7 versions (2.3.1 and 2.5) of the ADT_A08 message are
selected. Any inbound messages that are received, but not selected in the Choose
documents field, are ignored and not processed.

5-4
 Chapter 5
Overview of the Integration Receiving the Inbound HL7 Message During Runtime

See Create Oracle Integration for Healthcare Schemas and Documents.

Invoke Child Integration

1. The map action (callProcessor) shows the source healthcare-message-reference

element of the translateHL7 healthcare action. This element contains the contents of the
healthcare action message in XML, but in an opaque message reference format. This
output is mapped as a binary object into the integration action that invokes the
processADT_MLLP_A08 child integration.

The target Connectivity Properties section shows the integration name, integration
version, and project code being called. This information is obtained from a lookup function.
For example, for Integration Code, if the message definition value is A08 Update Patient

5-5
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

2_5, it is routed to the processADT_A08 child integration. The use of lookup functions
offers a way to enable specific child integrations to process specific HL7 messages.
2. The integration action (callProcessor) invokes the processADT_A08 child integration to
process the ADT_A08 message.

Tip:
As a best practice, build a parent routing integration that can invoke a different
child integration to process a different HL7 inbound message type (one child
integration per message). Do not build a single integration with routing logic (for
example, a switch or for-each action) to process each message.

3. A view of the integration action configuration shows the processADT_A08 child integration
is selected to be invoked.

Overview of the Integration Processing the Patient Updates

During Runtime
This section provides a runtime overview of key component responsibilities in the
processADT_A08 child integration that is invoked by the handleHL7_MLLP_6200_INBOUND

5-6
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

parent integration to process the patient updates. The processADT_A08 child integration
automatically updates the FHIR patient repository and pathology system with the patient
details initially updated in the EMR application.
• Process the Integration
• Update the FHIR Patient Repository
• Update the Pathology System

Process the Integration

1. A REST Adapter trigger connection (ReceiveMessage) receives the inbound message
from the handleHL7_MLLP_6200_INBOUND parent integration.

The child integration includes a healthcare action (ConvertMessage) after the map action
of the same name.
2. A view of the healthcare action configuration shows that the Convert message reference
to document operation is selected. This operation converts the inbound HL7 document
into an Oracle Integration-mappable format.

3. The map action (ConvertMessage) shows the mapping.

4. The assign action (assignID) in the Route 1 branch of the switch action checks for a FHIR
patient ID in the message. If there is an ID, it is extracted from the message.

5-7
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

5. A check is made with the extracted ID to ensure that the patient exists in the FHIR patient
repository.

The following actions are performed.

a. The FHIR Adapter (check4Patient) is invoked to check if the patient exists in the FHIR
server repository.

5-8
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

b. The map action (check4Patient) passes the FHIR patient ID.

6. If the patient ID is found in the repository, a variable is assigned in the assign action
(Assignment5).

patientExists = 'TRUE'

7. The FHIR ID is passed to a parallel action (Parallel) with two branches. A parallel action
allows the path of an integration to be split into multiple branches. Each branch is
processed in parallel due to their independence from each other. For this use case, a
parallel branch is provided to update both external applications:
• FHIR patient repository (branch 1)
• Pathology system (branch 2)

Update the FHIR Patient Repository

1. The first branch in the parallel action includes a switch action with two routes.
• The first branch in the switch action identifies whether to add a new patient in the FHIR
patient repository. The popup message on the first branch indicates that if the

5-9
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

assignment of patientExists equals false, insert the patient into the FHIR patient
repository.

The following actions are performed.

a. The FHIR Adapter (insertPatient) inserts the patient into the FHIR server
repository.

b. The map action (insertPatient) shows the source HL7 message payload under
Transaction Data that is mapped to the target Patient.

5-10
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

c. The expanded PID:PID element shows the specific patient mappings, such as
patient name, gender, and home phone number.

• The second branch in the switch action identifies whether to update an existing patient.
The popup message on the first branch indicates that if the assignment of
patientExists equals true, update the patient in the FHIR patient repository.

The following actions are performed.

a. The FHIR Adapter (updatetPatient) updates the patient in the FHIR server repository.

5-11
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

b. The map action (updatetPatient) shows the source HL7 message payload under
Transaction Data that is mapped to the target Patient.

c. The expanded PID:PID element shows the specific patient mappings, such as patient
ID, name, gender, and home phone number.

2. The expanded activity stream shows that the patient already existed and was updated in
the FHIR server repository.

5-12
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

Update the Pathology System

1. The second branch in the parallel action updates the pathology system. Because the EMR
application uses HL7 version 2.5 and the pathology system uses HL7 version 2.3.1, a
message conversion to the earlier version must be performed.

2. The expanded mapper (Translate2NativeHL7) shows the HL7 version 2.5 source and HL7
version 2.3.1 target element mappings performed by the user at design time (patient ID,
patient name, date of birth, and more).

5-13
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

Before sending the document to the pathology system, it must be converted from Oracle
Integration XML format back to HL7 format in a healthcare action.
3. A view of the healthcare action (Translate2NativeHL7) configuration shows that the
Translate to outbound message operation is selected. This operation converts the
outbound XML-formatted payload message to the HL7 version 2.3.1-formatted payload
message selected in the Choose documents field. The healthcare action produces a
healthcare message reference to pass directly to the MLLP Adapter invoke connection.

4. An MLLP Adapter invoke connection (MLLPAdapter_Outbound) sends the HL7 version

2.3.1 message to the pathology system for updating.

5. The logger action (logOutboundMessage) in the expanded activity stream shows that the
HL7 2.3.1 message was sent.

5-14
 Chapter 5
Overview of the Integration Processing the Patient Updates During Runtime

The integration is now complete. The EMR application patient detail updates have been
automatically synchronized in the FHIR patient repository and pathology system.

5-15