Microsoft BizTalk Accelerator for HIPAA

Article
06/30/2006

Microsoft Corporation

August 2002

Applies to:
Microsoft® BizTalk® 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). (52 printed pages)

Introduction
    Audience
    About This Guide
    Prerequisites
Operational Reference Model
    Microsoft Operations Framework
    Operations Infrastructure
    Reporting Model
    Business Disciplines Required
    Change Management Model
Operational Activities
    Gap Analysis
    Ongoing Operations
    Change Management
    Backup and Restore
    Database Maintenance
    Troubleshooting
    Failure Scenarios
    Monitoring the System
    Securing the System
    Planning for Capacity
    Planning for Scalability
    Tuning the System
    Managing Availability
    Managing the BizTalk Accelerator for HIPAA Configuration
    Going into Production
Getting Assistance
Additional Resources
Appendix: Additional Security Recommendations
    Deploying Microsoft Operations Manager
    Configuring Auditing in SQL Server 2000

Introduction

The Operations Guide for Microsoft® BizTalk® Accelerator for HIPAA is one in a series of guides; others in the series are Architecture, Deployment, and Services. 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, system administrators, systems architects, project managers, HIPAA experts, development leads, software developers, and anyone else concerned with planning for and operating 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 consists of two main sections. The first describes the reference model for the operation of the BizTalk Accelerator for HIPAA solution, and the second describes a variety of operational activities related to the solution.

This guide is not intended as a substitute for the BizTalk Accelerator for HIPAA documentation or for the 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 solution:

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 modeling

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

Operational Reference Model

The operational reference model uses the Microsoft Operations Framework and the related process model, both of which are reviewed in this section. This section also describes the operations infrastructure, reporting, change management, and people skills required for operating an installation of the application that uses Accelerator for HIPAA.

Microsoft Operations Framework

The Microsoft Operations Framework (MOF) is a collection of best practices, principles, and models. It provides comprehensive technical guidance for achieving mission-critical production system reliability, availability, supportability, and manageability for solutions and services built on Microsoft products and technologies. MOF will be our reference model for this Operations Guide.

For a comprehensive introduction to MOF, see the Microsoft Operations Framework Executive Overview.

Operations Infrastructure

Organizations that deploy an Accelerator for HIPAA solution require that the application must keep functioning 24 hours a day, 7 days a week. Indeed it has become increasingly more common for enterprise application integration (EAI) to have a similar up-time requirement. This guide outlines the administrative tasks a system administrator must perform to keep an Accelerator for HIPAA solution running on a continual basis. Also discussed are important concepts and common administrative issues of which system administrators must be aware.

The major areas of administration and management related to BizTalk Accelerator for HIPAA are:

BizTalk Server administration. You can use BizTalk Server Administration MMC snap-ins to manage server groups, receive functions, and document tracking. You can use BizTalk Messaging Manager or the BizTalk Messaging Configuration object model to update messaging objects, such as channels and messaging ports. You can also use BizTalk Messaging Manager or the BizTalk Messaging Configuration object model to facilitate the processing and transmission of interchanges and documents.
Database administration. You can use scripts and tools to maintain the various types of databases associated with BizTalk Server and the application that uses Accelerator for HIPAA.
Monitoring servers. You can use Microsoft Windows® 2000 System Monitor, Windows 2000 Event Viewer, and XLANG Event Monitor to monitor BizTalk Server and Accelerator for HIPAA.
Troubleshooting. You can use BizTalk Server Administration to view the Suspended queue for processing and transmission errors. You can use Event Monitor to troubleshoot server errors, Accelerator for HIPAA application errors, and other application errors.
Security. Security considerations include the security features that BizTalk Server uses and the configuration changes that might be necessary when managing a BizTalk Server installation.

Reporting Model

The operations team should generate reports to study the health and behavior of the system, and to invoke service-management functions as needed. Reports can identify incidents as they occur, and can also be important in analyzing audit information as required by HIPAA. Reporting is an important part of IT service management and of the MOF process. It is also a critical requirement in meeting HIPAA mandates.

System-level and application-level reporting for BizTalk Server can be accomplished by using the following:

System Monitor. Reports on memory, processor, and storage space usage.
Application Center. Reports on any performance counter, system counter, or system log. Can be centralized or local. Supports automated responses.
Microsoft Operations Manager. Provides centralized reporting and automated responses to performance counters, system counters, or system logs.
Application log. Reports application events.
Security log. When enabled, reports defined security events.

Business Disciplines Required

Different business disciplines are tasked with undertaking various roles in managing an Accelerator for HIPAA deployment. These disciplines are discussed in the following paragraphs.

Business managers

Business managers and business analysts define business rules for processing HIPAA transactions that include claims processing, eligibility request and response, benefit enrollment, and so on. Business managers evaluate the results of gap analysis and define actions to address issues related to HIPAA compliance deficiencies. Business managers work with the following types of content:

Trading partner agreements
Auditing and data archival
Application performance reports
User definitions
Definition of business processes

Developers

Developers add, change, or delete content by using Microsoft Visual Studio® and BizTalk Server tools in the development environment. These users also develop XML documents and configure BizTalk Messaging and Orchestrations. Developers perform the following functions:

Creating XLANG schedules
Creating maps by using BizTalk Mapper
Configuring BizTalk Messaging objects
Developing custom preprocessor components
Developing application integration components
Developing business logic components
Developing dynamic content (for example, ASP pages or Microsoft Visual Basic® scripts)
Administering the database

Testers

Testers test newly developed content in the test/staging environment, prior to deployment, in an effort to identify issues that might occur during operation.

System administrators

System administrators handle change requests from both business managers and site developers. These users configure and maintain BizTalk Messaging and Orchestration services. System administrators are responsible for:

Configuring and managing BizTalk Messaging Services.
Deploying and managing BizTalk Orchestration Services.
Deploying and configuring COM+ applications, including preprocessor components and application integration components.

Change Management Model

Change management for the Accelerator for HIPAA solution should be done through a well-defined change management process such as the following:

Develop new content and configuration changes within the confines of the corporate network by using tools such as Microsoft Visual Studio, BizTalk Messaging Manager, BizTalk Editor, BizTalk Mapper, and BizTalk Orchestration Designer.
Unit-test changes in the development environment.
Move content and configuration changes from the development environment to the test/staging environment when the content is ready for integration and regression testing. The test/staging environment should be similar in network topology to the production environment, at smaller scale (fewer processors or Web servers). This environment might be located within the corporate network if you are developing and administering applications in-house; or it might be located offsite at the Internet service provider (ISP) or application service provider (ASP) if your site is being administered externally.
Move the content and configuration changes from the test/staging environment to the production environment when you have successfully completed regression testing.

This process usually involves the activities listed in the following table.

Activity	Description
Design	Perform gap analysis with the legacy system data. Identify and address any compliance deficiencies. Define the business process for the HIPAA EDI transaction. The business process should define steps for functional acknowledgements, translation to/from legacy data format, additional validation of HIPAA X12N EDI documents, integration with the legacy systems, and data archival processes.
Implement	Implement the business process. Develop translation maps between HIPAA EDI transactions and the document format required by the legacy system. People who create this content include application developers. You usually use a source code management system, such as Microsoft Visual SourceSafe®, to track the authored content.
Review	Review the implementation to make sure that it satisfies the business process. A business analyst reviews the implementation.
Approve	Approve the implementation for deployment. It is important to have a well-defined approval process and assigned approvers.
Store	Place document specifications, maps, and applications in version-control systems, or other types of repositories.
Test	Test the final application. Testing should include functional acknowledgements, data storage, document translation, and outbound documents. Comprehensive, final integration testing should be done in a test/staging environment that is exactly the same as the production environment. Developers need to make sure that database connections are valid for the test/staging environment and the production environment.
Deploy and replicate content	Place the new application into production. You must be sure that all content, including document specifications, maps, components, and XLANG schedules, is moved to the live system. This stage can utilize Microsoft Application Center for deployment in a clustered environment.
Analyze	Analyze the document flow and application on an ongoing basis.

Operational Activities

This section describes the various operational activities associated with running an Accelerator for HIPAA installation. These activities are divided into the following categories:

Gap analysis
Ongoing operations
Change management
Backup and restore
Database maintenance
Troubleshooting
Failure scenarios
Monitoring the system
Securing the system
Planning for capacity
Planning for scalability
Tuning the system
Managing availability
Managing the BizTalk Accelerator for HIPAA configuration
Going into production

Gap Analysis

Organizations that have legacy applications for health care administrative and financial transactions must perform gap analysis with their legacy data. Gap analysis identifies compliance deficiencies with respect to HIPAA X12N transactions. It identifies data fields required in HIPAA X12N EDI transactions that are not used in legacy applications, as well as data fields that are used in legacy applications but are not required in HIPAA X12N EDI transactions.

The Washington Publishing Company (WPC) gap analysis tool incorporates Microsoft Solutions Framework concepts that include Process model, Team model, and Risk model. This is a Web-based tool that helps organizations identify compliance deficiencies. For more information see the Washington Publishing Company Web site.

Ongoing Operations

This section describes ongoing operational procedures that must be performed for an Accelerator for HIPAA installation. These procedures include trading partner configuration, report analysis, document specification configuration, document maps deployment, and application component deployment.

Trading partner configuration

Trading partner configuration defines how HIPAA transaction documents are received and sent. BizTalk Server configuration includes information such as protocol used for communication, formats of the documents, and where to send functional acknowledgements.

Business managers define the relationships with trading partners. Developers can configure and maintain trading partner configuration information by using the BizTalk Server Management Pack. The trading partner configuration can also be accomplished programmatically by using the BizTalk Server IBizTalkConfig interface.

Report analysis

All servers in a server group share a single Tracking database that stores all information related to interchange and document activity in BizTalk Server. The Tracking database is used to track the status of an interchange or document as it moves through the server. For example, if you want to verify whether an eligibility request was sent to a trading partner, you can query the Tracking database. This database can also be used to verify that interchanges and documents are successfully sent or received by BizTalk Server, or it can provide information for reports such as transmission times or receipt responses.

In BizTalk Server Administration, it is possible to enable tracking at the interchange or document level. The following options can be selected:

Log incoming interchange. With this setting, you can specify that documents received by BizTalk Server are stored in the Tracking database. Storing incoming documents provides an activity record for dispute resolution. This is selected by default.
Log outgoing interchange. With this setting, you can specify that documents sent by BizTalk Server are stored in the Tracking database. This is selected by default.
Log the original MIME-encoded message. With this setting, you can specify that MIME-encoded documents are stored in the Tracking database in their original message format before they are decoded. This is not selected by default.

Document specifications

Document specifications in BizTalk Server are used to identify and validate documents. Accelerator for HIPAA includes schema templates (specifications) for all 12 HIPAA X12N EDI 4010 transactions. The following table shows the transactions and the names of the template files.

Transaction number	Description	File name
270	Health Care Eligibility/Benefit Inquiry	270_V1_wpc.xml
271	Health Care Eligibility/Benefit Information Response	271_V1_wpc.xml
276	Health Care Claim Status Request	276_V1_wpc.xml
277	Health Care Claim Status Response	277_V1_wpc.xml
278	Health Care Services Review -- Request for Review and Response	278Request_V1_wpc.xml 278Response_V1_wpc.xml
820	Payroll Deducted and Other Group Premium Payment for Insurance Products	820_V1_wpc.xml
834	Benefit Enrollment and Maintenance	834_V1_wpc_multiple.xml 834_V1_wpc_single.xml
835	Health Care Claim Payment/Advice	835_V1_wpc_multiple.xml 835_V1_wpc_single.xml
837	Health Care Claim: Institutional	837Institutional_V1_wpc_multiple.xml 837Institutional_V1_wpc_single.xml
837	Health Care Claim: Dental	837Dental_V1_wpc_multiple.xml 837Dental_v1_wpc_single.xml
837	Health Care Claim: Professional	837Professional_v1_wpc_multiple.xml 837Professional_v1_wpc_single.xml

Document splitting allows individual instances in a batch transaction to be treated separately. The document splitting feature is available to use for 834, 835, and 837 HIPAA X12N EDI transactions. For these transactions two versions of schema templates are available: single and multiple. For example, when the 837Dental_v1_wpc_multiple.xml schema is used, a batch document containing multiple dental claims is split into many documents, each containing a single dental claim.

Select the appropriate schema template for the HIPAA X12N EDI transaction and copy it to the Web Distributed Authoring and Versioning (WebDAV) folder. Rename the schema template by using your organization's naming convention. It is strongly recommended that you do not modify the schemas. Altering the schemas means content removal, content addition, node name changes, and schema hierarchy changes. Altering content or changing hierarchy could result in the transaction being non-HIPAA-compliant. Changing node names will lead to difficulty in obtaining help about the schemas because the original node names closely match the names in the HIPAA implementation guides.

Maps deployment

Document translation rules (maps) are defined by using BizTalk Mapper. The maps are used to translate HIPAA X12N EDI documents into formats required by back-end applications and also to translate documents generated by back-end applications into HIPAA X12N EDI documents.

Maps are deployed to the WebDAV directory so that they can be accessed from BizTalk Messaging Manager. After the maps are deployed to WebDAV, the BizTalk Messaging Management database is updated by using the BizTalk Channel Wizard.

Application component deployment

Application components (COM+) are used in the solution as preprocessor components and application integration components. Developers build and configure components.

Preprocessor component is registered and configured for use with BizTalk Server receive function. Application integration component is registered and configured for use with BizTalk Server messaging port.

Change Management

This section describes aspects of BizTalk Accelerator for HIPAA that are likely to evolve over time. Detailed information is provided for the following:

XML schemas and BizTalk maps
New transactions
Microsoft SQL Server connection strings
COM+ components
System DLLs

XML schemas and BizTalk maps

The application that implements HIPAA EDI transactions must account for new document specifications and maps. These changes might be introduced because of the following:

HIPAA EDI transaction standards change
A new data format is introduced by integration with a new legacy application
The data format of the existing legacy application changes

Use the following steps to update document specifications and maps:

Update the XML file in the BizTalk Server WebDAV repository.

Default document definition (schema) path in the WebDAV repository:

%systemdrive%\Program Files\Microsoft BizTalk Server\BizTalkServerRepository\DocSpecs\Microsoft\

Default BizTalk map path:

%systemdrive%\Program Files\Microsoft BizTalk Server\BizTalkServerRepository\Maps\Microsoft\

Refresh BizTalk Messaging objects. BizTalk Server stores the XML document definitions and maps in the database. Therefore, when these document definitions and maps are updated, the objects need to be refreshed to update the XML stored in the database. To update XML document definitions, refresh the BizTalk document definition. To update BizTalk maps, refresh the associated BizTalk channel. The BizTalk channel can be updated from BizTalk Messaging Manager by selecting the new map and saving the changes to the BizTalk Server configuration database.

New transactions

New transactions are implemented over a period of time. The following are reasons for introducing new transactions:

A new X12N EDI transaction is implemented because the transaction is newly added to the list of HIPAA X12N EDI transactions and thus the implementation is mandated by HIPAA.
A business requirement necessitates implementation of a new HIPAA X12N EDI transaction.
New HIPAA X12N standards are adopted. The current version of the HIPAA transactions is 4010. In the future the version will change to 4030, then to 4050, and so on. Each new version will introduce changes to HIPAA transactions and could add new transactions, which will require organizations to migrate to the new standards.

To add support for a HIPAA EDI transaction with Accelerator for HIPAA requires several configuration steps.

Select a naming scheme for the new standard. In the following sequence of steps, you will create a number of BizTalk Messaging objects, each of which will require a name. Each name should include a standard string chosen for the new document standard.

For examples of standardized naming schemes, refer to the names of existing BizTalk channels, messaging ports, Message Queuing (also called MSMQ) queues, receive functions, and so on in your organization.
Create a new BizTalk document specification. Select the appropriate HIPAA X12 EDI schema from the templates supplied with Accelerator for HIPAA. XML schemas for the documents required for legacy applications must be created by using BizTalk Editor. If the document type is XML then the new standard can be created by importing a document type definition (DTD), an XML Data-Reduced (XDR) file, or a well-formed XML schema. Document specifications for flat files (positional or delimited) are created manually by using BizTalk Editor. All schemas are saved as XML within the BizTalk WebDAV repository.
Create new BizTalk maps. After creating new document definitions, use those definitions to create the necessary BizTalk maps. Depending on the type of the document, different mappings will be required, as follows:
- If the new document standard is a new version of an existing standard, the easiest way to create a new map is to open the existing map for the older version of that standard in BizTalk Mapper. In the pane that shows the standard to be updated, right-click and select Update Specification. (Depending on whether the document is outgoing or incoming from the perspective of BizTalk Server, the corresponding pane will be either the right pane or the left pane, respectively.) When the new specification is loaded, mappings will be retained for any fields that are the same as for the previous version. Then use BizTalk Mapper to create any additional mappings that are required.
- If the root node of the new specification is different, updating the specification in BizTalk Mapper will not retain the original mappings. In this case, edit the mapper-generated XSLT file with a text editor. Using search-and-replace, update the old root name with the new root name. Open the modified XSLT file in BizTalk Mapper and update the specification as described in the preceding paragraph.
- If the new document standard is completely new, create a new BizTalk map by using the new document schema and the schema for the HIPAA EDI transaction document. All of the mappings will need to be created manually. Even during this process, it might be useful to open an existing, similar map in a different instance of BizTalk Mapper and use it as a point of reference.
Create a new preprocessor component (optional). Preprocessor components are used to apply business logic after a document is selected by a File or Message Queuing receive function but before the document is processed by BizTalk Messaging Service. Because the HIPAA EDI parser removes HIPAA X12N EDI envelope information from the document, preprocessor components typically apply rules to preserve HIPAA X12N EDI envelope information. Preprocessor components can also be used for decrypting a document if a custom encryption process was applied to it at its point of origin. Registration is required for the preprocessor component. After registration, the component is assigned to one or more BizTalk Server receive functions.
Configure functional acknowledgements. Trading partners that are exchanging HIPAA X12N EDI documents often require functional acknowledgements (997s) for the documents. Obtain the address where the trading partner wants the functional acknowledgements to be delivered. Functional acknowledgements are sent by using BizTalk channels and ports. The BizTalk Server documentation describes the steps for configuring EDI receipt channels in BizTalk Messaging Manager.
Create a new BizTalk application integration component (AIC) (optional). AICs are used to perform additional processing that is required after the document transformation is performed in the BizTalk channel.

AICs for HIPAA EDI applications might need to perform the following processing:
- Apply extended validation business rules to the outgoing document.
- Deliver the outgoing document to the back-end system for processing.
- Pass the outgoing document to the indicated BizTalk transport channel.
- Perform custom encryption or compression on the outgoing document.
After creating the new AIC, a corresponding BizTalk application artifact should be configured. To create this artifact, open BizTalk Messaging Manager, search for organizations, and open the home organization. Create a new application for the AIC under the home organization, and provide a name for it. This name is used only for tracking purposes.
Create a new BizTalk XLANG schedule (optional). BizTalk Accelerator for HIPAA installs a sample XLANG schedule. This orchestration sample can be used as a reference for implementing custom business processes. New XLANG schedules can be created by using BizTalk Orchestration Designer. XLANG schedules are not registered. The XLANG schedules can be invoked programmatically or from BizTalk Messaging Service.
Create new BizTalk document definitions. After creating the new BizTalk map and XML schema, open BizTalk Messaging Manager and create a new BizTalk document definition, messaging port, and channel. Message transformation is performed by BizTalk Messaging Service. In BizTalk Messaging Manager, create a new document definition configured to point to the new schema that was created and saved to the WebDAV repository.
Create new BizTalk messaging ports. BizTalk messaging ports are created to send documents to specified destinations by using one of the following transports: Message Queuing, File, HTTP/S, SMTP, application integration (AIC, XLANG). When additional business rules are to be applied to the document, configure the port to communicate to either AICs or an XLANG schedule. Previous paragraphs describe the development and deployment of AICs and XLANG schedules.
Create or modify BizTalk channels. BizTalk channels are used in association with BizTalk messaging ports. A BizTalk channel defines inbound and outbound document formats, and associates a BizTalk map if the formats are different.

Create the channel for the port created in the previous step. The channel links the document definitions and maps that are created in previous steps.
Create a new Message Queuing queue (optional). If documents are received from or delivered to Message Queuing, then create a new Message Queuing queue by using the Message Queuing item under Services and Applications in the Computer Management administrative tool. The queue should be set to be transactional at the time of creation. After the queue has been created, set its security properties as follows:
- Give everyone permission to write messages to the queue.
- Give the BizTalk Server Administrators group all permissions associated with the queue (receive message, peek message, receive journal, get properties, get permissions, write message).
Create new BizTalk receive functions (optional). BizTalk Server supports two types of receive functions: File and Message Queuing. If a document is sent to BizTalk Messaging Services from a file folder, then define a File receive function by using the BizTalk Server Administration console. If a document is delivered from Message Queuing, then define a Message Queuing receive function by using the BizTalk Server Administration console.

SQL Server connection strings

The BizTalk Server SQL Server connection strings are managed through BizTalk Server Administration MMC snap-ins.

BizTalk Server SQL Server connection strings

BizTalk Server databases include the Messaging Management database, the Tracking database, the Shared Queue database, and the XLANG persistence database. When the connection information for the databases changes, it is updated by using the BizTalk Server Administration MMC snap-in.

The SQL Server connection strings for the Messaging Management, Tracking, and Shared Queue databases are configured in the BizTalk Server Administration MMC snap-in. The XLANG persistence database uses a data source name (DSN) that can be configured from the XLANG Scheduler COM+ application.

BizTalk Messaging Management database. This database stores information for all server and messaging configurations. Server configuration information includes server group, server settings, and receive functions. Messaging configuration includes channels, messaging ports, document definitions, organizations, and so on.
Tracking database. When tracking for a server group, channel, and/or document definition is turned on, this database stores the corresponding tracking information.
Shared Queue database. This database holds documents while they are being processed or waiting to be processed. Documents are removed from this database after they have been processed.
XLANG persistence database. This database stores the XLANG schedule state when an XLANG schedule is dehydrated.

COM+ components

The applications that are typically deployed to work in conjunction with Accelerator for HIPAA include BizTalk preprocessor components and BizTalk application integration components.

A BizTalk preprocessor component is assigned to BizTalk receive functions and can be used to manipulate X12N EDI envelope information. When the preprocessor component needs to be modified, the updated component DLL is copied over the old version. The BizTalk receive function is then updated with the newer version of the preprocessor component.

BizTalk application integration components are used to implement business logic related to HIPAA transactions. To change the application integration component, replace the old component DLL with the newer version.

System DLLs

Many times system DLLs need to be updated because a new service pack (for an application or for an operating system) or a new version of an application is introduced. An example is when BizTalk Server needs to be updated to a newer version.

If the system is to be migrated to the next version of BizTalk Server and/or Accelerator for HIPAA, then it is very important to test your solution in the pre-production environment with the latest version. Verify that the preprocessor components, application integration components, maps, XLANG schedules, and business components are compatible with the newer version of the application.

To update the system DLLs, the first step is to shut down BizTalk Server from the BizTalk Server Administration console. If the BizTalk Server group contains more than one server, then update the system DLLs on all the servers at the same time. After BizTalk Server is shut down, install the new system DLLs following the instructions provided with the installation guide. Restart the servers from the BizTalk Server Administration console.

Backup and Restore

Backing up data is one part of an effective disaster recovery strategy. The first step in implementing an effective backup and recovery strategy is to precisely identify the entities that need to be backed up. Two types of entities need some kind of backup strategy:

BizTalk artifacts such as channels and messaging ports.
Those entities that constitute the data associated with Accelerator for HIPAA. The most obvious examples of this type of entity are document specifications and maps.

The following sections discuss some strategies for both types of entities.

Implementation backup

The implementation of Accelerator for HIPAA consists of WebDAV content (schemas and maps), XLANG files, components, and receive functions. All of these entities need to be backed up in some fashion.

BizTalk Server WebDAV content

All of the document definitions and maps used by BizTalk Server are stored in a WebDAV repository. WebDAV can be configured to store the files locally on the BizTalk Server computer or remotely on a separate WebDAV Web server. Two backup strategies make sense for this type of entity. First, these files could exist in a second WebDAV repository that is also used for staging when changes to these entities are being tested. Second, these files could be updated on the production system, and then backed up daily along with any other Web site entities that are saved. Because these documents tend to be quite stable, the first option probably makes the most sense.

XLANG files

The XLANG files have an .skx file name extension. Two backup strategies could be applied. You could copy the XLANG files to a secure location, or you could back up the files daily. The XLANG files do not change very often; therefore the first option is more suitable.

Components

The following three types of components are used and need to be backed up: application integration components, preprocessor components, and components used in XLANG schedules. To back up the DLLs corresponding to the components, you could copy the DLL files to a secure location or you could back up the files daily. The DLLs do not change very often; therefore the first option is more suitable.

Receive functions, queues, and file folders

Receive functions, queues, and file folders are used to submit documents to BizTalk Server for processing. To back up the configuration for receive functions, queues, and file folders, back up the scripts that implement the code for the creation of these entities. The script files should be backed up in a secure location.

Implementation restore

In case of an emergency such as loss of data, the previously backed up implementation components need to be restored. The following paragraphs outline the steps for restoring implementation components.

BizTalk Server WebDAV content

WebDAV content refers to document specifications and maps. Create the WebDAV folders and copy the document specifications and maps into appropriate locations.

XLANG files

Select and copy the previously backed up XLANG schedules to the appropriate location on the production machine. If the XLANG schedules are invoked by BizTalk Messaging Services then verify the messaging port properties for the location of the XLANG schedules.

Components

To restore components, copy and register the DLL files for the components on the production machine. For preprocessor components, update the receive function properties. For application integration components, verify the settings on the messaging port that invokes each component. To restore business components used in XLANG schedules, additional steps beyond registration are not necessary.

Receive functions, queues, and file folders

Run the script files that configure receive functions, queues, and file folders to restore these entities on the production machine.

Database backup

Backing up data consists of backing up the various SQL Server databases used by BizTalk Server. These databases are:

BizTalk Databases

InterchangeSQ database (Shared Queue)
InterchangeBTM database (Message Management)
InterchangeDTA database (Tracking)
XLANG persistence database

When you create a database backup, the backup operation copies only the data in the database to the backup file; it does not copy unused space in the database. Because the database backup contains only the actual data in the database, and no empty space, the database backup is likely to be smaller than the database itself. An estimate of the size of the database backup can be determined by using the sp_spaceused system stored procedure; the reserved value indicates the estimated size.

When backing up databases, the backup interval should be long enough to keep the backup overhead from affecting production work, yet short enough to prevent the loss of significant amounts of data. Databases that do not contain critical data and have few modifications can be backed up on a weekly or biweekly basis. Data that is more critical or more volatile might need to be backed up daily, or even more frequently. Some databases that are usually read-only might need to be backed up only after a periodic refresh with new data.

It is also prudent to have more than one backup of the database. It is recommended that you maintain a rotating series of backup media, so that you have two or more versions of the database that you can restore. This allows you to address situations in which a user might make incorrect modifications that are not detected for some time, or to fall back to an earlier backup if backup media is damaged.

Create a backup of a SQL Server database

In SQL Server Enterprise Manager, expand a server group, and then expand a server.
Expand Databases, right-click the database you want to back up, point to All Tasks, and then click Backup Database.
On the General tab, in the Name box, type the backup set name.
Optionally, in Description, enter a description for the backup set.
Under Backup, select Database - complete.
Under Destination, click Add to add an existing backup device or to create a new backup device. Or, click Remove to remove a backup device from the list of backup devices to be used.

In the SQL Server Backup dialog box, under Overwrite, do the following:

Use this	To do this
Append to media	Append the backup to any existing backups on the backup device.
Overwrite existing media	Overwrite any existing backups on the backup device.
Schedule	Optionally, select to schedule the backup operation for later or periodic execution.

Optionally, click the Options tab and select from these backup options:
- Verify backup upon completion. Causes the backup to be verified when backed up.
- Eject tape after backup. Causes the tape to be ejected when the backup operation has completed. Available only with tape devices.
- Check media set name and backup set expiration. Causes the backup media to be checked to prevent accidental overwrites. In Media set name, enter the name of the media that should be used for the backup operation. Leave blank when specifying only the backup set expiration.
If you are using the backup media for the first time, or if you want to change an existing media label, under Media set labels, select Initialize and label media, and enter the media set name and media set description. (The media can only be initialized and labeled when overwriting the media.)

Data restore

Restoring a database backup returns the database to the same state it was in when the backup was created. When you restore a database, SQL Server re-creates the database and all of its associated files automatically by performing these steps:

All of the data from the backup is copied into the database; the rest of the database is created as empty space.
Any incomplete transactions in the database backup (transactions that were not complete when the backup operation completed originally) are rolled back (undone) to ensure that the database remains consistent.

This process ensures that the restored database is a copy of the database as it existed when the backup operation completed, except that all incomplete transactions have been rolled back. This is required to restore the integrity of the database.

Additionally, to prevent overwriting a database unintentionally, the restore operation can perform a safety check automatically. The restore operation fails if:

The database named in the restore operation already exists on the server and the database name does not match the database name recorded in the backup set.
The database named in the restore operation already exists on the server, but it is not the same database as the database contained in the database backup. For example, the database names are the same, but each database was created differently.
One or more files need to be created automatically by the restore operation (regardless of whether the database already exists), but files with the same file name as those that need to be created already exist.

These safety checks can be disabled if the intention is to overwrite another database.

Restore a SQL Server backup from a backup device

Expand a server group, and then expand a server.
Expand Databases, right-click the database, point to All Tasks, and then click Restore Database.
In the Restore as database box, type or select the name of the database to restore if different from the default. To restore the database with a new name, type the new name of the database.

Note Specifying a new name for the database determines automatically the new names for the database files restored from the database backup.
Click From device, and then click Select devices.
Under Restore from, click Tape or Disk, and then select a device from which to restore.

If no devices appear, click Add to add an existing backup device or to create a new one. In the Restore Database dialog box, click View Contents and select the backup set to restore.

Note This option scans the backup set for the backup content information and can be time consuming, especially when using tape devices. If you already know the backup set to restore, type the backup set number in Backup number instead.
Under Restore backup set, do one of the following:
- Click Database - complete to restore a database backup.
- Click Database - differential to restore a differential database backup.
- Click Transaction log to apply a transaction log backup.
- Click File or filegroup to restore a file or file group backup. Specify the name of the file or file group.
Optionally, click the Options tab, and then do one of the following:
- Click Leave database operational. No additional transaction logs can be restored if no further transaction log backups are to be applied.
- Click Leave database nonoperational, but able to restore additional transaction logs if another transaction log backup is to be applied.

Minimizing backup and recovery times

Mission-critical environments often require that the database be available continuously, or for extended periods of time with minimal downtime. Therefore, the duration of unexpected situations, such as a hardware failure, that require the database to be restored need to be kept as short as possible. Additionally, mission-critical databases are often large, requiring longer periods of time to back up and restore. Microsoft SQL Server offers several methods for increasing the speed of backup and restore operations, thereby minimizing the effect on users during both operations. These methods are:

Using multiple backup devices simultaneously to allow backups to be written to all devices at the same time. Similarly, the backup can be restored from multiple devices at the same time.
Using a combination of database, differential database, and transaction log backups to minimize the number of backups that need to be applied to bring the database to the point of failure.
Using file and file group backups and transaction log backups, allowing only those files that contain the relevant data to be backed up or restored, rather than backing up the entire database.

Database Maintenance

SQL Server database maintenance must be performed for Accelerator for HIPAA installations. After you deploy Accelerator for HIPAA, you might need to change the following settings associated with your SQL Server databases:

Auto shrink
Automatically grow file

You can change the Auto shrink setting in SQL Server Enterprise Manager in the <Database Name> Properties dialog box on the Options tab. You can change the Automatically grow file setting in SQL Server Enterprise Manager in the <Database Name> Properties dialog box on the Settings tab.

The Auto shrink setting controls disk space allocation. If you want to avoid unnecessary disk space allocation, select the Auto shrink option in SQL Server.

The Automatically grow file setting enables the SQL Server databases to grow in size if necessary. When SQL Server is installed, the Automatically grow file setting is selected by default. Keep this setting enabled under the following conditions:

If you want SQL Server to handle low database space conditions automatically.
If SQL Server is the only application using disk space and when ample disk space exists to grow databases.
If you want to use disk quota alerts to alert you that a database is nearing its capacity limits. This enables you to prevent BizTalk Server from failing because one of the databases it uses reaches capacity.

Although it is recommended that you leave the Automatically grow file setting enabled, you might need to turn this setting off in the following situations:

If you must have control over how much space SQL Server uses.
If SQL Server shares the same disk with other applications and those applications must have disk space available at all times.
If you want BizTalk Server or other processes to stop when SQL Server is out of space. This allows clean-up processes to run, and BizTalk Server can be restarted when the clean-up process is complete.

Maintaining the BizTalk Server tracking database

If you configured all tracking options for a server group in BizTalk Server Administration, and if you configured any channels or document definitions to track specific fields, your Tracking database will grow in size very quickly. BizTalk Server Service Pack 1a (SP1a) has utilities to assist with maintaining the Tracking database (InterchangeDTA). These utilities provide the ability to both archive and purge the database by setting up and linking an archive database as well as running an SQL script. This script, BTS_Tracking_Archive_Purge_Script.sql, can be found in the \Program Files\Microsoft BizTalk Server\Setup directory. For more information about these utilities, see the readme file that comes with BizTalk Server SP1a, "biztalk server 2000 sp1a readme.htm."

Replicating the BizTalk Server tracking database

It is recommended that your database maintenance plan include automatic replication of the Tracking database. If the Tracking database grows too large, BizTalk Server performance is adversely affected. You can use the SQL Server Enterprise Manager console to set up replication and to set up jobs to remove transactions from the database based on criteria that you specify.

Note Do not change the code, such as stored procedures or triggers, in the Tracking database. Do not access the Tracking database directly. Do not directly call the stored procedures or add triggers. Making changes to the Tracking database in this way might cause BizTalk Server to function incorrectly, cause the loss of data, or corrupt the Tracking database.

Maintaining the BizTalk XLANG persistence database

BizTalk Server does not include scripts to clean up old XLANG schedule instances or other utilities to manage the persistence database used by BizTalk Orchestration Services. However, this issue will be corrected in a future release. For information about maintaining the XLANG persistence database, white papers, and the most recent updates on the availability of such scripts, go to the Microsoft BizTalk Server Web site.

Note Do not attempt to create your own tools to maintain the XLANG persistence database. If you access the database in this way, you could delete important production data or corrupt the database.

Troubleshooting

When troubleshooting an Accelerator for HIPAA installation, there are a number of places to begin, referred to here as "check points." Check points are divided into the following categories:

General check points
HIPAA EDI document check points

General check points

The following general check points should be considered when troubleshooting a problem with an Accelerator for HIPAA installation:

Event Log
BizTalk document tracking
Date and time settings

Event log

The Event Log is the first place to look when attempting to troubleshoot a problem with an Accelerator for HIPAA installation. All of the underlying applications, including Accelerator for HIPAA, log errors to the Event Log.

BizTalk document tracking

You can use BizTalk Document Tracking to track interchanges and associated documents processed by Microsoft BizTalk Server as an aid to troubleshooting.

Documents can be tracked either in batches or as single transactions. BizTalk Document Tracking automatically stores metadata associated with an interchange, such as source and destination information, document type, and date and time parameters. Metadata is stored automatically; however additional fields are captured only if you configure BizTalk Messaging Manager to capture this information. For more information about configuring selected fields to be tracked, see the topics "Set Channel Properties" and "Set Tracking for Inbound Document Properties" in the BizTalk Server Help.

Although performance is degraded when tracking is enabled, it remains a powerful tool for resolving issues related to XML document transformation and BizTalk Messaging Services in general.

Date and time settings

Date and time settings should be synchronized across all of the Web servers. Discrepancies in date and time settings can result in premature time-outs for users accessing the Web site.

HIPAA EDI document check points

When a HIPAA X12N document is received, errors can occur in several ways. This section describes these errors and their causes, as well as how to detect and resolve them.

The following check points should be considered when troubleshooting a problem with an Accelerator for HIPAA installation:

Message Queuing queues and file folders
Functional acknowledgements
XLANG schedule

Message Queuing queues and file folders

When Message Queuing receive functions are used to send documents to BizTalk Messaging Services, inbound documents are first placed in Message Queuing queues. When debugging Message Queuing problems, target journaling can be enabled to log all messages passing through these message queues.

Target journaling is the process of storing copies of incoming messages on the destination computer. Target journaling is configured on a queue-by-queue basis. If it is enabled, a copy of each incoming message is placed in the target journal queue when the message is removed from the queue.

Note Journaling should only be enabled while debugging and not under normal production conditions. When the configurable journal storage size limit is reached, journal messages cannot be sent to any journal queues on the computer until the cumulative size of journal messages in all queues drops below the specified limit.

To enable or disable target journaling:

Open the Computer Management administrative tool.
Navigate to:
1. Services and Applications
2. Message Queuing
3. <your_queue_folder> (such as Public Queues or Private Queues)
4. <your_queue>
Click Properties.
To disable target journaling for the selected queue, in the Journal section of the General tab, in Journal, select the Enabled check box.

To disable target journaling for the selected queue, clear the Enabled check box.

If errors occur in BizTalk Messaging, the message is left in the Suspended queue. These errors can include transformation errors or failure to transport the message to the XLANG schedule.

Note Message Queuing transactional queues depend on the Microsoft Distributed Transaction Coordinator (MS DTC) service. They will not function unless the MS DTC service is running.

If a document is delivered to BizTalk Server by using a File receive function, the document is first placed in a file folder. If an error occurs in processing, errors are logged in the application event log.

Functional acknowledgements

BizTalk receipt channels send functional acknowledgements (997s) to trading partners in response to EDI transmissions. The functional acknowledgements contain segments that indicate the status of the EDI transmission.

In case of an error, evaluate the contents of the 997 document that is generated in response to the EDI transmission to identify the error.

XLANG schedule

The XLANG schedule serves as a place into which custom business logic can be added. Any errors that occur during this simple processing will result in an error being logged to the Event Log on the BizTalk Server computer.

Failure Scenarios

Several different failure scenarios are possible with an Accelerator for HIPAA installation. These scenarios are related to the various Windows Server System servers used in the Accelerator for HIPAA solution, and what happens when one or more of them is not functioning correctly. The following scenarios will be described:

BizTalk Server is down
SQL Server is down

BizTalk Server is down

If the BizTalk Server computer is unavailable, the system will not be able to receive or send any transaction data. Documents that are placed in a file folder or in a Message Queuing queue will not be picked up for processing by a BizTalk Server File receive function or Message Queuing receive function respectively. Also, an entry will be created in the application event log to indicate that BizTalk Server is unavailable.

To recover from this failure, administrators should:

Ensure that there is connectivity between the BizTalk Server computers and the SQL Server computers.
Use the BizTalk Server Administration MMC snap-in to ensure that the BizTalk Messaging Service is running. The BizTalk Server Administration snap-in also enables administrators to view the Suspended and Retry queues. Messages in the Retry queue will be processed automatically, but messages in the Suspended queue need to be manually resubmitted to BizTalk Messaging. After the BizTalk Server has been brought back online, the administrator should select all of the messages in the Suspended queue, right-click, and then click Tasks and Resubmit.
View the XML messages, view errors associated with those messages, and delete messages from the Suspended queue.
Check the Windows Event Log for errors.

SQL Server is down

If the SQL Server computer is unavailable, the system will not be able to receive or send transaction data. The application event log will contain more information about the loss in connectivity between BizTalk Server and SQL Server.

To recover from this failure, administrators should:

Ensure that there is connectivity between the SQL Server computers and the BizTalk Server computers.
Use the Services applet in Control Panel to ensure that the MSSQLSERVER service is running.
Check the Windows Event Log for errors.

Monitoring the System

Service monitoring allows the operations staff to observe the health of an IT service in real time. Accurate monitoring of a system is a complicated puzzle within a distributed process environment, complicated even more by the integration with systems operated by trading partners. With this in mind, the following list is an example of system components that are typically monitored to ensure that the IT service remains available:

Process heartbeat
Job status
Queue status
Server resource loads
Response times
Transaction status and availability

However, knowing the current health of a service or determining that a service outage might occur is of little benefit unless the operations staff can do something about it, or at the very least notify the appropriate group that a specific type of reactive or proactive action needs to occur. This is what is meant by the term "control." When combined and implemented properly, this service management function provides the critical capability to ensure that service levels are always in a state of compliance.

Event Log

The Event Log is the main error message repository for the Windows Server System products used in Accelerator for HIPAA. Monitor the BizTalk Server-generated events that have an Event ID of 324.

System Monitor counters

Use System Monitor to measure the performance of your own computer or other computers on a network. System Monitor uses a series of counters that track data, such as the number of processes waiting for disk time, the number of network packets transmitted per second, and the percentage of processor utilization. With this data, you can create charts, set alerts, and format reports that enable you to gauge and tune system performance. Data can be displayed as it is collected, stored in log files for later use and comparison, or both.

Relevant performance counters can be categorized into the following groups:

Memory
Physical disk
SQL Server
BizTalk Server (MSCIS.EXE)
Message Queuing
System
Tools

Memory

The following table shows the memory performance counters that are of interest in the context of BizTalk Accelerator for HIPAA, and observations to be made related to each counter.

Counter	Observation
Available bytes	Available bytes should not stay below 10 MB consistently. If so, a memory spike would cause paging to disk to start.
Page faults/second, Pages input/second, Page reads/second	If these numbers are low, the server should be responding to requests quickly. If they are high, an increase in the amount of RAM on your server might be needed.

Physical disk

The following table shows the physical disk performance counters that are of interest in the context of Accelerator for HIPAA, and interpretations to be made related to each counter.

Counter	Interpretation
Disk reads and writes/second	Combined, these two counters should be significantly under the maximum capacity for the disk device. To enable this counter, on the Start menu, point to Programs, point to Accessories, and then click Command Prompt. At the command prompt, type diskperf –y. Then, restart the computer.
% disk time	This counter should be well below 100 percent. If it is above this value (and it can go into the 1000 percent range), add more physical disks or move one of the databases to another server.
Current disk queue length	This counter is the number of requests outstanding on the disk at the time the performance data is collected. This counter should average less than 2 for good performance.

SQL Server

The following table shows the SQL Server segment performance counter that is of interest in the context of Accelerator for HIPAA, and interpretations to be made related to that counter.

Counter	Interpretation
I/O transactions/second	Indicates how much activity the SQL Server computer actually performs.

BizTalk Server

The following table shows the BizTalk Server performance counters that are of interest in the context of Accelerator for HIPAA, and interpretations to be made related to each counter.

Counter	Interpretation
Documents processed/second	Indicates how quickly BizTalk Server 2000 is polling documents from its Work queue and sending them.
Documents received/second	Indicates how quickly BizTalk Server is sending documents to the Work queue. This number reflects only the number of documents BizTalk Server has received (this includes documents that fail parsing), not the number of documents BizTalk Server checkpoints to its Work queue. The number of documents that are checkpointed to the Work queue is essentially equal to the documents processed/second counter.
Synchronous submissions/second, asynchronous submissions/second	Indicates how quickly Submit method or SubmitSync method calls occur. Because each interchange can contain any number of documents, this counter is not useful for determining documents processed. If pass-through (processing interchanges without parsing them) is being used exclusively, this is the counter you need to monitor to determine inbound performance.

Message Queuing

The following table shows the Message Queuing performance counter that is of importance for the management of Accelerator for HIPAA, and interpretations to be made related to that counter.

Counter	Interpretation
Messages in queue	This number should not get extremely large (over 50,000) because it will cause excessive memory use on the Message Queuing server and degrade the performance of the entire system.

System

The following table shows system performance counters that are of interest in the context of Accelerator for HIPAA, and interpretations to be made related to each counter.

Counter	Interpretation
Processor queue length	This counter displays the number of threads waiting to be executed in the queue that is shared by all processors on the system. If this counter has a sustained value of two or more threads, the processor is degrading the performance of the entire system.
Context switches/sec	If this is a high number on BizTalk Server, it could be because send and receive functions are running on the same server. If this is the case, consider separating the send and receive functions to separate servers.
% processor time	If this counter's value is high, while the network adapter card and disk I/O remain well below capacity, the processor is affecting performance. On a multiprocessor computer, examine this counter to identify any imbalance. Additionally, while peak utilization can be 100 percent, sustained utilization should be below this value. All server elements can be scaled horizontally.

Tools

Three tools can assist in monitoring the Accelerator for HIPAA solution. These tools allow the system to be monitored locally or remotely and allow changes to be made to the system to counter threats and impending service interruption. These tools are important because they fulfill the Problem Management and Change Management functions of the IT Service Management paradigm.

Application Center. Provides COM+ load balancing, Windows IP load balancing, and local and remote system and event monitoring. Also provides consumption of virtually any management interface, counter, or event to provide automatic triggered actions to promote a healthy system state. Application Center also provides the ability to deploy Web and COM+ applications across clusters of machines.
Microsoft Operations Manager (MOM). Provides remote system and event monitoring. Also provides centralized event gathering and reporting. MOM also provides consumption of virtually any management interface, counter, or event to provide automatic triggered actions to promote a healthy system state.
System Monitor. Provides local or remote system monitoring and logging. Any service or device for which a monitoring interface exists can be viewed in real time through a graph or can be logged to a log file for a snapshot of performance variables over time.

XLANG Event Monitor

When the XLANG Scheduler Engine executes XLANG schedules, it generates many types of events that show the progress of the schedule instances. BizTalk Server provides a tool that you can use to monitor XLANG schedule events and to see the progress of the schedule instances. You can monitor the default XLANG Scheduler application, or you can monitor the custom COM+ applications that you create to host XLANG schedules. XLANG Event Monitor can subscribe to all events published by the host applications on local or remote computers. XLANG Event Monitor can also store these events to a file for future analysis.

XLANG Event Monitor can receive events from all XLANG schedule host applications on the local computer or from XLANG schedule host applications on one or more remote computers. When XLANG Event Monitor is installed, the default behavior is to receive events from the XLANG schedule host applications on the local computer. If you want to include events from XLANG schedule hosts on remote computers, you must click the EventSources option on the Recording menu and update the event sources to include remote computers.

You can find the XLANG Event Monitor application in the \Program Files\Microsoft BizTalk Server\SDK\XLANG Tools folder. Review the readme located in the same folder for more information about how to use XLANG Event Monitor.

BizTalk Server Administration

The BizTalk Server Administration snap-in allows users to monitor the status of BizTalk message queues, receive functions, and the BizTalk Messaging Service running on the BizTalk Server computers.

BizTalk message queues

BizTalk Server provides shared queue management capabilities in BizTalk Server Administration. The shared queues are maintained in the InterchangeSQ database. BizTalk Server administrators can move documents from any other queue to the Suspended queue. From the Suspended queue, documents can be deleted, resubmitted, or viewed, depending on the processing state of the document. BizTalk Server administrators can sort and display error messages for documents in the Suspended queue.

The following queues are used to contain incoming and outgoing documents that are in various stages of routing and processing in BizTalk Server:

Work queue. The Work queue contains documents that are currently being processed by BizTalk Server. Transactions in the Work queue do not remain in the queue very long because they are processed upon arrival. BizTalk Server administrators can select any document in this queue and move it to the Suspended queue.
Scheduled queue. The Scheduled queue contains work items that have been processed by BizTalk Server and are waiting for transmission based on the service window. BizTalk Server administrators can select any document in this queue and move it to the Suspended queue.
Retry queue. The Retry queue contains documents that are being resubmitted for delivery and documents that are waiting for reliable messaging receipts. You cannot tell the difference between the two types of transmissions. By default, failed transmissions are retried every five minutes for a maximum of three tries before they are moved to the Suspended queue. These numbers can be changed through BizTalk Messaging Manager in the Channel configuration or programmatically. BizTalk Server administrators can select any document in this queue and move it to the Suspended queue.
Suspended queue. The Suspended queue contains work items that have failed processing for a variety of reasons, including parsing errors, serialization errors, failed transmissions, or the inability to find a channel configuration. BizTalk Server administrators can right-click any document in this queue to choose any of the following options:
- View Error Description. Enables BizTalk Server administrators to view error descriptions that indicate why the document was sent to the Suspended queue.
- View Interchange. Enables BizTalk Server administrators to view the contents of an interchange that has failed processing for a variety of reasons, including parsing errors or failed transmissions.
- View Document. Enables BizTalk Server administrators to view the contents of a document that has failed processing for a variety of reasons, including serialization errors or the inability to find a channel.
- Delete. Enables BizTalk Server administrators to completely remove an entry from the Suspended queue. This action is not recoverable. After a document has been deleted from the Suspended queue, you cannot retrieve it.
- Resubmit. Enables BizTalk Server administrators to resubmit interchanges and documents to BizTalk Server for processing.
  
  Note Interchanges and documents appear in BizTalk Server Administration in the order of "first in, first out." That is, the oldest items in a queue appear first and the newest items appear last. Additionally, up to 15,000 interchanges and/or documents appear in a queue at a time. If there are more than 15,000 actual items in a queue, you must remove or resubmit current items in the queue so that newer items can be displayed. The queue count in the console tree—the number next to the queue in parentheses—represents how many items there are in the queue. You can resubmit or delete documents to remove them from a queue.

Receive functions

Receive functions enable BizTalk Server to monitor directories and queues, and then submit documents found in the directories and queues to BizTalk Server for processing. BizTalk Server 2000 supports File and Message Queuing receive functions.

BizTalk Messaging Service

BizTalk Messaging Service is used to configure BizTalk Servers in groups. All servers in one BizTalk Server group share document processing. It is possible to configure a BizTalk Server to do only receive actions by disabling work item processing on that server.

Event Viewer

The BizTalk Server Administration snap-in includes Event Viewer. BizTalk Server and Accelerator for HIPAA generate entries in the application event log for any errors.

BizTalk document tracking

When BizTalk Server is installed, the ability to track metadata for interchanges is automatically activated. However, the capability to store whole copies of documents or specific or custom fields, or to track action events related to messages processed by XLANG schedules, must be configured separately. This section provides an overview of the available tracking settings in BizTalk Server and when you might need to configure or adjust those settings.

Tracking settings for a server group

When BizTalk Server is installed, or when you add a new server group, the following tracking options for a server group are enabled by default:

Enable document tracking
Log incoming interchange
Log outgoing interchange

These settings allow BizTalk Server to store the metadata for interchanges and documents to the Tracking database. The metadata for interchanges and documents includes source organization information, destination organization information, document type, date and time the interchange was processed by BizTalk Server, document count, error information, and control ID.

This tracking setting applies to a server group and is configured in BizTalk Server Administration.

Tracking settings in channels and document definitions

The ability to store whole copies of documents or to store standard and/or custom fields is not automatically enabled. These options are configured in the appropriate channel or document definition. If channels and document definitions were not configured to track documents or standard and/or custom fields as part of the initial BizTalk Server deployment, be judicious about configuring these settings. Configure tracking settings in BizTalk Messaging Manager only if you need to:

Store complete copies of incoming and outgoing document instances
Track specific fields
Track custom fields

If you turn on all the tracking settings in a channel and/or document, you will store redundant data. This will cause the Tracking database to grow quickly. If the Tracking database gets too large and if you do not regularly perform archiving operations during maintenance, the performance of BizTalk Server will be negatively impacted.

Securing the System

There are a number of different aspects to the security of an Accelerator for HIPAA installation. They can be categorized as follows:

Service accounts
Controlling document submission
Using certificates
Internet protocol security monitor
Advanced configuration of channel properties
Securing document exchange between trading partners

Service accounts

BizTalk Server should be run under service accounts rather than interactive user accounts. With interactive user accounts, a user must be logged on to the computer for the application to run. In other words, if BizTalk Server is set up to run under an interactive user account, and if that particular user is not logged on, BizTalk Server will not process any documents.

When BizTalk Server is installed, the account identity can be configured to run under a service account. However, the default XLANG Scheduler application, any new COM+ applications that you create, and the BizTalk Server Interchange Application default to an interactive user account. There are several potential problems with using an interactive user account, including:

If the user logs off, the application stops running.
If a malicious hacker obtains the user name and password for the interactive user account, the hacker could do a lot of damage.
If an application is running on a computer while an administrator is logged on, the application runs under the identity of the administrator and could make calls on behalf of the client by using the permissions possessed by the administrator. To prevent this, it is recommended that you create a service account and use the service account to run BizTalk Server.

For more information about settings for service accounts, see the topic "Create a service account" in the BizTalk Server Help.

Controlling document submission

Controlling the ability of a user to submit interchanges and documents to BizTalk Server provides yet another layer of security. The following properties for the BizTalk Server Interchange Application are configured inside the Component Services console to control who can send interchanges and documents:

Authentication level
Impersonation level
Access permissions
Launch permissions
Configuration permissions

Using certificates

If your deployment of BizTalk Server includes the use of certificates, it is recommended that you associate all certificates with a computer instead of with a specific user. This means that when you issue a certificate, you must do one of the following:

If you created a service account for BizTalk Server, log on using the service account you created.
Specify that you want the certificate associated with the computer and not with a specific user when you issue the certificate. This is so that all applications using the system account can access the private key of the certificate.

If you associate a certificate with a specific user, BizTalk Server must be configured to run with the credentials of that specific user. Additionally, if you have certificates associated with multiple users, the administration tasks can increase significantly. However, if a certificate is associated with the computer, any valid user can be logged on and the validity of the certificate is not affected.

If your business process requires that you associate certificates with specific users, you must store the certificates in the Certificates (Local Computer) item in the Certificates snap-in. BizTalk Server does not check the user store for certificates. In addition, if a password for a user changes and that user is associated with a certificate, you must update the following two applications:

BizTalk Server Interchange Application
BizTalk Messaging Service

For more information about certificates and BizTalk Server, see the topic "Certificates Overview" in the BizTalk Server Help.

Internet Protocol Security Monitor

Windows 2000 provides the Internet Protocol Security (IPSec) Monitor to confirm whether secured communications are successful. It displays the active security associations on local or remote computers. For example, the IPSec Monitor can be used to determine whether there has been a pattern of authentication or security association failures, possibly indicating incompatible security policy settings.

The IPSec Monitor can be used to monitor Security Associations (SAs), IPSec, and Internet Key Exchange (IKE) statistics. To start the IPSec Monitor, click Start, click Run, and then type ipsecmon.

Advanced configuration of channel properties

When you create or edit a channel, you can configure the channel to override the messaging port properties if necessary. This allows you to send interchanges and documents to password-protected folders, message queues, ASP pages, and so on. User names and passwords can be associated with a channel and messaging port combination for the following transport services:

File
HTTP and HTTPS
SMTP
Message Queuing

To associate a user name and password with a channel and messaging port combination, click Advanced on the Advanced Configuration page of the Channel Wizard. Verify that the Primary Transport tab is selected and then click Properties. Type a valid user name and password. If necessary, you can change other relevant information such as the name of the message queue location or the From address if you are using SMTP.

Securing document exchange between trading partners

To facilitate the exchange of secure information between trading partners, BizTalk Server uses security features offered through Microsoft Windows 2000 and SQL Server. The following list includes some of the Windows security features used by BizTalk Server:

Authentication. Authentication verifies the identity of a user who is logging on to a computer.
Public key infrastructure. Public key infrastructure is a set of policies, procedures, and technologies used to securely exchange information between trading partners. Elements of public key infrastructure include a public key, a private key, certification authorities, and digital signing. BizTalk Accelerator for HIPAA can be configured to perform certificate-based encryption and decryption of transmitted documents.

For more information about planning your public key infrastructure by using Secure Sockets Layer (SSL) and Secure Multipurpose Internet Mail Extensions (S/MIME), search for the phrase "Public Key Infrastructure" on the Microsoft TechNet Web site.
Digital signatures. Digital signatures are a guarantee that a document has not been altered after the digital signature was added. Digital certificates are used to ensure that the sender is not an impersonator. BizTalk Accelerator for HIPAA can be configured to perform X.509-based digital signatures and signature verification on transmitted documents.
Multipurpose Internet Mail Extensions (MIME). MIME is a standard encoding method used to transmit data through Internet e-mail. When data is sent, it is encoded. When data is received, it is decoded. The file header includes the information that the recipient needs to decode the information.

For more information about MIME, see About Simple Internet (RFC 822) Messages.
Secure/Multipurpose Internet Mail Extensions (S/MIME). S/MIME is the secure version of MIME. Before data is sent, it is encrypted to guarantee secure transmission and signed to ensure the identity of the sender.
Secure Sockets Layer (SSL). Secure Sockets Layer uses a randomly generated private key that can be used only for that session. At the beginning of a session, the server sends the public key to the browser. The browser randomly generates a private key and sends it back to the server.

For more information about SSL, see Using Schannel CSPs.

Planning for Capacity

The capacity management process involves planning, sizing, and specifying the capacity of IT services to meet user needs at levels agreed upon with external customers or for internal IT needs. Accelerator for HIPAA solutions will benefit from engaging in capacity planning early in the design process and repeating it at regular intervals because of auditing requirements that most customers will implement as part of achieving HIPAA compliance. Capacity management will ensure that IT resources will be available to meet business requirements though planning for expansion, analysis, design, specification, implementation, and monitoring activities. Key subprocesses within capacity management include:

Demand management. Ensures that future business needs are translated into IT requirements and implemented in a timely fashion. Examples of demand management planning activities around Accelerator for HIPAA solutions are:
- Estimating the volume of enrollments based on signing large new corporate customers. These enrollments can include thousands or even millions of new subscribers and can occur at periodic intervals (quarterly or year end).
- Estimating the volume of new electronic transactions such as claims (837/835) or eligibility (270/271), based on acquisition of new provider customers as they migrate from paper-based solutions or older non-HIPAA-compliant electronic systems.
Workload and resource management. Analysis and translation of customer demands for services into workloads to be sustained by IT solution components.

Electronic document processing such as 837 claims can be translated into volumes of documents to be handled by individual BizTalk Servers within a group or across multiple servers. A strategy can then be developed for load balancing based on group membership or on specific characteristics of the submitted document (for example, document size or document origin).
Performance management. Monitoring, analysis, reporting, and planning for performance of IT solutions to meet customer and internal requirements. Examples of performance management planning activities around Accelerator for HIPAA solutions are:
- Configuring performance counters for key Windows 2000, SQL Server, and Accelerator for HIPAA components to evaluate solution performance.
- Using orchestration to track latency in processing documents as they flow through the Accelerator for HIPAA solution.

Key parameters to consider for capacity management in Accelerator for HIPAA solutions include:

Number of users (business partners)
Number and types of transactions
Size of individual transactions
Timing windows for processing
Response time requirements for real-time transactions
Need for encryption and digital signatures
Number of servers
Kinds of receive functions
CPU and memory
Disk read/write speed
Network utilization
Mapping complexity
Number and type of functoids
Number of COM components
Orchestration complexity
Archiving requirements (how long, what format)
Trading partner and internal service requirements

Monitoring Accelerator for HIPAA solutions for performance purposes can be done by using the integrated performance monitoring support of the Windows operating system, SQL Server, and BizTalk Server 2000. By using the Windows API, it is possible to add your own performance counters to your AICs and preprocessor components.

For more information about configuring and interpreting the Windows 2000 performance counters, see Microsoft Windows 2000 Operations Guide, part II and Microsoft Windows 2000 Performance Tuning Technical Reference.

For more information about configuring and interpreting SQL Server 2000 performance counters, see Microsoft SQL Server 2000 Resource Guide.

For more information about configuring and interpreting Microsoft BizTalk Server 2000 performance counters, see Microsoft BizTalk Server 2000 Documented, chapter 3, page 95, "Enhancing the Performance of a Configuration."

For more information about adding performance counters to COM components, see Adding Performance Counters in the Microsoft Platform SDK.

Planning for Scalability

Scalability planning is an important part of the planning process for Accelerator for HIPAA solutions. The goals of scalability planning are:

Increase number of users per server
Increase total number of concurrent users the solution can support
Decrease the latency or response times

The following options are available through scalability planning:

Optimizing the application through redesign or tuning
Scaling up (larger, faster devices with more CPUs, memory, or drive space)
Scaling out (adding additional servers in parallel)

Option	Pros	Cons	Accelerator for HIPAA scenarios
Optimizing application	Identifies opportunities for improving performance, manageability, and functionality.	Might not be possible due to legacy code or to inadequate time, documentation, or developer skills.	BizTalk Server applications can be optimized for performance by reducing the amount and complexity of mapping, using functoids, and disabling logging features when not needed.
Scaling up	Can take advantage of multithreaded applications on multiple CPUs. Might reduce some licensing costs and complexity of management with single application image. Memory-intensive services (like databases) can benefit.	Higher entry cost for hardware. Might have reduced uptime. Risk of single platform failure.	BizTalk Server can run on multiple-processor Windows 2000 Server machines for enhanced performance. Large documents will benefit from additional memory because of the SQL Server database implementation for persistence.
Scaling out	Improved availability and capacity addition without downtime. Easier maintenance. Linear cost of increasing capacity.	Load balancing might be difficult and more expensive to implement. Multiple boot and load images. Might have increased management costs because of multiple servers unless best practices are applied.	BizTalk Server groups are a standard way to easily add more document processing capability.

Optimizing application

Identifies opportunities for improving performance, manageability, and functionality.

Might not be possible due to legacy code or to inadequate time, documentation, or developer skills.

BizTalk Server applications can be optimized for performance by reducing the amount and complexity of mapping, using functoids, and disabling logging features when not needed.

Scaling up

Can take advantage of multithreaded applications on multiple CPUs.

Might reduce some licensing costs and complexity of management with single application image.

Memory-intensive services (like databases) can benefit.

Higher entry cost for hardware.

Might have reduced uptime.

Risk of single platform failure.

BizTalk Server can run on multiple-processor Windows 2000 Server machines for enhanced performance.

Large documents will benefit from additional memory because of the SQL Server database implementation for persistence.

Scaling out

Improved availability and capacity addition without downtime.

Easier maintenance.

Linear cost of increasing capacity.

Load balancing might be difficult and more expensive to implement.

Multiple boot and load images.

Might have increased management costs because of multiple servers unless best practices are applied.

BizTalk Server groups are a standard way to easily add more document processing capability.

For more information about tuning Accelerator for HIPAA solution performance, see Microsoft BizTalk Server 2000 Documented, chapter 3, "Enhancing Performance and Scalability."

For more information about improving BizTalk Server Messaging performance, see Optimizing BizTalk Messaging Services.

For more information about optimizing XLANG orchestrations, see Optimizing the Contents of XLANG Schedules.

Tuning the System

When considering performance, it is important to first determine where performance is needed most. Because tuning techniques vary for the different Windows Server System servers used in Accelerator for HIPAA, they are discussed separately in this section:

BizTalk Server
SQL Server

BizTalk Server

This section provides general recommendations for optimizing system settings, and includes topics about optimizing BizTalk Server settings to increase performance. These recommendations include:

BizTalk Server performance can be optimized by using the BizTalk Server Administration console to configure the number of threads assigned for receive processing and for BizTalk Messaging Service. Use System Monitor to evaluate the following BizTalk Server counters: documents received per second and documents processed per second. If documents received per second is well below documents processed per second, then increase the number of threads assigned to receive processing. Similarly adjust the number of threads assigned to BizTalk Messaging Service.
Optimize Microsoft Windows 2000 settings. Apply best practices, such as not running unnecessary services or protocols, to improve Microsoft Windows 2000 performance. Many techniques used to optimize Windows 2000 can also be used to optimize BizTalk Server. For more information about optimizing Microsoft Windows 2000 settings, see "Best Practices" in Windows 2000 Help.
Maintain fast, reliable network connectivity between transport services, BizTalk Services (BizTalk Orchestration Services and BizTalk Messaging Services), and the databases (100 megabits per second or higher Ethernet). To optimize network throughput, use multiple adapters in each server, with a unique switch port for each, with inbound and outbound transactions separated between the network interface cards (NICs).
Do not replicate the default XLANG Scheduler application or any COM+ applications that host XLANG schedules. If Component Load Balancing (CLB) is used, these COM+ applications must be installed on each server. You can replicate COM components that are bound to XLANG schedules.
Document tracking degrades performance and should be run to debug issues with BizTalk Messaging Service or as required by business processes. If possible, document tracking should be kept to a minimum.
The BizTalk Servers run memory-intensive processes, including XML document transformation that loads into memory the XML document being transformed. Performing larger size or higher volume XML document transformations will require additional physical system memory; therefore, add as much memory as possible.
In high-volume environments, configuring the receive functions and BizTalk services on the same server degrades the performance of both. Additionally, if Secure Sockets Layer (SSL, also referred to as HTTPS) is used to receive documents, performance is degraded further due to decryption processing. Depending on the security needs of an organization, data might need to be encrypted using HTTPS. This added level of security might affect the performance of BizTalk Server. To improve performance, the Web server and BizTalk Server could be run on different machines. The separation introduces a latency due to cross-machine calls. As a result, your gain in performance might vary.
BizTalk Server is a native HTTP/HTTPS client. If a channel is configured to use HTTP/HTTPS as its outbound transport service, BizTalk Server uses HTTP/HTTPS to send data to a trading partner's HTTP/HTTPS server. You cannot move the HTTP/HTTPS outbound transport service to a separate server from the server on which BizTalk Messaging Services resides. If a server is configured to participate in work-item processing and it processes a document that uses an HTTP/HTTPS transport service, this same server sends the document.
BizTalk Server functions as an HTTP client, which affects the document-serializing power of the server. If the port is using HTTPS, the performance of the HTTP transport service is greatly affected. SSL accelerator cards cannot be used when acting as an HTTPS client because these cards only enhance HTTPS server performance.
To optimize performance for the HTTP/HTTPS service, which enhances the performance of BizTalk Server, configure the inbound ASP page on a server separate from BizTalk Server. If the inbound HTTP/HTTPS receive service cannot be installed on a separate server, use a faster CPU or add more CPUs.
Increase the CPU MHz that is required for BizTalk Server (to accommodate the additional need for sending documents) and add additional CPUs until the desired performance level is achieved.
Apply best practices when using ASP pages with the receive or send HTTP/HTTPS service. For more information about optimizing ASP pages and Internet Information Services, go to the Internet Information Services Help Web site (localhost/iisHelp) and click Active Server Pages Guide.
Message Queuing receive functions are highly desirable because documents can be received from a queue within a transaction. Also, security can be assigned to a queue. Note that Message Queuing imposes a maximum limit of 4 MB (2 MB for Unicode) on the document size. In addition, a Message Queuing receive function can be used securely with external trading partners provided that it is combined with another transport, such as SMTP or HTTP. Accept a document from a trading partner (using HTTPS or S/MIME for security) and write the file to a queue. Then BizTalk Server can use a Message Queuing receive function to receive the document. This combination of transports might not increase performance, but it will provide greater flexibility and security. To optimize performance for the Message Queuing receive function, use a private queue rather than a public queue to reduce the latency involved in directory lookup for the public queue.
To optimize performance for the File receive function and File transport service, which enhances the performance of BizTalk Server, use a local file directory rather than a remote file directory to reduce network latency.
To optimize performance for the File receive function and File transport service, which enhances the performance of BizTalk Server, use disk arrays to achieve high throughput. For more information about disk array speed and redundancy tradeoffs, see "Scale Up the Databases" in BizTalk Server Help.
BizTalk Server performance is significantly degraded if a digital certificate is needed to S/MIME-encode the outbound document.
When optimizing performance of SMTP, which enhances the performance of BizTalk Server, the performance level achieved depends greatly on the SMTP service that is used for receiving documents. An organization might have an SMTP server that is used to perform this function. However, if an SMTP server is not available and an organization chooses to use Microsoft Exchange Server or another third-party messaging system, the server might need a significant amount of additional hardware to maintain an adequate performance level for BizTalk Server. The SMTP server must be able to invoke an event-based mechanism that is capable of sending documents to BizTalk Server.
If an organization chooses to run BizTalk Server on an SMTP server, CPU performance will be impacted. To minimize the impact to performance, use a faster CPU.
If an organization uses S/MIME, BizTalk Server performance is significantly degraded. To reduce the overall performance impact of S/MIME on BizTalk Server, use faster CPUs.
For additional BizTalk Server tuning parameters, see the Microsoft BizTalk Server product documentation.

SQL Server

Performance characterization testing has shown that SQL Server is not a cause of poor performance in Accelerator for HIPAA. However, care should be taken to ensure that stored procedures, indexes, tables, and the databases that are accessed by a custom application are optimized for performance.

SQL Server Profiler is a tool that captures Microsoft SQL Server events from a server. The events are saved in a trace file that you can analyze or use to replay a specific series of steps later when you are trying to diagnose a problem. You can use SQL Server Profiler to:

Step through problem queries to find the cause of the problem.
Find and diagnose slow-running queries.
Capture the series of SQL statements that lead to a problem. The saved trace can then be used to replicate the problem on a test server where the problem can be diagnosed.
Monitor the performance of SQL Server to tune database performance.

For additional SQL Server tuning parameters, see the Microsoft SQL Server Books Online.

Managing Availability

The singular goal of availability management is to ensure that the customer can use a given IT service at any time. High availability for a service solution begins with the requirements phase of the project. Accelerator for HIPAA has a solid architecture, and the Windows platform provides a solid foundation for an effective availability strategy. It cannot, however, be stressed enough that the most critical success factor for availability lies in the processes in place as underpinning elements of availability management and the people who manage and work within them. Examples of underpinning elements include document exchange, document receipts, and incident management. The following section indicates at a high level some of the tools and strategies for managing availability for Accelerator for HIPAA.

BizTalk Server

Failure. A departure from the expected behavior of an individual computer system, networked system, or component. A failure might or might not impact availability. Failure of services can be detected, escalated, and recovered from automatically by using Microsoft Operations Manager or Microsoft Application Center.
Reliability. A measure of the time between failures occurring in a system. The reliability of Accelerator for HIPAA can also be enhanced by using Application Center to provide clusters of BizTalk Servers, or Windows Load Balancing Service can be used alone to provide clustered BizTalk Servers.
Availability. A measure of the amount of time a system or component performs its specified function. In other words, can the end user/customer perform the intended function? This objective can be addressed with the use of Application Center and Microsoft Operations Manager to provide monitoring, recovery, and clustering.
Maintainability. The ability of a component or an IT service to perform its required functions when maintenance is performed under stated conditions and by using prescribed procedures and resources. Clustered solutions provide the ability to allow service continuity during maintenance tasks.

SQL Server

Failure. A departure from the expected behavior of an individual computer system, networked system, or component. A failure might or might not impact availability. Failure of services can be detected, escalated, and recovered from automatically by using Microsoft Operations Manager or Microsoft Application Center.
Reliability. A measure of the time between failures occurring in a system. Microsoft Cluster Server provides the ability to have SQL Server use different nodes to reduce downtime. Microsoft Cluster Server allows SQL Server to fail over to other machines in the cluster if the current machine has any type of failure.
Availability. A measure of the amount of time a system or component performs its specified function. In other words, can the end user/customer perform the intended function? Microsoft Cluster Server provides the ability to fail services to other nodes to promote availability. It also supports failback policies that allow services to return to their original nodes when a failure is resolved.
Maintainability. The ability of a component or an IT service to perform its required functions when maintenance is performed under stated conditions and by using prescribed procedures and resources. Microsoft Cluster Server provides the ability to fail services to other nodes to facilitate maintenance.

Managing the BizTalk Accelerator for HIPAA Configuration

Configuration management is responsible for tracking all of the hardware, software, and documentation components that make up the total IT environment. These items are tracked within the Configuration Management Database (CMDB) and kept up-to-date as part of the change management process. The CMDB is typically a relational database, and can be used to determine which users and services will be affected by bringing down a specific server for maintenance or upgrade. Each Configuration Item (CI) in the CMDB refers to a specific hardware or software component, and the database is used to keep track of the relationships among these entities. Change management maintains the authority to approve changes in CIs in the environment.

Configuration management focuses on the following core activities:

Planning the configuration management process
Identification of CIs
Status accounting and reporting (baselines, audit results, CI status, license status, problems, rate of change)
Verification of CIs
Audit of CIs

Examples of Configuration Items (CIs) for a line-of-business solution using Accelerator for HIPAA are:

Physical servers
Network cards
Operating system
Service Packs
Hotfixes
WebDAV repository location (path)
Document specifications (file name)
Mapping specifications (file name)
AICs (file name and path)
Preprocessors (file name and path)
Certificates
Orchestrations (.skv/.skx files)
Scripts (file name and path)
COM components (file name and path)
Script components (file name and path)
Management tools (file name and path)
Message queues (name)
File folders (path)
Receive functions (name, target address, type, channel or document specification)
Web servers and services (URL and file name)
Performance counters (name)
Log files (file name and path)
Event logs (file name and path)
BizTalk Server groups
BizTalk Server servers
Channels
Ports
Envelopes
Document definitions
Organizations
Registry keys
Application files and location
Documentation (operations guides, procedures, policies, references, help locations)
Databases
SQL Server groups
Connection strings
Backup devices (names and file paths)
Support personnel
Licenses
Service level agreements (trading partner and internal IT requirements)
Trading partner agreements
Networking components (routers, switches, hubs)
Load balancing components
Firewall and proxy components
Vendors
Incident and problem records
Definitive software library (location and catalog)

It is useful to create separate CMDBs for both the development/test and production environments.

The precise level of granularity for the CMDB depends on the resources available for management and the kinds of monitoring activities desired. With Accelerator for HIPAA solutions, which will undergo versioned updates in document specifications and therefore in many other components, it is recommended that a finer granularity be maintained. This facilitates auditing for compliance checking, because both legacy LOB systems and HIPAA transaction standards will continue to change and evolve over time. The key tradeoff decision to be made is to define CIs at the level where maintenance is affordable and the granularity of the information is useful to the other Service Management Functions that draw upon the CMDB.

Going into Production

Release management focuses on coordination and management of a release to the production IT environment.

Definitive Software Library (DSL)

The DSL is the repository in which the elements that make up the release are stored under secure conditions. Software stored in the DSL can be used to restore the environment after catastrophic failure or as a means for archiving earlier production versions. For Accelerator for HIPAA solutions, it is essential that the production environment be archived within the DSL following successful audits for compliance. This provides a basis for recovery of the technology environment should an implementation require rollback from an unsuccessful change or recovery from disaster.

The DSL should at a minimum contain the following components for any single Accelerator for HIPAA solution release:

Windows 2000 Server installation source
Windows 2000 Service Packs and hotfixes
SQL Server 2000 installation source
SQL Server 2000 Service Packs and hotfixes
Accelerator for HIPAA installation source
Accelerator for HIPAA service packs and hotfixes
Microsoft Visio® 2000 Standard SR-1 installation source
Source code, binaries, and installation source for custom AICs, preprocessors, and COM components used in orchestrations or to connect to legacy systems
Orchestration schedule .skv and .skx files
Source code for Windows Script Components used in orchestrations
Build scripts for configuring SQL Server databases
Build scripts for configuring Accelerator for HIPAA (ports, channels, receive functions, document definitions, organizations, envelopes)
Configuration scripts
Detailed step-by-step build instructions
Backup of SQL Server database holding baseline BizTalk Server configuration
Restoration instructions to recover configuration from most recent backups
Any custom components or scripts used to build or configure the Accelerator for HIPAA solution
Description of version information for each component in the release
Test X12 EDI documents used to assess compliance with the design specification and HIPAA requirements
Test legacy system data sets to assess compliance with the design specification and HIPAA requirements
Version of the implementation guides and the Accelerator for HIPAA document schemas for the EDI transactions supported by the Accelerator for HIPAA solution

Getting Assistance

Microsoft Consulting Services (MCS) offers services and products to assist in the delivery of solutions around BizTalk Accelerator for HIPAA. MCS provides services related to the critical points for integrating Accelerator for HIPAA into your organization, such as interoperability, integration, and security. Together with products and services, MCS can assist in planning, developing, and deploying complete solutions to solve your business problems. MCS can help to address other critical HIPAA concerns with flexible solutions to fulfill the unique needs of customers. For more information, see:

Microsoft Consulting Services

Microsoft's Vision and Strategies for Healthcare

Additional Resources

The following resources provide additional information about the corresponding subject areas:

Microsoft Operations Framework

Microsoft BizTalk Server

Microsoft Application Center

Microsoft Operations Manager

Appendix: Additional Security Recommendations

Deploying Microsoft Operations Manager

Microsoft Operations Manager (MOM) can require an enterprise-class database. A best practice is to deploy MOM using a clustered implementation to enhance the availability of critical auditing data. MOM offers management packs that are ready-made rules for monitoring and consolidating events related to individual applications. It is recommended to use these where applicable. The following steps provide a summary of how to deploy MOM to consolidated security events. Microsoft Consulting Services can provide assistance with deploying MOM.

General recommendations

Create a new database on the existing SQL Server database cluster or deploy a separate cluster server to house the MOM event consolidation database.
Consult the Microsoft Operations Manager site for more information about deploying MOM.
It is recommended to place MOM agents on each computer in the architecture.
A custom monitoring resource will need to be set up to manage and consolidate security events.
It is recommended to place the database in a secure zone.
Consolidation and reporting servers should be located in secure zones.
The instructions here are specifically designed for configuring a MOM consolidation server and all of its centralized services inside a firewall that only allows specific ports through. MOM has specific ports that it communicates on by default, but these can be changed. The following information assumes that the MOM server in the secure zone will be separated from the client servers in the perimeter network (also called demilitarized zone or DMZ) by a firewall. The firewall is assumed to allow communication between the client server and the MOM consolidation server over the necessary ports. MOM can be deployed to take automatic actions/trigger events on client machines that are within the firewall. Because this level of interaction requires RPC communication, it cannot be achieved over a firewall unless RPC port ranges are open between client and server.

Installing MOM and preparing a new configuration group

As a best practice, install redundant MOM servers that use the same database components.
Install MOM by using the custom configuration option.
Installation notes:
- Only one reporting server is needed per configuration group. This can also be done on a separate workstation if desired.
- Choose to install to a remote database and point to the MOM database for the enterprise.
- MOM should be installed as an agent manager and data consolidator.
Configure the MOM server:
- Add a new computer group to the Rules, Computer Groups section called "BTA4H".
- Add a rule for the client server to be included in the computer groups.
- Add a rule to the computer group.
Configure the MOM server:
- Commit changes by right-clicking Rules and selecting Commit Configuration Change.
- Initiate managed computer scan for the relevant agent manager.

Manual MOM Agent Install on client machines

Run the setup program from the Manual Agent Install Directory on the MOM CD.
Choose to Install a new Configuration.
Choose to Join the Computer to the Appropriate Configuration Site.
Add the Configuration Site Name.
Add the Consolidator Name.
Add redundant consolidator names.
Open Advanced Options.
Select the appropriate ports for MOM communications. (Be sure that the configuration group of which the server is a member uses the same communication port rules as those selected.)
Select the Bottom (None) Configuration option Install. This is the installation for clients outside of a firewall (minimum) and does not support Managed Agents.

Preparing the network for a new computer

Complete Manual Agent Install on client servers. (See the preceding section.)
Configured a DNS entry for the client servers if they are located in another zone.
- Create a host record with the same host name as the Managed Node with no DNS suffix.
- Create a host record with the same IP address as the client server.
- Create a host record in the same domain as the MOM server.
Configure the Consolidator and Redundant Consolidators to see the newly installed agent.
- Add the remote server names to a text file named ManualMC.txt. The names must consist of only the host name without domain suffixes. There must be no white space at the beginning of the list and no white space before or after a host name. There must be a carriage return after the last host name.
- Place the text file on the MOM server in the directory: Program Files/Operations Manager/One Point.
- Add a rule specifically including the computer to the properties sheet of the "BTA4H" Computer Group (see: Preparing A New Configuration Group).
- Add a rule specifically including the computer to the Managed Computer List of the Agent Managers off the appropriate MOM Consolidator and redundant Consolidator computers. The rule should have "wildcard" as the selection criterion and * for the domain name. The rule should also specifically indicate the host name of the computer in the computername selection area.
- Right-click the configuration node in the MOM Admin console and select Commit Changes Now.
- Initiate a Managed Computer Scan.

Create a processing rule to consume event logs

If this MOM implementation is to be used only for Security Auditing and Reporting, it is recommended that all Rule Processing Groups be removed from within the MOM Management Console under the Rules, Processing Rules Groups Folder.
Right-click the Processing Rules Group folder, click New, and then click Processing Rule Group.
Under the New Event Processing Rule Group, right-click Event Processing Rules, click New, and then click Event Processing Rule.
In the dialog box, select Collect Specific Events and click Next.
Under Provider Name, select Security, and click Next.
Select the Of Type check box and select Error from the drop-down list. Click Next.
Click Store All Event Parameters and then click Next.
Select Always Process Data and then click Next.
Enter any custom information that you would like to be added to the knowledge base when this event is fired. Click Next.
Enter a name for the processing rule and click Finish.
Repeat to create other Event Processing Rules in which the "of type" selection indicates these events: Warning, Information, Failure Audit, and Success Audit.
In the MOM Management Console, under the Computer Groups folder, right-click the BTA4H Computer Group and click Properties.
On the Processing Rules tab, click Add.
Select the Processing Rules Group in which the processing rules created earlier were placed.
Click OK to exit. Click Apply.

Create a notification (alarm) that corresponds to a security event

In the MOM Management Console, under a new or previously created Rule Group, right-click Alert Processing Rules, click New, and then click Alert Processing Rule.
On the first page of the wizard, select Only Match Alerts Generated By Rules in the Following Group and click Browse.
Browse to and select the processing rule group created in the preceding section.
Click OK to exit and then click Next to proceed to the next page of the wizard.
Select Always Process Data and click Next.
Click Add and select Send a notification to a Notification Group.
On the Notification tab, click New.
Create a name for the notification group.
Select New Operator to create a New Enabled Operator. Define the e-mail address and notification times. Define the pager address and times. Define any custom notification commands and times. Click Finish to exit the New Operator Wizard.
After you have exited the New Operator Wizard, you will be back to the Notification Group Properties dialog box. Select the Newly Created Operator from the right pane called Available Operators. Select any desired Operators and use the arrow buttons to move them to the left pane called Group Operators.
Click Finish to complete the Notification Group Properties dialog box.
You will be returned to the Notification tab. Be sure that the newly created Notification Group is selected in the drop-down list.
To customize e-mail, page, and command formats, select the corresponding tab. It is possible to add additional variables to notifications to increase the amount of information that the operator receives.
Click OK to exit the notification properties sheet. Click Next to proceed to the next page of the wizard.
If needed, add any additional information to identify the notifications for addition to the company knowledge base. Click Next.
Name the Response Rule. Be sure the Enabled check box is selected. Click Finish.

Configuring Auditing in SQL Server 2000

Determine which tables or views relate to each type of user that you will support. Only the minimum necessary information should be accessed.
Group the users with similar access requirements into roles. Create Microsoft Active Directory® groups that relate to these roles. Give each of the users an Active Directory user account. Place each user in the group that relates to that user's role.
In SQL Server Enterprise Manager, locate the database that the groups/roles will access.
Double-click the database to expand the nodes beneath it.
Right-click Users and click New Database User.
In the Login Name drop-down list, select <NEW>.
Beside Domain, select the domain in which the groups were created.

Note If the groups and users are in another domain, forest, or Kerberos realm, implement trusts to be able to browse for them as desired and give permissions as desired. See the Windows documentation for more information about implementing trusts.
Click the ellipsis beside Name and browse for one of the groups. Select the group and click OK.
Select the default database for the user.
On the Database Access tab, specify the databases that the users/role can access and the role of users/role in each database.
Click OK to exit to the database Users Dialog Box.
Select All from the Audit Level Section.
Select the newly created login from the Login Name drop-down list.
Specify the role for this login.
Click OK to exit.
In the nodes under the database, select Tables.
In the details pane, right-click any table with sensitive data and select Properties.
On the General tab, click Permissions.
Select the role/group and edit permissions. To edit Permission on Fields, select the role/group and click Columns.
Repeat this process for each table and group.
Alternatively, you can group map roles/groups to stored procedures that access information.
Alternatively, you can use COM+ and map permissions to roles.
Alternatively, you can enforce roles programmatically from within the business rules of the application.

Microsoft BizTalk Accelerator for HIPAA

Contents

Introduction

Audience

About This Guide

Prerequisites

Operational Reference Model

Microsoft Operations Framework

Operations Infrastructure

Reporting Model

Business Disciplines Required

Business managers

Developers

Testers

System administrators

Change Management Model

Operational Activities

Gap Analysis

Ongoing Operations

Trading partner configuration

Report analysis

Document specifications

Maps deployment

Application component deployment

Change Management

XML schemas and BizTalk maps

New transactions

SQL Server connection strings

COM+ components

System DLLs

Backup and Restore

Implementation backup

Implementation restore

Database backup

Data restore

Minimizing backup and recovery times

Database Maintenance

Troubleshooting

General check points

HIPAA EDI document check points

Failure Scenarios

BizTalk Server is down

SQL Server is down

Monitoring the System

Event Log

System Monitor counters

Tools

XLANG Event Monitor

BizTalk Server Administration

BizTalk document tracking

Securing the System

Service accounts

Controlling document submission

Using certificates

Internet Protocol Security Monitor

Advanced configuration of channel properties

Securing document exchange between trading partners

Planning for Capacity

Planning for Scalability

Tuning the System

BizTalk Server

SQL Server

Managing Availability

BizTalk Server

SQL Server

Managing the BizTalk Accelerator for HIPAA Configuration

Going into Production

Definitive Software Library (DSL)

Getting Assistance

Additional Resources

Appendix: Additional Security Recommendations

Deploying Microsoft Operations Manager

General recommendations

Installing MOM and preparing a new configuration group

Manual MOM Agent Install on client machines

Preparing the network for a new computer

Create a processing rule to consume event logs

Create a notification (alarm) that corresponds to a security event

Configuring Auditing in SQL Server 2000

Additional resources