Cloud Recipes: Oracle Integration Cloud B2B support for X12 HIPAA

Oracle Integration B2B can be used to securely and reliably exchange business documents between your back-end applications and trading partners.

With the 24.02 release of OIC, support for X12 HIPAA document type is available. X12 HIPAA is a subset of the X12 standard, commonly used in the healthcare industry.

The healthcare integration industry (known as healthcare interoperability) uses several different message standards and protocols that are not used in other industry’s enterprise integration uses cases. X12 HIPPA being one of them, its a set of healthcare insurance specific B2B transaction definitions in the X12 format used for interoperability between payers and providers for exchange of data about health insurance claims and payments.

I recently came across a usecase where customer as part of their claims process generates 837 EDI claim files which are sent to insurance companies via a clearing house. Customer eventually gets back 835 ERA files from the clearing house detailing claims payment, denial, and adjustment information.

Customer would like to build a process that can ingest 837 and 835 files, parse them, model the data, and associate the claims requests to their responses. Customer’s goal would be to query a claim and retrieve all the information related to it, e.g., when was it sent, what procedures are part of the claim, was it denied, how much payment was accepted, etc.

Here is a high-level diagram illustrating the flow:

In this blog I will demonstrate how to use OIC for EDI 837 (Health Care Claim) parsing. Data can be picked up in OIC through multiple mechanisms like AS2, FTP and use OIC to parse the message to be inserted into a data layer(We are using Oracle ADW).

This same approach can be used for processing other EDI Documents like 835 (Health Care Claim Payment/Advice), 834 (Benefit Enrollment and Maintenance), 276 (Health Care Claim Status Request) etc. as well.

Log into Oracle Integration Cloud service console

Create Autonomous Data Warehouse Connection

Create FTP Connection

(Using the embedded SFTP-compliant repository in Oracle Integration for storing and retrieving files)

Create REST Connection

Now navigate to B2B

Select B2B Schemas and On the B2B Schemas page, click Create to create a new schema

A B2B Schema represents a customized variant of one of the Standard schemas.

In the left navigation pane, click B2B Documents. On the B2B Documents page, click Create to create a new B2B Document.

A B2B Document is a mandatory object required by an Agreement, and specifies a data format and some additional configuration about the data format.

Host Profile is where you configure information about your company.

The Host Profile has only B2B Identifiers for you to enter. This is where you will enter your company's identity information such as EDI Interchange ID and AS2 Identifier.

In the left navigation pane, click Host Profile

Enter the details and click Save to save the Host Profile.

A Trading Partner is the external business entity with which your company interacts to send or receive business documents, such as Health Care Claim, in electronic form.

In the left navigation pane, click Trading Partners. Click Create to create Trading Partner,

You can add ways to contact the trading partner, such as their name, email, phone number, or short message service (SMS) number. Use this information to contact individuals offline, as needed. Contacts are currently provided only for reference and are not used in Oracle Integration B2B.

Add contact and then Click Save

You collect identifying information from your external trading partner and enter it on their behalf in the B2B Identifiers section. This is very similar, in concept, to the identifiers specified under Host Profile Identifiers. In a message exchange, the Host Identifiers and Trading Partner Identifiers are used in the role of a sender or receiver, depending on the message direction.

EDI Interchange ID - This identifier is used as either the Interchange Sender or Receiver ID field of the interchange envelope.

EDI Interchange ID Qualifier - It is a code to indicate the category of the value specified in the EDI Interchange ID (for example, DUNS number, IATA number, and so on). For an outbound message, this value is inserted as the Interchange Receiver ID Qualifier.

EDI Group ID - For an outbound X12 message, this value is inserted in the GS segment as the Application Receiver's Code. For an inbound message, this value is used only in case the EDI Interchange ID, on its own, is not enough to uniquely identify a trading partner

EDI Group ID Qualifier - It is a code to indicate the category of the value specified in the EDI Group ID (for example, DUNS number, IATA number, and so on).Only used for an outbound message, to insert as EDI Group ID Qualifier, if specified.

Application Partner ID - Optionally used as an alternate way to specify which trading partner to which to route an outbound message.

Click the B2B Identifiers tab.

Select an Identifier or, if none are defined, click Add Identifiers +.

Add B2B identifier and then Click Save

A Transport maps to a technical communication protocol. In most cases, you add one transport per trading partner to send or receive messages to and from the partner.

Click the Transports & Agreements tab. In the Transports section, click + to add a new Transport.

Enter name and Select the FTP Connection you previously created.

(AS2,FTP,RosettaNet,REST transport protocols are supported)

Two Integrations are created automatically when a Transport is created. These Integrations are the heart of the Transport for its runtime functioning. The two Integrations process the runtime messages that pass through the Transport.

B2B Integration for receiving messages.
B2B Integration for sending messages.

Click the Action menu on the DemoEDI837 Transport to view available actions. Select Deploy, then Deploy again to confirm the deployment.

Each Transport is listed with its Name, Direction/Type, Status, and Last Updated time. The Direction is an indicator of whether it is configured to receive (down arrow), send (up arrow), or both.

You define one or more Agreements for a B2B Trading Partner with an intent to send or receive only certain types of business documents to or from that Trading Partner.

In the Inbound agreements section, click + to add a new Agreement.

Check An existing B2B document and select the document created earlier(DemoHealthCareClaimDocument)

Select the integration created automatically along with Transport for receiving message and then click Add

Click the Action menu on the Demo Receive 837 Outbound Agreement to view available actions. Select Deploy, then Deploy again to confirm the deployment.

You can deploy Transport and Transport Agreements in any sequence and if you modify anything, you can just deploy the corresponding section. For example, if you modify Outbound Transport Agreement then you can deploy (or redeploy) only Outbound Transport Agreement.

Exit the Trading Partner page.

Let's create a backend integration flow that receives the message from B2B Integration for receiving messages and sync with ADW.

Navigate to Home > Design > Integrations and Create an App Driven Orchestration integration

Click on + sign and choose the REST Trigger Connection

Click on + sign after the Rest Trigger and choose For each Action

Click on + sign inside For each and choose B2B Action

Click on + sign after the For each Action and choose ADW Connection

Integration is now completed and you would need to complete the primary business identifier for the integration.

Save and close. Now Activate the Integration

Edit the Integration created automatically when Transport was created earlier for receiving messages(DEMOMED TP 837 FTP Receive) and call this child backend service from same.