BizTalk 2013 EDI for Health Care: HIPAA-Compliant 834 (Enrollment) and 837 (Claims) Solutions (2014)

Chapter 6. Solution: Receiving 834 Data

The actual receipt and delivery of files is central to any solution. Common approaches to receiving and sending data within the EDI space include SFTP, encrypted data over standard FTP, and secure communications over AS2. BizTalk 2013 finally introduces native SFTP support. Historically, SFTP has been handled through third-party adapters. Dealing with encrypting and decrypting data on standard ports requires custom pipeline component code. Configuring AS2 for direct party-to-party communication requires certificates and complex configurations within BizTalk. This chapter will detail the setup and configuration for each of these methods, as well as how to successfully deliver various forms of EDI acknowledgements.

SFTP

SFTP is a common option used in the exchange of data, since it ensures that the data is secure throughout the posting, storing, and retrieving stages. SFTP allows documents to be sent and received in plain text, as the protocol itself encrypts the information (with standard FTP, encrypting the file must be done through a custom pipeline component).

There are several options for sending and receiving data via SFTP in BizTalk Server. The first is the new SFTP native adapter that ships with BizTalk 2013. The second is the third-party bLogical BizTalk SFTP adapter (Blogical.Shared.Adapters.SFTP) available from CodePlex. Both of these adapters are covered here, as you may find that in some cases you may have connectivity challenges with certain SFTP servers. You will also find more robust scheduling options with the Blogical SFTP adapter.

Configuring the Native SFTP Adapter

With BizTalk 2013, the native support of SFTP is finally available. Prior to this release, only third-party (or custom) adapters could be used, but now you can set up SFTP communication as easily as standard FTP (which has been available natively since the beginning of BizTalk).

The available configurable properties on the adapter are different for inbound (receive) and outbound (send). The properties listed below come from both, and are intended to highlight the most important. Figure 5-1 shows the receive adapter properties.

Note Before you configure your SFTP adapter, make sure to test connectivity to the target SFTP site through a standard SFTP compatible FTP utility (one excellent option is FileZilla, which has support for a wide array of FTP and SFTP connection types). There are a number of things that may require attention before you will be able to connect successfully, and it is much easier to troubleshoot using a client utility than it is through the adapter.

Figure 5-1. The Receive Adapter Properties

ConnectionLimit

This field sets the number of concurrent connections to the target server. By default, this is 5. If you know that the possibility exists that you could have many concurrent connections to a single SFTP server, you will need to experiment with load testing and determine how you want to configure this field. It may be best to set this to 0 (no restrictions) and let the SFTP Server manage how many connections it will allow (if it gets too many, it will throw an error back to BizTalk, and BizTalk can handle a retry of the data later).

PollingInterval and Unit

These fields are what you have available for setting a polling schedule. You can identify the polling interval. For example, if you want to check for files on the server every five minutes, you would set this the PollingInterval to 5 and the Unit to Minutes. This is pretty limited functionality, and if you need anything more robust, you will want to use the Blogical CodePlex adapter, covered later in this chapter.

AcceptAnySSHServerHostKey

This ensures that regardless of the key on the server, you will be able to make a connection. Because SFTP uses SSH, all communications require a key.

Password

Set this to the password used for connecting to the SFTP server.

FolderPath

If you are receiving data from a subdirectory of the SFTP site, you'll need to set the full path in this directory. Make sure to add a forward slash (/) before any path you enter in this property. The path is based off of the root server - so if your full path is 192.168.0.1/ChildOne/ChildTwo, you should enter /ChildOne/ChildTwo in this property, and enter 182.168.0.1 in the FolderPath property.

TargetFileName Property

The file name can be set using whatever combination of plain text and BizTalk macros that you may need. Some of the most common macros are shown in Table 5-1. Macros can be combined. If, for example, you want to show the source file name and combine it with the current datetime, you could put a value of %SourceFileName%_%datetime% in the SSH Remote File Name property.

Table 5-1. Common BizTalk Macros

There are more macros than are shown in this table, but there are some fairly severe limitations around what you can name files. If you find that the available BizTalk macros are not flexible enough to meet your requirements, you will have to develop a custom pipeline and pipeline component to create your filename. This pipeline can be added directly to the Send Pipeline on the SFTP Send Port.

UserName

Set this to the username used for connecting to the SFTP server.

Configuring the Blogical CodePlex SFTP Adapter

This adapter is available free of charge and is very reliable. It can be downloaded, compiled, and made available within BizTalk Server within a few minutes. It has been available for a number of years, and has some capabilities (like expanded scheduling) that make it more versatile than the new native SFTP adapter.

Note The SFTP adapter will automatically download the original host certificate from the party you are interacting with. However, if this certificate expires (which is common), the SFTP adapter won't automatically be able to download the new certificate. If you get an exception in the Windows Event Log that says “HostKey does not match previously retrieved HostKey” you will need to browse to the sftphostfiles.config file and delete the HostKey setting. The directory where this file is located will be in the Local Settings of the host user that the SFTP adapter runs under. For example, if your BizTalk Host instance runs under DOMAIN\Host_User_Account, then you will browse to Host_User_Account\Local Settings. The config file will be buried under a unique directory several levels below, so you will likely need to run a search for it once you have located this directory.

Once the adapter has been installed, setting it up to receive and send data can be done by creating a new receive location or send port and setting the Type property to SFTP (or whatever you named it during the installation). You can then click Configure. You will want to configure the SFTP adapter with the key fields shown in this section. In some cases, you will need to configure additional fields beyond what is shown here, but in most cases these are all that is required.

Some of the properties listed (such as the Schedule) are unique to the receiving of data. As you configure your SFTP send port or receive location, you'll be able to easily identify which properties apply.

Schedule Property

This setting has some robust functionality for determining the schedule that the source SFTP site will be queried. Clicking the ellipses on this property pops up an interface that allows for scheduling on Daily, Weekly, Monthly, or “Timely” intervals. You will most likely use the timely interval - every x number of minutes, for example. In Figure 5-2, you will see the property set to poll the source SFTP site every five minutes. In most cases, you'll be pulling your EDI data on regular intervals throughout the day, but you'll need to coordinate with your trading partner to determine if there are any scheduling windows that should be avoided.

Figure 5-2. Setting the Schedule Property for “Timely” polling interval

After Get Property

This property defaults to Delete, which ensures that the file being retrieved is removed from the source SFTP site as soon as it has been successfully received by BizTalk. If there is an error in transmission, the file will remain on the server. In most cases, you will want to leave this set to Delete, but some trading partners provide archiving of data after a certain period of time, so you may want to leave the file on the server to take advantage of this. If this is not set to Delete, you will need to make sure your polling interval set in the Schedule property does not cause this same file to be retrieved multiple times before it is auto archived by the trading partner.

SSH Error Threshold Property

The SSH Error Threshold property can be used to control how many errors can be encountered before the adapter shuts down. It is fairly common to have connectivity issues with SFTP sites, and it would make sense to increase this error threshold to a sizeable amount to account for this. If left at a low number, the adapter may shut down if the source site cannot be reached over a certain period of time.

Note If the SFTP adapter encounters errors, the exceptions will be logged to the Windows Event Viewer. Make sure and monitor the state of your SFTP ports, as they will automatically shut down if the error thresholds are exceeded.

SSH Host Property

This property should be set with the actual SFTP server host address. This could be an IP or a named server. It should only contain the root server name, not any subfolders. It should also not contain sftp://. An example of this property set to an IP would be 192.168.0.1.

SSH Port Property

The default port for SFTP servers is 22. If you are interacting with an SFTP server that has a different value, you will need to set the appropriate port value here.

SSH Password Property

Set this to the password used for connecting to the SFTP server.

SSH Remote Path Property

See the discussion on the FolderPath property in the section on the native SFTP adapter earlier in this chapter.

SSH Remote File Name Property

See the discussion on the TargetFileName property in the section on the native SFTP adapter earlier in this chapter.

SSH User Property

Set this to the username used for connecting to the SFTP server.

Trace Property

If you are running into exceptions when the SFTP adapter runs, you may want to set this property to True in order to log detailed information about what is happening.

Encrypted Data with Standard FTP

Using the Standard FTP adapter to send and receive data with BizTalk is a breeze - but having to deal with encrypting and decrypting data is not. This section will outline the standard properties used to configure an FTP adapter for sending or receiving data. Additionally, it will discuss some of the challenges around custom pipeline and pipeline component development, and show how to set up a custom pipeline on a Send Port and a Receive Location.

Note All data sent/received using either of the SFTP adapters is automatically encrypted.

FTP Adapter Settings

If you are sending data over FTP, you can create a Send Port in BizTalk and set the Type to FTP. If you are receiving data over FTP, you can create a BizTalk Receive Location and set the Type to FTP. In either case, you will need to set the following key properties:

· User Name - the user with which you connect to the FTP site

· Password - the password used for connections.

· Server - the FTP server. This should contain the IP or named server being connected to, and should not have the ftp:// prefix on it.

· Port - the specific port required for FTP connections

· Folder - the remote folder that you are posting data to. It should not have a leading forward slash (/) on it.

· Representation - binary or ASCII. In general, this should be set to binary, but some FTP servers don't handle binary data, so you may have to experiment with settings here.

With the FTP adapter settings configured properly, you need only to focus on the requirements of the send pipeline.

Pipelines and Pipeline Components

One of the most complex tasks in BizTalk is creating custom pipelines, as it is pure C# development. If you are using PGP for encryption and decryption, some pointers on how to develop this custom pipeline component are outlined in this section. If you need to use an alternative encryption format, then you'll need to code something specific to the tools that are used for that format. In either case, you'll need someone who is familiar with C# development to be available to work on this.

There are two items that must be set up for both the send pipeline that will encrypt data and the receive pipeline that will decrypt data. These items are the custom pipeline and the custom pipeline component. The custom pipeline component should be developed first. Let's assume that you are going to be dealing with PGP encrypted data. There are several tools that you could use - one of the easiest to interact with is GNU Privacy Guard (www.gnupg.org). This utility allows for the generation and management of PGP keys, and provides a command line interface that can be communicated with via C# .NET code.

Calling the command line tool requires that you build out a .NET class to wrap the call so that the pipeline can pass parameters to the command line and execute it (using System.Diagnostics.ProcessStartInfo is one option to do this). Assuming you have built a wrapper class for the GNU Privacy Guard command line tool (generally located in the GNU/GnuPG/pub directory), then a sample of calling this command line tool from within a custom pipeline component to encode data is shown in Listing 5-1, while a sample of decoding data is shown in Listing 5-2.

Listing 5-1. Calling a Class to Encode Data with Parameters

GnuPGWrapper GPG = new GnuPGWrapper(_gnupgbindir);
GnuPGCommand GPGCommand = GPG.Command;
GPGCommand.Command = Commands.Encrypt;
GPGCommand.Recipient = _recipient;
// this is the recipient on the PGP key
GPGCommand.Passphrase = _passphrase ;
// this is the passphrase on the PGP key
GPGCommand.Armor = true;
GPGCommand.InputFile = inFile;
GPGCommand.OutputFile = outFile;

Listing 5-2. Calling a Class to Decode Data with Parameters

GnuPGWrapper GPG = new GnuPGWrapper(_gnupgbindir);
GnuPGCommand GPGCommand = GPG.Command;
GPGCommand.Command = Commands.Decrypt;
GPGCommand.InputFile = inFile;
GPGCommand.OutputFile = outFile;
GPGCommand.Passphrase = _passphrase;
// this is the passphrase of the PGP key

Creating the custom pipeline component will take some effort, and will depend on the encryption and decryption requirements of your solution. You will want to make a number of the fields configurable, so that you can use the send and receive pipelines on multiple trading partners. Figure 5-3 shows what these configurable properties could look like when they are set within the custom pipeline in Visual Studio.

Figure 5-3. Configurable Parameters on the Send Pipeline Component

The actual custom pipeline where you would be adding the custom pipeline components has to also be created. This is done within Visual Studio as a new BizTalk Pipeline project. An example of a send pipeline and what stage the custom pipeline component to encrypt should be added is shown in Figure 5-4. An example of a receive pipeline and the custom pipeline to decrypt is shown in Figure 5-5.

Figure 5-4. The Send Pipeline with Encrypt Component

Figure 5-5. The Receive Pipeline with Decrypt Component

After you have created your pipelines and deployed them, they will be available to the Send Port and Receive Location where you have configured your FTP adapter. An example of a Receive Location with the decryption pipeline configured on it is shown in Figure 5-6.

Figure 5-6. Configuring the pipeline on an FTP Send Port

AS2 Communications

Configuring BizTalk for AS2 communications can be a time consuming and difficult task. The most complex aspect of it is dealing with certificates. Both you and your trading partner are required to exchange certificates and configure communications with one another with the same settings. Should your data be encrypted? Should your MDN be signed? Do you have the correct certificate for the development environment vs. the production environment? Is your trading partner sending data in the expected format? The purpose of this section is to provide you with enough detail around configuring and testing AS2 so that you can avoid most of the pitfalls associated with setting this up.

Certificates

The first thing you will want to do is get your certificates set up. You'll begin by exchanging public keys with your trading partner. You should have a public and private key for your organization and a public key from the trading partner. Once you have these, you can take the following steps to set up the certificates on the BizTalk server.

CERTIFICATE CONFIGURATION FOR AS2

This exercise will demonstrate where to place and how to reference the certificates required in AS2 communications with BizTalk.

1. Log into the BizTalk server using a BizTalk service account.

2. Open the Certificate manager. From the Start Menu, click Run and type mmc. Once this is open, click File and select Add/Remove Snap-in. Select Certificates and click Add. Select the My user account option and click Finish. Select Certificates again and click Add - this time, select the Computer account option and click Next. Select the Local Computer option and click Finish. You should now have two Certificate types, as shown in Figure 5-7. Once this is complete, click OK.

Figure 5-7. Configuring the Certificate Snap-In

3. With the Certificate console open, expand Certificates - Current User, and right click Personal. Select Import and import the private key (.pfx) for your home organization.

4. Next, expand Certificates - Local Computer, and right click Other People. Select Import and import the public key (.cer) for your trading partner's organization.

You should now see your certificates in several locations - the Personal and Other People folders of both the Local Computer and Current User. With these certificates installed, you will now be able to reference them from the appropriate locations in BizTalk.

5. In the BizTalk Administration Console, right click the BizTalk Group and select properties. Click on the Certificate option and select Browse. Your home organization's certificate should appear - select it and click OK. Figure 5-8 shows the certificate set at this level. This will be your primary certificate used to sign outbound data.

Figure 5-8. Configuring the Certificate at the Group Level

Note You can override this default certificate for specific parties, if needed, in the Certificate page of the AS2 properties for your trading partner. In most cases, you'll use a single certificate for everyone, but there may be times when you'll need to use a unique certificate for signing.

6. Right click your trading partner’s BizTalk party in the BizTalk Admin Console’s Parties folder and select properties. Click the Certificate option and click Browse. Select the trading partner’s certificate.

There are only two other locations that you may need to configure certificates for your AS2 communications with a single trading partner - on the “Signature Certificate” page of the AS2 agreement (which allows for overriding the default home organization certificate on outbound documents and MDNs) and on any Send Ports that you may be using. However, it is unlikely that you will need to do anything with either of these, if you are engaging in standard AS2 communications.

IIS and the BizTalk HTTP Receive Location

AS2 is communication over HTTP - so setting up a site within IIS on the BizTalk Server is a requirement. There are a number of ways this can be set up, but the most common is to create a virtual directory for a specific trading partner that maps inbound requests to the BTSHTTPReceive.dll (which then pushes the inbound data to BizTalk for processing). This is a fairly involved yet easy configuration, and the following exercise outlines how to set up the various components.

Note In some cases, your organization may not allow companies outside your network to post data directly via HTTP to BizTalk. In this case, you’ll have to set up a proxy server to allow traffic to flow through your DMZ and hit the HTTP location in BizTalk. This is a separate area of expertise from BizTalk, and should be handled by a network administrator.

CONFIGURING IIS AND THE HTTP RECEIVE LOCATION

This exercise will demonstrate how to create and configure the appropriate IIS components to handle inbound AS2 posts. It will also show how to set up the BizTalk Receive Location that receives these posts.

1. Log into the BizTalk server using a BizTalk service account.

2. Open the IIS 7 manager, click on the root server, and select the Handler Mappings option. In the Actions area on the right-hand side of the screen, click Add Script Map. Set the Request path property to BtsHttpReceive.dll and set the Executable to the location of the BtsHttpReceive.dll (this is located in the HttpReceive folder in the root BizTalk Server directory). Set the Name field to BizTalk HTTP Receive and then click the Request Restrictions button. In the Request Restrictions box, on the Access tab, select Script and click OK.

Click OK on the Add Script Map window when this has all been completed. Right click the BizTalk HTTP Receive item that was just created and select Edit Feature Permissions. In the window that opens, select the Read, Script, and Execute boxes and click OK.

See Figure 5-9 for a view of the final configuration.

Figure 5-9. Configuring the HTTP Receive Handler Map in IIS

3. Back on the root server in IIS, click the ISAPI and CGI Restrictions icon. In the window that opens, set the BTSHTTPReceive Restriction setting to Allowed, as shown in Figure 5-10.

Figure 5-10. Configuring the HTTP Receive Handler Map in IIS

4. Create a new Application Pool in IIS, and set the name to BizTalkAppPool (or similar). Set the .NET Framework version property to 4.0 (whichever specific version is available to you) and the Managed Pipeline mode to Integrated.

5. Create a new virtual directory (as an Application) under the Default Web Site. The name of this site should be specific to the trading partner that you will be receiving data from over HTTP - so in this case, name it TradingPartner. Set the Application Pool to the app pool you created in the previous step and select Test Connection to ensure you are able to connect.

Note Depending on your security setting, you may find that you also need to set the Physical Path Credentials to a specific account that has access to that directory. The easiest way to access this is to right click the web Application you created and select Manage Application and then Advanced Settings.

6. Click on the virtual directory you just created and select the Authentication icon. In Authentication window that opens, set Anonymous Authentication to Enabled.

This completes the setup of all IIS related components for AS2. If additional trading partners need to be set up, create one additional virtual directory for each one.

Agreements and Party Settings

In order to specify how to handle the AS2 data and how to work with the underlying EDI document that is being sent via AS2, you will need to set up a BizTalk Party and two Agreements. One Agreement is for the AS2 messaging, and one Agreement is for dealing with the actual EDI data. The basic steps for setup are as follows for receiving AS2 data from a trading partner (sending data to a trading partner is very similar):

· Create a new BizTalk Party with the name of the trading partner you will be receiving data from.

· If you will be sending a 997/999 to the trading partner, specify the Send Port that the 997/999 will be sent out on.

· Create a new Agreement on this Party that will handle AS2 messaging (you can call it something like Agreement_AS2).

o On the General Tab, set the Protocol property to AS2, the First Party to the trading partner and the Second Party to your home organization. Once you’ve set the General Tab this way, two additional tabs will appear, one for inbound data from the trading partner, and one for outbound data to the trading partner. If you are just receiving data from the trading partner and returning an MDN, you only need to configure the inbound trading partner tab.

o On the inbound trading partner tab, on the Identifiers tab, set the AS2-From and AS2-To properties to the appropriate values as defined in your trading partner agreement. These must match what is on the AS2 envelope being sent to you. Figure 5-11 shows an example of these settings.

Figure 5-11. The Identifiers tab in the AS2 Agreement

o On the Validation tab for the AS2 Agreement, you can set the appropriate values for validation of the data. For example, if you are receiving a signed and encrypted inbound post from a trading partner, then you would set the properties as shown in Figure 5-12.

Figure 5-12. The Validation tab in the AS2 Agreement

o On the Acknowledgement tab of the AS2 Agreement, you can set the properties that pertain to the MDN response back to the trading partner. If you need to send an unsigned MDN, you can use the properties as shown in Figure 5-13. If you are sending a signed MDN, then the certificate specific in the Signature Certificate settings will be used (or, if none is specified, then the default certificate associated with the BizTalk Group will be used).

Figure 5-13. The Acknowledgement tab in the AS2 Agreement

o There are some additional properties that will likely need to be set or adjusted on the other tabs. A few of the most common are noted here.

· On the Receive MDN Settings tab, enable the Sign requested MDN setting if you want to always send an MDN, regardless of what is noted on the inbound AS2 request from the trading partner.

· In the HTTP Settings for Messages, enable everything except for the Ignore SSL Certificate Name mismatch property.

· In the HTTP Settings for MDN, enable everything except for the Unfold HTTP headers property.

· On the Signature Certificate tab, set the certificate that you want to use for signing the outbound MDN. If nothing is selected here, the default certificate for the BizTalk Group will be used.

· Create a new Agreement for the EDI data that will be consumed. Setting this up will depend on the specifics of the EDI document type(s) that are being received over AS2 (you can see details of configuring Agreement settings in Chapters 2 and 3). What is important to know here is that you must have this additional Agreement in place so that BizTalk knows how to process the EDI data once the AS2 Agreement has successfully completed the data transfer.

The Generic MDN Send Port for Asynchronous Messages

The MDN is the acknowledgement for AS2 posts. There are two possible methods for postback of an MDN - synchronous and asynchronous. The synchronous response is posted back via the same open HTTP connection that the original document came in on, and does not require any additional BizTalk components (simply set the Request MDN checkbox in the BizTalk Agreement, and it will automatically post back). For asynchronous MDNs, a send port must be created. You can create a generic send port that will work for all parties by taking the following steps:

· Create a new Dynamic One-way Send Port and name it something like SendAsyncronousMDNs

· Set the Filter on the Send Port to EdiIntAS.IsAS2AsynchronousMdn == True

· Set the Send pipeline to AS2Send

· In the BizTalk Agreement for AS2, select the Request asynchronous MDN property and set the Receipt-Delivery-Option (URL) property to the URL on which the trading partner is expecting data to be delivered.

When the configuration is set like this, the moment a document is received from a trading partner, BizTalk will automatically create an MDN and drop it on the BizTalk Message Box. The SendAsynchronousMDNs send port will subscribe to this document and send it out to the URL specified in the Receipt-Deliver-Option (URL) property on whatever trading partner’s Agreement was just used to receive the data.

Testing your AS2 Configuration

One of the most challenging (and frustrating) aspects of AS2 configuration is the actual trading partner testing. The best advice is to plan to set up your AS2 configuration in stages. Try to exchange plain text data (unencrypted and unsigned) first before dealing with the various settings requiring certificates. If you can get the plain, un-encoded data to flow (and the MDN to return) successfully, then you can move into testing encryption and signing.

There are many things that can go wrong during testing, and the error messages are often very generic and cryptic. The errors could be on your side, or they could be on the trading partner’s side. The more you can do to limit what is being tested at any given stage, the quicker you will be able to get to resolution and completion.

Sending 997/999 Acknowledgements

There are several types of acknowledgements that can be sent in response to EDI communications - Functional (997/999), Technical (TA), and MDNs (for AS2). Configuring and sending MDN acknowledgements was covered earlier in the AS2 section in this chapter. Technical Acknowledgements are rarely required, and are identical in setup to the Functional. You will now look at sending the Functional acknowledgements for the EDI data itself. The steps to take are as follows:

· Open the BizTalk Party Agreement that relates to the documents and trading partner that you need to set up the Functional Acknowledgement for, click on the Acknowledgements tab. You will be able to set a checkbox next to 997 Expected, as shown in Figure 5-14.

Figure 5-14. The Acknowledgement tab in the EDI Agreement

· Set up one Send Port per trading partner. These send ports will subscribe directly to the BizTalk Message Box, and will filter on the specific trading partner required. The Send Port should have the following settings:

o The transport type - FTP, SFTP, or other. Set the appropriate connection information for the actual adapter that will be used to connect to the trading partner.

o The Send Pipeline should be set to EdiSend - or, if you are required to encrypt 997 data (which is uncommon), you will need to add your custom send pipeline to do the encryption.

o Three filters, as follows:

· EDI.IsSystemGeneratedAck == true

· EDI.ST01 == 997 (or 999 if version 5010)

· EDI.ISA06 == [this should be the specific trading partner’s ID that you are configuring for this specific Send Port - this ID can be retrieved from the Party settings of the BizTalk Agreement where you have configured 997s to be sent]

· Depending on your configuration, you may need to associated the 997/999 Send Port with your Agreement on the Send Ports tab.

Once you have these settings configured, BizTalk will automatically generate a 997/999 when the inbound EDI document is received and drop it on the BizTalk Message Box. Next, the Send Port will pick it up and deliver it to the specified destination.

Conclusion

This chapter has gone in depth on the most common transport mechanisms for any BizTalk EDI health care implementation you may need to build out. It has also shown how to deal with acknowledgements - 997/999s and MDNs. With the information related to AS2, SFTP, and encrypted data over FTP that has been covered, you'll be able to successfully develop and interact with trading partners.