What healthcare organizations collect uhdds data

Chapter 4: Healthcare Data Sets and Standards

Kathy Giannangelo, MA, RHIA, CCS, CPHIMS, FAHIMA

Learning Objectives

Describe the purpose of healthcare data sets and standards

Explain the importance of healthcare data sets and standards

Identify the common health information standardized data sets

Explain the need for electronic data interchange standards

Explain the healthcare data needs in an electronic environment

Discuss how data standards are developed

Identify well-known standards that support electronic health record (EHR) systems

Discuss how data standards support the development of EHR systems

Identify prominent health informatics standards development organizations (SDOs)

Recognize the impact of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) on the development of health informatics standards

Explain the relationship of core data elements to healthcare informatics standards in electronic environments

Describe the role of government agencies, such as the ONC, in healthcare informatics standards development, testing, coordination, and harmonization

Key Terms

American College of Radiology and the National Electrical Manufacturers Association (ACR-NEMA)

American National Standards Institute (ANSI)

ASTM International

Clinical Document Architecture (CDA)

Common Formats Version 1.1

Continuity of Care Document (CCD)

Continuity of Care Record (CCR)

Core data elements

Core measure

Data dictionary

Data element

Data Elements for Emergency Department Systems (DEEDS) 1.0

Data set

Data standard

Department of Health and Human Services (HHS)

Digital Imaging and Communication in Medicine (DICOM)

Electronic data interchange (EDI)

Extensible markup language (XML)

Health Information Technology Expert Panel (HITEP)

Healthcare Effectiveness Data and Information Set (HEDIS)

Healthcare informatics standards

HIT Policy Committee (HITPC)

HIT Standards Committee (HITSC)

Hospital discharge abstract system

Inpatient

Institute of Electrical and Electronics Engineers (IEEE)

Metadata

Minimum Data Set (MDS) Version 3.0

National Center for Health Statistics (NCHS)

National Committee on Vital and Health Statistics (NCVHS)

National Institute for Standards and Technology (NIST)

Nationwide Health Information Network (NHIN)

Office of the National Coordinator of Health Information Technology (ONC)

ORYX initiative

Outcomes and Assessment Information Set (OASIS-C)

Outpatients

Prospective payment system (PPS)

Quality Data Model (QDM)

Standard

Standards and Interoperability (S&I) Framework

Standards development organizations (SDOs)

Structure and content standards

Transaction standards

Uniform Ambulatory Care Data Set (UACDS)

Uniform Hospital Discharge Data Set (UHDDS)

Introduction

Data and information pertaining to individuals who use healthcare services are collected in virtually every setting where healthcare is delivered. As noted in other chapters, data represent basic facts and measurements. In healthcare, these facts usually describe specific characteristics of individual patients. The term data is plural. Although the singular form is datum, the term that is frequently used to describe a single fact or measurement is data element. For example, age, gender, insurance company, and blood pressure are all data elements concerning a patient. The term information refers to data that have been collected, combined, analyzed, interpreted, and/or converted into a form that can be used for specific purposes. In other words, data represent facts; information represents meaning.

In healthcare settings, data are stored in the individual’s health record whether that record is in paper or electronic format. The numerous data elements in the health record are then combined, analyzed, and interpreted by the patient’s physician and other clinicians. For example, test results are combined with the physician’s observations and the patient’s description of his or her symptoms to form information about the disease or condition that is affecting the patient. Physicians use both data and information to diagnose diseases, develop treatment plans, assess the effectiveness of care, and determine the patient’s prognosis.

Data about patients can be extracted from individual health records and combined as aggregate data. Aggregate data are used to develop information about groups of patients. For example, data about all of the patients who suffered an acute myocardial infarction during a specific time period could be collected in a database. From the aggregate data, it would be possible to identify common characteristics that might predict the course of the disease or provide information about the most effective way to treat it. Ultimately, research using aggregated data might be used for disease prevention. For example, researchers identified the link between smoking and lung cancer by analyzing aggregate data about patients with a diagnosis of lung cancer; smoking cessation programs grew from the identification of the causal effect of smoking on lung cancer and a variety of other conditions.

History of Healthcare Data Collection

The first known efforts to collect and use healthcare data to produce meaningful statistical profiles date back to the seventeenth century. In the early 1600s, Captain John Graunt gathered data on the common causes of death in London. He called his study the Bills of Mortality. However, few systematic efforts were undertaken to collect statistical data about the incidence and prevalence of disease until the mid-20th century, when technological developments made it possible to collect and analyze large amounts of healthcare data.

Modern efforts at standardizing healthcare data began in the 1960s. At that time, healthcare facilities began to use computers to process larger amounts of data than could be handled manually. The goal was to make comparisons among data from multiple providers. It soon became evident that healthcare organizations needed to use standardized, uniform data definitions in order to arrive at meaningful data comparisons.

The first data standardization efforts focused generally on hospitals and specifically on hospital discharge data. The intent of the efforts was to standardize definitions of key data elements commonly collected in hospitals. Discharge data were collected in hospital discharge abstract systems. These systems used databases compiled from aggregate data on all the patients discharged from a particular facility. The need to compare uniform discharge data from one hospital to the next led to the development of data sets or lists of recommended data elements with uniform definitions.

Today, hospitals and other healthcare organizations collect more data and develop more information than ever before. Moreover, data and information from the health records of individual patients are used for more purposes than ever before. The demand for information is coming from users within the organizations as well as from external users such as third-party payers, government agencies, accreditation organizations, and others. The extensive use of information within and across organizational boundaries demands standards that promote interoperable electronic interchange of data and information. Information and informatics standards are critical in the migration to electronic health records (EHRs), as described in chapter 16.

Data Sets in the Electronic Environment

The data sets originally developed to support uniform data collection are inadequate for an electronic environment, and many public and private organizations have been actively engaged in the process of developing healthcare informatics standards to support EHR development and information interchange. Standards development is a dynamic process as key players in the standards development community negotiate, refine, and revise standards. The critical importance of healthcare information and informatics standards has been recognized in recent federal initiatives including those of the Office of the National Coordinator of Health Information Technology (ONC).

According to Toward a National Health Information Infrastructure by the National Committee on Vital and Health Statistics (NCVHS), “if information in multiple locations is to be searched, shared, and synthesized when needed, we will need agreed-upon information guardians that can exchange data with each other … we will need equitable rules of data exchange so that competitors (within or between healthcare provider systems, health information management companies, or health web services) will be willing to connect and share data” (NCVHS 2000).

Developing Standardized Data Sets and Standards

This chapter describes the initial efforts at developing standardized data sets for use in different types of healthcare settings, including acute care, ambulatory care, long-term care, and home care. It explores the recent national initiatives related to interoperability and connectivity of healthcare information systems that will support widespread implementation of EHRs. It also explains the work of developing a Nationwide Health Information Network (NHIN) that will improve patient care, increase safety, and assist clinical and administrative decision making.

It is essential that the HIM professional understand the purpose, content, and importance of healthcare data sets and standards. HIM professionals work with many of these data sets and data standards on the job. In the years to come, the roles of the HIM professional will be influenced and likely change as standards continue to develop, be adopted, and ultimately implemented.

Theory into Practice

In a large Midwestern health system, the director of health information services leads the system’s clinical data standards committee. The committee recently decided to develop a data dictionary as a first step toward implementing an EHR system. To assist in this effort, the group used the following guidelines (AHIMA e-HIM Workgroup on EHR Data Content 2006):

Design a plan

Develop an enterprise data dictionary

Ensure collaborative involvement and buy-in

Develop an approvals process and documentation trail

Identify and retail details of data versions

Design for flexibility and growth

Design room for expansion of field values

Follow established ISO/International Electrotechnical Commission (IEC) 11179 guidelines or rules for metadata registry

Adopt nationally recognized standards and normalize field definitions across data sets

Beware of differing standards for the same concepts

Use geographic codes and standards that conform to the National Spatial Data Infrastructure and Federal Geographic Data Committee

Test the information system

Provide ongoing education and training

Assess the extent to which the data elements maintain consistency and avoid duplication

Data dictionaries include the following components:

A list of data elements collected in individual health records

Definitions of the data elements

Descriptions of the attributes of each data element

Specifications for the size of the data field in the information system

Descriptions of the data views to be accessed by various users

Location where the data are stored

The committee began the process with what it considered to be a simple data element: patient gender. Committee members reviewed the types of services provided by the healthcare system’s hospitals and clinics. One of the hospitals offered a gender re-identification program that treated patients who were in the process of transitioning from one gender to the other. Another hospital provided neonatal intensive care services for a large geographical region. Some of the infants treated in the neonatal intensive care unit had been born with congenital defects that made it difficult to determine their gender.

During discussions of the problem, the clinical laboratory representative on the committee stressed the importance of documenting the gender of every patient. She explained that the normal range for most laboratory tests varies by gender. This information was a surprise to many committee members.

After the committee’s initial discussion, the health information management director agreed to research data sets and standards for gender. He accessed the United States Health Information Knowledgebase (USHIK) and found gender is defined as administrative sex rather than biological sex. After further review of several options for administrative gender, he noticed the Health Level Seven (HL7) Version 3.0 recommended three values: F, M, UN, with display names of Female, Male, Undifferentiated, and definitions of female and male. When the gender of a person could not be uniquely defined as male or female, such as hermaphrodite, the gender was considered undifferentiated. The HIM director also learned this code system is tied to the Clinical Document Architecture (CDA) Release 2 which is one of the content exchange standards for stage 1 meaningful use. The committee decided to adopt the HL7 standard for administrative gender.

The challenges the committee faced in defining this relatively simple data element raised its awareness of how difficult it would be to adequately define every data element to be included in the new EHR system. The committee members gathered information on every available healthcare data set and healthcare informatics standard and carefully compared the data definitions recommended. During their discussions, the HIM manager shared the following from the International Organization for Standardization (ISO 2004):

The increased use of data processing and electronic data interchange heavily relies on accurate, reliable, controllable, and verifiable data recorded in databases. One of the prerequisites for a correct and proper use and interpretation of data is that both users and owners of data have a common understanding of the meaning and descriptive characteristics (e.g., representation) of that data. To guarantee this shared view, a number of basic attributes has to be defined.

They discovered that implementation of the EHR system would be a huge project. However, they were committed to the process because it would improve the quality of the data collected in the system. The collection of consistent, reliable, and valid data would improve administrative and clinical decision making, make it possible to perform meaningful performance improvement comparisons, and result in the ability to move healthcare information electronically between disparate healthcare information systems.

Data Sets

Without data there is no information. However, because of the vast amounts of data available there needs to be some way to organize them so they can be managed. Creating a data set is a method to capture and arrange certain data elements in order to turn data into information.

Definition of Data Set

A data set is a list of recommended data elements with uniform definitions that are relevant for a particular use. For example, the Medicare Provider Analysis and Review (MEDPAR) File available from the Centers for Medicare and Medicaid Services (CMS) contains data from claims for services provided to beneficiaries admitted to Medicare-certified inpatient hospitals and skilled nursing facilities (SNF). The data set for this file is the data contained in the billing form’s fields.

Another example of a data set is the Quality Data Model (QDM), formerly known as the Quality Data Set (QDS), published by the National Quality Forum (NQF). The QDM will be discussed later in this chapter.

Importance and Use of Data Sets

The idea of data standardization became widely accepted during the 1960s. Under the leadership of the National Center for Health Statistics (NCHS) and the NCVHS in collaboration with other organizations, data sets were developed for a variety of healthcare settings. Data sets for acute care, long-term care, and ambulatory care were the first to be created.

Healthcare data sets have two purposes. The first is to identify the data elements that should be collected for each patient. The second is to provide uniform definitions for common terms. The use of uniform definitions ensures that data collected from a variety of healthcare settings will share a standard definition.

Standardizing data elements and definitions makes it possible to compare the data collected at different facilities. For example, when data are standardized, the term admission means the same thing at City Hospital and at University Hospital. Because both hospitals define admission in the same way, they can be compared with each other on such things as number of admissions and percentage of occupancy.

The contents of data sets vary by their purpose. However, data sets are not meant to limit the number of data elements that can be collected. Most healthcare organizations collect additional data elements that have meaning for their specific administrative and clinical operations.

Data sets may be formed for such activities as research, clinical trials, quality and safety improvement, reimbursement, accreditation, and exchanging clinical information (Giannangelo 2007). The MEDPAR File, for example, allows researchers to track inpatient history and patterns/outcomes of care over time. Acute care hospitals use the AHRQ Common Formats Version 1.1 when reporting patient safety events. Contained within Version 1.1 are technical specifications which include a data dictionary. By defining the Common Formats data elements and their attributes, standardization is possible.

Having defined data sets ensures consistent data collection and reporting. Standardized data sets provide information about the effectiveness of interventions and treatments for specific diseases, thereby improving the quality and safety of healthcare, maximizing the effectiveness of health promotions and care, minimizing the burden on those responsible for generating the data, and helping facilitate efficient reuse of data (Giannangelo 2007).

Types of Data Sets

The following are examples of data sets the HIT professional will most likely encounter in his or her daily work.

Data Sets Required or Recommended by the Federal Government

A number of data reporting requirements come from federal initiatives. Some are mandated through published federal regulations, such as the Medicare prospective payment system (PPS), while some are only recommendations.

Uniform Hospital Discharge Data Set

In 1969, a conference on hospital discharge abstract systems was sponsored jointly by NCHS, the National Center for Health Services Research and Development, and Johns Hopkins University. Conference participants recommended that all short-term general hospitals in the United States collect a minimum set of patient-specific data elements. They also recommended that these data elements be included in all databases compiled from hospital discharge abstract systems. They called the list of patient-specific data items the Uniform Hospital Discharge Data Set (UHDDS).

The purpose of the UHDDS is to list and define a set of common, uniform data elements. The data elements are collected from the health records of every hospital inpatient and later abstracted from the health record and included in national databases.

In 1974, the federal government adopted the UHDDS as the standard for collecting data for the Medicare and Medicaid programs. When the Section 1886(d) of the Social Security Act was enacted in 1983, UHDDS definitions were incorporated into the rules and regulations for implementing the inpatient prospective payment system based on diagnosis-related groups (DRGs). A key component of DRGs was the incorporation of the definitions of principal diagnosis, principal procedure, and other significant procedures into the DRG algorithms. As a result, accurate DRG assignment depends on accurate selection and coding of the principal diagnosis and principal procedure and the appropriate sequencing of other significant diagnoses and procedures. NCVHS revised the UHDDS in 1984, and the new UHDDS was adopted for all federal health programs in 1986. Because UHDDS data definitions are a component of DRGs, short-term, general hospitals in the United States generally collect patient-specific data in the format recommended by the UHDDS.

The UHDDS has been revised several times since 1986. The current version includes the recommended data elements shown in figure 4.1.

Figure 4.1. UHDDS data elements

Data Element

Definition/Descriptor

01. Personal identification

The unique number assigned to each patient within a hospital that distinguishes the patient and his or her hospital record from all others in that institution.

02. Date of birth

Month, day, and year of birth. Capture of the full four-digit year of birth is recommended.

03. Sex

Male or female

04. Race and ethnicity

04a.

Race

American Indian/Eskimo/Aleut

Asian or Pacific Islander

Black

White

Other race

Unknown

04b.

Ethnicity

Spanish origin/Hispanic

Non-Spanish origin/Non-Hispanic

Unknown

05. Residence

Full address of usual residence Zip code (nine digits, if available) Code for foreign residence

06. Hospital identification

A unique institutional number across data collection systems. The Medicare provider number is the preferred hospital identifier.

07. Admission date

Month, day, and year of admission

08. Type of admission

Scheduled: Arranged with admissions office at least 24 hours prior to admission

Unscheduled: All other admissions

09. Discharge date

Month, day, and year of discharge

10 & 11. Physician identification

• Attending physician

• Operating physician

The Medicare unique physician identification number (UPIN) is the preferred method of identifying the attending physician and operating physician(s) because it is uniform across all data systems.

12. Principal diagnosis

The condition established after study to be chiefly responsible for occasioning the admission of the patient to the hospital for care.

13. Other diagnoses

All conditions that coexist at the time of admission or that develop subsequently or that affect the treatment received and/or the length of stay. Diagnoses that relate to an earlier episode and have no bearing on the current hospital stay are to be excluded.

14. Qualifier for other diagnoses

A qualifier is given for each diagnosis coded under “other diagnoses” to indicate whether the onset of the diagnosis preceded or followed admission to the hospital. The option “uncertain” is permitted.

15. External cause-of-injury code

The ICD-9-CM code for the external cause of an injury, poisoning, or adverse effect (commonly referred to as an E code). Hospitals should complete this item whenever there is a diagnosis of an injury, poisoning, or adverse effect.

16. Birth weight of neonate

The specific birth weight of a newborn, preferably recorded in grams

17. Procedures and dates

All significant procedures are to be reported. A significant procedure is one that is:

• Surgical in nature, or

• Carries a procedural risk, or

• Carries an anesthetic risk, or

• Requires specialized training.

The date of each significant procedure must be reported. When more than one procedure is reported, the principal procedure must be designated. The principal procedure is one that is performed for definitive treatment rather than one performed for diagnostic or exploratory purposes or was necessary to take care of a complication. If there appear to be two procedures that are principal, then the one most closely related to the principal diagnosis should be selected as the principal procedure. The UPIN must be reported for the person performing the principal procedure.

18. Disposition of the patient

• Discharged to home (excludes those patients referred to home health service)

• Discharged to acute care hospital

• Discharged to nursing facility

• Discharged home to be under the care of a home health service (including a hospice)

• Discharged to other healthcare facility

• Left against medical advice

• Alive, other; or alive, not stated

• Died

19. Patient’s expected source of payment

Primary source

Other sources

All categories for primary and other sources are:

• Blue Cross/Blue Shield

• Other health insurance companies

• Other liability insurance

• Medicare

• Medicaid

• Worker’s Compensation

• Self-insured employer plan

• Health maintenance organization (HMO)

• CHAMPUS

• CHAMPVA

• Other government payers

• Self-pay

• No charge (free, charity, special research, teaching)

• Other

20. Total charges

All charges billed by the hospital for this hospitalization. Professional charges for individual patient care by physicians are excluded.

Uniform Ambulatory Care Data Set

Ambulatory care includes medical and surgical care provided to patients who depart from the facility on the same day they receive care. The care is provided in physicians’ offices, medical clinics, same-day surgery centers, outpatient hospital clinics and diagnostic departments, emergency treatment centers, and hospital emergency departments. Patients who receive ambulatory care services in hospital-based clinics and departments are referred to as outpatients.

Since the 1980s, the number and the length of inpatient hospitalizations have gone down dramatically. At the same time, the number of healthcare procedures performed in ambulatory settings has gone up. There are several reasons for this trend, including:

Technological improvements in diagnostic and therapeutic procedures and the development of short-acting anesthetics have made it possible to perform many medical and surgical procedures in ambulatory facilities. Surgical procedures that once required inpatient hospitalization and long recovery periods now are being performed in same-day surgery centers.

Third-party payers have extended coverage to include most procedures performed on an outpatient basis.

Medicare’s acute inpatient hospital prospective payment system limits reimbursement for inpatient care and, in effect, encourages the use of ambulatory and/or outpatient care as an alternative to more costly inpatient services.

Like hospitals, ambulatory care organizations depend on having accurate data and information. A standardized data set to guide the content and structure of ambulatory health records and data collection systems in ambulatory care was needed.

In 1989, NCVHS approved the Uniform Ambulatory Care Data Set (UACDS). The committee recommended its use in every facility where ambulatory care is delivered. Several of the data elements that make up the UACDS are similar to those used in the UHDDS. For example, the UACDS data elements that describe the personal identifier, residence, date of birth, gender, and race/ethnicity of the patient are the same as the definitions in the UHDDS. The reason for keeping the same demographic data elements is to make it easier to compare data for inpatients and ambulatory patients in the same facility as well as among different facilities.

The UACDS also includes data elements specific to ambulatory care, such as the reason for the encounter with the healthcare provider. Additionally, it includes optional data elements to describe the patient’s living arrangements and marital status. These data elements (shown in figure 4.2) are unique to the UACDS. Ambulatory care practitioners need information about the living conditions of their patients because patients and their families often need to manage at-home nursing care (such as activity restrictions after a surgical procedure). Hospital staff members provide such nursing services in acute care settings.

Figure 4.2. UACDS data elements

Data Element

Definition/Descriptor

Provider identification, address, type of practice

Provider identification: Include the full name of the provider as well as the unique physician identification number (UPIN).

Address: The complete address of the provider’s office. In cases where the provider has multiple offices, the location of the usual or principal place of practice should be given. Profession:

• Physician including specialty or field of practice

• Other (specify)

Place of encounter

Specify the location of the encounter:

• Private office

• Clinic or health center

• Hospital outpatient department

• Hospital emergency department

• Other (specify)

Reason for encounter

Includes, but is not limited to, the patient’s complaints and symptoms reflecting his or her own perception of needs, provided verbally or in writing by the patient at the point of entry into the healthcare system, or the patient’s own words recorded by an intermediary or provider at that time.

Diagnostic services

Includes all diagnostic services of any type.

Problem, diagnosis, or assessment

Describes the provider’s level of understanding and the interpretation of the patient’s reasons for the encounter and all conditions requiring treatment or management at the time of the encounter.

Therapeutic services

List by name all services done or ordered:

• Medical (including drug therapy)

• Surgical

• Patient education

Preventive services

List by name all preventive services and procedures performed at the time of the encounter.

Disposition

The provider’s statement of the next step(s) in the care of the patient. At a minimum, the following classification is suggested:

1. No follow-up planned

2. Follow-up planned

• Return when necessary

• Return to the current provider at a specified time

• Telephone follow-up

• Returned to referring provider

• Referred to other provider

• Admit to hospital

• Other

Source: Adapted from Hanken and Water 1994.

The goal of the UACDS is to improve data comparison in ambulatory and outpatient care settings. It provides uniform definitions that help providers analyze patterns of care. The data elements in the UACDS are those most likely to be needed by a variety of users. Unlike the UHDDS, the UACDS has not been incorporated into federal regulations. Therefore, it is a recommended, rather than a required, data set. In practical terms, it has been subsumed by other data definition efforts, most notably the core data elements recommended as part of the Standards and Interoperability (S&I) Framework, described later in this chapter.

Resident Assessment Instrument (RAI) and Minimum Data Set

Uniform data collection is likewise important in the long-term care setting. Long-term care incorporates the healthcare services provided in residential facilities for individuals who are unable to live independently because of a chronic illness or disability. Long-term care facilities also provide dietary and social services as well as housing and nursing care. To participate in the Medicare and Medicaid programs, long-term care facilities must develop a comprehensive functional assessment for every resident. From this assessment, a nursing home resident’s plan of care is developed.

The RAI process is a federally mandated standard assessment used to collect demographic and clinical data on residents in a Medicare and/or Medicaid-certified long-term care facility. It consists of three components, the Minimum Data Set (MDS) Version 3.0, the Care Area Assessment (CAA) process, and the RAI utilization guidelines (CMS 2012). To meet federal requirements, long-term care facilities must complete an assessment for every resident at the time of admission and at designated reassessment points throughout the resident’s stay.

The MDS is far more extensive and includes more clinical data than either the UHDDS or the UACDS.

The MDS organizes data according to 20 main categories. Each category includes a structured list of choices and responses. The use of structured lists automatically standardizes the data that are collected. The major categories of data collected in the MDS include:

1. Identification information

2. Hearing, speech, and vision

3. Cognitive patterns

4. Mood

5. Behavior

6. Preferences for customary routine and activities

7. Functional status

8. Bladder and bowel

9. Active disease diagnosis

10. Health conditions

11. Swallowing/Nutritional status

12. Oral/Dental status

13. Skin conditions

14. Medications

15. Special treatments and procedures

16. Restraints

17. Participation in assessment and goal setting

18. Care area assessment (CAA) summary

19. Correction request

20. Assessment administration

The data collected by the MDS are used to develop care plans for residents and to document placement at the appropriate level of care. The MDS is also used as a data collection tool to classify Medicare residents into RUGs (Resource Utilization Groups), a system used in the PPS for skilled nursing facilities, hospital swing bed programs, and in many state Medicaid case-mix payment systems. Another use of the MDS assessment data is the monitoring of the quality of care in the nation’s nursing homes through MDS-based quality indicators (QIs) and quality measures (QMs).

Because the MDS is used nationwide to collect data about residents in long-term care facilities, the data can and will be used as a basis for identifying and assessing resident safety and quality improvement activities in nursing homes. For example, MDS data can give valuable information about the incidence of falls and their impact on the care of nursing home residents. From those data, prevention measures can be developed and implemented to address a common and significant problem in elderly care.

Outcomes and Assessment Information Set

The Outcomes and Assessment Information Set (OASIS-C) is a standardized data set designed to gather and report data about Medicare beneficiaries who are receiving services from a Medicare-certified home health agency. OASIS-C includes a set of core data items that are collected on all adult home health patients whose care is reimbursed by Medicare and Medicaid with the exception of patients receiving pre- or postnatal services only.

The OASIS-C data set became effective January 1, 2010. OASIS-C includes process items that support measurement of evidence-based practices across the post-acute care spectrum that have been shown to prevent exacerbation of serious conditions, can improve care received by individual patients, and can provide guidance to agencies on how to improve care and avoid adverse events. OASIS-C contains more than 30 data elements.

OASIS-C data are grouped into the following categories (CMS 2011):

Patient Tracking Items

Clinical Record Items

Patient History and Diagnoses

Living Arrangements

Sensory Status

Integumentary Status

Respiratory Status

Cardiac Status

Elimination Status

Neuro/Emotional/Behavioral Status

Activities of Daily Living (ADLs)/Instrumental Activities of Daily Living (IADLs)

Medications

Care Management

Therapy Need and Plan of Care

Emergent Care

Discharge

Data collected through OASIS-C are used to assess the patient’s ability to be discharged or transferred from home care services. The data are also used in measuring patient outcomes in order to assess the quality of home healthcare services. Under the prospective payment program for home health, implemented in 2000, data from OASIS-C also form the basis of reimbursement for provided services. In addition, these data are used to create patient case mix profile reports and patient outcome reports that are used by state survey staff in the certification process. Home health agency quality measures that appear on the CMS Home Health Compare website are also based on OASIS-C data.

Healthcare Effectiveness Data and Information Set

The Healthcare Effectiveness Data and Information Set (HEDIS) is sponsored by the National Committee for Quality Assurance (NCQA). HEDIS is a set of standard performance measures designed to provide healthcare purchasers and consumers with the information they need to compare the performance of managed healthcare plans.

HEDIS is designed to collect administrative, claims, and health record review data. It collects standardized data about specific health-related conditions or issues so that the success of various treatment plans can be assessed and compared. HEDIS data form the basis of performance improvement (PI) efforts for health plans. They also are used to develop physician profiles. The goal of physician profiling is to positively influence physician practice patterns.

HEDIS contains more than 70 measures related to conditions such as heart disease, cancer, diabetes, asthma, chlamydia infection, osteoporosis, and rheumatoid arthritis. It includes data related to patient outcomes and data about the treatment process used by the clinician in treating the patient.

Standardized HEDIS data elements are abstracted from health records in clinics and hospitals. The health record data are combined with enrollment and claims data and analyzed according to HEDIS specifications.

An example of a HEDIS measure is comprehensive diabetes care. Other examples of HEDIS effectiveness of care measures include:

Adolescent immunizations

Medical assistance with smoking and tobacco use cessation

Antidepressant medication management

Breast cancer screening

Cholesterol management for patients with cardiovascular conditions

Follow-up care for children prescribed ADHD medication

Health plans often release data from HEDIS studies publicly to document substantial positive effects on the health of their clients. Results are compared over time and with data from other sources. From the data, health plans determine opportunities for performance improvement and develop potential interventions.

HEDIS is an example of a population-based data collection tool. It illustrates the need for developing standardized data definitions and uniform collection methods. It also emphasizes the importance of data quality management.

Data Elements for Emergency Departments

Emergency and trauma care in the United States are very sophisticated. Emergency services represent a large part of healthcare delivery. As services increase, it is more and more important to collect relevant aggregate data about emergency and trauma care. Many states require the reporting of trauma cases to state agencies.

In 1997, the Centers for Disease Control and Prevention (CDC) through its National Center for Injury Prevention and Control (NCIPC) published a data set called Data Elements for Emergency Department Systems (DEEDS) 1.0. The purpose of this data set is to support the uniform collection of data in hospital-based emergency departments and to reduce incompatibilities in emergency department records.

DEEDS recommends the collection of 156 data elements in hospitals that offer emergency care services. As with the UHDDS and UACDS, this data set contains recommendations on both the content and the structure of the data elements to be collected. The data are organized into the following eight sections:

Patient identification data

Facility and practitioner identification data

Emergency department payment data

Emergency department arrival and first-assessment data

Emergency department history and physical examination data

Emergency department procedure and result data

Emergency department medication data

Emergency department disposition and diagnosis data

DEEDS incorporates national standards for electronic data interchange (EDI), so its implementation in an EHR system can make possible communication and integration with other information systems (NCIPC 2006).

The Health Level Seven (HL7) Emergency Care Work Group has begun the process of updating and revising DEEDS 1.0 with the intent to expand the scope of DEEDS to harmonize with the prehospital arena, disaster response systems, and the needs of secondary data users such as the CDC and public health agencies (HL7 2011).

Core Measures for ORYX

The Joint Commission (TJC) is one of the largest users of healthcare data and information. Its primary function is the accreditation of hospitals and other healthcare organizations. In 1997, the TJC introduced the ORYX initiative to integrate outcomes data and other performance measurement data into its accreditation processes. (The initiative was named ORYX after an African animal that can be thought of as a different kind of zebra.) The goal of the initiative is to promote a comprehensive, continuous, data-driven accreditation process for healthcare facilities (TJC 2012).

The ORYX initiative uses nationally standardized performance measures to improve the safety and quality of healthcare. The ORYX initiative integrates outcomes and other performance measures into the accreditation process through data collection about specific core measures (TJC 2012). The core measures are based on selected diagnoses/conditions such as diabetes mellitus, the outcomes of which can be improved by standardizing care. They include the minimum number of data elements needed to provide an accurate and reliable measure of performance. Core measures rely on data elements that are readily available or already collected. The Joint Commission is in the process of reclassifying the core measures as accountability measures.

Data Sets for Interoperable Electronic Information Exchange

ARRA and HITECH provided funding to support the adoption of qualified EHRs. Their subsequent regulations define the meaningful use of HIT systems. To meet the meaningful use requirements, the submission of information on clinical quality measures is necessary. Formed by the National Quality Forum with support from the Agency for Healthcare Research and Quality (AHRQ), the Health Information Technology Expert Panel (HITEP) was tasked with creating a better link between current quality measurement and EHR reporting capabilities. The HITEP Quality Data Set (QDS) Workgroup developed a QDS framework, which includes standard elements, quality data elements, and data flow attributes (NQF 2009).

The QDS, now known as the Quality Data Model (QDM), has undergone several revisions. However, its underlying purpose remains. According to NQF (2011), the QDM “clearly defines concepts used in quality measures and clinical care and is intended to enable automation of structured data capture in EHRs, PHRs, and other clinical applications. It provides a grammar to describe clinical concepts in a standardized format so individuals (i.e., providers, researchers, or measure developers) monitoring clinical performance and outcomes can concisely communicate necessary information.”

The QDM element, which is defined as an atomic unit of information that has precise meaning to communicate the data required within a quality measure, provides unambiguous definition and enables consistent capture and use of data for quality measurement (NQF 2011).

One of the government’s health outcomes policy priorities used to create the framework for meaningful use of EHRs is to improve care coordination. A key to interoperable electronic information exchange is having defined core data sets. ASTM International (ASTM) was instrumental in identifying a core data set for a patient’s clinical summary with the publication in 2005 of ASTM E2369-05e2 Standard Specification for Continuity of Care Record (CCR). The CCR core data set is shown in figure 4.3.

Figure 4.3. Continuity of Care Record core data set

• Patient administrative and clinical data

• Basic information about the patient’s payer

• Advance directives

• Patient’s sources of support

• Patient’s current functional status

• Problems

• Family history

• Social history

• Alerts

• Medications

• Medical devices or equipment needed by the patient

• Immunization history

• Vital signs (as appropriate)

• Results of laboratory, diagnostic, and therapeutic results

• Diagnostic and therapeutic procedures

• Encounters

• Plan of care

• Healthcare providers

Source: Reprinted, with permission, from E2369, copyright ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA 19428. A copy of the complete standard may be obtained from ASTM International, www.astm.org.

Another organization, Health Level Seven (HL7), developed the CDA. The CDA provides an exchange model for clinical documents (such as discharge summaries and progress notes). It also makes documents machine-readable so that they can be easily processed electronically and makes them human-readable so that they can be retrieved easily and used by the people who need them.

ASTM and HL7 combined their work to create the Continuity of Care Document (CCD). The CCD is an implementation guide for sharing CCR patient summary data using the CDA. The CCD was recognized as part of the first set of interoperability standards. The CCR, CDA, and CCD will be discussed later in this chapter.

Continuing the work toward interoperability is the transitions of care (ToC) initiative, one of the projects of the Standards and Interoperability (S&I) Framework. According to the initiative’s charter (S&I Framework 2011a para 1), “The exchange of clinical summaries is hampered by ambiguous common definitions of what data elements must at a minimum be exchanged, how they must be encoded, and how those common semantic elements map to MU specified formats (C32/CCD and CCR).” An outcome of the initiative is a clinical information model (CIM) “consisting of unambiguous, clinically-relevant definitions of the core data elements that should be included in care transitions” (ONC 2011a slide 4). The core data element categories are demographics, active medication list, active problem list, and intolerances including allergies. Figure 4.4 lists the core data elements for the active problem list category.

Figure 4.4. Active problem list

• Coded Problem(s) or no known problem(s)

• Start Date (or date of onset) of problem(s)

• Clinician who added it to the problem list (include date/time stamp)

• Reconciled (Yes or No)

• Reconciled by? Date/Time Stamp

• Resolved and/or changed problems in this encounter

Note: What clinician sending the message has determined to be the patient’s active problems and/or diagnoses or determination of no known problems—this list may be reconciled at each ToC.

Source: S&I Framework 2011b.

Check Your Understanding 4.1

1. Which of the following is designed to collect a minimum set of data about inpatients?

A. DRGs

B. NCHS

C. UACDS

D. UHDDS

2. Which of the following is used to collect data about ambulatory care patients?

A. DRGs

B. MDS

C. ORYX

D. UACDS

3. Which of the following is used to collect data about long-term care residents?

A. NCHS

B. MDS

C. UACDS

D. UHDDS

4. Which of the following provides a structured way to develop a long-term care resident care plan?

A. MDS

B. OASIS-C

C. UACHD

D. UHDDS

5. Which of the following is used to gather data about Medicare beneficiaries receiving home care?

A. MDS

B. NCHS

C. OASIS-C

D. UHDDS

6. Which of the following best describes the DEEDS data set?

A. Uses data for home health outcomes research

B. Collects data about hospital emergency encounters

C. Uses data for inpatient analysis

D. Collects data for ambulatory care

7. Which of the following is a set of performance measures used to compare the performance of managed healthcare plans?

A. DEEDS

B. HEDIS

C. ORYX

D. UHDDS

8. Which of the following was developed by the Joint Commission?

A. HEDIS

B. MDS

C. OASIS-C

D. ORYX

9. Which of the following would be a core data set for a patient’s clinical summary?

A. CDA

B. CCR

C. CCD

D. QDS

10. The Resident Assessment Instrument is triggered by the data collected by the:

A. Core measures

B. DEEDS

C. MDS

D. HEDIS

Standards for Electronic Data and Electronic Data Interchange

The original uniform data sets such as the UHDDS and the UACDS were created for use in paper-based (manual) health record systems. They were not designed to accommodate the data needs of the current healthcare delivery system or the demands of EHRs and clinical information systems.

Standards are needed in order for data to be easily, accurately, and securely communicated and exchanged electronically among various computer systems. This is referred to as interoperability. Without standards for interoperability, EHRs and the NHIN will not realize their full benefits (Thompson and Brailer 2004).

Many types of standards are being developed to support the EHR and health information exchange. Some involve defining record structure and content, others specify technical approaches for transmitting data, and still others provide rules for protecting the privacy and security of data.

Public and private organizations have been actively engaged in the process of developing healthcare informatics standards to support EHR development, interoperability, and information exchange. The federal government supports this work in a variety of ways. One example is the S&I Framework. According to Fridsma (2010 slide 4), the Framework “is the mechanism by which ONC will manage the implementation of specifications and the harmonization of existing health IT standards to promote interoperability nationwide.”

Definition of Data Standard for Electronic Data Exchange

Data standards provide the ability to record a certain data item in accordance with the agreed upon standard (Giannangelo 2007). Data content standards are “clear guidelines for the acceptable values for specified data fields” (Fenton et al. 2007). Data exchange standards are protocols that help ensure that data transmitted from one system to another remain comparable.

One of the purposes of HIPAA’s Administrative Simplification rules was to standardize information exchange and in August 2000, the Department of Health and Human Services (HHS) published regulations for electronic transactions. These regulations apply to transactions that occur among healthcare providers and healthcare plans and payers (Rode 2001). The long-term goal of the transaction standards is to allow providers and plans or payers to seamlessly transfer data back and forth with little intervention. To do this, HHS adopted the electronic transaction standards of ASC X12 Insurance Subcommittee (Accredited Standards Committee Health Care Task group [X12N]). The standards adopted for EDI are called ANSI ASC X12N.

The HIPAA standards also include code sets standards for the electronic exchange of health-related information. To illustrate how the adoption and utilization of standards for data representation and data exchange facilitates billing functions, consider the codes sets are data standards used to identify specific data elements such as the diagnosis on a claim. The compendium of data elements on the claim form make up a data set. In order to send the diagnosis and other items that make up the data set electronically, the healthcare provider uses the ASC X12N 837 messaging standard. The 837 specifies the format for each data element. For example, one specification for the format of the diagnosis would be that diagnosis codes have a maximum size of seven (7) characters.

A new version of the standard for electronic healthcare transactions (Version 5010 of the X12 standard) was approved in 2009 and implemented in 2012. This new version is essential to the use of ICD-10-CM and ICD-10-PCS codes that are slated for implementation in 2013.

Data Needs in an Electronic Environment

As discussed in chapter 16, healthcare organizations often have several different computer systems operating at the same time. For example, a hospital’s laboratory system might be entirely separate from its billing system. In fact, the various departments of large healthcare organizations often use different operating systems and are serviced by different vendors. In addition to operating multiple systems, it is an ongoing challenge to integrate information from legacy (older) systems operating on old platforms with state-of-the art information systems.

Healthcare organizations must integrate data that originate in various databases within facilities as well as in databases outside the facility. They also must be able to respond to requests to transfer data to other facilities, payers, accrediting and regulating agencies, quality improvement organizations, and other information users. These goals can only be accomplished when every database system is either operating on the same platform or using common standards.

Benefits of Data Exchange Standards

Healthcare informatics standards describe accepted methods for collecting, maintaining, and/or transferring healthcare data among computer systems. These standards are designed to provide a common language that makes it easy to:

Exchange information

Share information

Communicate within and across disciplines and settings

Integrate disparate data systems

Compare information at a regional, national, and international level

Link data in a secure environment

Having the ability to exchange, share, communicate, integrate, compare, and link data is important to healthcare delivery. These activities make possible important activities such as:

Disease surveillance

Health and healthcare population monitoring

Outcomes research

Decision making and policy development

The long-term vision is to enhance the comparability, quality, integrity, and utility of health information from a wide variety of public sources through uniform data policies and standards (NCVHS 2001). Thompson and Brailer (2004, 13) expressed the federal commitment to standards in their statement that “A key component of progress in interoperable health information is the development of technically sound and robustly specified interoperability standards and policies.” In 2010, states, eligible territories, and qualified State Designated Entities received awards from ONC to assist them in facilitating the secure exchange of health information in order to advance state-level health information exchange while moving toward nationwide interoperability. The ONC expects the funding to be used to increase connectivity, enable patient-centric information flow to improve the quality and efficiency of care, and ensure healthcare providers and hospitals meet national standards (ONC 2011b).

Many types of standards are necessary to implement EHRs and a health information technology infrastructure that supports connectivity, interoperability, and seamless data interchange. International, national, state and regional or local standards ensure communication and efficiency and minimization of duplication of effort along the continuum of healthcare. It is especially important to note that healthcare is provided locally and standards must be adopted at the local level to achieve the full benefit of an EHR.

American Recovery and Reinvestment Act

Officially known as the American Recovery and Reinvestment Act (ARRA P.L. 111-5) and Health Information Technology for Economic and Clinical Health Act (HITECH), the “Stimulus Law” was signed on February 17, 2009. ARRA provides $19.2 billion in spending on health IT. Title XIII of ARRA, given a subtitle, “Health Information Technology for Economic and Clinical Health Act (HITECH),” deals with many of the health information communication and technology provisions.

Office of National Coordinator

ARRA includes the statutory authorization of ONC, which makes ONC a permanent office under HHS (Asmonga 2009). Its charge is to help develop a national health IT infrastructure to improve the quality and efficiency of healthcare and the ability of consumers to manage their care and safety. ARRA stipulated $2 billion to ONC for use as follows (Asmonga 2009):

$20 million: to advance healthcare information enterprise integration through technical standards analysis and establishment of conformance testing infrastructure to be done by the National Institute of Standards and Technology (NIST) and coordinated with ONC

$300 million: to support regional or subnational efforts toward health information exchange

Remaining funds: to the immediate implementation assistance to support:

— Health IT architecture

— Development and adoption of certified electronic health records (EHRs) for categories of healthcare providers not eligible for support under title XVIII or XIX of the Social Security Administration for the adoption of such records

— Training on best practices to integrate health IT

— Infrastructure and tools for the promotion of telemedicine

— Promotion of the interoperability of clinical data repositories or registries

— Promotion of technologies and best practices

— Improvement and expansion of the use of health IT by public health departments

The ONC published a final rule establishing standards, implementation specifications, and certification criteria for the certification of EHR technology to support the achievement of meaningful use Stage 1 by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR incentive programs in 2010. Stage 1 standards, which took effect in 2011, fall into three categories: content exchange, vocabulary, and privacy and security (ONC 2010). Transport standards were proposed but removed in the final rule. These standards will be discussed later in this chapter.

Health Information Technology (HIT) Policy Committee and HIT Standards Committee

Two official HHS advisory committees established as a result of ARRA are the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC). The HIT Policy Committee provides recommendations to the National Coordinator on a policy framework for the development and adoption of a nationwide health information technology infrastructure that permits the electronic exchange and use of health information as is consistent with the Federal Health IT Strategic Plan and that includes recommendations on the areas in which standards, implementation specifications, and certification criteria are needed.

The HIT Standards Committee provides recommendations to the National Coordinator on standards, implementation specifications, and certification criteria for the electronic exchange and use of health information for purposes of adoption, consistent with the implementation of the Federal Health IT Strategic Plan, and in accordance with policies developed by the HIT Policy Committee.

Standards Development, Coordination, Testing, and Harmonization

Developing, coordinating, testing, and harmonizing healthcare standards is a complex process in which many organizations are involved. The following definitions provide further information on standards and harmonization (HITSP 2009):

The term standard … is a well-defined approach that supports a business process and:

has been agreed upon by a group of experts

has been publicly vetted

provides rules, guidelines, or characteristics

helps to ensure that materials, products, processes, and services are fit for their intended purpose

is available in an accessible format

is subject to an ongoing review and revision process.

Harmonization is the name given to the effort by industry to replace the variety of product standards and other regulatory policies adopted by nations, in favor of uniform global standards. Usually used in the context of trade agreements, harmonization has recently been adopted by the United States government to refer to information technology standards.

Most standards are created through a voluntary consensus process that involves identifying the need for a standard, negotiating the content of the standard, and drafting a proposed standard. The final standard is published after undergoing a comment and revision period. This process facilitates wide adoption and improved utility. Figure 4.5 describes the standards value chain.

Figure 4.5. Standards value chain

Standards typically go through several stages in a process that can take three or more years. It begins with developers, who draft new standards or update existing ones. Profiling organizations select among applicable standards, combine the work of multiple developers, and create use scenarios for how to apply them. Typically, independent, neutral organizations test the standards, and implementers put them to work.

Advocates

Advocacy organizations influence and facilitate the value chain at every step. National governments are prominent standardization advocates, often sponsoring, funding, and staffing standards activities. Private-sector stakeholders include advocacy organizations such as health IT and finance advocates and software vendors, implementers, and users. Consumers also have a stake in standards, although they are underrepresented in standards advocacy.

Market Stakeholders

Software vendors, implementers, and users are economic stakeholders. They influence standards development and implementation through participation and funding. Their balance of interest is both strategic and tactical.