Using the BizTalk Accelerator for HIPAA

The BizTalk Accelerator for HIPAA is designed to provide support for the X12N HIPAA EDI document transactions used within the healthcare industry and covered under the HIPAA regulations. Real-world implementations have a high degree of variability around the specific details of mapping the X12N HIPAA transaction data sets to legacy system data, but they all tend to build around fundamental architectural designs reflecting the nature of core healthcare insurance business processes.

Solution Architecture

Four example architectures are presented in this section, demonstrating how the Microsoft BizTalk Accelerator for HIPAA can be deployed to build real-world solutions.

Enrollment Scenario

To support a typical sponsor-based enrollment scenario, Microsoft BizTalk Accelerator for HIPAA can be deployed as shown in Figure 24.12.

In this scenario, demographics and benefits information is exported from the sponsor HR benefits system using a flat file format, transported to the payer, and then transformed using the BizTalk Accelerator for HIPAA to an 834 Enrollment transaction. The 834 EDI document is then submitted to the Membership system located at the payer to provide the update to the membership list.

The solution described in this scenario is not required at the present for all employers under the current HIPAA regulations because employers acting as sponsors are not classified as “covered entities.” However, the solution can offer clear benefits for employers and payers by reducing the costs of benefits administration and by providing an easy way to convert the many different formats for data to be transferred from sponsors into a single format for entry into the core membership systems.

Eligibility Scenario

To verify eligibility, the Microsoft BizTalk Accelerator for HIPAA can be deployed as shown in Figure 24.13 at a provider organization to allow a practice management system to perform eligibility inquiries directly to a payer system.

In this eligibility scenario, a practice management system located at a large clinic is configured to send eligibility requests and receive eligibility information via an XML data structure. Using the BizTalk Accelerator for HIPAA, these XML transactions can be converted into EDI 270 requests and submitted to the payer system. The EDI 271 response can then be converted back into XML and loaded into the practice management system.

Authorization Scenario

To implement an authorization scenario, the Microsoft BizTalk Accelerator for HIPAA can be deployed at a payer site in the configuration shown in Figure 24.14.

In this authorization scenario, a payer wants to add support for online authorization of referrals for physician practices that have practice management systems that support the 278 EDI transaction. The BizTalk Accelerator for HIPAA can be deployed at the health plan to provide the needed 278 transaction support integrating to the legacy benefits system using exchange of flat files.

Claims Scenario

A claims scenario might deploy two Microsoft BizTalk Accelerators for HIPAA as shown in Figure 24.15.

In this claims processing scenario, the practice management system and the claims system both use the Microsoft BizTalk Accelerator for HIPAA to provide support for HIPAA EDI using the 837 transaction to submit claims and the 835 transaction to return the remittance advice.

Installation

The minimum hardware and software requirements for installation of the Microsoft BizTalk Accelerator for HIPAA are similar to those for Microsoft BizTalk Server 2002 and are listed as follows:

Hardware (minimum)

• 300 MHz Pentium III or better

• 128 MB RAM (256 MB recommended)

• 6 GB hard drive

• CD-ROM drive

• SVGA or VGA monitor

• Mouse or pointing device

Software

• Microsoft Windows 2000 Server or Advanced Server with Service Pack 2

• Microsoft BizTalk Server 2000, any version, with BizTalk Server 2000 Service Pack 1a, or Microsoft BizTalk Server 2002, any version, with the BizTalk Accelerator for HIPAA Service Pack 1

• Microsoft SQL Server 7.0 with Service Pack 3, or Microsoft SQL Server 2000 with Service Pack 2

For development machines running Microsoft SQL Server 7.0 or SQL Server 2000 and Visual Studio 6.0, it is helpful to increase the RAM to at least 256 MB. To use the Orchestration Designer, Visio 2000 SR1, or Visio 2002 must be also be installed.

If you are running on BizTalk Server 2000, you must be sure to run the SQL database update scripts after installing BizTalk Server 2000 SP1a. These scripts should be applied to SQL 7.0-based installations as well as SQL 2000-based installations of BizTalk Server. The two scripts to run are

• ControlNumbers.sql

• CleanQueuesPatch.sql

These may both be found in the Program FilesMicrosoft BizTalk ServerSetup folder. Run the ControlNumbers.sql script against the BizTalk Messaging Management database and run the CleanQueuesPatch.sql script against the BizTalk Shared Queue database. Follow the detailed installation instructions in the Readme file for BizTalk Server 2000 SP1A to ensure that the SQL database updates are performed correctly when using BizTalk Server 2000.

If you are installing the BizTalk Accelerator for HIPAA 1.0 on BizTalk Server 2002, then you do not need to install BizTalk Server 2000 SP1A or run the two SQL scripts. You must instead apply the BizTalk Accelerator for HIPAA SP1 to ensure proper operation.

Working with the 837 Institutional Claim Transaction

In this section, you will use the BizTalk Editor, BizTalk Messaging Manager, BizTalk Server Administrator, and a sample 837 Institutional Claim to explore the features of the Accelerator for HIPAA.

X12 EDI Review

The X12 EDI standards are developed by the consensus activity of voluntary industry participants using a standardized process to be generic and cross-industry. The X12N standards are a subset of the generic X12 standards and represent the insurance industry specific requirements. The ANSI ASC X12N HIPAA Implementation Guides specify these requirements in precise detail.

It is therefore important to have a solid understanding of X12 EDI messaging before attempting to use the Microsoft BizTalk Accelerator for HIPAA. This section contains a brief survey of the basic X12 concepts and terminology necessary to understand the features and operation of the product.

X12 Data Types

Data types defined by X12 are listed in Table 24.6 along with a brief description of notation and some examples of use.

X12 Delimiters

Three levels of delimiters are used within X12N to separate individual data elements and to build the structure of the EDI document. These delimiters are as follows:

• Data segment

• Data element

• Component

The smallest unit for data defined within X12 is the data element. Some data elements in X12N may be composed of smaller related fields called components. Data segments are composed of one or more data elements that group together elements with related meaning. Keep in mind that the use of the term element within X12 is not the same as the use of the same term within XML. The HIPAA Transaction Implementation Guides do not require that implementations use a specific set of delimiters. In general, delimiter sets are negotiated within individual trading partner agreements. The list of potential delimiters available may be found in the appendix of the HIPAA Implementation Guides. The BizTalk Accelerator for HIPAA offers a choice of any arbitrary set of valid X12 delimiters. In the sample data that ships with the product that is used in the hands-on exercises in this chapter, the delimiter set is listed in Table 24.7. Using the carriage return as the segment delimiter has the advantage of displaying one segment per line when viewing an EDI file within Notepad or a standard text editor.

See the ANSI ASC X12N HIPAA Implementation Guides for more detailed information on how the delimiters are used within the individual transactions.

X12 Document Structure and Loops

The structure of EDI documents dates back to a time when transmission speeds on networks were slow and costs were priced on a per-byte basis. The format of EDI therefore is designed to be efficient and compact. Unlike XML, however, EDI documents were not designed to be user readable. X12 EDI documents are capable of representing hierarchical data structures by using a system of embedded pointers within the character stream. The ANSI ASC X12N HIPAA Implementation Guides provide numerous examples where such structures are implemented within the HIPAA transactions and provide detailed guidance specifying under what circumstances parent-child relationships may be used.

In X12 terminology, a loop is a data structure analogous to a branch in an XML hierarchical data structure. Loops contain a sequence of segments that contain logically related information. For instance, a commonly found loop within a typical X12 document is a Name and Address loop. Loops may contain child loops, leading to a complex hierar-chical structure whose form is not clearly evident from examining the EDI data in a standard text editor. Figure 24.16 depicts schematically what the structure of an X12 EDI document may look like when it has multiple loops with parent-child relationships.

Not every field, record, and subcomponent will be used in every transaction. Because many data elements and indeed entire segments are optional under the standard, there is no unequivocal answer to the question “how big is a HIPAA transaction?” The presence of looping structures within X12 implies that under certain conditions an X12N HIPAA transaction can become extremely large (several megabytes). In the final analysis, the size of any given X12N HIPAA transaction will be determined by the business requirements driving its use.

Examination of the HIPAA transaction document schema within the BizTalk Editor reveals visually how rich in content these transaction sets documents are. The ANSI ASC X12N HIPAA Implementation Guides provide the details for how specific individual elements should be used, the potential for looping structures, what kind of data types are supported, enumeration of specified code list values, field lengths, and the situational logic for use of optional field values. An example of situational logic specifying the circumstances under which an element is required is cited here from the syntax notes of the 837 Institutional Claim for Loop 2402—Attending Physician Name:

• If either NM108 or NM109 is present, then the other is required.

• If NM111 is present, then NM220 is required.

Transaction Set Header and Trailer

Each transaction is surrounded by a transaction set header beginning with ST and ending with a transaction set trailer denoted by SE followed by two fields that contain the number of segments (records) contained between the SE segment and ST segment, and a transaction control number. Table 24.8 summarizes the structure of the transaction set header (ST), and Table 24.9 summarizes the structure of the transaction set trailer (SE).

For more detailed information on the structure and use of the transaction set header and trailer, search for the terms “TRANSACTION SET HEADER” and “TRANSACTION SET TRAILER” within the ANSI ASC X12N HIPAA Transaction Implementation Guides.

Control Segments

X12 EDI control segments are headers and trailers placed before and after the transaction set headers delimited by the ST-to-SE segments. Control segments add information needed for addressing, security, and transaction versioning. The two control segments defined in the ANSI ASC X12N HIPAA Implementation Guides are as follows:

• Functional Group Header and Trailer(GS/GE)

• Interchange Control Header and Trailer (ISA/IEA)

The Functional Group Header is used to wrap groups of transactions of the same class (that is, 270 or 835 or 837 and so on). The type of the transaction within the functional group is specified within the GS01 field. Table 24.11 contains the definitions for the two-letter Functional ID codes. The GS06 field contains the Group Control Number, which is generated from a one- to nine- digit number specified when an EDI port is configured (Group Control Number seed value) and incremented after each transmission of a document through the port. Additional information in the Functional Group Header includes date and time stamps, and routing and addressing information used by BizTalk Server during channel selection.

The Application Sender's code (GS02) and the Application Receiver's Code (GS03) are used to identify specific internal applications used by trading partners. They provide an additional level of granularity for addressing beyond the organizational identifier information contained within the Interchange Header. The precise values of these codes are determined by mutual agreement between trading partners, and they will be defined within the trading partner agreement.

The Functional Group Header also contains version information for the transaction sets within the GS08 field. Table 24.12 contains the list of codes for each transaction type.

The Functional Group Trailer (GE) is simple in structure but contains important information used for tracking and auditing data integrity. The GE01 field contains the transaction set count within the functional group and must equal the number of ST-to-SE blocks. The GE02 element contains the Group Control Number and must be identical to the value contained in GS06. Table 24.13 contains a summary description of the structure of the Functional Group Trailer.

The Interchange Control Header (ISA) is used to wrap a series of Functional Groups, thus allowing EDI documents to combine different types of transactions into a single transmission. The Interchange Control Header contains the major addressing information for the EDI document in the Interchange Identifiers and Identifier Qualifiers. X12 does not depend on a single method for determining a unique identity for a sending or receiving organization, but instead has evolved a flexible method for using named attribute-value pairs. Attributes of an organization that uniquely identify an organization are called Organizational Qualifiers.

Table 24.14 lists eight qualifiers using various identification numbers assigned by government agencies and industry organizations along with their encoding defined within the HIPAA Implementation Guides. Thus, if the value of the Interchange ID Qualifier in ISA05 is set to 01, then the Interchange Sender ID value corresponding to it in ISA06 must be a DUNS (Data Universal Numbering System) number. If the value of ISA05 is set to 30, then ISA06 must contain the sending organization's Federal tax ID number. If the value of ISA05 is set to ZZ, then this indicates that the value of ISA06 is set to a custom value agreed on by individual trading partners.

The Interchange Control Header also contains a nine-digit tracking number, the Interchange Control Number, in ISA13. This tracking number is generated by the sending organization and incremented between document interchanges. Table 24.15 contains a summary description of the structure of the Interchange Control Header.

The Interchange Control Trailer (IEA) has a similar structure as the Functional Group Trailer. It contains the Interchange Control Number, which must match the contents of the ISA13 element, and a count of the enclosed Functional Groups, each delimited by a GS-to-GE block. Table 24.16 summarizes the description of the structure of the Interchange Control Trailer.

Using the control header structures X12 documents can be combined to support a heterogeneous batch structure—that is, X12N permits mixing of transactions of different types within the same document.

The general structure of such a combination X12N EDI document is depicted in Figure 24.17.

Figure 24.18 shows a real-world example of an EDI document demonstrating this structure.

For more detail on control segments, see the ANSI ASC X12N HIPAA Implementation Guides for each transaction, Appendix B.1 Control Segments.

Routing and Addressing

Microsoft BizTalk Server uses the following information to select the correct channel for processing a document:

• Source qualifier

• Source value

• Destination qualifier

• Destination value

• Document type

When receiving inbound EDI documents with the Accelerator for HIPAA, the channel selection information is found within the document control segments and compared with the settings of the available channels. The EDI document is then processed by all BizTalk channels having matching settings for these properties. Unlike XML, all valid X12 EDI documents are essentially capable of self-routing behavior within BizTalk Server because they must contain data within the EDI headers for the document type, and source and destination qualifiers and values.

Table 24.17 summarizes the channel selection information and where it is located within a BizTalk Server configuration and the EDI document headers. The inbound documents contain source organization, destination organization, and document name information within the Interchange Control Segment Header (ISA) and the Functional Group Header (GS). These values are used to identify messaging port-channel combinations that will process the EDI document based on the values of their source and destination organization settings, and the values of the document definition selection criteria for the inbound document definition.

When BizTalk Server outputs an EDI document, it adds an EDI envelope to the content transformed from the internal canonical XML format and then places the organization information from the channel settings and the outbound document definition selection criteria into the appropriate ISA and GS data elements. Table 24.18 summarizes the location of the addressing information within the EDI headers and where the configuration location is within BizTalk Server for outbound document transport. The values for the source and destination organization identifiers and values are taken from the port and channel configuration and the document type information taken from the outbound document definition selection criteria. The values are then used to construct the appropriate Interchange Control Segment (ISA) and Functional Group (GS) header information on the outbound document.

Configuring BizTalk Server Accelerator for HIPAA for EDI

This section contains some basic guidelines for configuring the BizTalk Accelerator for HIPAA to perform basic EDI messaging using HIPAA X12N transaction sets.

Creating Organizations

When creating BizTalk organizations for use in HIPAA EDI settings, be sure to add the appropriate identifiers and set the default value appropriately. When you add a new custom identifier to a BizTalk organization, the name of the identifier is not important, so using “ID” or “MyCustomID” is fine because it provides a user-friendly descriptive value visible in the BizTalk Messaging Manager user interface.

The qualifier, however, has special meaning within HIPAA EDI. “ZZ” is far from being an arbitrary string selection for the qualifier, but rather, it signifies that the values for the identifier have been mutually agreed on for use by trading partners. If you select a standard identifier, you can select the type of identifier from the drop-down list in the Identifier Properties dialog box (see Figure 24.19). Although more than 40 standard identifiers are in the drop-down list (including the mutually defined ZZ Qualifier), the HIPAA Implementation Guides specify which Interchange Qualifier codes are valid. Refer to Table 24.14 for a list of acceptable qualifier codes and their meaning. Each organization will already have an assigned standard identification code such as a Federal Taxpayer ID. The specific qualifier and values should be included in the trading partner agreement.

Creating Document Schemas

The BizTalk Server Accelerator for HIPAA installs XML document schemas for the HIPAA transaction set as read-only templates and does not automatically create document schemas in the BizTalk Server WebDAV repository. Use the BizTalk Editor to create an XML document schema for each HIPAA EDI document that will be processed. It is helpful to preserve the name of the underlying XML template file to ensure that the correct schema will be used when creating BizTalk document definitions and map files. The schema templates can be found by selecting the HIPAA template in the New Document Specification dialog box that appears, as shown in Figure 24.20, after clicking File, New on the main menu of the BizTalk Editor.

Creating Document Definitions

When creating a document definition for HIPAA EDI documents, remember to add the document selection criteria name-value pairs using the Selection Criteria tab on the Document Definition Properties dialog within the BizTalk Messaging Manager, as shown in Figure 24.21.

The document selection criteria specified by the value of application_sender_code and application_receiver_code are a means for routing documents among specific applications inside an organization. The value of application_sender_code and application_receiver code are mutually agreed on between trading partners and may include embedded spaces but must adhere to the size restrictions listed in Table 24.19. The functional_identifier is a two-character string assigned to a specific ASC X12N transaction and listed in Table 24.11, and the standards_version is a code that refers to the version identifier codes used by X12 to identify the insurance industry specific implementation standards listed in Table 24.12.

Configuring Ports for Outbound Transport

When creating ports for delivery of HIPAA EDI documents, you need to configure some settings within the BizTalk Messaging Port Wizard Envelope Information page, as shown in Figure 24.22. Configure the port to

• Use an X12 envelope

• Use delimiter values to be applied to the outbound document

• Use an Interchange control number seed value

• Use the correct organizational identifier (qualifier and value)

The X12 envelope adds the correct EDI header and trailer structure to the EDI document, and the delimiter settings determine what characters will be used to separate data segments, elements, and components within the document body. The Interchange control number seed is a numeric value incremented with each document transmitted through this messaging port. The organization identifier settings specify the Destination Organization for this messaging port and provide the destination information for the Interchange Control Segment fields ISA07 and ISA08.

Creating Channels for Inbound Processing

When creating channels for processing HIPAA EDI documents, you will need to do the following:

The Group Control Number is set using the Advanced Configuration page on the BizTalk Channel Wizard, shown in Figure 24.23.

Receive Functions

No special configuration is required for using receive functions with the BizTalk Accelerator for HIPAA. Keep in mind, however, the 2 MB UNICODE file size limit for MSMQ when designing solutions that may involve large EDI transactions.

EDI to XML

In this section, you will configure the Microsoft BizTalk Accelerator for HIPAA to receive an EDI 835 transaction and transform it into XML. You will implement the configuration depicted in Figure 24.24.

This configuration simulates the delivery from a provider organization (in this case a hospital) of an 837 Institutional Claim to a payer organization by using file folders and file receive functions and transport. The goal is to submit an EDI 837 and transform it into an XML document that might be used to interface with an internal claims processing application at the payer.

Modify the Home Organization

Using the BizTalk Messaging Manager, modify the Home Organization so that it has the properties listed in Table 24.20.

In this demonstration, you will use the mutually agreed on Identifier Qualifier code ZZ and assign it a fictional value. In a real implementation, this value would be part of the trading party agreement. Because the ultimate destination within the Home Organization is the claims processing application, you will create a single BizTalk organization application named Claims.

Add a BizTalk Organization

Using the BizTalk Messaging Manager, add a new organization with the properties listed in Table 24.21. This organization will be the source of the EDI 837 Institutional Claim.

Here you use a different identification method for the source organization involving the Federal Tax ID number in contrast to the ZZ identifier used for the Home Organization.

Create a HIPAA Transaction Document Specification

Using the BizTalk Editor, create a new document specification using the 837Institutional_V1_wpc_single.xml template. Store this schema in the WebDAV repository as 837Institutional_V1_wpc_single.xml.

Create an EDI Document Definition

Using the BizTalk Messaging Manager, create a document definition for the 837 Institutional (single) document schema. Modify the document selection properties so that it has the properties listed in Table 24.22.

Add the document selection criteria properties listed in Table 24.23 to the document definition.

The functional_identifier and standards version codes are selected from Tables 24.11 and 24.12 to correspond to the 837 Institutional Claim, version 4010. The application sender and receiver codes are mutually agreed on definitions and, in a real implementation, would need to be specified in the trading partner agreement.

Create a BizTalk Messaging Port

Create a folder c:Claims. Using the BizTalk Messaging Manager, create a new messaging port to an application with the properties listed in Table 24.24.

This port uses file transport to deliver the outbound XML transformation of the 837 EDI document into a folder named Claims. You may need to modify the folder path to suit your computer configuration.

Create a BizTalk Channel

Using the BizTalk Messaging Manager, create a new channel from an organization with the properties listed in Table 24.25.

This channel configuration is the simplest way to convert an inbound X12N EDI document to XML. Use of the BizTalk HIPAA document schema and the same document definition for both inbound and outbound documents causes this channel to transform the inbound EDI into an XML document that fits the XML specification. No mapping is necessary to create this XML representation.

Create a File Receive Function

Create a folder c:Input837 that you will use to submit an 837 EDI document to the Microsoft BizTalk Accelerator for HIPAA. Using the BizTalk Administrator, create a new file receive function with the properties listed in Table 24.26.

This file receive function simulates the transmission of the 837 Institutional Claim from the hospital to the payer organization where it is submitted to the BizTalk Server Accelerator for HIPAA for transformation into XML.

Receive EDI and Transform to XML

In this section, you will demonstrate submitting an EDI 837 to the BizTalk Accelerator for HIPAA and observe the subsequent transformation into XML. You will use a sample 837 Institutional Claim file as the input.

Figure 24.25 shows the output XML file.

XML to EDI

In this section you will configure the Microsoft BizTalk Accelerator for HIPAA to convert XML to EDI. You will implement the configuration depicted in Figure 24.26.

For this demonstration, you will transform the XML document output from the previous EDI-to-XML scenario back into EDI and simulate sending it to another payer organization.

Creating Another Organization

Using the BizTalk Messaging Manager, create a new organization with the properties listed in Table 24.27.

This organization will be identified using a custom organization identifier qualifier and the ZZ code.

Creating a Document Schema

You will need to create an additional document schema referencing the XML document so that BizTalk can perform the transformation.

Use the BizTalk Editor to create a new document schema from the XML document instance that was deposited in the c:Claims folder by completing the following steps:

You cannot use the BizTalk HIPAA Transaction document schema for the 837 Institutional Claim because it describes the structure of the EDI document and does not describe the structure of the canonical XML transformation of the EDI document.

Creating a Document Definition

Use the BizTalk Messaging Manager to create a new document definition for this XML document with the properties listed in Table 24.28.

Create a BizTalk Messaging Port

Create a folder c:AnotherPayer. Using the BizTalk Messaging Manager, create a new messaging port to an organization with the properties listed in Table 24.29.

This BizTalk messaging port must be configured to deliver the outbound EDI document, so you must configure the appropriate envelope, delimiter, and Interchange Control Number seed values. In this part of the demonstration, you will use a different segment terminator (~) than was used in the original EDI 837 file (carriage return). You will also need to use an X12 envelope. You may create one from within the Messaging Port Wizard or by using the BizTalk Messaging Manager.

Create a BizTalk Channel

Using the BizTalk Messaging Manager, create a new channel from an application with the properties listed in Table 24.30.

This channel configuration represents the simplest and easiest way to transform XML into the EDI. By using the canonical XML document structure used by BizTalk Server to represent the 837 Institutional Claim data, there is no need for a mapping file. However, if you were attempting to use any other XML data structure as input, you would need to create a document specification for the XML document instance and create a mapping file between the XML document specification and the BizTalk HIPAA transaction document schema for the 837 Institutional Claim. This can be a tedious process owing to the complexity of the 837, and the Implementation Guides are specific regarding what elements must be present within the outbound EDI document for it to be within the HIPAA regulations.

Washington Publishing Company has developed a special mapping tool for tackling this gap analysis and remediation process for mapping between legacy file formats and the BizTalk Accelerator for HIPAA document schema that can create BizTalk Server compatible mapping files. It is highly recommended that you strongly consider use of this tool for best results during the mapping process. For more information on the OnlyConnectä gap analysis and mapping tool, visit http://www.wpc-edi.com.

Create a File Receive Function

Just as in the previous part of the demonstration, you will use file folders and a file receive function to simulate document transmission to BizTalk Server. For the XML-to-EDI exercise, create a folder named c:InputXML that you will use to submit an 837 EDI document to the BizTalk Accelerator for HIPAA. Using the BizTalk Administrator, create a new file receive function having the properties listed in Table 24.31.

Receive XML and Transform to EDI

In this section you will demonstrate submitting an XML document containing claims information to the BizTalk Accelerator for HIPAA and subsequent transformation into an EDI 837 Institutional Claim. You will use an XML document instance with canonical BizTalk structure for the 837 Institutional Claim as the input.

Figure 24.27 shows the output of the 837 Institutional Claim.

Notice that the segment terminator has been set in this EDI file to the tilde character (~) instead of the carriage return appearing in the original 837 (refer to Figure 24.18).

Configuring Receipts Using the 997

Although not mandated by the HIPAA Transaction Standards, the use of the 997 Functional Acknowledgement is generally accepted to be an industry EDI best practice. The Microsoft BizTalk Accelerator for HIPAA provides support for configuring production and return of 997 Functional Acknowledgements.

The mechanism for receipt production builds on the core receipt functionality of BizTalk Server. Internally, information related to delivery such as date, time, and document type is stored in an internal data structure known as the canonical receipt. The BizTalk Accelerator for HIPAA installs a special map file to produce a valid X12N 997 Functional Acknowledgement from the internal canonical receipt information. For more on how BizTalk Server produces receipts, see the Microsoft BizTalk Server 2002 Online help.

In this section you will modify the EDI-to-XML configuration you created earlier so that it will send an 997 EDI Functional Acknowledgement on receipt of the 837 Institutional Claim.

Figure 24.28 shows the modified configuration.

Create Receipt Document Specifications

You will need to create a document specification for the 997 Functional Acknowledgement so that the BizTalk Receipt channel will have an outbound document definition.

Use the BizTalk Editor to create the new 997 EDI document schema. The template for the 997 may be found in the X12 template folder within the New Document Specification dialog box (refer to Figure 24.20). It will be found as the file 997schema.xml contained within the 4010 folder, which is inside the X12 folder. Store this schema in WebDAV under the name 997schema.xml.

Create a second new XML document schema for the BizTalk canonical receipt. The document schema template for the BizTalk canonical receipt is found in the XML folder in the New Document Specification dialog box and has the name CanonicalReceipt.xml. Store this document schema in the WebDAV repository under the name sch_CanonicalXMLReceipt.xml.

Document Definitions

You will need to create document definitions for use when you configure the BizTalk Receipt channel. Use the BizTalk Messaging Manager to create a new document definition with the properties listed in Table 24.32.

Because this is an X12 EDI document, you will need to add the document selection properties listed in Table 24.33.

You must set the functional_identifier to AK and the standards_version to 004010X091 to indicate that this is a 997 Functional Acknowledgement. These two values are specified within the appendix of each of the ANSI ASC X12N HIPAA Transaction Guides in the section “B.2 Functional Acknowledgement Transaction Set, 997.”

Now create a document definition for the XML canonical receipt using the properties listed in Table 24.34.

Receipt Port and Channel

BizTalk Server 2002 uses the same message channel-and-port mechanisms for configuring delivery of receipts as for delivery of the outbound documents. To demonstrate 997 Functional Acknowledgement delivery, you will need to create the receipt port and a receipt channel. In this section, you will step though configuration of an existing channel for receiving EDI 837 transactions to produce 997 Functional Acknowledgments and deliver them to a file folder.

First, create a folder named c:Receipts. This will simulate the delivery point for the 997 in the provider (hospital) organization. Next, create a messaging port to an organization using the properties listed in Table 24.35 to deliver the 997.

Receipt ports are simply standard BizTalk messaging ports configured for delivery of EDI documents. Accordingly, you will need to supply envelope and delimiter information.

Using the BizTalk Messaging Manager, create a new channel with the properties listed in Table 24.36.

The configuration of the receipt channel requires you to specify the map file between the XML canonical receipt and the 997 Functional Acknowledgement.

Updating the Channel

In this section you will use the BizTalk Messaging Manager to update the EDI-to-XML configuration you created earlier so that it will send a 997 Functional Acknowledgement on receipt of the 837 Institutional Claim.

Demonstrating Receipt Generation

To demonstrate the generation and delivery of a 997 Functional Acknowledgement, you will submit an 837 Institutional Claim to the EDI-to-XML configuration you modified.

Figure 24.29 shows the 997 Functional Acknowledgement.

Using Preprocessors

Preprocessors are a powerful feature of the Microsoft BizTalk Server programming model that permits you to extend the product by adding custom processing functionality that occurs before the document reaches the BizTalk parser components. In this section you will learn about how preprocessors work, you will see what kinds of typical uses they have, and you will use Microsoft Visual Basic 6.0 to build and install a sample custom preprocessor for working with EDI transactions.

What Is a Preprocessor?

A preprocessor is a COM component that can be installed into BizTalk Server (and the BizTalk Accelerator for HIPAA) to provide additional document processing after a document is picked up by a receive function, but before it is submitted to the server for parsing and channel selection. Figure 24.30 shows this process for a file receive function.

Some examples of additional processing that can be carried out by using a preprocessor are

• Data decompression

• Decoding or decryption

• Modification of header or document contents

• Parsing

• Custom receipt generation (such as TA1)

• Custom logging or tracking

How Do Preprocessors Work?

Preprocessors are COM components that implement the IBTSCustomProcess interface. This interface has only two methods, Execute and SetContext. The Execute method implements the custom work to be performed on the inbound document by the preprocessor.

Table 24.37 contains the method signatures for Visual Basic and C++ versions of the Execute method

Table 24.38 defines the parameters for this method.

The SetContext method provides a means for the preprocessor to retrieve information from the BizTalk Server regarding the document processing by the channel after submission. Table 24.39 shows the method signatures in Visual Basic and C++ versions.

The IBTSCustomProcess_SetContext method returns a read-only IBTSCustomProcessContext object that contains information on the document and channel that ultimately receives the document from the preprocessor. Table 24.40 lists the properties available for use within the preprocessor.

The events that occur when a file receive function is configured to use a preprocessor are as follows:

The IBTSCustomProcess_SetContext method can be invoked by the preprocessor component to return channel and document information.

Using a Preprocessor in an EDI Scenario

When the BizTalk Accelerator for HIPAA receives a document, it removes the EDI headers (ISA, GS, ST) and trailers (IEA, GE,S E) before submitting the document for parsing and processing by a channel. The information contained in the headers is not stored within the document tracking database. The information if there is a need for keeping track of any of the information contained within the EDI headers for auditing or tracking purposes, a custom preprocessor must be used. In the following sections you will implement a custom preprocessor that will demonstrate how to access the contents of the Interchange Control Segment Header (ISA) to illustrate the flexibility of the programming model. Virtually any functionality that you may require within your solution can be implemented within the Execute method programmatically.

The Visual Basic Custom Preprocessor Sample

Microsoft BizTalk Server 2002 includes as part of the Software Development Kit (SDK) Visual Basic and Visual C++ samples for creating a preprocessor. The preprocessor projects are located in the Program FilesMicrosoft BizTalk ServerSDKMessaging Samples folder. In this section we will modify the Visual Basic sample to read the EDI header information contained in the ISA segment.

Follow these steps to create and install a custom BizTalk preprocessor for use with the BizTalk Accelerator for HIPAA:

Sub IBTSCustomProcess_Execute(ByVal vDataIn, ByVal nCodePageIn as Long, ByVal bIsFilePath
 As Boolean, ByRef nCodePageOut, ByRef vDataOut) 

'vDataIn contains the path of the file in the receive function
'vDataOut is a string that contains the entire file contents
'    which will be passed back to BizTalk Server
'add project reference to Microsoft Scripting Runtime
'add project reference to Microsoft BizTalk Server
     'Application Interface Components 1.0 Type Library

nCodePageOut = nCodePageIn

If bIsFilePath Then
    Dim objFSO As FileSystemObject
    Dim objText As TextStream
    Set objFSO = New FileSystemObject
    Set objText = objFSO.OpenTextFile(vDataIn, ForReading)

    Dim str837 As String
    Dim strISA As String

    str837 = objText.ReadAll
    objText.Close
    Set objText = Nothing
    strISA = Left(str837, 105)
    vDataOut = str837

    Dim objTextOut As TextStream
    Set objTextOut = objFSO.OpenTextFile("c:ISA.txt", ForWriting, True)
    objTextOut.Write (strISA)
    objTextOut.Close

    Set objTextOut = Nothing
    Set objFSO = Nothing
End If

End Sub

Windows Registry Editor Version 5.00 
[HKEY_CLASSES_ROOTCLSID{<your preprocessor guid>}Implemented Categories
{20E8080F-F624-4401-A203-9D99CF18A6D9}]

You can find a copy of the registry script (VBCustPreProcessor.reg) in the directory containing the Visual Basic custom preprocessor sample project. Copy the CLSID for your component from the registry and paste it into the script. Be extremely careful when working with the registry as changes are reflected immediately and cannot be undone!

After running this script you will be able to see the component listed in the Preprocessors drop-down list in the Service tab in the Receive837 file receive function you created earlier for the EDI-to-XML demonstration.

Test your preprocessor by submitting the 837I.txt sample claim. Look for the file named ISA.txt in the c:directory and examine the contents using Notepad. This file was constructed by the preprocessor from the ISA segment contents and is shown in Figure 24.31.