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

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

Chapter 1. Architectural Patterns

BizTalk is a development platform and lends itself to a wide variety of implementation styles. After you've worked with the platform on a number of projects, however, you will find that there are really only a few patterns that meet the critical requirements of a well-developed solution. You will look at the some of the most appropriate architectural patterns for health care implementations, centered on the specific requirements of the Professional Health Care Claim in the 837P 5010 format and the Benefit Enrollment and Maintenance in the 834 5010 format.

The Health Care Claim 837 Format

The 837 format is one of the most complex document types in EDI, and requires careful planning to implement correctly. By working through this document format in detail, you'll be able to quickly move on to other health care document formats without delay, as they will all follow similar patterns. The patterns you will look at include details on:

· Receiving inbound 837P files

o Receiving data via SFTP, FTP, and AS2

o Decrypting inbound data

o Mapping to other 837P versions, proprietary flat file formats, and SQL Server databases

o Returning acknowledgements

o Working with orchestrations

· Sending outbound 837P files

· Mapping from internal flat file formats

· Creating source data from SQL Server

· Encrypting data

· Sending batched and unbatched data

· Working with orchestrations

The Benefit Enrollment and Maintenance 834 Format

The 834 format is not as complex to map (in most cases) as the 837, but it does have a number of architectural requirements that are often required. In some cases, simply receiving the 834 and mapping to inbound data models is all that is required. In other cases, splitting the inbound data, doing business rule validation on it, and providing advanced metrics are required. The patterns you will look at specific to the 834 include details on:

· Receiving inbound 834 files

· Advanced pipeline development for 834 metrics and reporting, and for splitting inbound data

· Custom business rule development in an easy to maintain environment

· Advanced mapping for outbound 834 data

Receiving Inbound Data

Receiving and processing inbound data can take on a variety of flavors, depending on where the data is coming from, whether it is encrypted or not, what is being done with the data once BizTalk has it, and what kind of validation and acknowledgements are required. Some of the most common patterns to consuming this data and processing it are outlined in the following sections.

Receiving Data via SFTP

In many health care related businesses, data is exchanged using SFTP. SFTP ensures data is transferred in an encrypted format that allows for HIPAA compliant communication, yet is a simple to implement transfer protocol. Retrieving data via SFTP in BizTalk is very simple, and can be done through several adapters, none of which ship with the core product itself. Details on implementing two of these - the free bLogical adapter (available on CodePlex) and the new SFTP adapter that ships with BizTalk - are given in Chapter 5, “dapters, AS2 and Acks.” The pattern for receiving the 837P data over SFTP is shown in Figure 1-1. And inbound 834 (and other document types) would follow a similar pattern.

image

Figure 1-1. Receiving 837P data via an SFTP adapter

Receiving PGP Encrypted Data via FTP

When SFTP is not available, standard FTP is used; however, this protocol is not HIPAA compliant and requires the actual data file to be encrypted. FTP is very easy to implement within BizTalk through the use of the standard FTP adapter, but creating processes to decrypt the data is much more labor intensive and requires coding. The most common approach to handling this is through developing a custom pipeline and pipeline component to do the decryption.

Details on building a decryption pipeline that can be used on an FTP Receive Port are given in Chapter 5. The pattern for receiving the 837P data over standard FTP and decrypting the data through a custom pipeline is shown in Figure 1-2. Again, 834 and other document types can be handled in a similar manner.

image

Figure 1-2. Receiving encrypted 837P data via the standard FTP adapter

Receiving Data via AS2

In some cases, data will be exchanged directly between trading partners using AS2. AS2 is a highly secure protocol that allows for various levels of encryption and signing of data. AS2 data is received over HTTP and requires the use of IIS and an HTTP adapter in BizTalk Server. Configuring AS2 is much more involved than is setting up other types of communication protocols, and can lead to fairly lengthy testing cycles with trading partners when used. Chapter 5 details how to implement an inbound AS2 solution. The pattern for receiving EDI data over AS2 is shown in Figure 1-3.

image

Figure 1-3. Receiving data via AS2

Receiving Data that is Mapped to Other Formats

Once data has been received via any protocol, something generally needs to be done with it. In many cases, it is mapped from the original standard into another version of the schema data which can be handled by legacy applications within an IT infrastructure. For example, with the release of version 5010, many companies have to exchange data in the 5010 format, but still have internal applications that deal with the data in the older 4010 version. These applications can directly consume 837P data, but are not 5010 compliant. Therefore, the inbound 837P 5010 format must be downgraded to the 4010 version through BizTalk mapping. Two patterns for receiving the 837P 5010 data and mapping it to the 4010 version is shown in Figure 1-4. One uses a simple Port to Port combination, while the other uses an orchestration to handle the mapping.

image

Figure 1-4. Mapping 837 data from the 5010 to 4010 version

Receiving Data that is Mapped to Proprietary Flat Files

Mapping inbound data from the 837P format (regardless of version) to a proprietary flat file format is also extremely common. One example of this is the ECSIF (Electronic Claims Submission Input Format) format, which is used by a wide variety of claims management systems. Mapping the 837P data to the ECSIF format (or other flat file format) often requires complex manipulations that are best handled with a combination of standard BizTalk mapping as well as XSLT. Chapter 4 “Mapping Data” has information on how to handle this mapping, and how to work with XSLT.

Receiving Data that is Mapped to a SQL Server Database

There are times when the inbound data simply needs to be received and sent directly to a database (or series of databases). There is a huge amount of data available in both the 834 and 837 formats, and writing this data to tables that reflect this structure in SQL server can require writing to dozens (or hundreds) of tables, along with many database lookups. There is really only one appropriate way to handle this kind of complexity within BizTalk, and it consists of a very simple pattern and the use of a stored procedure and XML.

For example, when the 837P data arrives in BizTalk, it is always converted to an XML structure that represents the EDI document. This XML can be passed directly to a SQL Server stored procedure which can tear apart the XML and insert it into the appropriate tables and databases. The pattern for receiving the 837P data and mapping it directly to a SQL Server database is shown in Figure 1-5, with some basic details of doing this for archiving data outlined in Chapter 2 “Solution: Receiving 837P Data.”

image

Figure 1-5. Mapping from an 837P to a SQL Server Database

Receiving Data that Requires an Acknowledgement

Acknowledgements come in several flavors. The 997/999 (Functional Acknowl­edgement) is the most common. The technical acknowledgement is also available, but is rarely used by trading partners. The MDN acknowledgement is specific to AS2. All of these acknowledgements are easily configured in BizTalk Server, and are automatically generated by the system when they are required. In the case of each of these a Send Port with an appropriate filter must be set up and certain fields may need to be configured in the Party and Agreement settings within BizTalk. Chapter 5 has details around working with the various acknowledgements. The pattern for sending acknowledgments for an 837 (834 is virtually the same) from BizTalk is shown in Figure 1-6.

image

Figure 1-6. Sending Acknowledgements

Receiving Data that Requires an Orchestration

In many cases, there is no need for an orchestration in order to handle inbound 837P data - the data simply needs to be received, mapped, and dropped in an appropriate format for another subscribing system. In many other cases, it is not enough to map and deliver - actual workflow steps must take place in order to handle the data appropriately. In cases where workflow is required, an orchestration must be developed. Examples of implementing orchestrations for common requirements are shown in Chapter 2.

Receiving Data that Requires Custom Pipeline Development

There are frequently business requirements defined that require creative use of the various BizTalk components. One example of this is the 834 - with the way data is grouped, along plans, divisions, subscribers, and dependents, it is often a requirement to split the inbound data and to also perform counts and other metrics on the data (for reporting). This kind of work is often most easily done in the pipelines when the data is first received (and before anything arrives on the message box or instantiation of any orchestrations). Chapter 7 “Pipelines for 834 Processing” covers in detail how to set up a custom pipeline and pipeline component to split the data and to write metrics to the database. Figure 1-7 shows the flow of this data.

image

Figure 1-7. Splitting and Processing Data in a Pipeline

Receiving Data that Uses Custom Business Rules

Many organizations require that data validation occur prior to the acceptance of inbound data. The standard EDI schema validation and related 999 still occur, but additional custom validation of the data itself is required after this initial validation has passed. One important pattern related to this is the comparison of the inbound 834 data with existing historical data that is housed within an existing database. For example, if the requirement was to check and see if the first name, last name, or SSN has changed on an inbound subscriber or related dependents, then the inbound 834 data would need to be compared against the existing data. A detailed discussion about how this can be done using XML and a stored procedure is given in Chapter 8 “Custom Business Rules,” while Figure 1-8 gives a conceptual overview. In this diagram, the historical data is pulled from Oracle in XML format, and then both this historical XML and the EDI 834 XML are passed as input parameters to a SQL Server stored procedure. The stored procedure does cross comparisons on the data, and inserts the results into tables for reporting, analysis, and further processing.

image

Figure 1-8. Splitting and Processing Data in a Pipeline

Sending Outbound 837P Files

We’ve looked at a variety of inbound patterns - now let's look at some outbound patterns. Sending data includes determining where the source data will come from, how this data will be mapped into the various EDI formats, whether this data will be batched or not, and how the data will ultimately be delivered. We'll look at a number of outbound patterns that will allow you to develop your outbound 834 and 837 solutions.

Sending Data Mapped from an Internal Flat File Format

Internal data is often stored by claims management systems, and this data can be readily exported in a variety of formats. In some cases, these systems can export fully compliant EDI documents. In other cases, these systems can export only proprietary representations of the claim data. In either case, this data generally must be mapped to the exact format and standard required by a trading partner. Some trading partners have very lax standards, while others have extremely rigid requirements.

image Note There are seven levels of HIPAA EDI Compliance. BizTalk handles level one and two.

In general, all trading partners have their own unique map from whatever internal format you have within your environment to their specific format. Even trading partners that have virtually identical EDI format requirements should have a separate map within BizTalk. The pattern for outbound maps based on an internal flat file format is shown in Figure 1-9.

image

Figure 1-9. Mapping Outbound 837P Data from an Internal Flat File

Sending Data Mapped directly from SQL Server

Often, you can map your internal representation of data directly to a port (in XML) and map it to the target EDI standard without the use of an orchestration or other intermediary components.

For example, when claims data is available in SQL Server databases and tables, there is a fairly straightforward pattern that can be built which will allow this data to be structured for ease of mapping to 837P by a SQL stored procedure. This data can be retrieved from the stored procedure by BizTalk, mapped to the 837P format, and delivered.

The maps can often be extremely simple when using this pattern, as all of the data can be preprocessed and delivered to BizTalk by the stored procedure in the format required by the targeted trading partner. Instead of having logic in functoids and within the map, this logic can reside in SQL, and the maps can remain as simple as possible. Examples of building a stored procedure and mapping the contents to an outbound 837P are shown in Chapter 3 “Solution: Sending 837P Data.” The pattern for handling this type of scenario is shown in Figure 1-10.

image

Figure 1-10. Mapping Outbound Data from SQL Server

Sending Unencrypted Data via SFTP

SFTP is a secure file transfer protocol, and files sent over SFTP can be unencrypted and still be HIPAA compliant. Sending files via SFTP requires a third party adapter, as BizTalk does not ship with an SFTP adapter. Chapter 5 gives details on how to work with one of the available SFTP adapters. The pattern for sending unencrypted 837P data via SFTP is shown in Figure 1-11.

image

Figure 1-11. Sending Data via SFTP

Sending Encrypted Data via FTP

Data sent over the standard FTP protocol - which is very common within the health care world - must be encrypted for it to be HIPAA compliant. Encrypting data requires the use of a custom pipeline and custom pipeline component, which can be added directly to an FTP Send Port using the FTP adapter that ships with BizTalk. You can look at the discussions in Chapter 5 for more information on how to build out custom pipelines and pipeline components for encryption and decryption. The pattern for sending encrypted data via FTP is shown in Figure 1-12.

image

Figure 1-12. Sending Encrypted Data via Standard FTP

Sending Outbound Data Based on Inbound Data

A complex requirement that many companies face with the 834 is the need to base the outbound data mapping on what was originally contained on the inbound 834 data. This involves pulling current data from the internal data stores that represent the enrollment/effectuation data, along with pulling historical data related to the specific record from the original 834. The complexities associated with this can be managed through some smart mapping and extraction of data, and Chapter 9 “Advanced 834 Mapping” is dedicated to dealing with this specific concept. While it is a complex problem, the resulting component architecture can be relatively simple - most of the work can be done within a map, and there is no absolute requirement for an orchestration to complete this scenario.

image

Figure 1-13. Sending Outbound Data Based on Inbound Data and Internal Data

Sending Batched Data

There are a number of options around batching data, the two most common examples for 837P being multiple claim records per ST/SE and single claim records per ST/SE. Trading partners will dictate their requirements around batching, including maximum number of claims in a file, maximum number of claims in a batch, maximum number of batches in a file, and so on. Dealing with these can often require major shifts in the way you build the same processes for different partners. For example, sending single claims per ST/SE will require a different set of maps and other components than will sending multiple claims per ST/SE. A detailed analysis and examples for implementing batching have been outlined in Chapter 3. While the examples in Chapter 3 are specific to the 837, the concepts all apply directly to the 834 and other data types.

Conclusion

There are a wide variety of patterns to dealing with EDI data. This chapter has outlined some of the most common or most useful, and has pointed to where in this book you'll be able to find more detail. In addition to the specifics around how to receive and send data via various protocols, how to encrypt and decrypt files, how to batch data and how to include orchestrations, you'll also need to know how to configure trading partners as BizTalk parties, and how to set up the core EDI functionality within BizTalk. In the next two chapters you will look at specific implementations of receiving and sending 837P data, both of which touch on many components of the various architectures just outlined. Chapter 6 outlines similar components specific to an inbound 834.