Introduction
Note: text in bold/italic is taken directly from the Oracle Docs.
SOA Suite for Healthcare integration has been around since 11g, there ´have been some changes for 12c.
This blog post, however, is just a genral introduction to the component.
HealthCare document exchange often equates to HL7 and a great resource in this area is the HAPI TestPanel - we will use this later for testing our healthCare app.
This is available from -
SOA Suite for Healthcare Integration 12c
So what components are we talking about here?
The healthcare console -
This has 3 tabs -
Designer - used for creating HealthCare artefacts
Dashboards - for monitoring HealthCare engine activity
Reports - self explanatory.
Designer
Here you create your artifacts such as -
document protocols, endpoints, callouts, mapsets etc.
Document protocols
These are essentially doc definitions, used later in endpoint definitions.
You can create documents with Oracle Document Editor, or you can use a pre-seeded export zip file that contains already created document definitions by using the Import/Export feature available in the Administration tab.Once imported, these definitions are visible in the Configuration tab
ADT_A03 is the Discharge Patient message.
ADT stands for Admit-Discharge-Transfer
ADT generic is what is used generally. This can include A01(Admit) to A51.
You can create a Generic ADT message, which allows you to create various ADT messages in a generic format.
Customization of HL7 docs is done by adding Z-Segments to doc defs, using the Oracle Document Editor. Some may also amend the HL7 doc defs themselves, or use them for other purposes..
Endpoints
Endpoints define how documents are exchanged with an external system, specifying the location, transport protocol, documents to be exchanged, and other configuration parameters.
An endpoint can be a URL, folders, or path, among others.
Based on the direction of the message, an endpoint can be inbound, outbound, or both. For example, when Oracle SOA Suite for healthcare integration reads from a directory, the directory is the inbound endpoint.
Conversely, when Oracle SOA Suite for healthcare integration
writes to or sends messages to a directory, the directory is the outbound endpoint.
Also, an MLLP endpoint can be used both for receiving and sending messages.
For Oracle SOA Suite for healthcare integration, you must associate an endpoint with
document definitions and enable the endpoint to be able to start sending and receiving messages.
An endpoint can be a URL, folders, or path, among others.
Based on the direction of the message, an endpoint can be inbound, outbound, or both. For example, when Oracle SOA Suite for healthcare integration reads from a directory, the directory is the inbound endpoint.
Conversely, when Oracle SOA Suite for healthcare integration
writes to or sends messages to a directory, the directory is the outbound endpoint.
Also, an MLLP endpoint can be used both for receiving and sending messages.
For Oracle SOA Suite for healthcare integration, you must associate an endpoint with
document definitions and enable the endpoint to be able to start sending and receiving messages.
Here we have the in_patient_admission receiving a doc of type ADT_A03. Naturally, from a functional perspective, this should be A01.
Here we have the in_patient_laboratory sending a doc of type ADT_A03.
Callouts: Java code that can do supplementary processing.
In my example, In_patient_admission listens on port 8010
In_Patient_Laboratory 9010.
Note In_Patient_Admission is defined as a server.
In_Patient_Laboratory 9010.
Note In_Patient_Admission is defined as a server.
The other, as client.
If the endpoint is configured as server,
Oracle SOA Suite for healthcare integration engine starts listening on a port and waits for a client to connect to it. In general, the server connection mode is for inbound case. When configured as client, the engine connects to hostname and port of a remote computer or device. In general, this is for an outbound case.
Oracle SOA Suite for healthcare integration engine starts listening on a port and waits for a client to connect to it. In general, the server connection mode is for inbound case. When configured as client, the engine connects to hostname and port of a remote computer or device. In general, this is for an outbound case.
Dashboard
The HealthCare adapter
Allows us to interface with SOA Suite HealthCare Integration from composites.
Note:
Composites are the value add for enrichment etc.
However, 70% to 80% of hospital uses cases are pass thru. In the following example,
the HL7 payload is translated to XML for demo purposes only. I will show how to pass by reference later.
the HL7 payload is translated to XML for demo purposes only. I will show how to pass by reference later.
Using the HealthCare Adapter -
Here is a composite, designed to receive an HL7 ADT_A03 message.
Configured as follows -
Now I add an adapter to 'send' the HL7 message to In_patient_laboratory.
Now, I add a Mediator to route from receive to send.
I now add the following routing assignment rule to the Mediator.
Just to recap, the above composite receives a HL7 doc and then sends it on to the "In_Patient_Laboratory" endpoint.
In this case, the In_Patient_Admission endpoint.
So I select the Endpoint and configure it to call the composite, we just created.
Now to testing...
The In_Patient_Laboratory receiving on port 9010.
We use HAPI to test -
I send a message to In_Patient_Admission
I click Send
Now I click on the In_Patient_Laboratory endpoint - it has received the message
from the composite, called by In_Patient_Admission
Simple isn't it?
HealthCare Integration Monitoring - Dashboard
Let's look at the monitoring functionality -
We can also create our own dashboards -
We can drill down for more details -
drill even further...
to the message -
to the composite -
Click on Application Message to see the xml payload from the composite.
Naturally we can also see the trace in em, just by clicking on the composite -
The example above is currently designed to simply pass messages through SOA Suite. The only reason we are parsing (translating) the message to xml is so we can define the sequencing in the composite (Mediator FIFO Resequencing). Leveraging sequencing rules, will allow us to maintain the sequence of messages at the interface level. This provides a performance benefit, as we no longer need to do the xml marshalling/unmarshalling.
Just un-check the Translation checkbox.
Then activate interface sequencing at Transport Protocol level.
Now, we need to amend the composite as follows - the Receive will now
get an opaque document.
The Send will also be configured for opaque.
The Healthcare Adapter generates a SequenceId upon receipt of the inbound message. This Id must be passed through the composite. In our case we need to modify our Mediator to pass this value on.
The property is called hc.interfaceSequenceId, so we just assign this from in to out
Re-test
Look at the Application Message in the Dashboard.
no XML translation.
Excellent Stuff!
No comments:
Post a Comment