Microsoft BizTalk Accelerator for HIPAA

Microsoft Corporation

August 2002

Applies to:
    Microsoft® BizTalk® Server 2002

Summary: How to plan, deploy, and maintain a robust, highly functional, and cost-effective business solution for the electronic transfer of information in accordance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). (78 printed pages)

Contents

Introduction
    Audience
    About This Guide
    Prerequisites
    Scenarios
Proof-of-Concept Application
    Overview and Approach
    Software Testing
    Physical Configuration Testing
    Setting Up the Proof of Concept Application
    Results
Design Considerations
    Logical Design Considerations
    Physical Design Considerations
    Reliability, Availability, and Scalability
    Security
Appendices
    Appendix 1: Transaction Cost Analysis Testing Methodology
    Appendix 2: Services Guide
    Appendix 3: WEDI SNIP White Papers

Introduction

The Architecture Guide for Microsoft® BizTalk® Accelerator for HIPAA is one in a series of guides; others in the series are Deployment Guide, Operations Guide, and Services Guide. Together these guides offer prescriptive architecture guidance to help you plan, deploy, and maintain a robust, highly functional, and cost-effective business solution for the electronic transfer of information in accordance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

Audience

This guide should be read by Chief Technical Officers, Chief Security Officers, systems architects, project managers, HIPAA experts, development leads, software developers, and anyone else concerned with planning for and implementing a HIPAA-specific data exchange solution for a health care organization. We assume that you are familiar with business transactions in the United States health care system.

About This Guide

This guide provides architecture and performance scenarios, approached from a payer perspective, to assist you in planning and deploying your solution. It reflects best practices derived from experiences of Microsoft Consulting Services.

We discuss some basic scenarios, show you how we created a proof-of-concept (POC) application for performance testing and how you can create your own, and go over the major design considerations that you will need to make to get the most from your BizTalk Accelerator for HIPAA solution. After you have successfully implemented and run the test scenario, you can add additional features to meet your own requirements and measure the results.

This guide is not intended as a substitute for the BizTalk Accelerator for HIPAA documentation or for the Microsoft BizTalk Server 2000 documentation. You should familiarize yourself with these documents before attempting to use BizTalk Accelerator for HIPAA, and use them as a reference for descriptions and discussions of product features.

BizTalk Accelerator for HIPAA addresses only the transaction set standards detailed in the Administrative Simplification section of HIPAA, and this is what we discuss here. The implementation of the HIPAA Security and Privacy requirements will vary widely between organizations, and the permutations are beyond the scope of this document.

As you read this document, note that many of the terms used here are defined in the glossary of the BizTalk Accelerator for HIPAA documentation.

Prerequisites

You should be prepared as follows before considering your architecture:

• Understand the HIPAA implementation guides that are published by Washington Publishing Company (WPC).

• Use the BizTalk Server and BizTalk Accelerator for HIPAA online Help files for troubleshooting.

• Understand the basics of Microsoft BizTalk Server:

  BizTalk Orchestration Designer, a visual environment for business process modelling

  BizTalk Editor, which defines business document schemas

  BizTalk Mapper, an Extensible Stylesheet Language Transformation (XSLT) component

  BizTalk Messaging Manager, used to specify and manage business relationships

  BizTalk Server Administration, used to manage queues, transports, and services

  BizTalk Document Tracking, used to track message and schedule activity

• Have experience in configuring and implementing BizTalk Server in a development environment.

• Understand the basics of BizTalk Accelerator for HIPAA:

  BizTalk Accelerator for HIPAA parser, a component that translates HIPAA (X12) files into Extensible Markup Language (XML) files

  HIPAA-specific document specifications, BizTalk Server-specific XML schemas that are created by using BizTalk Editor

Scenarios

Three major types of customers—called covered entities or CEs—in the health care industry are affected by the HIPAA legislation. They are:

• Providers. Primarily doctors' offices, clinics, and hospitals. One goal of the HIPAA legislation is to relieve providers of the burden of supporting hundreds of proprietary data formats for electronic data interchange (EDI) specified by individual payer organizations.
• Payers. Primarily insurance companies and medical plans such as Health Maintenance Organizations (HMOs).
• Clearinghouses. A clearinghouse can work as a business associate on behalf of either payers or providers.

This guide focuses on the payer scenario, and discusses both batch-style transactions and online transactions. For information about the technical aspects of these scenarios, see the Logical Design Considerations section later in this guide.

Batch-style transactions

Examples of batch-style transactions are 837, 835, and other 8xx transactions.

Figure 1.

Online transactions

Examples of online transactions are 270, 271, and other 2xx transactions.

Figure 2.

Proof-of-Concept Application

For the purposes of this paper, a proof-of-concept (POC) application was modeled around batch-style processing specifically focused on the health care industry payer. Testing of this application was centered on performance—the goals were to establish a performance baseline in each configuration around a number of document types, to make incremental changes around that baseline, and to measure and analyze the effects of the changes.

Overview and Approach

For the purposes of this guide, the POC application was modeled and tested for performance implications on the following:

• The 837 Institutional transaction with varying size and complexity (the major focus)
• Batch processing from the payer perspective
• The 270 transaction (a lesser focus)
• Parsing 837I as EDI
• Serializing 837I inbound as XML

Business flow modeling is out of the scope of this Architecture Guide, which focuses on transactional throughput testing. Self-routed documents, preprocessing, and other business logic implementations—for example, application integration components (AICs)—were not considered during our main testing. (However, information about the 997 appears in the Results section later in this guide.)

In creating the POC application, we made the following decisions:

• Real-time processing would stress the front-end systems (for example, Internet Information Services (IIS) and Active Server Pages (ASP)); much performance data is already available about these applications.
• The 837 Institutional transaction was chosen due to its relative complexity. 837 transactions can have many hierarchical relationships represented within a claim. 837I transactions can also be very large, with more line items per transaction than the other 837 forms.
• The 270 transaction was also chosen to demonstrate relative performance on a simpler document (from a parsing/serializing perspective).
• Our architectural focus is on HIPAA-specific BizTalk Server performance metrics; therefore we consider the parser/serializer performance and not Orchestration, AICs, or preprocessors.

Software Testing

The software architecture testing was simple in scope. It involved the HIPAA-specific message processing functionality (parser/serializer), with focus on the following tests:

• Independent exercise of each individual schema (837, 270)
• Parallel execution of each of the schemas on the same BizTalk Server
• Multiple interchanges
• Multiple groups within an interchange
• Multiple documents within a group
• File-based receive function to submit the documents

The data scenarios based on incoming and outgoing data included HIPAA-EDI in, HIPAA-EDI out; HIPAA-EDI in, XML out; and XML in, HIPAA-EDI out. We prioritized inbound messaging as a performance target. The following illustration shows the data flow.

Figure 3.

The processing was limited to only the parsing/serializing functions of HIPAA, which means we focused in on just those pieces. The most straightforward way of doing this was to use a file drop into an NTFS directory, with a custom receive function (File receive function) that called a channel with a corresponding port that dropped the message to another file directory. The objective was to run performance tests against the parser/serializer, not against additional components such as Orchestration, database access, and message queuing, because the business application integration will vary widely from one health care entity to the next. The following illustration shows more details of the data flow.

Figure 4.

Physical Configuration Testing

The tests of this application concentrated on common infrastructure server configurations that are found in n-tier applications. We tested the following scenarios:

• Single server/pilot configuration; houses both BizTalk Server and Microsoft SQL Server™ (dual-processor system)

  

  Figure 5.

• One BizTalk Server, one SQL Server (both dual-processor systems)

  

  Figure 6.

• One BizTalk Server, one SQL Server (both multiprocessor systems), as well as this configuration in a clustered configuration

  

  Figure 7

• Two BizTalk Servers in a BizTalk Server group, two BizTalk Servers (multiprocessor) configured in a clustered configuration, and two SQL Servers (multiprocessor) configured as a cluster

  

  Figure 8.

In business-to-business and enterprise application integration (EAI) projects, the number of variables is significant enough to warrant solution-specific custom performance analysis. The POC work in this section provides a repeatable methodology for establishing and measuring this performance analysis.

Note that the recommended implementation for BizTalk Accelerator for HIPAA is two multiprocessors (two or more processors is preferable) to run the BizTalk Accelerator for HIPAA services, and at least two multiprocessors to run SQL Server. We highly advise in the Physical Design Considerations section below that both BizTalk Server (and all BizTalk message disk writes such as when using BizTalk messaging ports to file or message queue) and SQL Server be clustered using the Microsoft Windows® 2000 Cluster service.

The vision for these tests is that testers could reproduce the tests and benchmark their systems to arrive at accurate estimates for sizing and capacity planning, given the following:

• A set of data, for example, a sample 837 that your company uses today
• The configuration that is easiest to test (file drop or Message Queuing drop as opposed to back-end legacy or database integration)
• The BizTalk Accelerator for HIPAA product installed

Setting Up the Proof-of-Concept Application

The primary goals of these tests are to establish a performance baseline in each configuration around a number of document types, to make incremental changes around that baseline, and to measure and analyze the effects of the changes. For repeating these results in another setting (for a customer or for your own company), follow these guidelines:

• Choose a representative set of data (837, 270, and so on). Where possible, use actual transmitted data with identifying information removed. (Favor realism wherever possible in the tests.)
• Configure the BizTalk Server objects (channels, ports, document definitions) that are needed to run your tests. Keep it simple, and if you have questions on how any of this is accomplished, see the Learning BizTalk Server 2000 lessons.
• Set up a File receive function on the NTFS file folder where you want to test performance.
• Disable the File receive function.
• Create many copies (hundreds or even thousands) of the file to be tested. Windows Script Host (Microsoft Visual Basic® Scripting Edition and Scripting Library) can automate this process.
• Enable performance logging through Windows 2000 against the counters listed in the Transaction Cost Analysis Testing Methodology appendix. For more information about performance monitoring, open the file smlogcfg.chm in the %systemroot%\help\ directory on your Windows 2000 Server computer.
• Enable the File receive function.
• Run the test for a set amount of time (10 to 30 minutes or longer).
• Stop the performance log.
• Start a new log and repeat the test (to verify the logs).

For more information about duplicating the performance benchmarking on which we based the recommendations in this paper, see Appendix 1:Transaction Cost Analysis Testing Methodology.

Results

The recommendations presented in this section are based upon a specific series of tests and the documents used in them. Actual results (throughput, bytes per second, and the like) are not published in this paper, because your results can be highly variable. Our tests were kept simple so that they can be extended to apply to a variety of testing environments.

The following table shows architectural recommendations based on the tests that were run on the POC application.

Design Considerations

To make the most of BizTalk Accelerator for HIPAA, you must determine what your logical design will be—what functionality you need to have in place—and what physical components you will use to implement that design.

Logical Design Considerations

Identify what logical steps must be taken, what pieces must be put in place to perform the steps, and how the pieces can be most effectively used.

Major building blocks for processing HIPAA documents by using BizTalk Accelerator for HIPAA include:

• Inbound document submission
• Preprocessor
• HIPAA EDI parser
• BizTalk Messaging Services (channels, ports, document definitions, and so on)
• BizTalk Orchestration
• SQL Server databases
• COM/COM+ components
• Microsoft Message Queuing (MSMQ)
• Outbound documents
• BizTalk Server optimization

In this section, we start with two architectural design scenarios: batch claims processing and online data submission.

Batch claims processing scenario

The following illustration shows how a payer might process batch claims. Notice the following points:

• 837 EDI batch documents are submitted to BizTalk Server through a File receive function.

• The preprocessor is optional. If control segments (such as ISA or GS) need to be preserved in XML format, a preprocessor custom component is needed. The preprocessor can also be used to store the original document to a database for audit logging.

• 837 EDI documents are parsed into XML based on corresponding XML specifications.

• 997 functional acknowledgments are generated.

• Orchestration is used to perform extended validation, coordinate request and response, manage long-running transactions, and implement business rules.

• Relevant data is extracted from a transaction (by using a map) to meet the format requirements of the payer's existing systems (flat file or XML).

• The preprocessor used to audit/log the 837 in the following diagram is optional, in case your organization needs to audit the document before it is processed (as it was when it came across the wire from the external health care organization). For simple message logging use the native BizTalk Server Tracking features.

  

  Figure 9.

Online data submission scenario

Many businesses want the Web-based user experience to be synchronous if possible. Because there are scalability limitations when implementing a front-to-back synchronous solution, a business might choose to place a synchronous facade on an asynchronous, back-end processing application architecture. In this way, the applications can continue to receive requests at high rates regardless of the back-end processing latencies. The back end can then be scaled out independently of the Web server layer.

The Web page that is accessed passes the message to a stateless component. This stateless component invokes a component (that might be pooled) to encapsulate Message Queuing and save the message to a queue. Either the Web page or the stateless component provides a globally unique identifier (GUID) to each request message. If the stateless component provides the GUID, the GUID is returned to the ASP page as an out parameter or placed into the Internet Information Services (IIS) application or session object. In this way, messages can be safely moved through firewalls and through a single port in the last firewall into the business domain. These messages are then read within a Distributed Transaction Coordinator (DTC) transaction from the queue. This is known as a clustered resource. The messages are then sent in a load-balanced fashion to a server farm of processing servers using either COM+ Component Load Balancing or Message Queuing by a multithreaded component or service.

The following illustration shows how an eligibility check can be processed through direct data submission. Notice the following points:

• From the Web client, 270 content is submitted as an XML document to the Web server.

• On the Web server, the XML document (270 XML) can be transformed into a 270 EDI to be saved to a database for audit logging or can be input as a 270 in XML. Audit logging the 270 X12N HIPAA EDI, as recommended by the Workgroup for Electronic Data Interchange Strategic National Implementation Process (WEDI SNIP), provides proof that our process is utilizing, creating, and maintaining the full HIPAA data content.

• 270 XML goes through Orchestration to get the eligibility response from an existing benefits and eligibility system; when the response is received it is stored in the 271 response database.

• While the 270 is being processed through Orchestration, the end user is simultaneously redirected to a polling Web page. This Web page displays a message to the end user that the 270 is currently being processed.

• The polling Web page has a time-out and retry count. Each time through the retry process it checks the 271 response database for a response to the submitted 270.

• When the 271 data is ready, the 271 is serialized out to the polling Web page as XML and is transformed into HTML.

• The Web client displays 271 content.

• Alternatively, you might choose to provide a mechanism for serializing the data out as EDI to be sent either by SMTP or FTP (not shown below). This would involve allowing the end user to click a button to initiate this EDI-format transmission over e-mail or secure FTP.

  

  Figure 10.

Other design considerations are as follows:

• The front end could be another system (for example, Microsoft SharePoint™ Portal Server or Microsoft Commerce Server 2000).
• Where .asp is referenced above, this could easily be created by using a Web service that uses ASP.NET. The illustration shows technologies that are widely available now; however Web services would be simpler and quicker to create than existing ASP code.
• The benefits/eligibility database above could contain the 271 response database and could reside on a single physical instance of Microsoft SQL Server (or other RDBMS).
• The 270 audit database could reside on the same system as the eligibility and the 271 response databases. Audit databases are important, because they allow a third party to validate that our business process is utilizing the content of fully compliant HIPAA X12N EDI.
• There are several ways to implement the polling implementation; however the central idea is that a 270 is logged into an audit database, the 270 is passed through an automated eligibility lookup in a benefits database, and the subsequent 271 is generated and stored in a response database/table. The polling.asp code is designed to simulate a single, synchronous activity (for example, a credit check in an e-commerce Web application) that began with the posting of the 270 data in receive.asp.
• Note that this appears as a single physical location. The assumption is that both the BizTalk Servers and the front-end (Web) servers are hosted by the payer, which is not necessarily true. The payer need only host the Web service to which the Web server will post 270 data; the self-service portal indicated through this architecture could be self-hosted by the provider.
• The 271 (XML) data above can be quickly and easily generated by using Microsoft SQL Server 2000. Microsoft SQL Server 2000 supports generation of XML directly from the database tables, which can then be consumed by a Web page as an XML data island (source). For more information see the Microsoft SQL Server 2000 Books Online.
• Although XML is indicated in this data path, EDI could also be used if needed. The additional design and coding effort for generating EDI is painless when using BizTalk Accelerator for HIPAA, because the 12 HIPAA Transaction Sets (including both the 270 and 271) are built into the product, and translating between EDI and XML for these transaction sets is as easy as a few mouse clicks.

Inbound document architecture

Identify business interchanges that are covered under the standard transactions with your current trading partners, and determine what transport service(s) to use for HIPAA EDI interchanges as part of your trading partner agreement. BizTalk Server supports a core set of transport services that enable the server to send HIPAA EDI documents to organizations or applications, whether or not the applications are capable of communicating directly with the server.

The BizTalk Server architecture allows you to design an application in which trading partners can submit business documents by posting them to a File Transfer Protocol (FTP) site, by posting them to an Internet Information Services (IIS) Web site through Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS), or by sending them as a Simple Mail Transfer Protocol (SMTP) e-mail. However, within the context of BizTalk Accelerator for HIPAA, the choices should be focused on the file transport protocols with the highest programmability, widest reach of health care partners, and greatest flexibility in security and application integration. The following table summarizes these choices.

FTP can be appropriate in some situations, especially when integrating with legacy systems; however for the broadest reach of external business integration, lowest security hurdles, greatest programmability, and relative ease of application integration, the recommendation for the inbound document architecture is HTTPS.

Alternatively, you can use the IInterchange interface to submit messages. However, there are a few issues to consider with this approach:

• Programmatic submission is slower than using a receive function, which has built-in support to handle messages concurrently.
• The submission of documents is tightly coupled. If the BizTalk Server is not available, then the submission cannot be performed.

Receiving documents by using File receive functions

Although you can get high performance by using a File receive function for business-to-business transactions, a File receive function is not secure for Internet-based transactions. For application-to-application transactions within a corporation, you can use a File receive function for optimal performance without jeopardizing security. To use a File receive function securely with external trading partners, you need to combine it with another receive function, such as HTTP. The HTTP receive function can accept a document from a trading partner (using HTTPS or S/MIME for security) and write the file to an internal file system directory. Then BizTalk Server can use a File receive function to receive the document. This combination of transports might not increase performance, but it will provide greater flexibility and security. For example, it allows trading partners with different platforms to communicate by using EDI with minimum impact on either side.

There are cases where using FTP to transfer large documents is appropriate, but BizTalk Server does not support it as a transport protocol. You can set up a Windows 2000 FTP server to receive files to an appropriate directory and then transfer the files into BizTalk Server with a simple File receive function. An administrator needs to designate access levels (read, delete, and so on) to the file directory for specific users. A trading partner needs to add a certificate to the data, and a copy of its private key must be received to decrypt the data before BizTalk Server can process the document.

To optimize your File receive function, use a local file directory rather than a remote file directory to reduce network latency, and use disk arrays to achieve high throughput and fault tolerance.

Receiving documents by using HTTP or HTTPS

To receive documents through HTTP or HTTPS, you must use IIS to publish a Web site to which documents can be posted. Use an ASP page in your Web site to receive the incoming document and place the document into a Message Queuing queue for BizTalk Server to process. The ASP page could also use a BizTalk Server Interchange object to submit the incoming document to BizTalk Server, but that is not recommended for scalability reasons. Keep in mind that Message Queuing limits document size to 4 megabytes (MB) of Unicode data or 2 MB of non-Unicode data (BizTalk Server converts data to Unicode).

To optimize performance, you need to configure the inbound HTTPS receive service on a separate server from BizTalk Server. If the inbound HTTPS receive service cannot be installed on a separate server from BizTalk Server, use a faster CPU or add more CPUs.

To maximize scalability, you should also use Windows Network Load Balancing or a hardware IP load balancing solution to distribute the load of your inbound HTTP traffic.

Supporting SSL connections

To support HTTPS communication, you must install a digital certificate on your Web server and configure the site to allow Secure Sockets Layer (SSL) connections. This should be considered a minimum requirement for security in a business-to-business scenario, because it provides server authentication and encryption services for the document exchanges performed over the connection. In addition, you can disallow anonymous access to the site and require that your trading partners be authenticated.

Submitting SMTP messages to BizTalk Server

The SMTP receive function is similar to the HTTP receive function for inbound transactions in that there is no native SMTP receive function built into BizTalk Server. To allow trading partners to send business documents through SMTP, you must use an e-mail system that supports programmatic events and customization. Due to the requirement for additional dependent services, which can add unwanted time delays to the project, we do not recommend using SMTP for HIPAA EDI transactions.

HIPAA EDI and self-routing

A HIPAA EDI document header contains control segment data used for internal document routing. BizTalk Accelerator for HIPAA can also use this data to make EDI documents self-routing. For example, you can have multiple inbound file types handled by one receive function and routed to multiple destination locations (for example, a billing system and a patient management system) simultaneously to reduce the support burden. Open source or open destination is not an option for HIPAA EDI for the following reasons:

• Functional acknowledgements prevent the use of open source and open destination.
• BizTalk Server must know the destination path to send a functional acknowledgement.
• BizTalk Server must know source and destination for digital signatures and encryptions.

You must define a channel, a port, and a document definition for each trading partner.

Inbound document architecture summary

• If you receive HIPAA EDI in batch mode (for example, 837), we recommend using File receive functions because they allow trading partners with different platforms to communicate and are easy to implement. HIPAA EDI documents can be received either by an HTTPS receive function or by FTP. FTP is appropriate in some situations, especially when integrating with legacy systems, but for the broadest reach of external business integration, lowest security hurdles, programmability, and relative ease of application integration, we recommend HTTPS for the inbound document architecture.
• If you receive HIPAA EDI in online mode (for example, direct data submission of 270 contents through a Web client), we recommend using HTTPS as the transport service. You can use an ASP page to receive a document (for example, 270 contents in XML) and submit it to BizTalk Server through Message Queuing or through a BizTalk Server Interchange object.
• Within an organization, we recommend placing documents into a Message Queuing queue before submitting them to BizTalk Server for optimal scalability. If file size is larger than 4 MB (Unicode), then consider using a local NTFS directory with a File receive function.

BizTalk Orchestration

Use BizTalk Orchestration to add extended validation to HIPAA transaction sets and to provide integrated business processing between applications.

Orchestration is a powerful feature provided by BizTalk Server that provides the most flexible approach to integrating business process logic with new and existing applications and systems. The HIPAA implementation guides include specific content and situational requirements that are not checked by the BizTalk Accelerator for HIPAA parser or the BizTalk HIPAA schemas.

BizTalk Orchestration is used to automate short-running and long-running business processes. Each business process is designed by using the BizTalk Orchestration Designer and compiled into an XLANG schedule, which is executed by using an XLANG Scheduler Component Services component. XLANG schedules typically operate on a document sent to the Orchestration servers through Message Queuing.

Orchestration schedule optimization

To optimize XLANG schedules, developers must understand the execution thread issues relating to the creation of components that will be implemented in XLANG schedules.

The XLANG Scheduler Engine is configured to execute within a multithreaded apartment, and there is a limited pool of threads that the engine can use to invoke components that need to execute in single-threaded apartments, such as Visual Basic components. Because Visual Basic components run as single-threaded apartments, one component can block others if there are many outstanding concurrent calls. Visual Basic components used from COM+ server applications can deadlock and cause schedule instances to halt. The way to avoid this issue is to ensure that the components are built with the "retain in memory" option set (from project properties in the Visual Basic environment). Another option is to create a highly scalable solution by creating components in C++ in a multithreaded apartment instead of using Visual Basic.

The design of Orchestration schedules also has an impact on database performance. The XLANG Scheduler requires frequent reads and writes to the XLANG persistence database, especially when you implement a transaction and use time-out intervals. Low throughput of XLANG schedule instances can be caused by bottlenecks in the XLANG persistence database. Use SQL Server optimization techniques to minimize database contention. Use the Transaction shape only where needed. Review the design of XLANG schedule drawings to ensure that the latency on receive actions is set to a value less than 180 seconds. This will prevent the dehydration of XLANG schedule instances that contain rapidly occurring receive actions.

The XLANG Scheduler Engine uses Microsoft ActiveX® Data Objects (ADO) for persisting the state of schedules into the database. By default, ADO installs itself as apartment threaded, which could cause a performance slowdown. You can run a batch file (found in \Program Files\Common Files\System\ado\makfre15.bat) that converts ADO to be "both threaded." Consider the impact on other database applications before making this change.

When schedules using transactions are executed under heavy stress (for example, a large number of concurrent schedule instances), Distributed Transaction Coordinator (DTC) transactions might time out. The XLANG Scheduler Engine enrolls in the application's DTC transaction to do its state management. Schedule designers might not realize that the XLANG Scheduler Engine does this and might set the time-out to a value that works well under low-stress situations but encounters problems at higher stress. For these reasons, transaction time-out values of less than 60 seconds are not recommended. In addition to the transaction time-out, the time-out values for ADO connection and commands might also need to be increased.

Message Queuing (MSMQ)

Use Message Queuing to pass messages from the Web farm to the BizTalk Servers. There are many scenarios in which Message Queuing is the most effective way to communicate with BizTalk Server because of its loosely coupled, reliable delivery functionality. This functionality includes:

• Inbound messages received through HTTP or HTTPS by an ASP script.

  When a document is posted to an ASP page, you can submit it to BizTalk Server by using Message Queuing. Message Queuing provides a scalable, loosely coupled, reliable, transaction-protected architecture.

• Outbound documents to line-of-business applications.

  After a message has been received and processed by BizTalk Server, it can be placed in a message queue and sent to a line-of-business application. The application can read the message from the message queue, or the message can be routed through the MSMQ-MQSeries Bridge to a mainframe environment for processing by a non-Windows host. (For more information about the MSMQ-MQSeries Bridge, see the Microsoft Host Integration Server 2000 documentation.) As another option there is currently a Microsoft Adapter for MQ Series.

• Inbound documents from line-of-business applications.

  When a line-of-business application needs to submit a document to BizTalk Server, it can place the document in a queue.

• XLANG Orchestration.

  Orchestration relies heavily on the use of Message Queuing, because Message Queuing is one of the binding components that integrate with other applications, including BizTalk Messaging.

Note   The physical limit for the amount of data a queue can hold is 2 gigabytes (GB). Each message can be up to 2 MB for non-Unicode data (because BizTalk Server converts data to Unicode) or 4 MB for Unicode data.

Planning your queues

To be able to read messages in a transacted manner, the queues you create for documents to be passed to and from BizTalk Server should generally be local queues. Transactional reads from remote message queues are not supported in Microsoft Message Queuing version 2.0.

For this reason, you should architect your solution so BizTalk Server can access queues locally. Thus, receive functions should reference local queues. Private queues are preferable to public queues because public queues can suffer up to 40 percent performance degradation because of directory name resolution.

Planning to send messages

You should use direct format addressing mode when addressing a message queue. This instructs Message Queuing not to use the directory service to get routing information. When a direct format name is used, all routing information is taken from the format name. Message Queuing sends the messages to the queue in a single hop without querying the central Message Queuing database in Microsoft Active Directory®, thus enhancing performance considerably.

Use the following syntax when addressing a private local queue using the direct format addressing mode:

QueueInfoObject.formatname = "Direct=OS:ComputerName\private$\QueueName"

Configuring BizTalk Messaging to use queues

BizTalk Server can both send and receive messages by using Message Queuing. Inbound documents can be read from a queue by using a receive function or an XLANG schedule, and outbound documents can be sent to a queue by configuring a messaging port to use the Message Queuing protocol or an XLANG schedule to bind to the message queue.

Interoperating with IBM mainframe environments

Message Queuing can be used to integrate with IBM solutions running in an IBM AS400 or OS/390 environment. To send messages to these environments, you must install Microsoft BizTalk Adapter for MQSeries 1.0 to route messages from a Message Queuing queue to an IBM MQSeries queue.

Outbound document architecture

When BizTalk Server needs to send documents to trading partners, it can do so by posting them to a remote site through HTTP or HTTPS. See the Inbound Document Architecture section for an overview of the recommendation of HTTPS as the protocol of choice for BizTalk Accelerator for HIPAA implementations. Both SMTP and FTP have barriers for adoption that HTTPS does not present.

Sending documents by using HTTP or HTTPS

To send documents by using HTTP or HTTPS, you must use BizTalk Messaging Manager to configure the properties of the messaging port used to transmit your document. You can set the outbound transport protocol to HTTP or HTTPS and specify the URL to which you want the document sent.

For BizTalk Server to successfully send documents by using HTTP or HTTPS, it must be able to send data to the Internet. If BizTalk Server is installed behind a firewall, the ports on the firewall must be configured to allow outbound traffic on port 80 for HTTP data, and on port 443 for HTTPS data.

Sending SMTP messages

To send SMTP mail, you must configure the outbound messaging port for your message to use the SMTP transport protocol and specify the destination address (such as someone@microsoft.com). Messaging ports configured to use encryption will encrypt the e-mail message by using S/MIME-encrypted encoding.

Serializing EDI

The HIPAA-specific parser translates HIPAA (X12) files into XML. It requires configurations on both port and channel to convert XML back to EDI.

Configure the port as follows:

• Use a standard EDI X12 envelope configuration.
• Configure the EDI delimiter.
• Set the Interchange Control Number Seed (for example, 900000001).

Configure the channel as follows:

• Set the Group Control Number Seed.
• Configure the EDI Interchange Control Segment (envelope property page).

Outbound EDI batching

Write custom code to batch multiple transactions and handle functional acknowledgements returned from a sent batch. Microsoft Consulting Services has a custom service offering with code developed for BizTalk Server outbound EDI batching support.

Perform the following steps to develop outbound batching:

• Develop a software component "batcher" that can combine different EDI documents into a single batch with multiple functional groups.
• Create a port for the EDI batch to the destination organization.
• Let BizTalk Server serialize the different outbound EDI documents going to the same destination locally to the file system.
• Schedule (or trigger) the batcher to read the documents from the different directories to make the batch document.
• Have the batcher write the EDI batch to another file location where a File receive function will pick up the batch file.
• Configure the File receive function to submit the batch document to BizTalk Server by using a pass-through channel.
• Correlate receipts from individual items in a batch transaction by storing control numbers in a database.

Optimizing BizTalk Server

Use the System Monitor BizTalk Server counters (for example, Documents Received/sec, Documents Processed/sec) to assess and tune administrative parameters for your environment. The following settings are accessible from the property pages within the BizTalk Server Administration management console.

Prioritize parsers

This setting allows you to rearrange the parser sequence to match your document types. For example, if you receive mostly HIPAA EDI documents through your BizTalk Server system, you should verify that the BizTalk.ParserHippaX12.1 parser has highest priority so that it will be tried first to resolve inbound documents. If you have multiple message conversions occurring throughout your business process, consider all the document types that will be parsed.

Disable document tracking

Document tracking places a load on the BizTalk Server CPU, SQL Server CPU, network, disk, and memory. Track only what you need. By default, interchanges (which can contain multiple documents) are tracked along with inbound documents in their native format.

Dedicate receive servers

Work-item processing can be disabled on BizTalk Servers, allowing one set of servers to receive documents through Interchange.Submit (or receive functions) and post to the Shared Queue database while a different set of servers processes those documents. This is a technique for scaling out by function.

Adjust number of receive threads

The recommended thread count for receiving servers is one to two. This should increase for larger documents, if decryption is required, if digital signatures must be verified, or if receiving is separated from work-item processing. A low setting could cause CPU underutilization. A high setting could cause performance degradation due to thread contention.

Adjust number of worker threads

The recommended thread count for processing servers is four to twelve for work-item processing (the default is four). This will be greater if work-item processing is separated from receive processing.

Time between BizTalk Server Scheduler calls

This parameter controls how often a thread polls for available items in the Work queue. Set it from 500 to 1000 if the volume is low enough (the default is 2000 milliseconds).

Tune registry settings

All keys should be added as DWORD values to HKLM\System\Current Control Set\Services\BTSSVC. See Optimizing Registry Settings in the BizTalk Server online Help for detailed instructions. Set the registry keys as follows:

• ParserRefreshInterval. Set the parser refresh interval. BizTalk Server checks for new parsers every 60 seconds (60,000 for the setting value) by default. Set this value to zero if no additional parsers will be needed.
• CacheSize. Set the size of the management object cache. By default, 20 objects are cached. Increase this setting if surplus memory is available on the system.
• BatchSize. Set the receive batch size. The Message Queuing receive function reads documents in batches of 20 by default. Reduce this number if more granular document processing is desired. Do not set this value to zero.

Physical Design Considerations

After the logical design is complete, determine what computers you will need, how they will work together, and how to get the best performance from them.

Required hardware for BizTalk Servers

The first step in obtaining optimal performance from your BizTalk Server solution is to ensure that your servers have an adequate hardware configuration. This can be accomplished by capacity planning based on the anticipated production load on the system. Although multiple elements can contribute to the overall performance, the following elements must be considered while doing the capacity planning to yield the optimum hardware configuration:

• Anticipated number of documents per day to be processed by BizTalk Server
• The size of each document type to be processed
• Complexity of business processes required by the documents

Due to these varying elements, it is not practical to put numbers in this document for the optimum hardware configuration. However, considering these elements during the capacity planning, along with some testing, will help guide you to a reasonable configuration.

The following recommendations should be considered the minimum specification in a production environment.

Each BizTalk Server should be a dedicated server with the following configuration:

• 933 megahertz (MHz) Intel Pentium III Xeon or higher
• 1- to 2-megabyte (MB) Level 2 processor cache
• 1 gigabyte (GB) of RAM
• A 100-megabits-per-second (Mbps) or faster network card connected to 100-Mbps switch ports

Using multiple BizTalk Servers

In highly demanding applications, the optimal configuration is to have multiple dedicated receiving servers and multiple dedicated processing servers. We recommend that you start with the ratio of two processing servers to one receiving server. To make a server behave purely as a receiving server, you can use the BizTalk Server Administration tool to configure the server to not participate in work-item processing.

Maximizing performance of receiving servers

You can maximize the performance of receiving servers by increasing the number of receive threads on the receiving server. This setting can also be configured through the BizTalk Server Administration tool and should be set to a value between one and four per processor (start with one and then use two or more only after testing) for normal circumstances. The value should be increased for dedicated receiving servers, scenarios where encryption or digital signing is used, and interchanges involving large documents.

A low setting could cause CPU underutilization. A high setting could cause performance degradation due to thread contention. The critical metric here is sustained zero Work queue growth.

Maximizing performance of processing servers

To maximize the performance of processing servers, do the following:

• Increase the Worker Threads setting from the default (four) to a value between six and twelve. Start with six and increase as appropriate; more than twelve yields diminishing returns.
• Adjust the Time Between BizTalk Server Scheduler Calls setting to control the frequency with which BizTalk Server polls the work item queue in the InterchangeSQ database. Solutions with a low volume of inbound messages will benefit from a higher frequency value to prevent unnecessary database queries. Decrease this to 500 milliseconds and then increase to 1000 if the volume is low enough.

Clustering BizTalk Server

To provide the highest level of availability for all messages handled by BizTalk Server, you should cluster the computers running BizTalk Server. Additionally, any file or message queues that BizTalk Server uses should also be clustered. Also, high volume usage of queues and file system (through receive functions) should be separated onto its own disk channel (meaning a separate set of disks on separate physical RAID channels on a hardware RAID controller). Finally, ensure that the BizTalk Server Repository in WebDAV (which relies on the NTFS File System) is clustered so that no loss of document schemas occurs. For more information, see the Clustering BizTalk Server white paper.

Using RAID

You can enhance the performance of these file and queue storage locations by using redundant array of independent disks (RAID) disk configurations that rely on hardware caching RAID controllers. The performance and reliability of these storage containers can be optimized by using a combination of RAID 1 (disk mirroring) and RAID 0 (disk striping).

Scaling out BizTalk Messaging

The first step in scaling out is separating the SQL Server database from BizTalk Server. Having redundant BizTalk Servers provides fault tolerance for work-item processing, but there are performance incentives for physically separating the InterchangeDTA and InterchangeSQ databases from the BizTalk Server system (see the following section about SQL Server).

BizTalk Server relies on the underlying transport to load balance the inbound documents. For example, Network Load Balancing Services in Windows 2000 or an IP load balancing hardware solution are valid approaches to scaling document submissions received through HTTP. See the Microsoft BizTalk Server 2000 Deployment Considerations ** white paper for further description of transport scaling alternatives.

Create multiple instances of receive functions to reduce document submission bottlenecks. To balance the receipt of documents across several computers, place the receive functions on separate computers. To avoid overburdening an individual receive function, the business application that sends documents should distribute the documents evenly to all the polling locations. Remember that message queues should be read from local (transacted) queues, not remote queues.

By default, all servers in the group process work items, which involves picking up documents from the Shared Queue (InterchangeSQ) database, processing them, and then sending them out using the transport method designated in messaging ports. After a document is posted to the Shared Queue database, any server in the group can process, serialize, and transport it. Therefore, it is reasonable to consider the scaled-out inbound infrastructure independent of the scaled-out processing infrastructure.

BizTalk Server provides separate thread pools for receiving and processing data. Separating work-item processing from receive functions reduces CPU contention by eliminating the need for the server to alternate between send and receive operations. The level of performance you can achieve by separating these roles depends on the number of documents being processed and the complexity of the data translation. In our performance testing, receiving was significantly more processor-intensive than work-item processing. Receive threads are not necessarily the bottleneck; it may instead be the Work queue threads and the subsequent database access they perform. You should add additional servers to do only Work queue processing.

Separate server groups might be appropriate for high-volume processing, administrative manageability, security partitioning, or grouping related transport services. If you are expecting to process mostly HIPAA documents, you can increase the efficiency of document processing by setting the HIPAA parser to be first in the parser order on the BizTalk Server group.

Using SQL Server

Because the messaging scalability of BizTalk Server is largely dependent upon SQL Server performance, you should plan the SQL Server implementation with future BizTalk Server capacity in mind.

The BizTalk Server–related databases can be installed on a single computer (preferably clustered) running SQL Server, or in high-volume environments, they can be distributed among multiple computers running SQL Server. If you choose to use a single (clustered) system running SQL Server for all BizTalk Server databases, you should install the InterchangeSQ and InterchangeDTA databases on separate disks, each with its own I/O channel to avoid resource contention and maximize performance. The InterchangeSQ database performs many disk reads and writes, because each incoming message is recorded here by a receiving server and then read by a processing server. The InterchangeDTA database experiences frequent writes as message interchanges are logged, meaning that the database grows rapidly and therefore requires processing activity for archiving and purging. You should estimate the average document size for a single transaction and multiply this by the number of expected transactions before the database can be purged to predict the required size of the InterchangeDTA database.

The InterchangeBTM database contains messaging service configuration data, which is generally cached, resulting in less activity in this database. Consequently, the InterchangeBTM database can share a disk with the InterchangeSQ or InterchangeDTA database with little overhead. Depending on the amount of orchestration performed by your application, you might choose to install the XLANG persistence database on its own disk on a central database server or to install an XLANG persistence database on each computer that runs BizTalk Orchestration. You should, at a minimum, install the XLANG persistence database on its own disk channel, because it requires frequent read and write operations.

Using RAID

You can enhance the performance of these databases by using redundant array of independent disks (RAID) disk configurations that rely on hardware caching RAID controllers. In particular, the performance and reliability of the InterchangeSQ and InterchangeDTA databases can be optimized by using a combination of RAID 1 (disk mirroring) and RAID 0 (disk striping).

Clustering SQL Server

To provide the highest level of availability, you should cluster the computers running SQL Server that are used by BizTalk Server. To maximize utilization of the available hardware, you might want to consider using an active/active cluster configuration, in which one node hosts the InterchangeSQ and InterchangeBTM databases, while the other node hosts the InterchangeDTA and XLANG persistence databases. Furthermore, each database should be separated onto its own disk channel (meaning a separate set of disks on separate physical RAID channels on a hardware RAID controller). The following illustration shows an optimized configuration for your SQL Server database cluster.

Figure 11.

**Note   **When planning to use an active/active cluster as shown here, you must ensure that each node is sufficiently specified so that it can handle database processing for all four databases in the event of a failover. If your volume of transactions is extremely high, you should consider using multiple active/passive clusters as needed to optimize the SQL Server performance. For further information, see the Clustering BizTalk Server white paper.

Message Queuing

Microsoft Message Queuing is a supported transport. It is used internally when passing between BizTalk Messaging and BizTalk Orchestration and any time that reliable transactional messaging is required. Like SQL Server, this technology is disk-intensive.

Planning to install the Message Queuing service

The Message Queuing service is a component provided with Windows 2000 Server. However, the service is not installed by default with Windows 2000 Server and must be added to each server that will take part in communication using Message Queuing.

When installing the Message Queuing service, it is important to install a Message Queuing server instead of a dependent client. This allows Message Queuing to store messages locally, and to send and receive messages even when not connected to an Active Directory service providing a queue directory service.

You should avoid using public message queues, because they must query Active Directory. Local queues on BizTalk Server, rather than remote queues, must be used for transactional queues to receive.

Message Queuing message file, message logger, and transaction logger folders can be partitioned across multiple disks by using Control Panel. One way to reduce disk time on heavily loaded drives is to put these files on separate physical disks. If your queues get too big, the memory mapping strategies employed by Message Queuing tend to slow down the entire system. Avoid configurations that result in over 50,000 messages waiting in queues.

Network

The local network can be a performance bottleneck if multiple BizTalk Servers are separated from their SQL Server database. Network utilization might increase depending upon outbound transports and any additional tracking options specified. If XLANG persistence databases are remote, hydration/rehydration activity will also add to network traffic.

The BizTalk Server group in your design is the hub of your BizTalk Server integration solution. As such, it must be configured to provide the required levels of scalability, availability, security, and manageability for a given environment.

Clustering Message Queuing

To provide the highest level of availability for all messages handled by BizTalk Server, you should cluster the systems running Message Queuing. Furthermore, high-volume usage of queues (through receive functions) should be separated onto its own disk channel (meaning a separate set of disks on separate physical RAID channels on a hardware RAID controller). For further information, see the Clustering BizTalk Server white paper.

BizTalk Orchestration

Scaling out BizTalk Orchestration

Perform the following steps to configure a BizTalk Server for Orchestration and a custom service component:

• Install the Cluster service on the BizTalk Servers to provide fault tolerance for the Message Queuing service used for Orchestration in a BizTalk Server group.
• Configure the BizTalk Server used for Orchestration so that it does not participate in the processing of work items. This setting can be configured by using the BizTalk Server Administration tool.
• Make sure that no receive functions in the BizTalk Server group run on this BizTalk Server. This can be verified by using the BizTalk Server Administration tool.
• Create a custom service component that monitors a message queue for a new message added to the queue by the work-item-processing servers. After the message is removed from the queue, the service component will instantiate a designated XLANG schedule. After the instantiation of the XLANG schedule object, the payload of business documents in the message can be passed on to the instance object of the XLANG schedule for further processing.

BizTalk Orchestration schedules tend to reference multiple local resources such as message queues and registered components. For this reason, it is necessary to continue processing a running XLANG schedule on the same computer on which it was instantiated. For highest availability, BizTalk Orchestration servers must be clustered using the Windows 2000 Cluster service in an active/passive configuration. In this way, if the active server fails, the passive server will not lose any messages stored in the message queues. For more information on fault tolerance related to executing XLANG schedules, see the Orchestration white paper.

The XLANG Scheduler performs frequent reads and writes to the XLANG persistence database if Transaction shapes and time-out intervals are used. For scale-out scenarios, the database should have a dedicated disk I/O channel and fast network connectivity between BizTalk Server and SQL Server.

For further Orchestration scale out, install COM+ applications that host XLANG schedules on their own servers, isolating them from other BizTalk Messaging services.

Optimizing XLANG persistence databases

The XLANG Scheduler requires frequent reads and writes to the XLANG persistence database, especially when transactions are implemented and time-out intervals are used. Bottlenecks in the XLANG persistence database can cause low throughput of XLANG schedule instances.

BizTalk Server uses the XLANG persistence database for persisting Orchestration schedules. When designing an application for high demand, the XLANG persistence database needs to reside on a separate disk channel from other databases on the computer running SQL Server. Another recommended design is to place the database on one disk stripe and transaction logs on another disk stripe.

Clustering Orchestration

To provide the highest level of availability for all workflow processed by BizTalk Server, you should cluster the systems running Orchestration. Additional work is required to ensure that no loss of data or workflow state occurs in this clustered environment. Furthermore, the Orchestration schedule itself should reside on a clustered volume. For further information, see the Clustering BizTalk Server white paper.

Reliability, Availability, and Scalability

This section discusses specific architecture changes and additions to implement when your focus is on highly reliable, available, and scalable systems. These system requirements are dictated by four factors:

• Hardware
• Software
• People
• Processes

This guide focuses specifically on hardware and software options for improving the availability of the system. The other two (people and processes) are out of the scope of an architecture guide; for more information you are encouraged to review the Microsoft Operations Framework and other operations best practices for managing data centers.

Any of the alternatives presented here can increase the cost of the solution, and should be weighed against the business cost of the systems in question being unavailable due to a hardware or software fault.

BizTalk Server

Keep in mind that for each of the following scenarios, except where explicitly stated, all servers represented as single systems should be considered as clustered for maximum fault tolerance. For more information, see the Clustering BizTalk Server white paper.

Redundant server group configurations

In a redundant server group configuration, all BizTalk Servers within a group are configured to share the same Shared Queue, Tracking, and BizTalk Messaging Management databases. In this configuration, a document is posted to an ASP page. The ASP page is configured to place documents in a specific message queue that a Message Queuing receive function monitors. The Messaging Queuing receive function submits the document to BizTalk Server where it is placed in the Work queue. The first available server picks up the document from the Work queue and completes processing. This solution enables any server in the group to process the document. The following illustration shows the structure of a group of servers.

Figure 12.

Partitioned or specialized server group configurations

You can configure all servers in the group to share the same Shared Queue, Tracking, and BizTalk Messaging Management databases in this scenario. Configure at least one BizTalk Server specifically to receive documents, usually by using the HTTP transport service. A document arrives in a message queue and is picked up and submitted to BizTalk Server. The BizTalk Server that runs the Message Queuing receive function does not participate in document processing. This results in rapid document submission that helps prevent documents from accumulating in the message queue. BizTalk Servers configured to only receive documents provide the following functionality:

• Decryption, decoding, and digital signature verification
• Parsing and document validation
• Submitting the document to the Work queue for processing on successful submissions or to the Suspended queue for faulty submissions

The other BizTalk Servers in the group are responsible for processing. In this partitioned configuration, the server used to receive documents must be part of a failover cluster to provide fault tolerance. This is because the receiving server is neither functionally replicated nor redundant. The following illustration shows the structure of a group of servers for partitioned processing.

Figure 13.

Scaling out architecture samples

This section describes the "starter" solution, and shows a set of alternatives for scaling the solution. As previously discussed, it is impossible to describe an exact architecture for a certain transaction volume, because so many factors affect the system performance, including the transaction mix (what types of transactions, how many 837 claims per GS segment, how many line items in 837I claims, and so on), the speed of back-end legacy systems (which will impact the response time for eligibility inquiries), and so on. The solution is to start with a system that meets your needs today, and monitor its loads carefully. As the loads increase (due to more providers using the HIPAA format, for example) you will be able to scale out the system.

Basic configuration

The basic recommended configuration for a reliable and scalable BizTalk Accelerator for HIPAA solution is a four-server system: BizTalk Messaging on one server, and SQL Server running on the other server. Each of these servers should also have a clustered server installed for redundancy. In a small deployment, BizTalk Orchestration could run on the BizTalk Messaging server; however this configuration is difficult to scale. It is recommended that Orchestration should run on a different server than BizTalk Messaging. This configuration can grow as transaction volumes increase, as shown in the following diagrams.

In the first configuration, a scalable BizTalk Server system has been started. The BizTalk Server and SQL Server applications are loaded on separate servers. This improves both performance and maintainability, and will allow scaling without reconfiguration later. Note that all of the BizTalk Server data is stored on a single SQL Server computer. The locations of the individual databases should consider the earlier comments on database location and drive design, if it is expected that transaction volumes will grow. SQL Server transaction logs should also be separated from the database disk device for ease of recovery in the event of a disk failure.

Figure 14.

Scaling out: separating processing and receiving

The second configuration splits apart the receive function from the far less processor-intensive Work queue processing. This will improve performance somewhat (because the server is not continually context switching), but its biggest benefit is that it sets up the future scale-out of the receiving servers. In our testing, SQL Server does not become a bottleneck at this point, so only a single SQL Server computer is necessary for scaling. The guidelines presented for separating InterchangeDTA and InterchangeSQ databases onto separate disk devices should be followed.

Figure 15.

Volumes increase: clustering and load balancing

As inbound traffic increases, the first major scale-out hurdle is reached. The large, multiprocessor BizTalk Server that processes files has become fully loaded, with peak processor utilization nearing 90%. At this point it will be necessary to build out multiple BizTalk Servers to process the files. The third configuration shows the next architectural step. Additional processing servers have been added. All of the BizTalk Servers should still exist in a single server group.

On the database side, the InterchangeSQ Work queue (which was moved to a separate disk in the previous configuration) is moved to a separate SQL Server from InterchangeDTA. This retains a single Work queue for more effective processing server load balancing. The BizTalk Server configuration database, InterchangeBTM, can reside on either server because it is typically read and cached.

In this example the two SQL Servers have been clustered to improve availability as well as scalability. The servers should be sized to be able to support the full transaction load on a single server in case of failover. For more information, see the Clustering BizTalk Server white paper.

Figure 16.

Building the data center: network load balancing

In the fourth configuration the receive functions have been distributed across several BizTalk Servers. Additional BizTalk Servers handle processing, performing automatic load balancing by virtue of the single shared Work queue. The SQL Server cluster handles all of the queue reads and writes.

Figure 17.

To scale out this fourth configuration further would require additional receiving and processing servers. While the ratio shown is one receiving server to two processing servers, the exact balance will be different for every situation.

As load increases on the SQL Server computers, they would need to be scaled up with additional processors and memory as well as improved disk controllers and RAID chassis to manage the disk I/O. A Storage Area Network (SAN) should be considered if the SQL Server RAID arrays are becoming saturated.

Security

Security considerations for a BizTalk Accelerator for HIPAA solution fall into two categories: industry-specific security standards and generic security recommendations for Microsoft systems. While this section does not attempt to address all the aspects of The United States Department of Health and Human Resources provides information about HIPAA security requirements that have been proposed, but not finalized. You can find this information in the Security Standards section of the U.S. Department of Health and Human Services page on Privacy and Security. In addition, the Center for Medicaid and Medicare Services (CMS, formerly HCFA) Internet Security Policy contains vital information on the new security standards soon to be implemented. Documented below are some general guidelines for implementing security for Microsoft systems based on these resources.

Industry-specific standards

In addressing security, the first step is to be sure that any legally binding standards are integrated into the security planning and implementation processes. The HIPAA and CMS policies are presented here in a structured manner to quickly convey the necessary information. The discussion includes:

• What must be protected
• Requirements
• Methods for addressing the requirements

Open-ended consideration must be extended to state and local laws that apply to health-related information. HIPAA statutes are meant to work in conjunction with other guidelines for protecting sensitive health-related information.

Considerations

The information provided here is not intended to deliver a HIPAA-compliant solution. It is merely intended to provide some good starting points and help to underscore the importance of a structured and comprehensive approach to security. Microsoft Consulting Services provides services that are designed to assist in devising security strategies from both a general and an industry perspective.

The CMS Internet Security Policy can be regarded as a subset of HIPAA requirements. Organizations using this policy as the basis of their security planning should also consider HIPAA requirements even though the security standard has not yet been finalized. No security plan alone is adequate without procedural and policy elements. These are addressed partly by physical and administrative safeguards. They are also addressed by aspects of the planning process itself. The most important aspects of the security plan are documentation and reassessment.

Having a documented security plan is a fundamental HIPAA concept. Not only must the planning process be undertaken, but also there must be written evidence of the audit process, threat evaluation, and mitigation strategy that are key components of the plan. This process must be repeated at regular intervals to probe for newly emerging threats and for changing standards, and to incorporate newer technologies as they evolve.

HIPAA security standard

The Health Insurance Portability and Accountability Act provides for several levels of safeguards to protect sensitive information from threats. These include administrative, physical, and technical safeguards. Technical safeguards most directly relate to the use of technology to mitigate security threats. The scope of this section focuses on technical safeguards.

Protected information

The HIPAA Security Standard is applicable to any health information pertaining to an individual that is electronically maintained or transmitted.

Requirements

The following list shows the HIPAA technical security requirements. The requirements are followed by features that are articulated in the text of the proposed rule as critical in satisfying them.

• Access control. Allowing access only to privileged entities and allowing access only to the minimum necessary information.
  • Procedure for emergency access.
  • Context-based access, role-based access, or user-based access
  • Optional use of encryption
• Audit control. Recording and examining system activity to facilitate analysis of threats and weaknesses and periodic reassessment.
• Authorization control. Obtaining consent for the use and disclosure of health information
  • Role-based access
  • User-based access
  • Context-based
• Data authentication. Corroboration that data has not been altered or destroyed in an unauthorized manner. Examples include the use of a checksum, double keying, a message authentication code, or a digital signature
• Entity authentication. Corroboration that an entity is who it claims to be.
  • Automatic log off
  • Unique user identification
  • Biometric identification system, password system, personal identification number, telephone callback, or token system that uses a physical device for user identification
• Technical security mechanisms. Guarding against unauthorized access to data that is transmitted over a communications network.
  • Integrity controls
  • Message authentication
  • Access controls or encryption (required over non-private networks)
  • Security features for network communication of protected data
  • Alarm
  • Audit trail
  • Event reporting

Methods

This section addresses products or strategies that might be used to meet specific security requirements.

• Access control. All these requirements can be fully satisfied by implementing user names and passwords for all users as illustrated by the small office example in the HIPAA text.
  • A procedure for emergency access can be implemented by granting more than one person full control of protected data.
  • Context-based access, role-based access, and user-based access can all be addressed by Active Directory or Windows-based security using users, groups, domains, organizational units, forests, trees, policies, and trusts. A mix of these mechanisms can be used to provide very robust and granular security. Component Services (COM+) in the Windows 2000 server operating systems also allows applications themselves to map different levels of users and groups of users to roles. Many Microsoft applications such as SQL Server provide similar capabilities outside of Windows-based authentication.
  • Encryption can be achieved at many levels. Application data and files can be stored using the Encrypted File System (EFS). Transmitted data can be encrypted by using a variety of public key or private key encryption mechanisms. Examples of this include the Kerberos authentication protocol, Secure Sockets Layer (SSL), and secure Remote Procedure Call (RPC). In addition, CryptoAPI allows solution developers to add cryptography-based security to their applications.
• Audit control. The recording and examining of system activity can be achieved by using audit policies when using Windows-based security. The Windows operating system provides the ability to audit a variety of system and security events—logon, logoff, directory access, access to resources such as files, and so on. The level of auditing is controlled through Policy Management Consoles. Microsoft SQL Server and the Web Storage System can also be configured to capture and log relevant events. In addition, solution developers can leverage the Event Tracing API to log application-specific events.
• Authorization control. Obtaining consent for the use and disclosure of health information is more than a technical security issue. There are procedural considerations for consent. One popular model for informed consent is called the Transparency Model in which all aspects and implications of care are rendered transparent to the patient. In any situation, obtaining consent for care implies the ability to access medical information. It is recommended to include confirmation of consent for access to patient information as part of the administrative process used to confirm consent to care. At that point, provisioning processes can be used to determine which entities and what type of information can be accessed. In this way, the complexities of necessary sharing of patient information with other medical personnel, billing departments, and so on can all be managed within the framework of other HIPAA security requirements from the first instant the patient information is used.
  • Role-based access and user-based access can be achieved by coupling the ability to determine and enforce the level of information required by a particular role, such as a physician or billing role, with provisioning/administrative processes that map the users of the patient information to their roles. Role-based access can be enforced by using Windows operating system security, Component Services, and individual applications such as SQL Server. Complex provisioning scenarios between standards-based and non-standards-based directories can be facilitated by Windows interoperability tools such as Microsoft Metadirectory Services, Services for Unix, and Microsoft Directory Synchronization Services.
• Data authentication. Corroboration that data has not been altered or destroyed in an unauthorized manner can be achieved by using digital signatures (in the form of message digests). For secure Web communications, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are standard protocols that ensure message integrity. Both Internet Explorer 5 and Internet Information Services (IIS) support digital signatures through the use of SSL and TLS. Microsoft Exchange Server and Microsoft Outlook support digital signatures through the use of the secure MIME (S/MIME) protocol.
• Entity authentication. Corroboration that an entity is who it claims to be can be addressed from several different levels. There is considerable flexibility in what features are required and a similar level of flexibility in the tools available to address those features. Of notable importance here, again, is the need for the integration of administrative processes to ensure the security of the entity provisioning and management process.
  • Automatic log off can be achieved by using the functionality of Internet Explorer and Internet Information Services to accomplish automatic log off. Time-sensitive cookies can be distributed to force clients to sign on after some period of time. Traditional applications can utilize the functionality of the Microsoft Win32® API to log off from the system. It is also possible to customize the Kerberos Service Ticket policy to force Kerberos sessions to be renewed.
  • Unique user identification is supported in several ways using Windows 2000 and Windows XP. The Windows 2000 operating system authentication system is based on the concept of individual user accounts identified by unique user names. Unique identifiers can exist within Windows domains, at the operating system level or within individual applications such as SQL Server. The Windows platform also supports the use of digital certificates that can be mapped to users within Active Directory. This is made even more powerful with the Microsoft Certificate Server, which can be used to create and manage a certificate authority that can be integrated into Windows security features.
  • Biometric identification is supported by custom programming and customizable objects and user attributes. Biometric authentication might be supported natively in coming Windows releases. Windows 2000 user account passwords are supported as a default part of Windows Authentication. They are subject to granular constraints and control via policies and user properties sheets. Windows supports Smart Cards. Personal identification numbers are supported both in place of passwords and accompanying digital certificates when using Smart Cards. Telephone callback policies are supported in Windows Routing and Remote Access technologies including ISA Server.
• Technical security mechanisms. Technical security mechanisms that protect network communications are also required by HIPAA regulations. The text of the rule indicates the necessity for documenting the approaches chosen to protect information transmitted by using network communications.
  • Integrity controls protect data on the network. Digital signatures (in the form of message digests) can ensure the integrity of data that has been transmitted over a network. For secure Web communications, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are standard protocols that ensure message integrity. Both Internet Explorer 5 and Internet Information Services (IIS) support digital signatures through the use of SSL and TLS. Exchange Server and Outlook also support digital signatures through the use of the S/MIME protocol. Layer Two Tunneling Protocol (L2TP) and Point-to-Point Tunneling Protocol (PPTP) protect the integrity of communications by creating a secure tunnel between devices on the network. Internet Protocol Security (IPSec) also tunnels all network communications over several TCP/IP ports.
  • Assurance of message authenticity can be achieved with digital signatures in the form of message digests. These ensure the integrity of data that has been transmitted over a network. Exchange Server and Outlook also support digital signatures through the use of the S/MIME protocol.
  • Access controls or encryption (required over non-private networks). See the earlier section on access controls.
  • Alarms. Windows security and the Windows operating system provide the ability to trigger application and system events in response to very granular levels of conditions and occurrences. Many applications such as ISA Server and Exchange Server provide alarm features that enable events and notifications. Specialized products including Microsoft Operations Manager, Microsoft Application Center and Health Monitor provide the ability to capture system events, react to them with custom scripts or custom events, and send notifications via e-mail. These products provide the ability to monitor events, performance thresholds, and virtually any Windows Management Instrumentation (WMI) interface that exists. Along with the existing policy management and alarm features of the Windows platform, these constitute a full-featured approach to implementing alarms.
  • Audit trail. The Windows operating system provides the ability to audit a variety of system and security events. The level of auditing is controlled by security policies that vary in scope from specific objects to entire domains. Microsoft SQL Server and the Web Storage System can also be configured to capture and log relevant events. Solution developers have the ability to leverage the Event Tracing API to log application-specific events. Maintaining the audit trail can be accomplished with a variety of off-the-shelf applications and custom tools. Microsoft Operations Manager, Health Monitor, and Application Center provide the ability to forward events by e-mail or by using custom scripts. Operations Manager is specifically designed to do event consolidation.
  • Entity authentication. The Windows authentication system is based on the concept of individual user accounts identified by a unique user name or ID. This is strengthened with the Kerberos v5 support in Active Directory as a part of Windows 2000 and later. In addition, the Windows platform supports digital certificates and Certificate Server. Certificate Server allows an organization to become its own root certificate authority or to utilize external root authorities to integrate digital certificates into Windows security, including the Kerberos features of Active Directory.
  • Event reporting. The audit and alarm capabilities of the Windows platform are rounded out by applications and other custom tools for reporting on security and other events in the enterprise. Microsoft Operations Manager is specifically designed to aggregate and report in enterprise-wide events. Other tools such as Health Monitor, Application Center, and custom tools using Windows Management Instrumentation can be used to forward events to a database, an e-mail account, or other information store. Reporting on the information can then be accomplished by further customizing the solution.

CMS Internet Security Policy

The CMS Internet Security Policy is designed to address the use of the Internet for the communication of patient-related information. The following sections address the Internet policy in the context of the HIPAA requirements articulated in the preceding section.

Protected information

The CMS Internet Security Policy regards the scope of protected information to include data, which, if disclosed, could result in harm to the agency or to individual persons. Examples include:

• Individually identifiable data held in systems of records, automated systems of records subject to the Privacy Act and subject to Exemption 6 of the Freedom of Information Act. Such information, if disclosed without authorization, would constitute a clearly unwarranted invasion of personal privacy.
• Payment information that is used to authorize or make cash payments to individuals or organizations. These include benefits information, such as that found at the Social Security Administration (SSA), and payroll information. Such information also includes databases that the user has the authority and capability to use and/or alter.
• Proprietary information that has value in and of itself and which must be protected from unauthorized disclosure.
• Computerized correspondence and documents that are considered highly sensitive and/or critical to an organization and which must be protected from unauthorized alteration and/or premature disclosure.

Requirements

The CMS requirements are articulated in the context of business processes that rely upon the Internet for functionality. Though this policy is intended to cover systems or processes that use the Internet, those that interface with the Internet in order to transmit HCFA Privacy Act-protected and/or other sensitive HCFA information are covered also. This is inclusive of Virtual Private Network (VPN) and tunneling implementations over the Internet but specific to the use of these technologies to transmit data. The requirements are as follows:

• HCFA Privacy Act-protected and/or other sensitive HCFA information sent over the Internet must be accessed only by authorized parties.
• Technologies that allow users to prove that they are who they say they are (authentication or identification) and the organized scrambling of data (encryption) to avoid inappropriate disclosure or modification must be used to ensure that data travels safely over the Internet and is disclosed only to authorized parties.
• Encryption must be at a sufficient level of security to protect against the cipher being readily broken and the data compromised.
• The length of the key and the quality of the encryption framework and algorithm must be increased over time as new weaknesses are discovered and processing power increases.
• Passwords may be sent over the Internet only when encrypted.
• A complete Internet communications implementation must include adequate encryption, employment of authentication or identification of communications partners, and a management scheme to incorporate effective password/key management systems.
• Organizations desiring to use the Internet for transmittal of HCFA Privacy Act-protected and/or other sensitive HCFA information must notify HCFA of their intent. The following information must be submitted to internetsecurity@hcfa.gov: organization name, organization address, type/nature of information being transmitted, name of company official to contact, telephone number and e-mail address for the contact.

Methods

The following section addresses the features and requirements with products or strategies.

Levels of encryption. Symmetric encryption must be at or above Triple 56 bit DES (defined as 112 bit equivalent). Asymmetric systems must be at or above 1024 bit level algorithms. Elliptical Curve systems must be at or above 160 bits. The Windows encryption capabilities offer the ability to meet encryption-level standards.

Hardware-based encryption. Hardware-based encryption is available from third-party vendors. An added benefit to hardware-based encryption is that it can offload the encryption workload from the operating system. However, this usually comes as an expense to trading partners and is less flexible than using data encryption standards defined and used over the Internet.

Software-based encryption.

• Secure Sockets Layer (SSL)—sometimes referred to as Transport Layer Security (TLS)—implementations. The Windows platform supports encryption using SSL.
• S/MIME. Microsoft Exchange Server supports the use of S/MIME.
• In-stream. The Microsoft CryptoAPI provides the capability of developing in-stream encryption.
• Offline. The Windows operating system provides the ability to encrypt files and folders.

Acceptable authentication approaches.

• Formal certificate authority-based use of digital certificates is acceptable. Microsoft Certificate Server offers flexibility in creating a root certificate authority and integrating external roots into Windows platform security features. Externally issued certificates can also be used without Certificate Server.
• Locally-managed digital certificates are acceptable, providing all parties to the communication are covered by the certificates. Microsoft Certificate Server offers flexibility in creating a root certificate authority and integrating external roots into Windows platform security features. Externally issued certificates can also be used without Certificate Server.
• Self-authentication, as in internal control of symmetric private keys, is acceptable. Windows supports self-authentication.
• Tokens or smart cards are acceptable for authentication. In-band tokens involve overall network control of the token database for all parties. The Windows platform supports smart cards.

Acceptable identification approaches.

• Telephonic identification of users and/or password exchange is acceptable. This is an administrative level of identification.
• Exchange of passwords and identities by U.S. Certified Mail is acceptable. This is an administrative level of identification.
• Exchange of passwords and identities by bonded messenger is acceptable. This is an administration level of identification.
• Direct personal contact exchange of passwords and identities between users is acceptable. This is an administrative level of identification.
• Tokens or smart cards are acceptable for identification. Out-of-band tokens involve local control of the token databases with the local authenticated server vouching for specific local users. Smart cards support is also a feature of Windows platform security.

General security recommendations

This discussion of security supplements existing information dealing with the security of generic Microsoft systems, can be found at Security Best Practices.

These recommendations cover most aspects of system deployment and security, including but not limited to monitoring, threat assessment, network-level security, patching, and configuration management.

Security in the context of the HIPAA architecture will come from the following areas:

• Network infrastructure hosting the services
• Authentication infrastructure for the components
• Configuration of the computers in the architecture
• Monitoring processes in the architecture

The network and authentication infrastructures are the domain of the architecture itself. Computer configuration is equally divided between operational and architecture scopes. Monitoring processes are almost entirely focused on the operational aspects of the system. In this guide we are focused on the architectural best practices that are associated with the infrastructure and the architectural implications of configuration management for the systems hosting functionality in the HIPAA topology.

The changing nature of the configuration best practices (for example, which patches to apply for which vulnerabilities) is a moving target, and not specifically related to the architecture of the system, so we will not cover that in depth here. Instead we will refer you to the documented best practices available at the time that you assemble the various servers in your topology.

This guide assumes that you are already familiar with the components involved in the HIPAA system. For more information about the various system components, see the Logical Design Considerations section of this guide.

Securing the network in the solution

Establishing network zones based on value of data being processed

The HIPAA solution consists of several discrete zones, differentiated by the audience—the people that will access the components in the zone—and the sensitivity of the data that is stored or queued in the zone. By compartmentalizing the solution components into several network zones, additional security can be introduced into the overall architecture. This security comes from the incorporation of additional firewalls and the corresponding capability to direct or drop traffic from more discretely identified hosts, and from the ability to segment the architecture logically so that configuration management can be more easily performed against computers commensurate with the value of the data that they have access to or contain.

A well-zoned architecture allows an administrator to segment the hosts for the service into (potentially) differing security levels. Establishment of several network zones also allows the audience for access to each type of host to be distinguished and a consequent value assessment of "how much money should be spent to secure the host" to occur. The resulting architecture for a HIPAA implementation will look like the following:

Figure 18.

There may be variations on this topology based on the customer's specific requirements, but in all cases these variations should augment and not compress the architecture above.

Understanding audiences for each of the zones

Establishing an audience profile for each network zone will facilitate the determination of the amount of time and resources that need to be allocated to securing the zone, through an evaluation of the value of the data that is in the zone or is being accessed through the zone. This process is analogous to the development of a threat profile for a group of systems (the computers that reside in the zone). More information on the assessment of threats is available at Microsoft Technet's Security Threats Web page.

The Web server array in the HIPAA solution will be protected against the threat of an attack commensurate with the people that are going to be accessing the system. Threats could come from several possible audiences in this scenario. Among these threats are:

• The generic threat from anyone that might not expressly be targeting the HIPAA implementation, but is targeting all systems.
• A potential threat directed at using the submitted treatment information to diagnose the nature of the patients' symptoms.
• A more serious threat dealing with fraudulent submissions to insurance payers.

The first two areas of threat can be eliminated on the HTTP submission by SSL-enabling the session. While this does not protect against an internal attack on either the submitter or the receiver, it does rule out a man-in-the-middle attack that could gain access to the data in transit. When considering the FTP transmission channel, the only way to secure the transmission is through the establishment of a virtual private network (VPN) connection between submitter and receiver or through the use of secure shell-enabled FTP. In either case, this would entail the deployment of a VPN-capable system or secure shell-enabled FTP client/server at each potential submitter and, of course, the receiver.

Securing the data in the transaction

As of this writing the government had not ratified a standard for the protection of the data in transit between the various payers and claim submitters. When this standard becomes available and is implemented in HIPAA solutions, the data that is submitted in the EDI transaction will be more impervious to attack when in transit and while at the submitter and receiver.

Until these standards become ratified, use public/private key encryption techniques for secure messaging to construct a public key certificate standard (PKCS) #7 message containing the EDI data format to a specific payer. (This standard for cryptographic message syntax is defined in RFC 2315.) The message can in turn be opened by the payer and submitted into the BizTalk Server receive function by Web servers at the payer's location. Any implementation such as the one described in the previous sections might or might not align with the government standard for data encryption, and most likely will not be based on the ratified certificate authority infrastructure. However, there are solutions available today for organizations that are concerned about this threat and are not willing to wait for a ratified standard to be available. These solutions take the form of the CAPICOM extensions to the CryptoAPI services already shipping in Windows 2000 and the capability for the BizTalk Server channel to be encrypted with S/MIME.

In either case, the system is producing a PKCS #7 message. This is configured on the BizTalk Server messaging port using the File protocol by configuring inbound and outbound files to be encrypted with an S/MIME signature set. CAPICOM is a new security technology from Microsoft that allows Visual Basic, Visual Basic Scripting Edition (VBScript), ASP, and C++ programmers to easily perform the following tasks:

• Sign data using PKCS #7
• Verify digital signatures including revocation checking
• Encrypt data with a password
• Encrypt data using certificates (like PGP)
• Manage certificate stores

Monitoring, auditing, and intrusion detection systems and their importance

In any public service implementation, monitoring, auditing, and intrusion detection are extremely important. Monitoring and Auditing for End Systems discusses this topic.

Monitoring that is specific to the HIPAA implementation will consist of the standard intrusion detection and systems/privilege use auditing that should occur on all systems, with the addition of specific scenarios that might indicate a pointed attack from the threat sources identified earlier. Develop intrusion detection profiles for the system. These intrusion detection profiles will vary based on the type of transaction and the systems that are being monitored and based on the organization that is deploying Accelerator for HIPAA. In any case, monitor systems for attacks that originate both internally and externally, specifically in the case of the highly valued data stored in work queues for BizTalk Messaging servers, Message Queuing servers, and legacy systems databases that are in the architecture.

Further monitoring, auditing, and intrusion detection processes are beyond the scope of this guide and are more tailored to the individual customer implementation. Recommendations will be forthcoming on operational recommendations for the HIPAA architecture in the Microsoft BizTalk Accelerator for HIPAA Operations Guide

Authentication infrastructures

While not expressly specified as part of the solution, the use of only authenticated sessions will drastically reduce potential threats to the system. One of the easiest ways to eliminate the ability of would-be hackers to access system components is to permit only authenticated connections. However, the HIPAA solution consists of several different audiences that might not be easily grouped into internal security principles. Following is a prescriptive view of the application of the various authentication methods in the system.

Figure 19.

Legacy system authentication

In this topology, legacy authentication consists of the user/password combinations that are and have been in use on the legacy systems for some time. These systems are quite removed from an external threat because several secure network zones shield them. However, they are still susceptible to an internal threat directed against the data stored in legacy databases or the communications channel from the processing systems to the legacy databases.

Depending on the legacy systems in question there might or might not be technical alternatives for closing these security holes. In the case that the systems can support technologies such as Kerberos authentication, cross-realm trusts should be created between the Windows 2000 topology and the legacy topology. Name-mapping systems should be implemented (using Microsoft Windows Services for UNIX 2.0) to facilitate the creation of security principles in the legacy system for incoming connections from the Windows 2000 architecture. In the case that there is no support for technologies such as Kerberos, increased monitoring (both of the technical system and of the people with rights on the system) might be necessary to detect a breach, and the legacy credentials will continue to be used.

There is no substitute for knowing your employees, and specifically the administrators of the system. This is especially true when the data that they deal with on a daily basis is as valuable as the data in your HIPAA implementation. Auditing activities is not always enough to detect the breach of an administrative user on the system. Administrators perform many tasks that are legitimate, and due to the large number of tasks performed, the one or two tasks that are not legitimate might go undetected. Therefore, an organization should always take a common-sense interest in technical irregularities or any other suspicious behavior among the administrative staff.

Authentication with internally managed security principles

In the case of the Microsoft-based HIPAA components, all of the authentication that is taking place already uses Windows 2000 credentials or—in the case of a BizTalk Server embedded SQL database configured as a messaging queue—credentials that are managed in the SQL database. These authentications are happening between COM components that are hosted in the BizTalk processing servers as well as the Message Queuing servers and SQL Servers that are functioning as the work queue for the processing activities.

An important note about these credentials is that they should be discrete enough to prevent privilege elevation in the case that a computer becomes exploited. This means that the credentials with which connections are made between these various components need to have only the essential rights required for the operation that they perform and no more. Do not run these processes under a "local system" or "administrative" security context; doing so is simply asking for problems. For example, if these processes are being run under local system, an administrator or someone exploiting a potential flaw in the process could take control of the account. Using this account context would make it nearly impossible to discretely identify the perpetrator of an attack; all of the activities would show up as "local system" requests. Running these processes with unnecessarily elevated privileges also makes the logging of component-level connection and execution activity nearly impossible. All of this activity should be logged by configuring the host system's group policy to audit events such as those shown in the following illustration:

Figure 20.

The resulting security event logs from all systems that are hosting services should be scrutinized to detect the context of a component being used as a tool in an attack and to detect a possible privilege elevation by a lower security process.

Authentication with internally managed security principles or public principles

It is possible that in the future the government will mandate a central agency for the distribution of identities (likely in the form of certificates) to claim filers and payers. However, such an infrastructure is not currently available from any government agency. If you wish to maintain authenticated sessions on your externally facing Web portal, you will need to manage accounts for the potential claim submitters, accept anonymous connections, or use a public principle (for example, Microsoft Passport) to identify the claimant.

If you decide to define security principles for claimant organizations, you can do so by generating SSL client authentication certificates for those organizations. These certificates can in turn be mapped on user account contexts in your organization's Active Directory®. You can then audit and authenticate incoming requests from the claimant organizations based on the credentials presented and their association with Active Directory security principles.

The primary downside of this approach is the (potentially) large amount of management effort that might be necessary for activities such as handling lost IDs or certificates and re-enrolling certificates. Additional downside might be the assumption of some degree of liability if the ID issued to the trading partner was used in a fraudulent manner against another trading partner or claims processor. While the risk can be mitigated by requiring a legal disclaimer before using the system, this issue coupled with the additional management overhead might be a deterrent.

For details about the process for mapping SSL client authentication certificates, see Step-by-Step Guide to Mapping Certificates to User Accounts.

Securing the Server Configurations in the Solution

Server configuration management is one of the most important steps in making sure that the core systems themselves cannot be used to exploit other areas of the architecture or to compromise the data. The following sections outline the general areas of policy that could be applied in the segmented network architecture shown in the following illustration.

Figure 21.

Segmented policy methodology

The idea behind segmenting policy for the various zones is to achieve economies of scale for administrative efforts while at the same time ensuring that the computers in a particular zone are secure against the most likely sources of attack. In the preceding illustration, five scoped policies are being applied to various computers in the topology, as follows:

• Array policy for trusted firewalls. This policy assumes that external hostile attacks have been stopped at a lower level of the topology. These policies are focused on the protection of the sensitive data in the production perimeter network (also known as DMZ or demilitarized zone) from internal threat and are constructed to allow source and destination traffic between legacy systems and the BizTalk Server processing servers in the production perimeter network.
• Group policy applied to the production perimeter network. These configuration options harden the systems in the production perimeter network against intrusion from both inside and outside the organization. An example of a policy that would be in effect at this level of the architecture is the application of IPSEC to the interfaces of the production systems.
• Array policy for moderately trusted firewalls. This policy is defined to prevent access to the systems from internal and external threats. Specifically, only traffic from the production Web servers to the BizTalk Parsing and Validation servers should be allowed. For return communications the Message Queuing servers that are part of the architecture will need to return data to the Web servers based on initial requests.
• Group policy for Web publishing servers. This policy is centered on the enforcement of the latest patches on the servers hosting the external Web presence for the solution.
• Array policy for untrusted firewalls. This policy is directed at dropping traffic from unauthorized external users of the system.

Components of the solution

Various server components are installed as part of this solution. They include:

• IIS servers
• BizTalk Messaging servers
• Servers running SQL Server
• BizTalk Orchestration servers
• Message Queuing servers

Details about the actual configuration of the servers in question are not within the scope of this guide; however there are some basic best practices that can be applied to the externally facing servers:

• Only run the essential services on the computer. An example of this policy in action would be disabling end-user-facing services (such as content indexing) if the server is directed at serving specific Web content only.
• Develop a patching regimen to prevent the essential services from becoming vulnerable to attack from known exploits. It should go without saying that the systems should always be running the latest Service Pack, or be appropriately patched to coincide with your organization's change management policies.
• Maintain encrypted connections wherever possible on internal host networks.
• Keep internal and external network interfaces segmented. Do not connect with administrative credentials on external networks or on network interfaces without VPN protection.
• Maintain auditing and monitoring operations commensurate with the data being hosted or the liability introduced due to an attack.
• Maintain source and destination filters on moderately trusted and trusted firewalls to prevent unauthorized connections and connections on unauthorized protocols.
• Log all network traffic possible. While this does not prevent an attack, it can be extremely valuable in the assessment of damage incurred as a result of the attack.
• Strive to have all connections to systems authenticated with as strong a credential as possible. This will ensure that the logs reflect the activity and the parties conducting activity on the systems.

You can find examples of specific recommendations for server hardening and the patches necessary for application to the specific types of servers in the topology from the National Security Agency (NSA). Microsoft does not warrant these guides, but they provide a good starting point for the hardening efforts on servers deployed in conjunction with this architecture. Other information about patches, security hotfixes, and tools is available on the Security page at Microsoft TechNet.

Appendices

Appendix 1: Transaction Cost Analysis Testing Methodology

This section is a how-to guide for establishing performance scenarios and a test environment for a custom solution based on Microsoft® BizTalk® Accelerator for HIPAA. This section reflects best practices derived from experiences of Microsoft Consulting Services. As you read this document, note that many of the terms used here are defined in the glossary of the BizTalk Accelerator for HIPAA documentation.

General guidelines for performance testing

The primary goal of performance testing is to provide an empirical basis for making decisions in a capacity planning strategy. To reach that goal, testers need to establish a performance baseline around a specific document type or types, make incremental changes around that baseline, and then measure and analyze the effects of the changes. The following are guidelines for executing a structured performance testing methodology:

Steps in performance testing

1. Build the hardware configuration

   The key objective should be to test in the lab as close as possible to what you will be using in production. If you plan to run everything on one production server, then get a second dedicated testing server of the same class/configuration. If you plan on separating SQL Server onto a separate machine (or machines) in production, then have two or more machines in the test lab. Mimic the processor speed/count, memory, disk subsystem, and other attributes of the system in your test environment. If this seems too expensive (justifying the costs of an additional server), then it is likely that more work must be done to provide the business requirements/need for these tests. By the time you begin a test plan the business need for the data should be sufficient to drive the additional hardware costs. Most will try to cut costs here and go with a desktop system or cheaper shared resource server, and our recommendation is that if this is the scenario you find yourself in, stop all work on developing this test plan. Work on developing a business case for this work and the systems that are required first. It cannot be understated how important "apples to apples" comparisons are. Simply put, if the machine count and configuration in the test lab do not match the machine count and configuration in production, then your tests and all of the data from them will be effectively meaningless for purposes of capacity planning.

2. Build the software configuration

   The software configuration in the lab should also mimic the configuration in production. During your configuration of the test environment, match as closely as possible the production placement and configuration of: Message Queuing service, Cluster service, SQL Server services, BizTalk Server services, BizTalk receive functions, XLANG schedules, Web services, COM objects, and any other services that make up your solution. Again, if the software configuration in the test lab does not match the software configuration in production, then your tests and all of the data from them will be effectively meaningless for purposes of capacity planning.

3. Before testing, gather test data and configure BizTalk Server

   • Choose your sample data

     For example, you will need real data from an 837I or 837P, a 270, and so on. Where possible, use actual transmitted data with identifying information removed. (Favor realism wherever possible in the tests.) For a sample file to get you started, use the 837I.txt file located in C:\program files\Microsoft BizTalk Accelerator for HIPAA\Samples\Claims Processing\TestData (if you used the C drive to install the BizTalk Accelerator for HIPAA product).

   • Configure BizTalk Server

     See the following setup instruction tables for information about a sample set of objects that could be used with the sample 837I document above. If you have questions about using or configuring BizTalk Server, see the Learning BizTalk Server 2000 lessons.

You must set up the BizTalk organizations for this sample test. In the sample test, using the preceding sample data, the first organization is the home organization (Our HealthPlan), who is the payer. The second organization is the health care provider business partner (Contoso Health Partners). Each of these must include the ISA segment for identification in order for BizTalk Server to process message exchanges.

Configuration steps

Note that the following steps can be automated by using the VBScript code fragment in the Automated Configuration of Your Test Lab section that follows these instructions. The organization names, channels, receive functions, and so on are identical.

1. Create the BizTalk organizations

   Use BizTalk Messaging Manager to create the BizTalk organizations (health care business partners).

2. Review and store the BizTalk schemas

   Use BizTalk Editor to load the custom payer schema to the WebDAV repository. Then use a standard HIPAA template to store an 837 Institutional schema to the WebDAV repository.

3. Create document definitions

   Use BizTalk Messaging Manager to define a BizTalk document definition for each schema.

4. Create BizTalk Messaging ports and channels

   Use BizTalk Messaging Manager to configure the port and channel to process the EDI message.

5. Create a BizTalk receive function

   Use BizTalk Server Administration to create a receive function that picks up the incoming EDI document to process.

6. Put it all together

   Test your work by dropping the EDI 837I instance document into the receive directory.

7. Start testing

   Disable the File receive function, and then populate the directory that the receive function is on with many copies of the file to be tested.

   Enable performance logging and then re-enable the File receive function.

   Run the test for a set amount of time (10 to 30 minutes or longer), and stop the performance log.

8. Analyze the data

   Use the System Monitor data to catalog and analyze trends and detect bottlenecks.

The following tables provide detailed tasks for each of the preceding sample configuration steps.

Step 1—Create the BizTalk organizations

Step 2—Review and store the BizTalk schemas

Step 3—Create document definitions

Step 4—Create BizTalk Messaging ports and channels

Step 5—Create a BizTalk receive function for EDI

Step 6—Put it all together

Step 7—Start testing

Dim filepath
Dim filename
Dim extension
Dim destinationpath
Dim clonecount
Dim count
Dim oFileSystem, oFolder, oFolders
Set oFileSystem = CreateObject("Scripting.FileSystemObject")
filepath = "c:\Program Files\Microsoft 
  BizTalk Accelerator for HIPAA\Samples\Claims 
  Processing\TestData\"
destinationpath = "C:\LabData\Our HealthPlan 
  (HOME)\EDIInput\"
filename = "837I"
extension = ".txt"
'This setting will create 1000 files
clonecount = 1000
count = 0
Do While Not count > clonecount - 1
    count = count + 1
    oFileSystem.CopyFile filepath & filename & 
      extension, destinationpath & filename 
        & "_" & count & 
  extension
Loop
Set oFileSystem = Nothing

Step 8—Analyze the data

What to measure

Some of the counters that should be monitored using Performance Logging are:

Automated configuration of your test lab

' Copyright (c) 2001 Microsoft Corporation. All rights reserved.
' Script to create all messaging objects related to a simple 
  performance test
' Works only with default configuration (not clustered), when group 
   name is "BizTalk Server Group" and is executed on the server. 
   Do not run this on a clustered server without taking into 
   consideration disk drive letter and server name changes. You will 
   need to use the cluster name and not the programmatically 
   derived server name.

dim strDrvLetter
strDrvLetter = GetSystemDrive()
dim strServerName 
strServerName = GetServerName()

Dim BTConf, doc, env, org, port, portGroup, channel

'Set up the file directories for use in the performance tests
'----------------------------------------------------------------------
Call AddFolder("C:\LabData")
Call AddFolder("C:\LabData\Our HealthPlan (HOME)")
Call AddFolder("C:\LabData\Our HealthPlan (HOME)\Claims")
Call AddFolder("C:\LabData\Our HealthPlan (HOME)\EDIInput")
'----------------------------------------------------------------------

Set BTConf = CreateObject("BizTalk.BizTalkConfig")
Set doc = BTConf.CreateDocument
Set env = BTConf.CreateEnvelope
Set org = BTConf.CreateOrganization
Set port = BTConf.CreatePort
Set portGroup = BTConf.CreatePortGroup
Set channel = BTConf.CreateChannel

Call CreateOrganizations
Call CreateDocuments
Call CreatePorts
Call CreateChannels
Call CreateReceiveFunctions

Set BTConf = nothing

Set doc = nothing
Set env = nothing
Set org = nothing
Set port = nothing
Set portGroup = nothing
Set channel = nothing

If err <> 0 Then
    WSCript.Echo "FAIL: x" & Hex(Err.Number) & " " & Err.Description 
      & " " & Err,Source
Else
    WSCript.Echo "Test Lab Messaging Setup Complete"
End If

'----------------------------------------------------------------------
Function CreateOrganizations
    Create_lOrg110001
    Create_lOrg110002
    Set org = nothing
End Function 'CreateOrganziations

Dim lOrg110001
'declare alias(es)
Dim lAlias120001
Dim lAlias120002
Dim lAlias120003
'declare application(s)
Dim lApp130001

Function Create_lOrg110001
    org.clear
    Call LoadDefaultOrg (BTConf, org)
    lOrg110001 = org.Handle
    org.CreateAlias "ID", True,  "ZZ", "9876543-21"
    org.CreateApplication "Claims"
    org.Save
    Call ErrCheck(lOrg110001)
    lAlias120001 = GetOrgNameAliasID ( org )
    lAlias120002 = GetAliasID ("Reliable Messaging Acknowledgement SMTP 
      From Address", "SMTP", "<acknowledgement email address>", org)
    lAlias120003 = GetAliasID ("ID", "ZZ", "9876543-21", org)
    lApp130001 = GetAppID ("Claims", org)
End Function 'Create_lOrg110001

'declare organization handle
Dim lOrg110002
'declare alias(es)
Dim lAlias120004
Dim lAlias120005

Function Create_lOrg110002
    org.clear
    org.name = "Contoso Health Partners"
    org.Comments = ""
    org.CreateAlias "ID", True,  "30", "12-3456789"
    lOrg110002 = org.Create
    Call ErrCheck(lOrg110002)
    lAlias120004 = GetAliasID ("ID", "30", "12-3456789", org)
    lAlias120005 = GetOrgNameAliasID ( org )
End Function 'Create_lOrg110002

'----------------------------------------------------------------------

Function CreateDocuments
    Call AddSchemaToRepository("837Institutional_V1_wpc_single.xml", 
      "C:\Program Files\Microsoft BizTalk Server\XML 
      Tools\Templates\HIPAA\", "C:\Program Files\Microsoft BizTalk 
      Server\BizTalkServerRepository\DocSpecs\Microsoft\")
    Create_lDoc140002
    Set doc = nothing
End Function 'CreateDocuments

'declare doc handle
Dim lDoc140002

Function Create_lDoc140002
    doc.clear
    doc.name = "EDI837I_Contoso"
    doc.reference = "https://" & strServername & 
      "/BizTalkServerRepository/DocSpecs/Microsoft/837Institutional
      _V1_wpc_single.xml"
    ' build the property set of the document
    Set doc.PropertySet = CreateObject("Commerce.Dictionary")
    doc.PropertySet.application_receiver_code = "PAYER ADJ DEPT"
    doc.PropertySet.application_sender_code = "HOSP CLAIM"
    doc.PropertySet.functional_identifier = "HC"
    doc.PropertySet.standards_version = "004010X096"
    lDoc140002 = doc.Create
    Call ErrCheck(lDoc140002)
End Function 'Create_lDoc140002

'-----------------------------------------------------------------------

Function CreatePorts
    Create_lPort160002
    Set port = nothing
End Function 'CreatePorts

Dim lPort160002

Function Create_lPort160002
    port.clear
    port.name = "Port_EDI837I_From_Contoso_To_OHPClaims"
    ' set the endpoint object - port.DestinationEndPoint
    port.DestinationEndPoint.Organization = lOrg110001
    port.DestinationEndPoint.Alias = lAlias120003
    port.DestinationEndPoint.Application = lApp130001
    ' set transport info for port.PrimaryTransport
    port.PrimaryTransport.Address = "file://C:\LabData\Our HealthPlan 
      (HOME)\Claims\OHPClaim%tracking_id%.xml"
    port.PrimaryTransport.Type =  256 ' BIZTALK_TRANSPORT_TYPE_FILE
    ' create object and check errors
    lPort160002 = port.Create
    Call ErrCheck(lPort160002)
End Function 'Create_lPort160002

Function CreateChannels
    Create_lChannel180002
    Set channel = nothing
End Function 'CreateChannels

Dim lChannel180002

Function Create_lChannel180002
    channel.clear
    channel.name = "Channel_EDI837I_From_Contoso_To_OHPClaims"
    ' set the endpoint object - channel.SourceEndPoint
    channel.SourceEndPoint.Organization = lOrg110002
    channel.SourceEndPoint.Alias = lAlias120004
    channel.InputDocument = lDoc140002
    channel.OutputDocument = lDoc140002
    channel.Port = lPort160002
    ' Logging info
    channel.LoggingInfo.LogNativeInputDocument = -1
    channel.LoggingInfo.LogNativeOutputDocument = 0
    channel.LoggingInfo.LogXMLInputDocument = 0
    channel.LoggingInfo.LogXMLOutputDocument = 0
    channel.RetryCount = 3
    channel.RetryInterval = 5
    ' create object and check errors
    lChannel180002 = channel.Create
    Call ErrCheck(lChannel180002)
    ' set port configuration for lPort160002
    Set dict = CreateObject("Commerce.Dictionary")
    dict.Filename = "file://C:\LabData\Our HealthPlan 
      (HOME)\Claims\OHPClaim%tracking_id%.xml" 
    dict.CopyMode = "1" 
    dict.Username = "" 
    dict.Password = "" 
    channel.SetConfigData 0, lPort160002, dict    ' 0 = 
      BIZTALK_CONFIGDATA_TYPE_PRIMARYTRANSPORT
    Set dict = nothing
    channel.Save
End Function 'Create_lChannel180002

'-----------------------------------------------------------------------

Sub CreateReceiveFunctions
    Const ADMIN_DOCUMENT_FORMAT_CUSTOM = 1
    Const ADMIN_PROTOCOL_TYPE_FILE = 1
    Const RECVFUNC_NAMESPACE = "MicrosoftBizTalkServer_ReceiveFunction"

    Dim WBEMLocator, WBEMFunction
    Dim objBTSRecvFunc, objBTSRecvFuncInstance
    Dim strTransport(3)

    strTransport(0) = "UNSPECIFIED"
    'strTransport(1) = "FTP"           ' not Supported – 
      should never happen
    strTransport(1) = "FILE"
    strTransport(2) = "FILE2"
    strTransport(2) = "FILE"
    strTransport(3) = "MSMQ"

    Set WBEMLocator = CreateObject("WbemScripting.SWbemLocator.1")
    Set WBEMFunction = WBEMLocator.ConnectServer(, 
      "root/MicrosoftBizTalkServer")

    Set objBTSRecvFunc = WBEMFunction.Get(RECVFUNC_NAMESPACE)
    Set objBTSRecvFuncInstance = objBTSRecvFunc.SpawnInstance_

    objBTSRecvFuncInstance.Name = "ReceiveEDI"
    objBTSRecvFuncInstance.GroupName = "BizTalk Server Group"
    objBTSRecvFuncInstance.FilenameMask = "*.txt"
    objBTSRecvFuncInstance.ProcessingServer = strServername
    objBTSRecvFuncInstance.ProtocolType = ADMIN_PROTOCOL_TYPE_FILE
    objBTSRecvFuncInstance.PollingLocation = "C:\LabData\Our HealthPlan 
      (HOME)\EDIInput"
    objBTSRecvFuncInstance.ChannelName = 
      "Channel_EDI837I_From_Contoso_To_OHPClaims"

    strWMIQuery = "select * from " & RECVFUNC_NAMESPACE & " where 
      groupname= '" & objBTSRecvFuncInstance.GroupName & "'"
    Set rs = WBEMFunction.ExecQuery(strWMIQuery)
    If err <> 0 Then
        WSCript.Echo "FAIL EXECUTE QUERY: x" & Hex(Err.Number) & " " & 
          Err.Description & " " & Err,Source
    End If

    'WSCript.Echo TypeName(rs)
    'WScript.Echo "Existing Receive Functions:"
    for each a in rs
        'WSCript.Echo TypeName(a)
        'WSCript.Echo "  " & a.Name & " (" & strTransport(a.ProtocolType)
           & ")"
        If a.Name = objBTSRecvFuncInstance.Name then
            bExist = True
        end if
    next

    if bExist then
        objBTSRecvFuncInstance.Put_ (1)    ' Update
'        WSCript.Echo "Updated " & objBTSRecvFuncInstance.Name & " Receive 
           Function"
    else
    objBTSRecvFuncInstance.Put_ (2)    ' Create
'        WSCript.Echo "Created " & objBTSRecvFuncInstance.Name & " Receive 
           Function"
    end if
End Sub 'CreateReceiveFunctions

'----------------------------------------------------------------------

'  UTILITIES

Sub AddSchemaToRepository(srcName, srcPath, destPath)
    Dim destFilePath
    Dim oFileSystem
    Set oFileSystem = CreateObject("Scripting.FileSystemObject")
    destFilePath = destPath & srcName
    If Not oFileSystem.FileExists(destFilePath) Then
       oFileSystem.CopyFile srcPath & srcName, destFilePath
    End If
    Set oFileSystem = Nothing
End Sub

Sub AddFolder(dirPath)
    Dim oFileSystem
    Set oFileSystem = CreateObject("Scripting.FileSystemObject")
    If Not oFileSystem.FolderExists(dirPath) Then
        oFileSystem.CreateFolder(dirPath)
    End If
    Set oFileSystem = Nothing
End Sub

Function GetAliasID(sName, sQual, sValue, org)
    Set aliasrs = org.Aliases
    Do While Not aliasrs.EOF
        If (aliasrs("name") = sName) And (aliasrs("qualifier") = sQual) _
                    And (aliasrs("value") = sValue) Then
            GetAliasID = aliasrs("id")
            Exit Do
        End If
        aliasrs.MoveNext
    Loop
End Function

Function GetAppID(sName, org)
    Set Apprs = org.Applications
    Do While Not Apprs.EOF
        If Apprs("name") = sName Then
            GetAppID = Apprs("id")
            Exit Do
        End If
        Apprs.MoveNext
    Loop
End Function

Sub ErrCheck(ObjectName)
    If Err.number <> 0 Then
        Wscript.Echo "---------------------------------------------" & 
          vbCRLF & _
            "Err Creating Object: " & ObjectName & vbCRLF & _
            "Code:  " & Hex(Err.number) & " (" & Err.number & ") " & 
              vbCRLF    & _
            "Error: " & Err.Description & vbCRLF
    End If
    Err.Clear
End Sub

' Load the default organization
Sub LoadDefaultOrg (conf, org)
    Dim rsOrgs    ' organizations recordset

    set rsOrgs = conf.Organizations

    do while not rsOrgs.EOF
        if ( -1 = rsOrgs.Fields ( "defaultflag" ).Value ) then
            org.Load rsOrgs.Fields ( "id" ).Value
            exit sub
        end if
        
        rsOrgs.MoveNext
    loop

    err.raise -1, "no default found"
End Sub 'LoadDefaultOrg 

Function GetOrgNameAliasID ( org )
    Set aliasrs = org.Aliases
    Do While Not aliasrs.EOF
        If ((aliasrs("qualifier") = "OrganizationName") and 
          (aliasrs("value") = org.Name)) Then
            GetOrgNameAliasID = aliasrs("id")
            Exit Do
        End If
        aliasrs.MoveNext
    Loop
End Function 'GetOrgNameAliasID

'function to retrieve the path of a script - does not append a terminating 
  "\"
'
Function GetScriptPath()
  dim strPath
  strPath = WScript.ScriptFullName
  GetScriptPath = Left(strPath, InstrRev(strPath, "\"))
End Function

'function to retrieve the system drive letter - appends the terminating 
  "\"

Function GetSystemDrive()
  'get the windows folder and the system drive
  dim fso
  set fso = CreateObject("Scripting.FileSystemObject")
  dim fldWindowsFolder
  set fldWindowsFolder = fso.GetSpecialFolder(0)
  dim drv
  set drv = fso.GetDrive(fso.GetDriveName(fldWindowsFolder.Path))
  GetSystemDrive = drv.DriveLetter & ":\"
End Function

'function to retrieve the name of the server
'
Function GetServerName()
  dim oWSHNetwork
 set oWSHNetwork = CreateObject("WScript.network")
  GetServerName = oWSHNetwork.Computername
End Function

More information about transaction cost analysis

The performance testing methodology used was the Transaction Cost Analysis (TCA) method used in numerous projects both inside and outside of Microsoft. This approach centers on a transaction; in these tests the transaction was either an 837I or a 270 transaction set of varying complexity. The approach was designed around simplicity and around the ability to repeat this test suite at any location where BizTalk Accelerator for HIPAA is installed. Simplicity was the goal, and most specifically simplicity of measuring only the cost of processing these documents, and not other actions such as database writes or extended business logic and process flows.

See the following sources for further information about the methodologies employed in the POC testing portion of this paper (all apply largely to both B2B and B2C implementations):

• Capacity Model for Internet Transactions
• Scalability Case Study
• Commerce Server Performance Tools

Appendix 2: Services Guide

For more information about planning your BizTalk Accelerator for HIPAA solution, see the accompanying Services Guide.

Appendix 3: WEDI SNIP White Papers

For more information about transactions, see the Transactions Workgroup Whitepapers published by the Workgroup for Electronic Data Interchange Strategic National Implementation Process (WEDI SNIP).