health care scenario - IBM Websphere

In this section,we provide an overview of our health care scenario.For this particular scenario, we implement a two-way flow that corresponds with an incoming health care claim (EDI 837 format) to the health provider system and its corresponding claim payment (EDI 835 format).

Note: It is important to note that the Functional Acknowledgement (EDIX12 824, 997, or 999) is not used in this example scenario in order to keep the example flow simple and easy to follow.

As you can see in this,the scenario can be divided into two logical subsets:

  • The inbound scenario of receiving the Health Care Claim by the trading partner.
  • The outbound flow to send the corresponding claim payment back to the trading partner. All the messages between the partner and the provider are exchanged, encrypted,and signed as a consequence of the assumed trading manager agreement.

HIPAA Health Care Claim Processing Transaction Flow

HIPAA Health Care Claim Processing Transaction Flow

From a naming perspective, we refer to our trading hub as the HIPAA Provider and to our partner as the HIPAA Partner (reflected in Figure above as Provider).

The health care claim: Inbound flow

In the case of an incoming health care claim,the HIPAA Provider system accepts a valid EDI X12 837 message (wrapped,signed, and encrypted in an AS2 message) that comes from the Internet to the demilitarized zone (DMZ),where the DataPower device is located. The device is responsible for decrypting the message and validating its signature,identifying the type of message that arrives (EDI, X12, XML, and so forth) and, based on the partner’s information,deciding whether the partner is allowed to trade with that kind of document.If that is the case,the device routes the document to whichever destination is set for this specific partner (in our case, it is the WTX Launcher, which performs the format transformation). DataPower also manages sending a signed and encrypted Message Disposition Notification (MDN), which is positive or negative depending on the results of the actions just explained.

After the document is delivered to the WTX Launcher,a transformation map is triggered. This transformation map is responsible for transforming the incoming X12 837 format into a custom flat file claim that can be consumed by a potential customer’s back end when the map is finished.

The claim payment: Outbound flow

For the claim payment, the WTX Launcher system is triggered by a new flat file message arriving to the system,which is transformed into a compliant X12 835 message. This message is sent to the appliance, and the appliance packages the message in a standard signed and encrypted AS2 message to be routed to the partner system, based on the partner information that is configured in the device.

After the message is sent to the trading partner, the device waits for the corresponding MDN, which is decrypted and signature-validated before considering that transaction complete.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Websphere Topics