HIPAA scenario outline - IBM Websphere

After describing at a high level the key aspects of the scenario that we implement,we explain in technical detail all of the steps necessary in order to fully implement the solution. One of the key aspects of the scenario implementation is that we simulate the trading partner within the DataPower device,which means that we create a specific B2B Gateway Service for the trading partner. We present a complete picture of all the services and objects to implement in the scenario outline,where we also present a summary of what is created.

Scenario outline

this shows the architecture of the scenario.

This architecture demonstrates that the DataPower device can provide the gateway services for both the partner and the provider.The left side of Figure below corresponds to the simulated trading partner,which is referred to as the HIPAA Partner, and the right side corresponds to the hub system, which is referred to as the HIPAA Provider.

HIPAA scenario outline

HIPAA scenario outline

As you can see in Figure above. we use WebSphere MQ (WMQ) queues to trigger WTXLauncher to transform incoming messages from both sides (Partner and back end) as well as a potential partner back end. The rest of the interactions are HTTP-based, and more specifically, AS2 over HTTP when going to the Internet.

Here is a summary of the steps that were used to implement the scenario:

  • Step 1: Creating all the necessary crypto objects
  • Step 2: Creating the HIPAA Partner partner profiles
  • Step 3: Creating the HIPAA Provider partner profiles
  • Step 4: Creating HIPAA Partner B2B Gateway Service
  • Step 5: Creating HIPAA Provider B2B Gateway Service
  • Step 6: Creating the inbound mapping system
  • Step 7: Creating the outbound mapping system

Scenario implementation

Now that we have the details of everything that needs to be configured, it is time to take a deeper look into each of the steps.

Step 1: Creating all the necessary crypto objects
This scenario is intended for people who are experienced with the DataPower device, so detail about how to create the crypto objects is not included. However, it is important to point out that several objects are required for signing and validating signatures and encrypting anddecrypting payloads.

We created the following objects specifically for this scenario:

_ Public/Private keys:

  • Health_partner keys pair
  • Hipaa_provider keys pair

_ Validation credentials:

  • HIPAAPartner_valcred: Used to validate signatures coming from the HIPAA partner
  • HIPAAProvider_valcred: Used to validate signatures coming from the HIPAA provider

_ Identification credentials:

  • HIPAAPartner_IDcred: Used to sign messages from the HIPAA partner and to decrypt payloads coming from the HIPAA provider.
  • HIPAAProvider_IDcred: Used to sign messages from the HIPAA Provider and to decrypt payloads coming from the HIPAA provider.

Both ID Credentials and validation credential objects are configured with the corresponding key pair.

Step 2: Creating the HIPAA Partner partner profiles
A partner profile is an object that defines the routing for messages by defining the destinations to it,as well as establishing the AS Security rules when interchanginginformation with that specific partner.

Because we simulate our trading within the DataPower device,we need two HIPAA Partner profiles: an internal profile for the B2B Gateway Service that will represent the partner back end and an external profile to be included in the HIPAA Provider B2B Gateway Service and where we set the destination pointing to the other B2B Gateway Service.

HIPAA Partner internal profile
The HIPAA Partner internal profile contains the details that help manage the information about what kind of AS Security the partner expects,including how to sign the outgoing messages, decipher the incoming messages (AS Security tab),and where to route the
messages (Destinations tab).

Here are the aspects of the configuration that you need to consider in order to successfully configure this profile, which is named it HIPAA_Partner_int. We follow this methodology for the next objects as well.First of all,we need to add Business IDs, so that the B2B Gateway (B2BGW) Service can associate the incoming business ID in the AS2 headers to this partner profile and route the message to its destination.

For this particular case, we have two Business IDs: zzhipaapartner comes in the X12 sent from our back end and 01hipaapartner comes from the partner to our system.

HIPAA Partner internal profile Main configuration tab

HIPAA Partner internal profile Main configuration tab

The next step is to properly configure AS Security. We use the crypto objects that we have created in“Step 1: Creating all the necessary crypto objects”.

HIPAA Partner internal profile AS Security configuration tab

HIPAA Partner internal profile AS Security configuration tab

As you can see in Figure above, we require Signature and Encryption on the InboundSecurity, which means that we only accept signed and encrypted messages.In order to decrypt those messages, we need our HIPAA Partner ID Credentials, which contain the private key.

From an Outbound Security perspective, we sign the AS2 messages, so we need to checkthat option and use the HIPAA _Partner ID credentials to sign messages with the HIPAA Partner private key.

Important: Notice that we use the same ID Credential objects, because in order to simplify the scenario,we assume that the HIPAA Partner uses the same certificate and key pair for all the crypto tasks.

The next step is to configure destinations. As we can see in this, the HIPAA Internal Partner sends its messages via WebSphere MQ (WMQ) to the MQ Queue that simulates a back end in the Partner system.

This MQ destination,which is named MQ_2_backend, will only accept X12 messages to be routed to the back end.

this shows the configuration. Do not forget to click Apply to save your destination.

HIPAA Partner internal profile Destinations tab details

HIPAA Partner internal profile Destinations tab details

HIPAA Partner external profile
The HIPAA Partner external profile contains the details that manage the information that is needed by the provider in order to successfully trade with the HIPAA Partner (AS Security tab) and the Partner destination point (Destinations tab).

Here, we discuss the aspects of the configuration in order to successfully configure thisprofile. We have named the profile HIPAA_Partner. In our naming convention, external partners do not have any special indication of that on the name,but they can choose their own naming convention.

From a Business ID perspective, we have the same configuration that we had on theinternal profile.this shows the configuration.

HIPAA Provider external profile Main configuration tab

HIPAA Provider external profile Main configuration tab

From an AS Security standpoint,we need to enter all the information to validate incoming signatures from the HIPAA Partner, because this partner profile will attach to the Provider B2B Gateway Service. Validation Credentials need to be configured to verify that the signature coming from the HIPAA Partner has been created with the HIPAA partner private key.

HIPAA Partner internal profile AS Security configuration tab

HIPAA Partner internal profile AS Security configuration tab

In the Destinations tab, we now set up the URL where our HIPAA partner waits for HIPAA Provider AS2 messages. Therefore, we configure an AS2 destination.This shows the upper part of the configuration page, where we set up the destination URL and the document types that are enabled (we will only use AS2).

HIPAA Partner external profile Destination details

HIPAA Partner external profile Destination details

If we scroll down,we see the rest of the configuration options as depicted. AS outbound security deals with how we want to send our AS2 messages. In our HIPAA Partner internal profile,we stated that it was a requirement to sign and encrypt all the incoming messages. We discuss signing in the HIPAA Provider internal profile (refer to step 3), because we use its private key. However from an encryption standpoint,we must configure the HIPAA Partner encryption certificate. Notice that this entry is only a certificate, not a validation credential object.

In the Advanced AS Behavior section,we request an MDN when we send our messages to the HIPAA Partner, and we request that message retransmission is attempted up to three times, in case a problem occurs.

HIPAA Partner external profile Destination details (continuation)

HIPAA Partner external profile Destination details (continuation)

We have finished configuring all the required profiles for the HIPAA Partner.

Step 3: Creating the HIPAA Provider partner profiles
Similar to Step 2,we also need two HIPAA Provider profiles: an internal profile to associate with the HIPAA Provider B2B Gateway Service (refer to Step 6 for further details) and an external profile to associate with the HIPAA Partner B2B Gateway Service that will enable our partner to successfully send all the messages to the HIPAA Provider.

HIPAA Provider internal profile
The HIPAA Provider internal profile contains the details that manage the information about the type of AS Security that the provider expects (AS Security tab), including signing the outgoing messages, deciphering the incoming messages,and where the messages are routed (Destinations tab).

Here are the aspects of the configuration to consider in order to successfully configure this profile. We have named it HIPAA_Provider_int.

Business IDs are the first required aspect, so the B2BGW service can associate theincoming business ID in the AS2 headers to this partner profile and route a messageto its destination.

W have two Business IDs: zzhipaaprovider comes in on the X12 sent from the back end and 01hipaaprovider comes from the partner to our system.

HIPAA Provider internal profile Main configuration tab

HIPAA Provider internal profile Main configuration tab

This shows all of the AS Security aspects. As in our Partner case, we also require Signature and Encryption on the Inbound Security. We will only accept signed and encryptedmessages. In order to decrypt those messages, we need our HIPAA Partner ID credentials that contain the private key.

From an Outbound Security perspective,we sign the AS2 messages,so we need to check both options and use HIPAA _Provider ID credentials to sign messages with the HIPAA
Provider private key.

HIPAA Provider internal profile AS Security configuration tab

HIPAA Provider internal profile AS Security configuration tab

The next step is to configure Destinations.This shows that the HIPAA Provider Internal Profile will send its messages via WebSphere MQ (WMQ) to the WTX system to trigger the message transformation.

Therefore,you must set an MQ destination. This MQ destination,which is namedMQ_2_backend, only accepts X12 messages to route to the back end.

This shows the configuration. Do not forget to click Apply on the window to save yourdestination.

HIPAA Provider internal profile Destinations tab details

HIPAA Provider internal profile Destinations tab details

HIPAA Provider external profile
The HIPAA Provider external profile contains the details that manage the information needed by the partner to successfully trade with the HIPAA Provider (AS Security tab) and the Provider destination point (Destinations tab).

We have named the HIPAA Provider external profile HIPAA_Provider. In our naming convention, external partners are not indicated by their name, but you can choose a meaningful convention.From a Business ID perspective, we have the same configuration that we had on the internal profile.This shows the configuration.

HIPAA Provider external profile Main configuration tab

HIPAA Provider external profile Main configuration tab

From an AS Security standpoint, we need to enter all the information to validate incoming signatures from the HIPAA Provider because this partner profile is attached to the Partner B2B Gateway Service.

Only validation credentials need to be configured at this point. They will be used to verify that the signature coming from the HIPAA provider was created with the HIPAA provider private key.

HIPAA Provider external profile AS Security configuration tab

HIPAA Provider external profile AS Security configuration tab

In the Destinations tab, we now set up the URL where our HIPAA partner is waiting for HIPAA Partner AS2 messages. Therefore, we configure an AS2 destination. This shows the upper part of the configuration page, where we set up the destination URL and the document types that are enabled (we only use AS2).

HIPAA Provider external profile Destinations tab details

HIPAA Provider external profile Destinations tab details

If we scroll down, we find the rest of the configuration options. AS outbound security deals with how we send AS2 messages. In our HIPAA Provider internal profile, we stated that it was a requirement to sign and encrypt all the incoming messages.

In the Advanced AS Behavior section,we request an MDN when we send our messages to the HIPAA Provider,and we request that message retransmission is attempted up to three times, in case a problem occurs.

HIPAA Provider external profile Destinations tab details (continuation)

HIPAA Provider external profile Destinations tab details (continuation)

Step 4: Creating the HIPAA Partner B2B Gateway Service
After creating all the profiles for the scenario, it is time to create the B2B Gateway Services. For the HIPAA Partner, this service acts as the entry point to their system,identifying the incoming messages and mapping the incoming messages to the specific profiles that need to handle them. As we can see this, the HIPAA Partner B2B Gateway Service has two partners attached: HIPAA Partner internal profile and HIPAA Provider external profile. You can add as many partner profiles as your business needs require.

The HIPAA Partner B2B Gateway Service has two Front Side Handlers (FSHs), which are used to receive incoming traffic. For this particular case, an AS2 FSH handler is needed to receive messages coming from the HIPAA Provider, and an HTTP FSH is needed to receive messages from the HIPAA Partner back end.

HIPAA Partner B2B Gateway architecture

HIPAA Partner B2B Gateway architecture

Note:For details about how to configure Front Side Handlers, refer to the XB60 AS2 Trading Tutorial (which is found in the Additional Materials folder.You can access the Additional Materials folder by using the instructions in Appendix A,“Additional material” ).

This shows the main window for the HIPAA Partner B2B Gateway Service.

HIPAA Partner B2B Gateway Main configuration tab

HIPAA Partner B2B Gateway Main configuration tab

The above shows both Front Side Handlers are attached (in the Front Side Protocol Handlers section) and the two Partner Profiles are attached (in the Attach Partner Profiles section). In order to add a new partner profile, select the profile that you want from the drop-down list and click Add. Then, select the Profile Destination if the profile has more than one destination, or leave it as default if the profile only has one destination.

This shows the detailed configuration on the AS2 FSH.

HIPAA Partner AS2 FSH

HIPAA Partner AS2 FSH

On the Archive configuration tab,we have selected Purge only and entered 3 Days for the Archive Document age,even though you might need to resize this property in a production environment.

HIPAA Partner B2B Gateway Archive configuration tab

HIPAA Partner B2B Gateway Archive configuration tab

There are no XML Formats to consider in this use case, because we are not trading with XML messages. Do do not add anything on this XML Formats tab .

HIPAA Partner B2B Gateway XML Formats tab

HIPAA Partner B2B Gateway XML Formats tab

Our AS2 MDNs are set up as synchronous,so you do not need to set a Default AS2 MDN Return path. Do not make any configuration changes in the Advanced tab. Make sure to click Apply to save the configuration changes.

HIPAA Partner B2B Gateway Advanced tab

HIPAA Partner B2B Gateway Advanced tab

Step 5:Creating the HIPAA Provider B2B Gateway Service
For the HIPAA Provider case, our B2B Gateway Service acts as the entry point to their system, identifying the incoming messages and mapping the incoming messages with the specific profiles that need to handle them. As we can see in Figure below, the HIPAA Provider B2B Gateway Service has two partners attached: HIPAA Provider internal profile and HIPAA Partner external profile.

The HIPAA Provider B2B Gateway Service has two Front Side Handlers to receive incoming traffic. For this particular case,an AS2 FSH is needed to receive messages coming from the HIPAA Partner and an MQ FSH is needed to receive messages from the WTX system back end.

HIPAA Provider B2B Gateway architecture

HIPAA Provider B2B Gateway architecture

This shows a view of the B2B Gateway Service main window with both Front Side Handlers and the two Partner Profiles.

HIPAA Provider B2B Gateway Main configuration tab

HIPAA Provider B2B Gateway Main configuration tab

This shows the detailed configuration on the AS2 FSH named HIPAA_Provider_AS2SFSH.

HIPAA Provider HTTP FSH

HIPAA Provider HTTP FSH

This shows the Archive tab view. Make sure to click Apply to save the changes.

HIPAA Provider B2B Gateway Archive tab in the configuration

HIPAA Provider B2B Gateway Archive tab in the configuration

Step 6: Creating the inbound mapping system
Now, it is time to build the transformation infrastructure to map the incoming Health care payment in X12 837 to the flat file format required by the back end systems.

We have already stated that these transformations are triggered by a message arriving into a specific MQ Queue; therefore, we are dealing with an event-based transformation that requires a Launcher system to handle it.

Important:Although we chose Launcher in this scenario as the event-driven engine, you can use other methods, such as WebSphere Message Broker or WebSphere Enterprise Service Bus (WSB), which also are tightly integrated with WebSphere Transformation Extender.

A portion of the incoming data that will be passed from the DataPower XB60 device to the MQ Queue is this.

Example - Input data coming from X12 837 format

Notice that 01hipaapartner and 01hipaaprovider are the business IDs that we configured earlier for the Partner profile objects.

This shows a part of the expected output that the system will produce after the transformation is complete.

Example - Output coming from the mapping inbound

Inbound map
Now, we look at the map structure.

The transformation map Inbound837 uses the Partner X12 Inbound Interchange EDI component of the HIPAA_X12_835_837.mtt,a type tree that is included in the WebSphere Transformation Extender pack for HIPAA. We will not have to create a type tree representation for that format. For the output type tree component, it uses Claim_FlatFile.mtt which contains a representation of the flat file format that will be consumed by the back end.

From a mapping perspective, the key element is that at the Claims level, we will need to split the mapping between Subscriber claims and Patient claims. We will create two functional maps for each case and will use the EITHER function to choose between these functional maps as in this.

Functional map call to choose between subscriber and patient claim

Functional map call to choose between subscriber and patient claim

This show the logic of both functional maps, including input and output cards.

Logical structure of the Inbound837.mmc map when we work with a Subscriber claim

Logical structure of the Inbound837.mmc map when we work with a Subscriber claim

Logical structure of the Inbound837.mmc map when we work with a Patient claim

Logical structure of the Inbound837.mmc map when we work with a Patient claim

Input system
After creating the map,it is time to create the Launcher system by using the Integration Flow Designer tool, which comes with WebSphere Transformation Extender V8.2. Create an event-based system that listens on Q1 from the Queue Manager QM,and put the output transformed file in Q2 from the same Queue Manager.

These are the settings that you use for the Input Card and Output Card inside Map Settings.

Notice that the two most important aspects are the MQ syntax and that the Source Event parameter is set to ON,which will cause the system to be triggered every time a message arrives on Q1.

This shows a widely used property within Transaction where you can can specify what to do with the message in case of success ( the On Success property) and in the case of failure (the On Failure property). This configuration is commonly used. If the message is transformed successfully, it will be deleted from the input queue. The transaction will be rolled back if the transformation fails,so that no message is lost.

Input Card map settings for Inbound 837 system

Input Card map settings for Inbound 837 system

This shows the Output Card with Q2.

Output Card map settings for Inbound 837 system

Output Card map settings for Inbound 837 system

This shows how the final system appears.The small pair of glasses in the center of the figure indicates that it is an event-based system.

Launcher system created to handle inbound mapping

Launcher system created to handle inbound mapping

After completing those steps,deploy the system in your system and start the Windows® Launcher service. Your system will be ready to transform.

Step 7: Creating the outbound mapping system
Now we must build the transformation infrastructure that will map the outgoing flat file coming from our back-end system to a well-formed Health Claim payment in X12 835 to be sent to our trading partner.

Similarly to the previous step, our transformations will be triggered by a message arriving into a specific MQ Queue,and another Launcher system will be used.

Important: Although we chose Launcher in this scenario for the event-driven engine,you can use other methods, such as WebSphere Message Broker or WebSphere ESB, which both are tightly integrated with WebSphere Transformation Extender.

A portion of the incoming data that will be passed from the back-end system device to the WTX system.

Example - Sample custom flat file format coming from the HIPAA Provider system

This shows part of the expected output that the system will produce after the transformation is completed.

Example - Output X12 835 after the outbound 835 mapping

Note that zzhipaapartner and zzhipaaprovider are the business IDs that we configured before as the Partner profile objects. These business IDs need to be set at the mapping level, at InterchangeSenderID and Interchange Rcv’rID element, as part of the ISAPartner Info group.

Outbound map

The transformation map Outbound835 uses the Partner X12 Inbound Interchange EDI component of the HIPAA_X12_835_837.mtt,a type tree that is included in the WebSphere Transformation Extender pack for HIPAA,which means that we will not have to create a type tree representation for that format. As the output type tree component, the transformation map uses Payment Advice.mtt,which contains a representation of the flat file format sent by the back end.

From a mapping perspective,the most remarkable aspects are that several functional maps need to be created in order to manage the data.This shows the functional map needed to map each transaction separately.

Functional map for mapping Each Transaction

Functional map for mapping Each Transaction

After we have each transaction mapped separately,each claim needs to be treated individually in a new Functional map call as depicted.

Functional map for mapping Each Claim

Functional map for mapping Each Claim

Inside every claim, we need to process each single service line separately,so a new functional map call needs to be done at this level.

Functional map for mapping Each Service Line

Functional map for mapping Each Service Line

Finally,each Service Line requires a specific Claim adjustment to be mapped to the CAS segment from the X12 format. Notice that this call will only be made if the first index of M’amt (Monetary amount field) in the SVC segment is not equal to the SVC segment monetary amount field (M’amt). You can see this call.

Functional map for mapping Each Claim Adjustment

Functional map for mapping Each Claim Adjustment

Outbound system
After creating the map, create the Launcher system using the Integration Flow Designer tool, which comes with WebSphere Transformation Extender V8.2, and create an event-based system that will listen on Q3 from our Queue Manager QM, and put the output transformed file in Q4 from the same Queue Manager.

These are the major settings that you use for the Input Card and Output Card inside Map Settings.From an Input Card perspective,the two most important aspects are the MQ syntax and that Source Event parameter is set to ON. These settings cause the system to be triggered every time that a message arrives on Q3.

This shows a widely used property within Transaction where you can specify what to do with the message in case of success (On Success property) and in the case of failure (On Failure property). This configuration is commonly used. If the message is transformed successfully,it will be deleted from the input queue. The transaction will be rolled back if the transformation fails so that no message is lost.

Input Card map settings for outbound 835 system

Input Card map settings for outbound 835 system

This shows the Output Card where the MQ Syntax is similar except that the queue name is Q4.

Output Card map settings for outbound 835 system

Output Card map settings for outbound 835 system

This depicts the outbound system.

Launcher system created to handle outbound mapping

Launcher system created to handle outbound mapping

The small pair of glasses indicates that it is an event-based system.

After completing those steps, deploy the system in your system and start the Windows Launcher service. Your system will be ready to transform.The scenario is ready to be tested.


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

IBM Websphere Topics