Road Map for Implementing the Health care service: Data Reporting Guide

Bob Davis (January 13, 2004)

Introduction

The road traveled for all information systems follows signs marked by relevant and appropriate data sources. The journey to obtain the needed data is best taken on well traveled and well marked roads. We have all envisioned that dream vacation in that exotic location. Any delays in the journey detract from the dream vacation experience. The same principle applies to our quest for data.

The purpose of this paper is to provide a road map of when and how to implement the Health Care Service: Data Reporting guide (HCSDRG) as a vehicle for taking the well traveled and well marked road to collect health services data.  The Health Care Service: Data Reporting guide is an implementation guide based on the ANSI (American National Standards Institute) ASC (Accredited Standards Committee) X12N (Insurance Subcommittee) Health Care Claim 837 transaction standard, which is also named for processing HIPAA compliant health claims. This standard is very robust. It was designed to accommodate the varied needs of all professional and institutional payers and health care providers in the United States. The Health Care Service: Data Reporting guide was developed using the version of the ANSI ASC X12 standard in effect as of October 2001 (Version 004050).

Who are the stakeholders most likely to use the HCSDRG?

All ANSI ASC X12N implementation guides are developed to meet specific business needs with official approval based on those stated needs. The implementation guide was designed and approved to meet the reporting needs of institutional providers (e.g., hospitals and health systems) to state agencies or hospital associations. Users of discharge or encounter data provided the greatest input into the development of the business case or argument for the Health Care Service: Data Reporting guide. Receivers and submitters of Medicaid institutional encounter data also participated in the guide design. Though existing state and hospital association reporting systems typically use the term “discharge data” and state Medicaid agencies typically use the term “encounter data,” both are collecting what could be considered “what’s wrong with the patient, what was done to the patient and how much does it cost” data. Medicaid agencies use the data for different purposes than state or hospitals reporting systems. For the purposes of this paper the terms encounter and discharge data refer to the same data, but different uses. We want to use both terms so that potential users can continue to identify with familiar vocabularies. (1)

Within health care institutions, medical records and billing department personnel maintain discharge and encounter data. Users and collectors of these discharge or encounter data are the stakeholders that will most likely be continuing on the journey that could be made easier using the Health Care Service: Data Reporting guide.

Is the Health Care Service: Data Reporting guide relevant for my purposes?

If your information system purposes rely on institutional medical records and/or billing departments as data sources, then the Health Care Service: Data Reporting guide would be an applicable data transmission standard. Before implementing the standard, it is critical to identify the prioritized questions to be answered by the proposed information system. The system design team must secure executive management “buy-in” to these questions. Then the design team can select the relevant set of data elements needed to answer those questions, decide how to organize the data, and determine the necessary response time required of the system. The priority of the questions balanced against the implementation budget will determine the scope of the resulting system design, implementation plans and development costs. Candidates for using the Health Care Service: Data Reporting guide should continue on their journey.

What data standards education is necessary?

To understand the full capabilities of the Health Care Service: Data Reporting guide it is necessary to understand how this data content is used and transmitted between trading partners. The data content of the Health Care Service: Data Reporting guide is based on the UB data specifications document maintained by the National Uniform Billing Committee (NUBC). The UB data set is coded with generic codes for discharge status, admission type and source, health conditions, important dates related to care (e.g. date injury reported, date hospice coverage began, or insured birth dates), numeric value amounts related to the patient stay (e.g. deductibles or co-insurance amounts), and health service charges.

The data transmission format of the Health Care Service: Data Reporting guide is based on HIPAA compatible ANSI ASC X12N electronic data interchange protocols using the health care claim 837-transaction.

The National Association of Health Data Organizations (NAHDO) and the Public Health Data Standards Consortium (PHDSC) Web sites provide progressively detailed education on data content and data formatting standards issues. Below are the Web site addresses (URLs) for those two sites respectively:

• www.nahdo.org

• www.phdatastandards.info

The most detailed information is available from the data content and standards organization Web sites:

• The NUBC Web site address is www.nubc.org. Access to the specific UB code lists is available to Web site subscribers, which is owned by the American Hospital Association (AHA), for a nominal fee

• General information about the ANSI ASC X12 standards is available on the X12 Web site at www.x12.org.

• Copies of the Health Care Service: Data Reporting guide itself are available for $30 from the Washington Publishing Company Web site, www.wpc-edi.com.

Review of the UB data content standards and the Health Care Service: Data Reporting guide will allow potential users to select the appropriate set of data elements to be included in the intended information system. Users need to extract the definitions and valid code values from the appropriate internal or external code sources and/or the X12 data format.

Ultimately, data standards education should allow stakeholders of the Health Care Service: Data Reporting guide to answer the following questions:

• What other industries besides health care are successfully using the X12 standards?;

• What data content is contained in the UB data specifications and integral to the 837 standard?;

• What other medical codes are referenced in the Health Care Service: Data Reporting guide and the HIPAA compliant 837?;

• What are the differences between the Health Care Service: Data Reporting guide and the HIPAA compliant 837 institutional implementation guide?; and

• Why is a standards solution to collecting health services data worth the investment?

What other documentation will keep the journey heading toward implementation?

The Health Care Service: Data Reporting guide was developed as a work product of the health care claim work group that developed the HIPAA institutional, professional, and dental claim implementation guides. This was done to ensure that the Health Care Service: Data Reporting guide would be compatible with the HIPAA claim guides. Building on the UB data content standards and the X12 implementation guides, it is this author’s experience in implementing a statutorily mandated emergency department data collection system in New York State that creation of a separate document, which is a subset of the Health Care Service: Data Reporting guide, with the state-specific requirements, is very beneficial. This document could contain the specific data elements and supporting code structures to meet just the particular data needs of the state or hospital association reporting system while still being permissible within the rules of the Health Care Service: Data Reporting guide. An example of this can be found at the following URL from the New York State Department of Health: http://www.health.state.ny.us/nysdoh/sparcs/pdf/soutadd.pdf.

If the intended information system is new, it will be necessary to provide documentation to the users, which includes the basic information needed to use the data. Though this step seems obvious, the better informed data users are about the resulting data set, the more likely they are to appropriately use the data. The ultimate success of a data system is not determined by the standards used for collection, but by the way the data are used. This important group of stakeholders needs to have the necessary documentation to be able to fully utilize the data collected.

How do you get all stakeholders to travel the same road?

The Health Care Service: Data Reporting guide was developed to be HIPAA compatible. All data segments and data elements in common with the HIPAA claim transaction are identical. Any stakeholders bound by the HIPAA rules will do not need to maintain parallel systems to adhere to the Health Care Service: Data Reporting guide requirements. Using proprietary transmissions vehicles will become the road less desirable and consequently less traveled over time.

The purpose of the Public Health Data Standards Consortium’s Web-based Resource Center is to provide a single portal for stakeholders to get information about the advantages of implementing standards-based systems. National and local outreach will be the key to replacing proprietary systems with standards-based systems.

An important stakeholder not always included in the design and development discussions for public health information systems is the vendor community. It is this group, however, that will be responsible for the software that supplies and uses public health data. Vendor systems that are applicable across state borders should be a goal for system designers. Proliferation of proprietary systems is more costly than development of standards-based systems.

Providing economic and system design advantages for using a national standards-based system should provide sufficient incentives for stakeholders to choose the well traveled, standards road. Communicating these advantages to all stakeholders is an important task on the road to successfully implementing national standards as the preferable option to maintaining proprietary legacy systems.

What technical things do I need to know?

The X12 format is not user friendly. It is comprised of data segments and within those are the data elements. Data segments and data elements are the building blocks of an X12 standard and define what would be permissible in any implementation of an X12 standard. There is a delimiter between each of the data elements in each segment. The 837 standard along with the implementation guide detail what data elements and what data segments are permissible for that implementation guide. In addition, the 837 standard and the implementation guide define rules for when segments and data elements can be repeated. The purpose of this delimited structured format is to make transmission more efficient for electronic data interchange (EDI). Below is an example of a typical string of delimited X12 data used to report the name and identifier of a person or organization. Note the delimiter used in this example is an asterisk (*).

NM1*QC*1*DONOR*MARY*A***MI*123456789M~

This string of data contains the segment name (NM1), a qualifier to indicate the name is the patient’s (QC), a qualifier to indicate that this is a name of a person (1), the patient’s last name (DONOR), the patient’s first name (MARY), the patient’s middle name (A), some unused data elements, a qualifier for an identifier (MI), the patient’s identifier, and a character to end the string (~).

To interpret the rules set by standard and the implementation guide there is typically translation software used to receive the X12 format and “translate” that application “unfriendly,” but efficiently transmitted data, into something more understandable by the application system. There are commercial translation vendors that sell this software, though it is possible to have “in-house” programming accomplish this same function. A key point to remember is that all the 837 rules for the Health Care Service: Data Reporting guide will be identical to those applied to HIPAA transactions. The implementation guide specific rules have been aligned with the HIPAA institutional claim implementation guide. By making the Health Care Service: Data Reporting guide compatible with the HIPAA standards, the translation software necessary can also be standard for claim and reporting uses.

To assist in creating the translation or “mapping” of the specific data elements for any information systems that would utilize the Health Care Service: Data Reporting guide, NAHDO and the PHSDC have developed mappings (or crosswalks) for the entire implementation guide. They are available on their respective Web sites. It is intended to be used to standardize how translation software maps the 837 data streams for application systems designed to use the Health Care Service: Data Reporting guide.

If there are data elements that do not map into the 837-standard, the Health Care Service: Data Reporting guide was designed to be capable of supporting those state-specific fields through use of the NTE and/or K3 generic segments.(2) Each of these segments allows codified or unstructured data to be reported that is not already supported by existing segments in the 837 standard. Use of either of these segments can satisfy immediate data needs, but this lack of standardization increases vendor and programming costs. When it is necessary to use these generic segments to provide short term data solutions, we would hope that those “gaps” in the standard are brought to the attention of the Public Health Data Standards Consortium to target long term changes to the standard to nationalize those state –specific data requirements.

Can the road to implementation be a smooth ride?

No one is suggesting that the implementation of any new or enhanced information systems would be without incident. The issue is the amount of effort it takes to resolve those incidents and whether the necessary accommodations affect the desired functionality of the system. A smooth implementation journey is most probable when the needs of the intended users have been balanced with the capabilities of the data suppliers. The communication necessary for both users and suppliers of the data to understand the other’s limitations is the critical factor in a successful implementation. The Health Care Service: Data Reporting guide provides a guideline of data supplier capabilities and a robustness to satisfy many data user needs. The national consensus process to change the standards and the Health Care Service: Data Reporting guide implementation guide is a vehicle to communicate those needs and capabilities across the country.

The bottom line is that once system design, development, and implementation take the standards road, there will need to be a long term commitment to maintaining that road. It is a road that can enable smoother implementation. It is a road that will also enable better communication among all potential stakeholders, which will also include the information system vendors. Systems with many special requirements cost more than systems derived from a set of standards. The long term commitment to the Health Care Service: Data Reporting guide is that it will need to be utilized and maintained to assist in making for a smooth journey.

Summary

Taking the road less traveled made all the difference to Robert Frost, but for information system developers that road less traveled is fraught with detours, delays, and cost overruns. The Health Care Service: Data Reporting guide is meant to provide a roadmap for that well traveled road for design and development of discharge and encounter systems.

It is not enough to just ride along the well traveled road. All roads and standards must be maintained or they soon would deteriorate. Stakeholders need to be active participants in the standards process to insure that the standards will evolve to meet our future needs. We hope to see you all on the road. May we all have smooth journeys.

References

(1) The release of the implementation guide does not support reporting of professional services data because no potential users articulated a business case, though the 837 Health Care Claim standard supports reporting of professional services.
(2) These segments are used as “space-fillers” in the X12 format.  The segments maintain space until they are eventually filled with data at a later date.