1. Using Oracle Integration for Healthcare in Oracle Integration 3
  2. Design Time and Runtime Overview of an Oracle Integration for Healthcare Use Case
  3. Overview of the Integration Processing the Patient Updates During Runtime

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

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


    The trigger connection, assign action, map action, and healthcare action are shown.

    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.


    The healthcare action is shown. To the right is the View - Configure healthcare action call page. The Name, Description, Operation, and Document fields are shown.

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


    The mapper shows three icons in the upper left. In the upper right are a Developer icon, XSLT icon, and six icons. Below this are the Sources section, Mapping canvas section, and Target section. The Sources and Target sections both include a Search icon. A source Healthcare Message Reference element is mapped to a target Healthcare Message Reference element.

  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.


    The healthcare action and switch action are shown. The switch action is expanded to show two routes: Route 1 (which includes an assign action) and Otherwise (which includes an assign action).

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


    The switch action consists of two branches: Route 1 includes an assign action, map action, FHIR Adapter invoke, and a second switch action with an assign action. The Otherwise route includes an assign action.

    The following actions are performed.

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


      The Configure Interaction page for the FHIR invoke shows the FHIR Schema Source, FHIR Resource (value of Patient), and FHIR Interaction (value of read) fields.

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


      The mapper shows three icons in the upper left. In the upper right are a Developer icon, XSLT icon, and six icons. Below this are the Sources section, Mapping canvas section, and Target section. The Target section both include a Search icon. A source FHIR ID element is mapped to a target ID element.

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


    The Configure assign panel shows a value of 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 assignment of patientExists equals false, insert the patient into the FHIR patient repository.


      The parallel action is shown. Route 1 includes a switch with a map action, invoke action, map action, and invoke action. Below this is Route 2.

      The following actions are performed.

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


        The Configure Interaction page for the FHIR invoke shows the FHIR Schema Source, FHIR Resource (value of Patient), FHIR Interaction (value of create), and Configure Resource fields.

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


        The mapper shows three icons in the upper left. In the upper right are a Developer icon, XSLT icon, and six icons. Below this are the Sources section, Mapping canvas section, and Target section. The Sources and Target sections both include a Search icon. A source PID:PID element is mapped to a target Patient element.

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


        The target PID:PID element is expanded to show the mapped target elements Patient Name, Mother's Maiden Name, Sex, and Phone Number - Home.

    • 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 Route 2 icon is selected icon is selected to show patientExists is true. A map action and FHIR Adapter connection are part of this route. Below this is an Otherwise branch with a logger action.

    The following actions are performed.

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


      The Configure Interaction page for the FHIR invoke shows the FHIR Schema Source, FHIR Resource (value of Patient), FHIR Interaction (value of update), and Configure Resource fields.

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


      The mapper shows three icons in the upper left. In the upper right are a Developer icon, XSLT icon, and six icons. Below this are the Sources section, Mapping canvas section, and Target section. The Sources and Target sections both include a Search icon. A source PID:PID element is mapped to a target Patient element.

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


      The target PID:PID element is expanded to show elements Set ID, Patient ID, Patient Identifier List, Alternate Patient ID - PID, Patient Name, Sex, and Phone Number - Home.

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


    Parallel Action Branch 1 is expanded. The milestone named Wire Message received by Invoke updatePatient is expanded to show a message indicating that the patient update was successful.

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.


    Branch 2 of the parallel action includes a map action, healthcare action, logger action, map action, and MLLP Adapter invoke connection.

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


    The mapper shows three icons in the upper left. In the upper right are a Developer icon, XSLT icon, and six icons. Below this are the Sources section, Mapping canvas section, and Target section. The Sources and Target sections both include a Search icon. Source Transaction Data elements are mapped to target Transaction Data elements.

    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.


    The healthcare action is shown. To the right is the View - Configure healthcare action call page. Fields for Name, Description, Operation, and Document fields are shown.

  4. An MLLP Adapter invoke connection (MLLPAdapter_Outbound) sends the HL7 version 2.3.1 message to the pathology system for updating.


    Branch 2 of the parallel action includes a map action, healthcare action, logger action, map action, and MLLP Adapter invoke connection.

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


    The activity stream shows the HL7 V2 request acknowledged milestone expanded. The message is shown.

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