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:
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.
IBM Websphere Related Tutorials
|IBM DB2 Tutorial|
IBM Websphere Related Interview Questions
|IBM DB2 Interview Questions||Weblogic Interview Questions|
|IBM WebSphere Datapower SOA Appliances Interview Questions||IBM WAS Administration Interview Questions|
|IBM Websphere Application Server Interview Questions||IBM WebSphere MQ Interview Questions|
|WebLogic Administration Interview Questions||IBM DataPower Interview Questions|
|Ibm Websphere Message Broker Interview Questions||Ibm Websphere Cast Iron Interview Questions|
|Ibm Websphere Process Server Interview Questions|
Ibm Websphere Tutorial
B2b Technologies And Standards
B2b Deployment Methodology
Aspects Of B2b Security
Websphere Datapower B2b Appliance Xb60
Device Setup And Administrative Tasks
B2b Configuration Options
Troubleshooting The Appliance
Xb60 And Wtx Integration For Hipaa
Xb60 With Transformation
Trading Outbound Binary Documents Using The B2b Gateway Service
Trading Binary Documents Using A Multi-protocol Gateway Service
Handling Soap Messages With Attachments In A B2b Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.