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). (35 printed pages)

Introduction
    Audience
    About this Guide
    Prerequisites
    About HIPAA
    About EDI
    About BizTalk Accelerator for HIPAA
Preparation and Assessment
    Individual Preparation
    Training
    Infrastructure
    Project Assessment Questions
Vision and Scope
    The Vision/Scope Document
Planning
    Gap Analysis
    Planning Phase Tasks by Role
    Determining the Project Size
    Implementation Cost and Time
    Risk Management Techniques
    Identifying and Managing Risk
Development
    Development Phase Tasks and Roles
    Building the Solution
    Other Development Considerations
Stabilization and Release
    Stabilization/Release Phase Tasks by Role
    Live Testing
    Release Criteria
Helpful Links
Reference

Introduction

The Services Guide for Microsoft® BizTalk® Accelerator for HIPAA is one in a series of guides; others in the series are Architecture, Deployment, and Operations. 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 document is intended primarily for business analysts and project managers who are responsible for implementing HIPAA-specific data exchange for health care organizations. Individuals working on portions of the implementation might also benefit from reading one or two sections. It is assumed that the reader has some familiarity with business transactions in the United States health care system.

About This Guide

This guide provides information about the five phases of a services engagement for a BizTalk Accelerator for HIPAA solution, and provides guidance for the successful completion of each phase.

This document contains services engagement guidance: practical advice to help you through the entire process of planning, implementing, and testing BizTalk Accelerator for HIPAA. It offers best practices as determined through the experiences of Microsoft Consulting Services, Washington Publishing Company, and early adopters of Accelerator for HIPAA.

BizTalk Accelerator for HIPAA addresses only the X12N transaction set standards detailed in the Administrative Simplification section of HIPAA, and this is what this guide discusses. The implementation of the other HIPAA requirements will vary widely between organizations, and the permutations are well beyond the scope of this document.

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

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 X12N guides adopted under HIPAA and published by Washington Publishing Company (WPC).
Use the BizTalk Server and BizTalk Accelerator for HIPAA online Help files for troubleshooting.
Understand the basics of Microsoft BizTalk Server:

BizTalk Orchestration Designer, a visual environment for business process modelling

BizTalk Editor, which defines business document schemas

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

BizTalk Messaging Manager, used to specify and manage business relationships

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

BizTalk Document Tracking, used to track message and schedule activity
Have experience in configuring and implementing BizTalk Server in a development environment.
Understand the basics of BizTalk Accelerator for HIPAA:

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

HIPAA-specific document specifications, BizTalk Server-specific XML schemas, originally published by WPC, that are included in BizTalk Accelerator for HIPAA

About HIPAA

HIPAA, the Health Insurance Portability and Accountability Act of 1996, was enacted to address deficiencies in business processes within the health care system.

Before HIPAA, organizations could collect, store, and transmit health care information in any format that they preferred. No federally mandated standards existed to guide the organizations in storing, processing, communicating, or securing data. Software potentially differed from organization to organization, even if it was purchased from the same software vendor.

HIPAA was enacted primarily to provide improved portability of health benefits and greater accountability to prevent health-care fraud. HIPAA has many purposes, including:

Improving the portability and continuity of health insurance coverage in the individual and group markets.
Combating fraud and abuse in health insurance and health care delivery.
Promoting the use of medical savings accounts.
Improving access to long-term care services and coverage.
Simplifying the administration of health insurance.

HIPAA standards affect all health care organizations that are involved in collecting, storing, processing, and exchanging information. Its mandates will require substantial changes in policies, business processes, and health care administration. Compliance can entail significant costs that will affect return on investment. Coordinating and co-implementing HIPAA-mandated changes among providers, payers, and IT vendors will minimize the costs, delays, and difficulties that are involved in this process.

Subtitle F of HIPAA, the Administrative Simplification section, is intended to reduce the costs and administrative burdens of health care by making possible the standardized, electronic transmission of many administrative and financial transactions that are currently performed on paper, and to provide an appropriate level of protection for the medical data on which the transactions are based.

The legislation contains detailed requirements for electronic health care business operations, including transaction set standards, security, privacy, and universal identification of payers, providers, and sponsors. Health care business entities must be compliant with these transaction set requirements by October 16, 2002 or be subject to fines by the United States government. Smaller health care entities have until October 16, 2003 to become compliant. Some states have passed state laws to implement these requirements even earlier.

About EDI

The health care industry has used many disparate forms of electronic data interchange (EDI) for a very long time. The term EDI does not necessarily mean X12N EDI; it can refer to flat files that are based on a recommended data set and modified for individual partners' needs. Traditionally these needs have been dictated by the organizations that pay or adjudicate the claims. Other organizations such as the National Uniform Billing Committee (NUBC), the National Uniform Claim Committee (NUCC), and the Centers for Medicare and Medicaid Services (CMS) have published data sets and file formats for the purpose of transmitting claims electronically, but these file formats do not adhere to a federally mandated standard data content set, nor do they meet the HIPAA mandated transaction set requirements. In addition, these data sets and file formats address only claims submission, leaving the industry to grapple with up to 400 different electronic formats for a simple claims transaction. They also do not address the other business functions now regulated and mandated under the HIPAA requirements.

Today all of the mandated transactions are carried out, but not necessarily in an EDI format. The majority of hospital claims are now filed electronically, and very few claims use the X12N 837s. A few more use an 835 for claims payment and remittance advice, but these 835 transactions are normally not the transaction mandated by HIPAA but rather an earlier version of the 835 transaction that has been modified from business partner to business partner. Eligibility is normally determined by a phone call, either to an automated system or to a person. Referrals can require many interactions between numerous people, including:

Phone calls
Voice mail
E-mail
Notification letters or bills
Face-to-face interaction

Currently it is not unusual to have many legacy environments within one organization, whether you are a provider, a payer, or another entity. Existing systems might have to deal with many of the 400 EDI formats that are in use, and the entities might require multiple systems just to handle this environment, which is expensive.

The cost of all of this is passed on to the consumer or patient. Claims status can be determined, but normally only after months of waiting for a payment. Most providers have an estimated 120-day lag in realizing commercial claims payments; the provider's staff typically waits the "normal" period of time before even beginning to consider the validity of the claim.

As a result of HIPAA, all major U.S. health care entities soon must be able to send electronic administrative information by using EDI in a single standard. Providers, payers, and other entities—such as clearinghouses that use administrative transactions (for example, claims and eligibility)—must be able to exchange information in a uniform standard format using approved implementation guides by October 16, 2002. Secondary claims will be easier to make because coordination of benefits information can also be sent in a standardized manner. This standard EDI transaction and implementation also delivers additional required fields and data elements.

About BizTalk Accelerator for HIPAA

Microsoft BizTalk Accelerator for HIPAA is the first supported product developed by Microsoft that specifically meets business requirements in the health care industry. It is designed to simplify and accelerate the process of meeting HIPAA transaction set standards in the electronic transfer of information between health care covered entities, which include providers, payers, clearinghouses, and many others.

It contains the following features that allow Microsoft BizTalk Server 2000 to process and validate health care EDI transactions as defined by HIPAA:

All 12 HIPAA X12N transaction sets as BizTalk Server schemas, which are provided by Washington Publishing Company (WPC):
- 834—The ASC X12N 834 (004010X095): Benefit Enrollment and Maintenance
- 820—The ASC X12N 820 (004010X061): Payment Order/Remittance Advice
- 270—The ASC X12N 270 (004010X092): Eligibility, Coverage or Benefit Inquiry
- 271—The ASC X12N 271 (004010X092): Eligibility, Coverage or Benefit Information
- 837—The ASC X12N 837 (004010X098): Health Care Claim: Professional
- 837—The ASC X12N 837 (004010X097): Health Care Claim: Dental
- 837—The ASC X12N 837 (004010X096): Health Care Claim: Institutional
- 278—The ASC X12N 278 (004010X094): Health Care Services Review - Request for Review
- 278—The ASC X12N 278 (004010X094): Health Care Services Review - Response to Request for Review
- 276—The ASC X12N 276 (004010X093): Health Care Claim Status Request
- 277—The ASC X12N 277 (004010X093): Health Care Claim Status Notification
- 835—The ASC X12N 835 (004010X091): Health Care Claim Payment/Advice
A HIPAA implementation reference guide for the X12N transaction sets as a Microsoft HTML Help document (provided by WPC)
A HIPAA-specific parser
Specialized support for encounter splitting for 837I, 837P, 837D, 835, and 834 transactions. An encounter is defined as one claim that would normally be represented on a UB-92 (HCFA 1450) form or one HCFA 1500 form that captures the information for a claim between one subscriber or dependent (patient) and their health care provider.

This Services Guide for Accelerator for HIPAA solutions discusses the five phases of a services engagement for this solution, and provides guidance for the successful completion of each phase. The five phases are:

Phase 0: Preparation and Assessment
Phase 1: Vision and Scope
Phase 2: Planning
Phase 3: Development
Phase 4: Stabilization and Release

Preparation and Assessment

At the beginning of the project, before the vision/scope phase, the organization needs to have a clear understanding of its internal competencies. This might include organizational experience with EDI (the X12N mandated implementation guides), with HIPAA rules and regulations, and with legacy system integration. Legacy system integration competence includes experience with interface engines, working between disparate applications. You can represent organizational experience by project team members, by a cross-departmental team, or by organizational documentation or knowledge bases.

It is recommended that you make an inventory of competencies, collected through individual assessment by using a standard survey. This should be sent to each member or potential member of the implementation team.

When surveying, keep in mind that you will need both technical and business-process competencies. This means that your survey population must include those outside the traditional IT organization; include those in the business departments of the organization. Depending on the organization, this can include:

Membership services
Medical coverage
Referral management
Claims processing
Accounting
Billing
Customer services

The summarized individual scores represent the competency map of the organization. It is critical that you build your implementation organization to have as much competency balance as possible.

To be successful, you must also identify the development and operating environment infrastructure that you need. The hardware and software requirements for Microsoft BizTalk Accelerator for HIPAA provide a good starting point. Beyond that, your requirements will depend on factors such as numbers of transaction sets being implemented, numbers of transactions by type to be processed per unit of time, and architecture of the proposed implementation.

Individual Preparation

The BizTalk Accelerator for HIPAA implementation should be designed to increase overall organizational capability, through the complementary goals of application development and an increase in your staff's experience and understanding of the application.

To determine the competencies and training needs of individuals in your organization, use the information collected in the survey mentioned in the preceding section. Competency gaps should be reviewed and a remediation plan developed and implemented at the individual level, either through additional training or through a change in team assignment.

In some cases, individuals will need additional training. If the training is in core technical competencies, it is recommended that these individuals be enrolled in Certified Technical Education Center (CTEC) training courses on the key Microsoft technologies. If the competency gap is in project management, attending a Microsoft Solutions Framework and/or Microsoft Operations Framework course offering is recommended. Specific health care EDI or HIPAA education can be obtained through WPC, our recommended solutions partner.

As training is completed, it is recommended that team members should be re-surveyed to see which gaps have closed and which remain. This also provides you some hedge on project risk due to lack of relevant competencies.

Ongoing compliance will be a direct result of the increased skills and competency of the organizational staff. While initial compliance work needs to be completed by October 16, 2002, this is only the first among ongoing compliance deadlines as changes are introduced to the implementation guides and new transactions and guides are finalized. Developing core individual competencies in the team will lessen the ongoing risks of compliance and will increase the organizational ability to respond to changes.

Tools for assessing competency

It is recommended that you use a standard format for surveying and establishing base lines for individual and organizational competency.

A useful survey instrument, MaterialsSampleSkillsAssessment—ALL.xls, can be found in the Reference section.

Training

It is critical to have well-trained staff to implement the application. This will help you reduce deployment risk and see rapid and accurate results.

It is recommended that your implementation staff complete a three-part training program before work begins as part of the overall organizational readiness program. Training should be done in a development lab setting, with didactic content presentation preceding hands-on lab work. Forming teams of learners working on specific and competitive assignments can increase the effectiveness of the training experience.

For more information, see the WPC Web site.

EDI implementation education

Implementers should have a solid understanding of the HIPAA implementation guides. They should understand:

Their structure
How to read them
How the guides were written and maintained
The Standard and Data Content Committees and their respective roles
The role that WPC plays in the publication of the guides
The unique structure of the transactions described in the final transaction standards
How to compose and decompose all the standard transactions
Change management
How the standards are implemented
How to participate in setting the standards
How to validate the syntax of transactions using third-party tools

BizTalk Server education

Implementers should understand the basics of Microsoft BizTalk Server:

BizTalk Orchestration Designer. Visual environment for business process modelling
BizTalk Editor. Defines business document schemas
BizTalk Mapper. XSLT transformation component
BizTalk Messaging Manager. Creates business relationships
BizTalk Server Administration. Manages queues, transports, and services
BizTalk Document Tracking. User interface for tracking message and schedule activity

Implementers must understand how to physically configure and implement BizTalk Server in a development environment.

Implementers should understand the basic configuration of the core application before covering the details of BizTalk Accelerator for HIPAA.

BizTalk Accelerator for HIPAA education

Implementers should understand components, features, and concepts of Accelerator for HIPAA:

BizTalk Accelerator for HIPAA parser. The parser is a component that translates HIPAA (X12N) files into Extensible Markup Language (XML) files.
HIPAA-specific document specifications. Specifications are BizTalk Server-specific XML schemas that are created by using BizTalk Editor. The BizTalk Accelerator for HIPAA parser uses a HIPAA-specific document specification to validate instances of HIPAA data in X12N format and to convert that data into XML. After it is converted into XML, you can use a map to transform the HIPAA data into another format to be used in your existing applications, such as delimited flat files or positional flat files. You also can use the XML data without any mapping.
Claims processing sample. The claims processing sample is a sample application that includes the following:
- BizTalk XLANG schedule. This schedule controls the long-running business processes in which HIPAA-specific documents are exchanged, validated, and processed. It also controls the database used to track, reconcile, and report the status of individual procedures within claims being processed. The sample schedule is designed to control the processes for both submitting and receiving claims. You can modify the schedule to reflect your role in the process and your specific business processes.
- Components. The sample includes a number of components that the XLANG schedule invokes to perform various functions related to claims processing, or that BizTalk Messaging Manager uses to assist in transporting data.
- SQL database. This database enables users to track, reconcile, and report the status of individual procedures that might be bundled in a single claim submission or in a payment advice document or interchange.
- BizTalk Messaging Configuration scripts. BizTalk Messaging Configuration scripts validate incoming interchanges against a designated specification, transform the format of claims information, and transport claims information to your internal applications or to your trading partners.

Implementers should also understand how to use both the BizTalk Server and the Accelerator for HIPAA Help files for troubleshooting.

Infrastructure

In the planning process, you inventory existing systems and begin to plan for necessary technology purchases or technology redirection. This inventory includes the following:

Identify and assess current systems
Identify and assess current EDI/edi (uppercase EDI is X12 EDI; lowercase edi is nonstandard edi, such as NSF and EMC)
Identify required hardware
Identify required software

Identify and assess current systems

You should identify what current infrastructure you have in place to support the software implementation. Make a complete inventory of legacy systems, databases, and applications that might be affected by a move toward standard transactions.

Identify and assess current EDI

Determine how you are currently managing electronic data interchange. This entails identification of current trading partners and formats particular to those partners. You should understand how you currently interchange with trading partners, and which interchanges are business processes covered under the standard transactions.

Identify required hardware and software

At a minimum, you must identify the hardware required to support the initial development environment, as well as the software required to support BizTalk Accelerator for HIPAA. See the Accelerator for HIPAA documentation for information about hardware and software requirements.

Project Assessment Questions

One of the keys to success in the preparation/assessment phase of an Accelerator for HIPAA solution project involves figuring out the right questions to ask, and then getting the answers to those questions. This process will help formulate the correct vision for the project and lead to an accurate assessment of the scope of the project described in the next phase.

This section provides some of these questions to help get the process off to a good start. They are divided into several different categories.

Assessing organizational knowledge and education

Does the organization have sufficient resources and training? Do they need HIPAA-EDI-specific training? Do they need BizTalk Server 2000 training? Do they need BizTalk Accelerator for HIPAA training?
Does the organization understand the Microsoft operating system platform and development tools? Do they have the operational and support expertise for a BizTalk Accelerator for HIPAA application?
Does the organization understand relational database design and implementation? Do they have DBA support?
Use the MaterialsSampleSkillsAssessment—ALL.xls file in the Reference section of this document to help assess the knowledge gaps for an organization.

Assessing existing business systems

What legacy systems and applications are affected by the HIPAA transaction sets? What databases are affected? Do they have a data warehouse?
What is the software/hardware platform for these systems? Are they on a mainframe? UNIX? Microsoft Windows®? How do they currently communicate with these systems?
Do any of these systems use EDI today? If so, do you know the business partners that integrate with these systems? Do you know if they are affected by the HIPAA legislation?
What HIPAA transaction sets are relevant for the organization's line of business? Do they have any preliminary assessment of their HIPAA-EDI remediation requirements?

Assessing existing infrastructure

How does the organization currently transmit and receive electronic health care data to and from business partners? Do they currently use a VAN? Modem? Public Internet?
Does the company have subsidiaries with which it must interact? If yes, how diverse is the geographical base?
Does the organization have a PKI infrastructure? If yes, using what platform?
How does the organization handle network security? How are users and business partners authenticated?
Do they use data encryption? If yes, what kind?

Vision and Scope

During this phase, a team of consultants will work closely with the customer to identify the vision and scope for the project. A primary goal of this phase is to sufficiently understand the risks and plan appropriately the environment, challenges, and opportunities as well as to illustrate how the technology can meet and exceed the requirements identified during an extensive business process review. Business goals and cost are key factors in developing the plan to move forward. During this phase of the engagement, the team will help the customer define resources, budget, and project scope.

The vision/scope phase of a typical service engagement for an Accelerator for HIPAA solution should be used to scope out the following issues:

Gain an understanding of and develop a shared common vision of the proposed solution
Project size
Business factors driving the project
Beginning assessment of the current situation of the customer
Determination of the high-level decision-making criteria for the project deliverables
High-level milestones for the project
Roles, responsibilities, deliverables, team structure, delivery process, and sponsor

The primary deliverable of the vision/scope phase is a vision/scope document that has been approved by all relevant parties. It is approved, accepted, and signed by all the lead stakeholders of the project. This document, when properly written according to Microsoft Solutions Framework (MSF) principles, can serve as the main resource for the statement of work provided by the solution implementers. Though this document should be backed up by more specific information and measurements, it should contain enough detail for all team members to understand the project parameters and the vision and scope of the project.

Completion and approval of the vision/scope document, and any related documents, constitutes completion of the vision-approved milestone.

For a comprehensive introduction to the MSF, see the Microsoft Solutions Framework overview white paper.

The remainder of this section provides details about the information that should be included in the vision/scope document and provides a collection of questions that will be useful in determining the vision for, and scope of, an Accelerator for HIPAA solution project.

The Vision/Scope Document

The vision/scope document is the primary deliverable of the vision/scope phase of an Accelerator for HIPAA solution project. As defined by the MSF, the vision/scope document should contain the following sections:

Executive Summary
Opportunity/Problem Statement
Business Benefits
Vision Statement
Decision-Making Criteria
Usage Scenarios
Solution Concept
Conceptual Design
Project Team
Critical Success Factors
Risk Management
Initial Project Schedule

The remainder of this section discusses the expected content of these sections, from the perspective of an Accelerator for HIPAA solution.

Executive summary section

This section of the vision/scope document should contain a brief but comprehensive summary of the various factors that have led to undertaking the Accelerator for HIPAA solution project, including the business motivation and objectives, the features to be implemented, the project timeline, and the anticipated outcome.

Opportunity/problem statement section

This section of the vision/scope document should contain a complete description of the business problems this project is trying to solve, or the opportunities this project intends to address. One of the most important reasons for including this section, and for making sure that it is comprehensive and accurate, is that it will drive many of the decisions made in the planning phase of the project.

The problem statement is the same for all health care entities because the United States government has mandated that all entities identified in the legislation are required to be transactional-compliant by October 16, 2002 or face potential penalties and fines from the U.S. government. There are also many benefits, including cost savings and improved medical information, patient care, privacy, and security.

Business benefits section

This section of the vision/scope document should list the anticipated business benefits that the completion of this project will yield. These benefits should correspond to the problems and/or opportunities stated in the previous section. Articulation of the project benefits will help drive the acceptance tests that will be written in the planning and development phases.

In a services engagement, a clear statement of the business benefits is very important because it will help establish a clear set of exit criteria for the project.

Vision statement section

This section of the vision/scope document states the project vision. Although short, this section is important because it provides the project team and the customer with a common understanding of what the project will achieve, and helps to:

Establish an agreement with the customer about the goals of the project.
Establish the decision-making criteria for the project.
Make project trade-offs.

Decision-making criteria section

This section of the vision/scope document addresses three standard, potentially conflicting, factors of any project: ship date, resources, and features. Constraining more than one of these factors results in a much greater chance that the project will not succeed in all respects.

Part of the process of determining the vision and scope of a project is determining in advance the relative priorities of the three factors being discussed here. For example, if the ship date is critical, features might need to be cut to a minimum, and more resources applied. Or it might be sufficient to trim features, or to add resources, but not both. Alternatively, if resources are limited, and features are already minimized, the ship date might be the only variable factor.

In any event, this section of the vision/scope document should provide information about the relative importance of ship date, resources, and features for the project. This information helps to ensure that the team's decision-making strategy remains consistent throughout the project.

Usage scenarios section

This section of the vision/scope document should describe the roles of the various users of the Accelerator for HIPAA solution. The number of unique types of users will vary depending upon the size of the health care organization, the number and type of HIPAA and non-HIPAA transactions they need to consume and produce, the number of health care business partners they have, and how they intend to interact with their business partners.

For example, is the organization a large payer who intends to provide all health care entities with an easy-to-use Web site that meets the requirements of direct data entry to handle eligibility inquiry (EDI X12N 270/271 transactions)?

Solution concept section

This section of the vision/scope document should outline the solution approach and architecture at a high level. The outline should be sufficient for beginning the planning phase. The outline should consider the following high-level aspects of the solution:

The required hardware
The required software
Integration with existing systems
Performance requirements

This section should not be too detailed, and should not attempt to take the place of the functional specification that is delivered in the planning phase.

In practice, this section can be constructed by using parts of the Microsoft BizTalk Accelerator for HIPAA Architecture Guide and Deployment Guide, including those sections that are relevant to the solution being devised.

Conceptual design section

This section of the vision/scope document should describe the basic scenarios in which the Accelerator for HIPAA solution will be used. Detailed usage scenarios will become part of the functional specification described below. This will correspond to the roles defined in the User Profiles section.

For example, with regard to the previously mentioned large payer eligibility inquiry Web site:

How and when is the user authenticated as a trusted business entity?
How is the data entry screen presented to the user? Is there a minimum data requirement to enter the data? What is assumed? How will users be able to change assumed values or behaviors?
How is the inquiry result presented to the user?
Can the user enter an eligibility inquiry for more than one patient on a single screen?

Project team section

This section of the vision/scope document should identify the roles on the project team and their corresponding responsibilities. It should also discuss issues related to team interaction, such as the frequency of various meetings and the combination of attendees at those meetings, how common team documents and other project information will be maintained, and so on.

The MSF team model defines a set of roles and corresponding responsibilities that have been found to be a constructive way to organize a project team. Although the names of roles and precisely how the responsibilities are distributed can vary, each responsibility described here should be covered by some role. Further, some responsibilities tend to conflict with each other, and are better distributed to unique roles. For example, it is generally accepted that software should not be tested by the same person who developed it.

The various project roles defined by the MSF are described below.

Product management

The goal of the product management role is satisfied customers. Product management team members engage in the following types of activities:

Act as a customer advocate
Drive the project vision and scope
Work with customer to define and maintain requirements
Develop and refine the business case for the project
Manage customer expectations
Drive feature-versus-schedule decisions
Manage marketing and public relations
Act as product evangelist

Program management

The goal of the program management role is to deliver the project within the defined constraints. Program management team members engage in the following types of activities:

Design the architecture
Drive the development process
Manage the product specification
Facilitate communication and negotiation within the team
Maintain the project schedule
Report project status
Drive high-level trade-off decisions

Development

The goal of the development role is to build the solution as specified. Development team members engage in the following types of activities:

Specify the features of the physical design and options
Estimate time and effort to complete each feature
Build the features
Prepare the solution for deployment

Logistics management

The goal of the logistics management role is to ensure smooth rollout of a manageable and supportable product. Logistics management team members engage in the following types of activities:

Act as an advocate for operations, support, and delivery channels
Manage procurement
Manage product deployment
Drive manageability and supportability trade-off decisions
Manage operations, support, and delivery channel relationships

User assistance

The goal of the user education role is to enhance user performance and reduce support costs. User education team members engage in the following types of activities:

Act as end-user advocate on the team
Manage user requirements definition
Design and develop performance support systems
Drive usability and user performance enhancement trade-off decisions

Test management

The goal of the test management role is to ensure a high-quality release. Test management team members engage in the following types of activities:

Ensure all issues are known before release
Develop testing strategy and plans
Manage test execution and reporting of results

Critical success factors section

This section of the vision/scope document should identify the key factors that will influence the success of this project. The identified factors can be ones that have either a positive or negative impact on the project, and the type of impact should be stated clearly. Relevant factors might include people, processes, technology, management, and competition. They can be internal or external to the supplier for whom the solution is being built.

From the point of view of the services engagement, the factors identified in this section are important because they can help determine when the project has been successfully completed, which can determine when final payment for services is due. Reaching a common understanding with the customer about such issues at an early stage in the project can definitely contribute to a harmonious project conclusion.

Risk management section

This section of the vision/scope document should establish a common understanding of risk management and procedures with the customer, and is a very important tool in any services engagement. Note that this section should only describe the process by which risks will be identified and managed within the project. Actual risks will be managed through the separate risk management process, which is further elaborated below.

All projects have risks that can hinder the critical success factors. To minimize impact of these risks on the success of the project, they must be identified as early as possible so that mitigating plans can be developed.

Educating the customer about risks that can affect the success of the project is an important discipline to develop and foster. Often these risks are outside the control of the project team, so that they cannot be avoided even with excellent planning and execution.

These risks must be identified and brought to the attention of the customer as early as possible. And since new risks can arise during the course of the project, risk management must be ongoing throughout the project.

There are many possible risks to a project. The following lists identify a number of common types of risks that should be considered, and suggestions for mitigating those risks.

Schedule risks

Tasks that are exceptionally complicated
Tasks with durations longer than two weeks
Tasks on the critical path
Tasks that have several predecessor tasks
Tasks with overly optimistic time estimates
Tasks that depend on external groups
Start-to-start and finish-to-finish dependencies
Dependencies with lags
Major milestones
Unforeseen issues (for example, reorganizations and office moves)
Unstated assumptions

Resource risks

Tasks with one key individual assigned
Tasks using scarce resources
Tasks for which the resources are mismatched
Tasks that require a large number of resources
Unavailability of appropriate tools
Tasks that rely on third-party vendors for their completion
Tasks that rely on resources within another group for their completion

Scope risks

Uncertainty of new technology
Changing customer requirements
Tasks with significant business impact
Overly aggressive performance requirements

Solution-specific risks

With respect to Accelerator for HIPAA solutions, a particular class of solution-specific risks needs to be considered and identified as early as possible. These include:

Overall quality of the implementation by business partner(s)
Degree of error handling implemented by business partner(s)
Network reliability
Network security exposure
File size and field size/type limitations of existing systems
Documentation and available expertise required to remediate existing systems

Initial project schedule section

This section of the vision/scope document should provide an initial project schedule. This schedule will be high-level, and can be used to express what the project team and customer would like the schedule to be. Whether or not the initial project schedule is realistic, given the features to be included and the resources to be engaged, will be determined as the schedule is refined during the planning phase. In any event, it should be possible to establish solid milestones, if not their associated dates, in the initial project schedule.

The following table shows an example of an initial project schedule for a typical Accelerator for HIPAA solution project.

Project phase	Milestone	Description
Prototype	X	Design a simple prototype to demonstrate a proof-of-concept
Preparation	0	Preparation and readiness assessment complete
Vision/Scope	1	Vision/scope approved
Planning	2	Project plan approved
Development	3	Gap analysis complete
Development	4	Remediation of existing and new systems complete and tested
Development	5	Transaction set submission to and from all trading partners complete and tested
Development	6	Transaction set error handling and functional acknowledgment generation complete and tested
Development	7	Code complete
Stabilization/Release	8	Zero bug bounce (ZBB)
Stabilization/Release	9	Final code deployed into production

Note An operations representative, probably working through the logistics management team, should be involved in the vision/scope phase of the project. Experience suggests that when this is not done, as often is the case, significant delays in the successful deployment into a production environment are common. For more information, see the Microsoft BizTalk Accelerator for HIPAA Operations Guide.

Planning phase schedule

Before concluding the vision/scope phase, the Program Manager should develop and release a detailed project plan for the planning phase. This plan should outline a specific schedule of key activities in the planning stage and assign specific responsibilities to those activities. This forms the framework for the next phase of work.

Planning

The deliverables of the planning phase are as follows:

Gap analysis. Identifies gaps between the HIPAA X12N transaction sets and existing systems. Used to determine the level of remediation required for existing systems and perhaps the specification for new systems.
Functional specification. Describes the solution to be built and includes the solution design goals, requirements, features, and dependencies. This is also where detailed usage scenarios will be described.
Master project plan. Describes how the solution will be built.
Master project schedule. Describes when and in what order the solution will be built.
Test plan. Identifies all relevant testing scenarios and test scripts.
Logistic/infrastructure plan. Organizes the acquisition of hardware, software, testing, and installation
Security plan. Describes a complete security plan along with tests, preferably by a third party.
User assistance plan. Identifies and develops user education materials and schedule.
Marketing and communication plan. Ensures project attention throughout the organization and maintains routine communication with executive sponsors.
Facilities plan. Ensures that meeting rooms, conference centers, training labs, test labs, and production facilities are accommodated.

The planning phase ends with the project plan approved milestone, which signals approval to build the solution.

Gap Analysis

One of the primary steps in the implementation of a BizTalk Accelerator for HIPAA solution is gap analysis. Gap analysis consists of identifying how existing systems and applications map to the required data content in the HIPAA transaction sets. Without this process, it is difficult to properly plan for the implementation. Organizations that have not completed a gap analysis have found implementation much more challenging. This process includes comparing legacy systems and applications to each HIPAA transaction set defined in the implementation guides for the purposes of identifying:

Legacy fields or data elements that will no longer be contained in data from the HIPAA transaction sets.
New fields that need to be added to the legacy system or handled elsewhere when the data is required in the HIPAA transaction sets.
Discrepancies in data types and field lengths between legacy systems and the requirements defined in the transaction sets.
Historical analysis of one year's worth of legacy data applied to the gap analysis, to validate the integrity of the gap analysis so that situational and/or line-of-business assumptions are not missed.

The OnlyConnect™ Gap Analysis Tool (GAT) from Washington Publishing Company is a useful tool for generating reports to identify all of the data-mapping issues between your legacy system and applications. An evaluation copy of this tool is available online.

When using the OnlyConnect Gap Analysis Tool, follow these steps:

Complete the customer profile.
Identify the systems information: source data systems and file structures.
Import the legacy systems information into Microsoft SQL Server™ 2000.
Build the connections through the multi-user interface.
Generate reports.
Verify gap analysis results.
Customize analytical reports.
Identify and prioritize the problem legacy data fields.
Track remediation progress graphically.
Provide a BizTalk Server map of legacy data format to HIPAA transaction sets.
Provide a graphical change management interface as the X12N HIPAA mandates evolve.

Legacy document schemas

Any legacy file format or data structure must have a corresponding BizTalk Server schema definition. Use BizTalk Editor to create schemas for flat file and XML documents. The simplest type of schema supported by BizTalk Server is XML, but most legacy applications will support some sort of flat file definition.

BizTalk Server supports a rich array of options for positional and delimited flat files. The legacy application specialist should provide the specification for the flat file along with test data. After completing the flat file schema, test data should be submitted to BizTalk Server to parse and serialize. The output should be run against the legacy application in test mode to verify accuracy. Use a year's worth of sample data where possible to generate a wide array of test cases.

Transaction set mapping

BizTalk Accelerator for HIPAA provides template schemas for all 12 X12N HIPAA transaction sets. Upon completion of the legacy BizTalk Server schema, use BizTalk Mapper to map the data from one document specification to another. You will need a distinct map for both directions (X12N HIPAA transaction set to legacy and legacy to X12N HIPAA transaction set). Using the reports generated from your gap analysis tool, you should be able to connect data elements from the source document to the destination document, adding the additional functionality of functoids when required.

Upon completion of the BizTalk Server map, test the mapping functionality. Again, a year's worth of data is recommended for generating test cases. Test maps that produce legacy files on your legacy systems and maps that produce X12N HIPAA/EDI documents using BizTalk Server. Testing and certification of the EDI document compliance can be obtained from EHNAC or—for level one and two development validation—by using OnlyConnect™ FirstPass from Washington Publishing Company.

For analysis, refer to the following topics from the OnlyConnect framework and OnlyConnect methodology:

Data Layer Analysis
Historical Data Analysis
Application Layer Analysis

Planning Phase Tasks by Role

This section lists the tasks that need to be performed during the planning phase, organized by role.

Program manager

Own and drive the schedule, including rolling individual schedules into a master schedule.
Own the project feature set, and communicate this through the functional specification.
Own the budget for the project.
Own progress reporting.
Coordinate resources.
Facilitate team communication.
Drive critical decisions and make tradeoffs based on project constraints.
Fill architect role to ensure alignment of design, business requirements, and team/work breakdown strategy.

Product manager

Drive customer satisfaction.
Act as customer advocate to the team, and act as team advocate to the customer.

Note It is important to distinguish between the customer and the end user. The customer is the one who pays for the product while the end user is the one who uses the product.
Understand and communicate customer requirements.
Articulate the business case for the project.
Ensure that team and customer share the same vision for the project.
Assume communication leadership with the customer.
Manage customer expectations.

Development lead

Lead the development team in building the prototype.
Ensure that the prototype, as built, meets customer expectations.
Build the prototype to drive the functional specification.
Serve as technology expert.
Contribute to high-level designs.
Evaluate alternative technologies.
Develop proof-of-concept prototypes.
Mitigate development risks early.

Test lead

Lead the test team in ensuring product quality.
Ensure that all issues are known and addressed prior to project completion. Issues include flaws in the code and documentation, and deviations from the functional specification.
Develop comprehensive test strategies, plans, and schedules.

User education lead

Act as advocate for the end user of the product (be the first end user).
Develop approach toward end-user and support staff documents.
Help ensure product usefulness.
Ensure product usability.

Logistics manager

Act as advocate for operations and product support.
Help ensure a deployable product.
Help ensure a manageable product.
Help ensure a supportable product.
Understand product infrastructure and support requirements.
Develop installation and support plans.

Determining the Project Size

This difficult task is important because an accurate estimate is required to properly determine the project budget, schedule, and resource requirements. To accomplish this task you will need to determine the required functionality, and compare that to the functionality provided by the Accelerator for HIPAA solution, both the out-of-the-box functionality provided by Microsoft BizTalk Accelerator for HIPAA, and the functionality enhancements discussed in the associated documentation.

It is important to have a thorough understanding of the BizTalk Accelerator for HIPAA architecture in order to be able to determine the size of an Accelerator for HIPAA solution project. Refer to the BizTalk Accelerator for HIPAA Architecture Guide or to the BizTalk Accelerator for HIPAA online Help for this information.

Determining the answers to the questions in the following sections is critical to properly estimating the size of the project.

General questions

What is the remediation plan after the gap analysis assessment is complete? Can you remediate all systems, applications, and databases, or will you need to build or purchase another system?
Can you identify the first business partner(s) to bring online for parallel testing? It will be important to identify for each transaction set a good business partner to work through the initial parallel testing in the next phase. Plan to begin testing early, and get a written commitment from the other organizations. Allow for plenty of extra time in your schedule, because you might not have control of the other half of the testing equation.
How many business partners are to be integrated? How many types of transaction sets per business partner need to be integrated? The HIPAA transaction set standards will make this easier as you add other business partners, but integrated testing should be done before bringing a new business partner online.
What message standards will be involved other than HIPAA-EDI? Accelerator for HIPAA provides support for HIPAA-EDI. Do any other message standards need to be supported? If so, identify these standards and determine if they will affect the size of the project.
Do you need reporting, monitoring, and/or auditing? If so, what is the scope of these functions?
Do you need to keep organization and/or user profiles?
Do you need to make changes to the network security infrastructure? Identify the scope and impact of those changes.
Do you require a fully redundant and highly available system? How will this affect the complexity of development, deployment, and operations? This will multiply the number of machines required, and consequently, the complexity of the deployment and management.
Do you require a data repository or data warehouse? If so, what is the scope of this task?
Do you need to integrate with other back-end systems like AR, AP, ERP, MRP, and so forth? If you need to integrate other systems into a complete order-processing system, allow for plenty of integration time.
Is there a significant data migration or cleansing effort required to move/modify the existing data? This can involve significant effort, depending on the amount of data you have to aggregate and its current format. You might want to consider a third-party service for data cleansing and migration.
What skill sets are needed? How many people in each skill set will be required? A typical BizTalk Accelerator for HIPAA implementation requires the following skills:
- Information architect
- Business process analyst
- Microsoft Visio® orchestration designers
- Trainers
- Technical writers (document specialists)
- Project management
- Testers
- SQL Server developers, SQL Server DBA
- Microsoft Visual Basic® or C++ COM developers
- Web/ASP developers (optional depending on requirements)
- XML/XSLT developers
- BizTalk Server developer and administrator
- Advanced Windows IT resources for deployment of high-availability solutions with clustering
- Backup operators
What is the deployment environment? Does the customer have the infrastructure and IT organization required to deploy and support this system?
How much staff does the customer have to support this effort?
Do you need high availability? How much exactly? Most organizations require 24/7, but how much downtime is acceptable per year or per week? Will you require a hot backup for instant switch-over? Or is a warm backup with a 10- or 15-minute switch-over time acceptable?
What are the scalability and performance goals?
How many claims per minute will need to be processed? How complex are the claims and the business process required to support them? Think about this carefully; one purchase order per second is 3600 purchase orders per hour.
What kind of error handling will you require? What level of HIPAA compliance checking do you require? Will you support functional acknowledgements?
What are the user experience requirements, such as a Web portal for eligibility inquiry?

Message standards selection questions

What standard(s) are current trading partners using?

We know that all health care entities will need to support the HIPAA-EDI standard. What other standards are required or nice to have in the future? Keep in mind the BizTalk Accelerator for HL7.
What are the characteristics of the standards you are considering, and how well do they match your needs?
Do you need to support the reception of HIPAA-EDI transaction sets using a transport mechanism other than HTTP/S, file system, FTP, SMTP, or MSMQ?
For standards not based on XML, can your system and infrastructure support the standard? Besides BizTalk Server, do your existing systems have support for XML? Will they in the future?

Business process questions

Is BizTalk Accelerator for HIPAA the only EDI translation and business processing engine you will be using? If not, then what is the role and usage of BizTalk Server and the other systems?
What core business processes are supported by the solution?
What is the sequence of steps, who is involved, and how are errors handled?
Based on the gap analysis, what kind of document definitions and translation maps will have to be created to support the HIPAA transaction sets? Do the current systems support XML or are they non-standard flat-file?
Do you need to support the reception of HIPAA-EDI transaction sets using a transport mechanism other than HTTP/S, File System, FTP, SMTP, or MSMQ?
How do you plan on using BizTalk Orchestration to handle the business processing between systems? How will you handle the correlation of messages for "long-running" transactions?
Will you be interacting with health care business partners using direct data entry means? If so, how will this approach be accomplished to ensure that you meet the requirements?
What is the consequence of downtime? What is the future of the business in terms of volumes, customers, and transactions?

Implementation Cost and Time

Based on the answers to these questions, you must now perform an effort and cost analysis. In the course of this task, consider the following:

Does the cost or time of implementation make any of these transaction sets prohibitive to implement?
Can you postpone one or more implementations to a future version? If so, will you incur penalties from the U.S. government?
Should you start by implementing one transaction set first with a single business partner, and then benefit from the experienced gained when implementing subsequent transaction sets? How long will it take to implement the perceived "most difficult" transaction set? It might be a best approach to tackle the hardest implementation first.

Risk-Management Techniques

A variety of risk-management techniques and information are part of MSF and can be found on the Microsoft Web site. For general information see Best Practices for Project Management, and for risk management information see Risk Management Process White Paper. The following section discusses risks that are often encountered in information technology projects.

Identifying and Managing Risk

A number of different types of risks are associated with an Accelerator for HIPAA solution project, particularly when it involves multiple health care business partners using heterogeneous systems. You need to identify, analyze, plan for, track, and control such risks. The relevant risks can be categorized as follows, and characterized by the questions associated with each category:

Technical risks. Do you have a good understanding of the new technologies being used? Have you prototyped and tested all the technical unknowns?
Integration risks. Do your trading partners have well-documented interfaces and protocols? Will they provide technical and validation support? Will they be responsive to your questions and needs? This is a significant risk, and one that is difficult to manage because you are dependent on another organization. Allow plenty of time in your schedule to mitigate this risk factor.
Security risks. Have you considered all the data and infrastructure security measures that will be required to adequately protect the customer? Are there any questionable areas that require specific proof-of-concept testing or analysis by a third-party security expert?
Schedule risks. Is the delivery date inflexible? Do you adequately understand the development effort required? Can you adjust the scope or resources if you cannot adjust the schedule? The effort required for integration with other organizations and applications is difficult to gauge accurately, so be conservative with these aspects of the project schedule. Also, be careful not to underestimate the learning curve required by technologies like HIPAA-EDI, BizTalk Server Accelerator for HIPAA, and so on. In particular, learning and understanding a new XML protocol can be quite challenging.
Budget risks. Is there sufficient funding to bring this project to completion? Is the budget so tight that any unexpected problems or delays will put the project in jeopardy?
Business risks. Is this project crucial to the survival of the organization? If so, does it have the appropriate level of support from all interested parties? Would a failure of this project put the organization at risk? Would a poor implementation put the organization and its reputation at risk?

All of these risks can be managed, but the more risks that exist, the more risk-management effort is required. On the other hand, not managing the risks will likely end up costing more. To help you identify all of the above risks, you should leverage the test team during the planning phase. They should be well-versed in risk analysis and management techniques. You should also make sure that the risks are well understood by all relevant parties, and try to ensure that those parties will constructively participate in solving problems associated with risks that come to pass.

Development

The deliverables of the development phase are as follows:

Frozen functional specification. At the end of this phase, the functional specification should be frozen and synchronized with the implementation and the final test plan.
Version-controlled release plan. This plan should be identified.
Users' guides and education plans. These should be drafted.
Operation guides, deployment guides, documentation, and support guides. These should be started and updated.
Capacity planning document. This should be developed and modified based on pilot and parallel testing.
Risk-management plan. The risk-management plan should be updated with the latest information and data. Some items might justify a higher priority in testing.
Source code and executables. The source code and executables should be in a Microsoft Visual SourceSafe® database or other source control system from which it can be installed by the test team on a clean machine or set of machines to manage source code, scripts, schema, and test data.
Test specification and test cases. The test plan should be completed and reviewed, using a realistic representation of test data and tools, before the test passes start.
Master project plan and master project schedule. These two documents should be updated with the latest data and should be distributed to key project personnel.

The development phase ends with the scope complete milestone. At this milestone, all features are complete and the product is ready for external testing and stabilization. This milestone is the opportunity for customers, end users, operations and support personnel, and other key personnel to evaluate the product and identify any remaining issues that need to be addressed before releasing.

Development Phase Tasks by Role

This section lists the tasks that need to be performed during the development phase, organized by role.

Program manager

Continually update the schedule.
Manage buffer times in order to meet the fixed-date schedule.

Product manager

Create an external release schedule.
Communicate with customer.

Development lead

Manage development effort.
Perform code reviews.
Help make technical tradeoffs and decisions.

Test lead

Lead creation of the test plan.
Lead creation of test tools.
Train testers about what needs to be tested.
Manage test creation.
Organize test-case review.

User education lead

Lead creation of product documentation.

Logistics manager

Create deployment plan.
Do capacity planning.
Install product infrastructure.
Implement daily build strategy.

Building the Solution

When you implement BizTalk Accelerator for HIPAA, you must identify your unique organizational requirements and clarify what the implementation will entail.

Business partner and application configuration matrix

To configure BizTalk Accelerator for HIPAA, you will need to obtain and document information about all of your HIPAA business partners and about your internal business applications that are affected by each of the HIPAA transaction sets that you will be supporting.

See the sample Microsoft Excel document, PartnerApplicationMatrix.xls, in the Reference section for recommended information to collect. This information will be used to set up BizTalk Server to manage the transaction set documents, business relationships, application identification, and document routing. Keep in mind that BizTalk Server configuration is made from the point of view of the home organization, and so the transaction document source might be from an outside organization (external business partner) or the transaction document source might be an internal business application/process from the home organization. Likewise, the transaction document destination might be an outside organization (external business partner) or the document destination might be an internal business application/process at the home organization.

Figure 1.

Figure 2.

Figure 3.

Identify the transaction source

Where is the transaction coming from? This information will be required to configure a messaging channel by using BizTalk Messaging Manager:

Organization (HIPAA/EDI transactions coming from an external organization)
- Obtain organizational qualifiers and identifiers to be used in the EDI Transaction Set ISA segment (ISA05, ISA06)
- Obtain the Application Sender Code to be used in the EDI Transaction Set Functional Group header (GS02, GS03). This code is set at the Selection Criteria tab for each document definition created by using BizTalk Messaging Manager.
Application (a named identifier for a business application or process that is the target of the transaction message at your organization)
- Identify the logical source application responsible for sending the transaction message (this will be an application internal to the BizTalk Server home organization).
- Describe the functionality of the application.
- If the application is a software component, describe the interface inputs and outputs.
- If the application is a BizTalk orchestration, make references to the orchestration source files and any supporting documentation.
Contact information
- Identify all outside and inside organizational contacts for system failure troubleshooting, scheduled outage notifications, operational change notifications, and application change notifications/remediation. These should include a technical contact, an operations contact, and an application/business manager.

Identify the destination

Where is the transaction going? This information will be required to configure a messaging port by using BizTalk Messaging Manager:

Organization (HIPAA/EDI transactions going to an external organization)
- Obtain the Application Receiver Code and the Application Sender Code you will use in the EDI Transaction Set Functional Group header (GS03, GS04). These codes are set at the Selection Criteria tab for each document definition created by using BizTalk Messaging Manager.
- Obtain the Authorization Information Qualifier, Authorization Information, Security Information Qualifier, and Security Information to be used in the EDI Transaction Set ISA Segment (ISA01, ISA02, ISA03, ISA04). BizTalk Server does not check this information before processing a document, so a custom preprocessor must be developed to handle this validation before submitting the document to BizTalk Server for routing and processing. For more information about preprocessors, see the Messaging Samples\VBCustPreProcessor example in the BizTalk Server SDK.
Application
- Identify the logical destination application responsible for receiving the transaction message (this will be an application internal to the BizTalk Server home organization).
- Describe the application's functionality.
- If the application is a software component, describe the interface inputs and outputs.
- If the application is a BizTalk orchestration, make references to the orchestration source files and any supporting documentation.
Contact information
- Identify all outside and inside organizational contacts for system failure troubleshooting, scheduled outage notifications, operational change notifications, and application change notifications/remediation. These should include a technical contact, an operations contact, and an application/business manager.

Identify document definitions

Source BizTalk Server schema
- Define the logical document definition name.
- Define the document definition selection criteria (required for EDI, optional for other file formats).
Destination BizTalk Server schema
- Define the logical document definition name.
- Define the document definition selection criteria (required for EDI, optional for other file formats).
- For HIPAA/EDI documents, define the EDI Envelope information: delimiters, Authorization Information Qualifier (ISA01), Authorization Information (ISA02), Security Information (ISA03), Security Information (ISA04), Usage Indicator (ISA15—this is where you define test or production transactions), Interchange Control Seed Number, and Group Control Seed Number.

Identify document maps

Define document maps for each source/destination schema relationship. Keep in mind that a distinct document map must be created for the reverse relationship. For example, a document map of an HCFA1500 to an 837 Professional is a one-way map, and you must create a corresponding map for the 837 Professional-to-HCFA1500 relationship.

Identify the primary messaging transport mechanism

The primary electronic messaging transport might be one of the following:

File system
Message queue
Web page (ASP)
SMTP
BizTalk Server software interface

Identify the backup messaging transport mechanism

The backup electronic messaging transport might be one of the following:

File system
Message queue
Web page (ASP)
SMTP
BizTalk Server software interface

Identify operations availability

Define the hours of operations of the system

Identify security requirements

Digital certificates
Signatures
Encryption

Identify receipt requirements

Required/Not required

HIPAA/EDI requires that an organization will generate a 997 functional acknowledgement upon receiving a HIPAA/EDI transaction from a health care partner.
Receipt destination

A custom receipt channel must be created for BizTalk Server to automatically generate a 997 functional acknowledgement to a business partner, so you must identify all the source, destination, and transport information as described above for the EDI 997 that will be returned to the organization that originated the transaction.

Orchestration

Orchestration is a unique feature of BizTalk Server that provides an extremely flexible approach to integrating business-process logic with new and existing applications and systems. The HIPAA implementation guides include content and situational requirements specific to HIPAA that are not accounted for by the BizTalk Accelerator for HIPAA parser or by the BizTalk HIPAA schemas. Orchestration can solve the problem of adding extended validation for HIPAA transaction sets and providing integrated business processing between applications.

Use BizTalk Orchestration Designer to integrate business-process logic with new and existing applications and systems. The impact of the HIPAA implementation guides affects the many business processing systems and applications currently used by health care organizations. BizTalk Orchestration is the recommended solution for adding extended validation of the HIPAA transaction sets and for providing integrated business processing between applications.

Identify the deficiencies in the ability of your current business processes, systems, and applications to handle HIPAA transactions by following the gap analysis process. Doing a risk assessment will provide you with enough information to begin remediation plans. Given the level of remediation that an organization needs to implement to become compliant, along with the time constraint for health care covered entities to become HIPAA compliant, BizTalk Orchestration can help in a number of ways:

Use orchestration to coordinate transaction messaging to multiple applications that are required to process a HIPAA transaction using synchronous and/or asynchronous methods. Use decision-making logical processing steps based on content contained in messages and/or software components.
Use orchestration to provide extended validation of HIPAA transactions before sending the transactions on to further business processing. Note that in this way, the validation processing logic does not have to be implemented in legacy systems.
Use orchestration as the facilitator for long-running HIPAA transactions, so that transactions that require coordination of data content details between the initiated transaction and the response transaction can occur over a long period of time. The claims processing sample included with BizTalk Accelerator for HIPAA is an example of this type of transaction, where the 837 Healthcare Claim contains data content required by the 835 Healthcare Payment/Advice. The 837 can contain many claims that might be processed asynchronously. Over time, as the payment/advice for the claim is generated from the legacy systems, data content from the originating 837 will be used to create the HIPAA-compliant 835 to be sent back to the sender of the 837 claim.

The Orchestration Designer tool makes it easy to document the logical business processing steps for an organization to implement each HIPAA transaction set. In addition, you can quickly build and implement a proof of concept by using rapid application development (RAD) tools like Microsoft Visual Studio® and BizTalk Orchestration Designer. Testing the business processing logic early in the planning phase can save time and helps to avoid risks associated with poor assumptions, incorrect sequences of business processing steps, and the handling of corrupted or unexpected data.

BizTalk application integration components (AICs)

How you use BizTalk Server AICs will depend on how much custom integration with new and existing applications is required. In the most basic scenario, BizTalk Server can read and write to a file system, message queue, HTTP/HTTPS, or SMTP, and requires no additional programming. Integration with software that does not support these methods requires some software development using the BizTalk Server Application Integration Component COM interface.

Implement AIC integration after the business process logic has been designed with BizTalk Orchestration Designer. In some cases, you might move business processing steps out of orchestration and into AICs. These kinds of decisions are made after performance benchmark analysis of the orchestration solution, where it can be shown that an AIC will significantly improve performance.

For more information about building AICs, refer to Messaging Samples\BTSAppIntegration in the BizTalk Server SDK.

Other Development Considerations

The following considerations are important to the development phase:

How are you going to use the relevant functionality in BizTalk Accelerator for HIPAA as part of your solution? This functionality includes HIPAA-EDI transaction sets as XML schemas, claims processing sample, automatic generation of EDI 997 functional acknowledgement, EDI document splitting for 837I, 837P, 837D, 835, and 834.
How are you going to use the relevant functionality in BizTalk Server as part of your solution? This functionality includes document transformation and transport facilities, and orchestration facilities.
What is your daily build strategy? How will it incorporate baseline testing on a daily basis?
If necessary, how will you develop a way to test your solution without ongoing access to a test facility maintained by the business partners? Can you devise a way to simulate the business partners so that you can decouple your ability to make progress from their ability to support your development efforts?
In what ways will you need to extend the solution provided by BizTalk Accelerator for HIPAA?

Stabilization and Release

The deliverables of the stabilization/release phase are as follows:

Golden release. A code base in which all critical bugs have been addressed.
Release notes. An itemized list of known issues and work-arounds for the current release.
Test results and testing tools. A summary of test results and, ideally, the test tools. These test results should include functionality and performance test results for the major feature areas while the site is under a load that represents average or peak usage. In addition to the test results, the test scripts and load-generation scripts should be included in this deliverable. These test results will serve as a baseline. All future development and configuration updates should incorporate analyzing both the functionality and performance tests to ensure that there is no degradation and hopefully that there is improvement. This defines the release criteria that must be met before any release to production. Performance test results for the Accelerator for HIPAA solution run while the solution was under stress are included in "Appendix 1: Transaction Cost Analysis Testing Methodology" in the Microsoft BizTalk Accelerator for HIPAA Architecture Guide. Results of this type of performance testing can vary depending on the hardware configuration and implementation details of each solution deployment.
Source code and executables. An installable program that reflects the debugged source code.
Project documents. Updated versions of the various project documents: Vision/Scope, Functional Specification, Project Plan, Risk Plan, Test Plan, and so on.
Milestone review. A post-mortem of both successful and unsuccessful aspects of the project. This can be a very useful exercise when done immediately after release and deployment.

The stabilization/release phase ends with the release milestone. At this milestone, the team has addressed all outstanding issues and has either shipped the product or placed it into service.

At the release milestone, responsibility for ongoing management and support of the product officially transfers from the project team to the operations and support teams. For information about operational prescriptions for BizTalk Accelerator for HIPAA, refer to the Microsoft BizTalk Accelerator for HIPAA Operations Guide.

Stabilization/Release Phase Tasks by Role

This section lists the tasks that need to be performed during the stabilization/release phase, organized by role.

Program manager

Drive bug fixing to completion.

Product manager

Manage customer sign-off.

Development lead

Lead development team in fixing bugs.
Resolve technical issues as they arise.

Test lead

Drive testing of product.
Manage bug fix tradeoffs, as dictated by the project goals and tradeoff matrix.
Help determine fixes to be deferred to a future release.
Determine project completion, and sign off.

User education lead

Lead finalization of all documentation.

Logistics manager

Deploy finished product.
Turn over operations to the operations team.

Live Testing

One of the final aspects of testing an Accelerator for HIPAA solution should be "live" testing with the relevant business partners. Before opening the solution to general use, the parallel testing of transactions placed through the health care systems that are currently in use and the new HIPAA-compliant transactions should be compared for expected results.

Release Criteria

Depending on the scope of your Accelerator for HIPAA solution, the items in the release criteria list will vary, but will generally include the live testing of all implemented functionality, for example, verifying that a HIPAA-compliant transaction can be generated, sent to the relevant business partner, and correlated with other corresponding HIPAA transactions received from the business partner. All of these functional areas must also meet minimal performance criteria based on existing performance levels or defined improvements.

Helpful Links

Microsoft Solutions Framework Web site.
The Department of Health and Human Services Administrative Simplification site posts general information, proposed rules with commentary, and legislation.
Data Interchange Standards Association (DISA). This site features information on ASC X12, X12N subcommittees, task groups, and workgroups. Results and conditions of upcoming HIPAA transaction testing will be posted here.
Electronic Healthcare Network Accreditation Commission (EHNAC) is an independent, non-profit accrediting body.
Center for Medicare and Medicaid Services (CMS) provides general information about CMS as well as a link to the CMS "HIPAA Home Page."
A comprehensive HIPAA site from Phoenix Health Systems.
A HIPAA site from Beacon Partners that includes news, timelines, and legal information.
Joint Commission on Accreditation of Healthcare Organizations (JCAHO) provides management of information guidelines and useful information regarding HIPAA's impact.
The National Committee on Vital and Health Statistics (NCVHS) is a public advisory body to the Secretary of Health and Human Services. The site provides meeting minutes and other useful HIPAA links.
American National Standards Institute (ANSI). This site posts two relevant ANSI documents that can be downloaded: ANSI Essential Requirements: Due process requirements for American National Standards (1/8/03) and ANSI Appeals Board Operating Procedures.
Workgroup for Electronic Data Interchange (WEDI). This site provides implementation materials and information regarding Notice of Proposed Rule Making (NPRM).
The Washington Publishing Company site includes reference documents pertaining to HIPAA: implementation guides, data conditions, and the data dictionary for X12N standards (except for retail pharmacies).
The Designated Standard Maintenance Organization, responsible for the implementation change request process.

Reference

MaterialsSampleSkillsAssessment.xls

PartnerApplicationMatrix.xls

Share via

Microsoft BizTalk Accelerator for HIPAA

Contents

Introduction

Audience

About This Guide

Prerequisites

About HIPAA

About EDI

About BizTalk Accelerator for HIPAA

Preparation and Assessment

Individual Preparation

Tools for assessing competency

Training

EDI implementation education

BizTalk Server education

BizTalk Accelerator for HIPAA education

Infrastructure

Identify and assess current systems

Identify and assess current EDI

Identify required hardware and software

Project Assessment Questions

Assessing organizational knowledge and education

Assessing existing business systems

Assessing existing infrastructure

Vision and Scope

The Vision/Scope Document

Executive summary section

Opportunity/problem statement section

Business benefits section

Vision statement section

Decision-making criteria section

Usage scenarios section

Solution concept section

Conceptual design section

Project team section

Critical success factors section

Risk management section

Initial project schedule section

Planning phase schedule

Planning

Gap Analysis

Legacy document schemas

Transaction set mapping

Planning Phase Tasks by Role

Program manager

Product manager

Development lead

Test lead

User education lead

Logistics manager

Determining the Project Size

General questions

Message standards selection questions

Business process questions

Implementation Cost and Time

Risk-Management Techniques

Identifying and Managing Risk

Development

Development Phase Tasks by Role

Program manager

Product manager

Development lead

Test lead

User education lead

Logistics manager

Building the Solution

Business partner and application configuration matrix

Orchestration

BizTalk application integration components (AICs)

Other Development Considerations

Stabilization and Release

Stabilization/Release Phase Tasks by Role

Program manager

Product manager

Development lead

Test lead

User education lead

Logistics manager

Live Testing