Mapping the NCVHS Core Data Elements to Health Level 7, Version 3.3

The Huntington Group

Evaluation Report

Mapping the NCVHS Core Data Elements to Health Level 7, Version 3.3.

HIS REPORT ON NCVHS DATA ELEMENTS AND HL7

Background Information

This report, on the mapping between Health Level 7 and the NCVHS Core Data Elements, has been produced under the Indian Health Services GCPR Project agreement. HL7 and Related Messaging Consultation for IHS

The Huntington Group has contracted to provide subject matter expertise and oversight in the analysis, planning and implementation of HL7 and other messaging standards within Indian Health Services for the following projects:

 RPMS HL7 Interfaces  Porting of DoD’s General Interface System (GIS) into the IHS environment  Implementation of the IHS Application Interface Engine (Cloverleaf)  Implementation of IHS MPI/MPIL  Implementation of IHS regional data repository  Techincal Consultation and Modeling for the GCPR GRM Workgroup related to the HL7 RIM Qualifications

The Huntington Group is a unit of IDX Systems Corporation. THG was established to extend IDX’s traditional healthcare IT vendor skills and knowledge base. As an independent unit of IDX, THG provides value-added, objective solutions to IDX and non-IDX customers.

THG offers three core competencies to the healthcare industry: System Integration, Process Redesign, and Organizational Development. We deliver solutions that combine these competencies with a variety of software offerings. The breadth of THG solutions include the following:

 Data Warehousing/Data Mart Implementation  Data and Data Architecture Evaluation  Information Architecture Development  Electronic Commerce and Electronic Data Interchange Planning  Year 2000 Compliance  Web-Enabled Solutions  Custom Application Development  Process Redesign

Our professionals have extensive consulting experience in these activities, and have helped clients like Indian Health Services achieve substantial and lasting benefits from better use of technology, faster turnaround times, and better quality outcomes. Professional Arrangements

The Huntington Group will assign the following resources to the IHS/GCPR engagement:

Mead Walker, Project Lead: Provides overall project management of the engagement. The project lead will ensure overall quality and timeliness of deliverables and will be the main interface/contact for IHS. The project leader will be responsible for providing technical expertise and oversight regarding HL7 informatics standards and will directly with the HL7 and related messaging project team.

Mr. Walker has over 19 years of experience in healthcare information focusing on data architecture. Past accomplishments include developing a object-oriented modeling framework for industry standards, involvement in the Logical Data Model and contributed to the development of an integrated healthcare applications project for a software vendor, and has experience with US healthcare standards developing organizations. Mr. Walker has served on the HL7 Board of Directors as well as chaired HL7's Modeling & Methodology Technical Committee leading efforts to introduce information modeling and object oriented analysis into HL7.

Abdul-Malik Shakir, Senior Advisor: Provides healthcare industry expertise to analyze data requirements, create standards and initial GCPR data model. He is familiar with the various industry data models, such as, the HL7 RIM and other data modeling principles like those employed by IDEF and UML.

2 Mr. Shakir has over 24 years of experience in information technology, specializing in all aspects of information management. IHS primary focus is in health care, where he has assisted large and small health care practices and HMOs with information system planning, information system integration, and data warehousing/decision support projects. Mr. Shakir is an industry leader and active participant in national health care informatics standards organizations including HL7, X12, and the Workgroup for Electronic Data Interchange (WEDI). He has presented IHS ideas on health care information management and health care informatics at major health care conferences such as TEPR, CPRI, and HIMSS and has written an article on HL7 for a major health care industry magazine. Mr. Shakir is co-chair of the HL7 Modeling and Methodology technical committee and a member of the HL7 Board of Directors.

Pamela Hudson, Project Executive: Provides oversight in the development and quality review of all project deliverables. Provide project management back-up support to project leader and will administer financial and contractual arrangements between THG and IHS. In addition, the Project Executive can provide healthcare industry expertise in the area of disease management and outcomes measurement.

Ms. Hudson has over 20 years of experience in healthcare consulting and operations management. Her experience ranges from managing the implementation of clinical/financial and patient care systems and data repositories for large medical centers and HMO’s to extensive information technology planning and systems development. As Practice Director Ms. Hudson is responsible for managing complex delivery solution and ensuring the quality of THG consulting engagements, as well as overall business/resource responsibilities. Ms. Hudson is an active member of the Medical Group Management Association and Healthcare Management Information Systems Society.

Recommendation

Overview

This report discusses the best way to support the NCVHS Minimum Data Set within the HL7 Standard. It concludes that the NCVHS core data elements can be readily mapped to HL7. There are some work items that will need attention to fully support the core data elements, and to make it possible to reliably communicate these elements between stakeholders in the health care environment. At the same time, achieving a reliable mapping requires some examination of different ways that data can be supported by the HL7 Standard.

Sources

The recommendations draw upon the following source documents:

 Health Level 7 standard, Version 2.3  Core Health Data Elements, Report of the National Committee on Vital and Health Statistics, August 1996  Excel Spreadsheet prepared by Steve Wagner, VHA  Email from Dan Pollock, CDC

3 Discussion

Clinical Observations

The HL7 Standard provides a highly generic structure for representing clinical observations. At the same time, administrative data is, for the most part, recorded as named data elements grouped into segments such as the PV1 and PV2. As a result, new information can often be accommodated either by adding new fields to existing segments, or by using the generic clinical observation structure based on the OBX and OBR segments. The question, therefore, is which approach to follow. There has been much discussion of this point, and multiple points of view exist. This report recommends the use of the OBR/OBX structure for data that are expected to be used to support clinical needs. Data whose use is purely or predominantly administrative, should be handled as named data elements to be added to the relevant HL7 segment. In situations where there are both clinical and administrative uses of the data, the generic OBX/OBR approach is preferred. For example, in the case of the NCVHS data elements, I recommend that a newborn’s birth weight be handled as a clinical observation, while years of schooling should be added to an existing segment – the PD1 – as a named data element.

Inpatients and Outpatients

Several of the NCVHS data elements differentiate between information collected for inpatients and outpatients. There is no need to create separate data elements within HL7 to handle this situation. The receiver of a message can readily find out whether a patient encounter is an inpatient or outpatient one – this is indicated by PV1.02, Patient Class. However, HL7 will need to revise the text definitions of some data elements to clarify this point.

Diagnoses

All of the diagnosis and condition information needed by the Minimum Data Set can readily be supported by HL7. However, some discussion and updating the text of the HL7 Standard will be required to make this clear. For example, the Minimum Data Set refers to the principal diagnosis for the patient, while the HL7 Standard uses the term primary diagnosis. In my experience, these are used as synonyms. However, it will be important to work with HL7 to make sure that the terminology used in the Standard is aligned with the Minimum Data Set.

Listing Services and Procedures

The Minimum Data Set calls for recording the procedures and services for a patient. It calls for “all diagnostic procedures and services of any type including history, physical examination, laboratory, x-ray or radiograph, and others that are performed pertinent to the patient’s reasons for the encounter; all therapeutic services performed at the time of the encounter, and all preventive services and procedures performed at the time of the encounter.” If suitable procedure codes are available, this list can be supported by the existing PR1 segment. Such a listing can also be provided using the ORC, OBR structure that HL7 uses to transmit clinical orders. It may be necessary to add an order control code (ORC.1), and some explanatory text to the standard to indicate that a message contains a

4 list of services that were performed, rather than a list of services that need to be performed.

Further Action

There are a couple of items in the Minimum Data Set that require addition of fields to HL7, and there are several more that would require support of additional codes, and some changes to the text of the Hl7 standard. It would some discussion between parties interested in implementing the Minimum Data Set and HL7 to make sure that any changes to HL7 met the functional needs. Beyond simply making changes to the standard, there is the need for discussion to ensure there is proper documentation of the Minimum Data Set, and of the way elements within the data set should be valued and used. This is needed to guarantee that using the Minimum Data Set accomplishes the goals of the NCVHS report.

Detailed Discussion

The table shows the individual NCVHS data elements, their state of completion, mapping to HL7, and comments.

Data Element NCVHS Status HL7 HL7 Complianc Comments Name of Data Segme Seq e Element nt .

Date of Birth Ready for PID 7 Full Implementation

Gender Ready for PID 8 Full Implementation

Race and Ready for PID 10& Full To fully meet the needs of the Ethnicity Implementation 22 Indian Health Service, this pair of attributes needs to be supplemented by an attribute that would record a person's tribal affiliation.

Residence Ready for PID 11 Full Implementation

Marital Status Ready for PID 16 Full Implementation

Years of Ready for None Add to PD1 segment. (Note, this Schooling Implementation could also be supported as a clinical observation.)

5 Data Element NCVHS Status HL7 HL7 Complianc Comments Name of Data Segme Seq e Element nt .

Patient's Ready for IN1 17 Partial NCVHS asks for the patient's Relationship to Implementation relationship to subscriber. Hl7 Subscriber provides the subscriber's relationship to the patient.

The requirement is a defined mapping. The difference in perspective appears to be based on the difference between the payer and provider view of the healthcare encounter.

Admission Ready for PV1 44 Full Date Implementation (Inpatient)

Discharge Ready for PV1 45 Full Date Implementation (Inpatient)

Date of Ready for EVN 6 Full Encounter Implementation (Outpatient)

Location or Ready for PV1 3 Full Use the existing field, PV1.03 - Address of Implementation Assigned Patient Location. Encounter (Outpatient)

It would be helpful to ask HL7 to change the definition to support this usage.

Principal Ready for DG1 3 Full DG1.15 Diagnosis Priority allows Diagnosis Implementation indication of diagnosis priority. (Inpatient)

In practice, the terms "primary diagnosis" and "principal diagnosis" are used as synonyms by software vendors and interface implementers.

Primary Ready for DG1 3&1 Full If a working/operational distinction Diagnosis Implementation 5 between primary and principal (Inpatient) diagnosis is defined and accepted, HL7 can add a new diagnosis type

or diagnosis priority code value.

Other Ready for DG1 3&1 Full Diagnoses Implementation 5 (Inpatient)

Qualifier for Ready for None Could be added to DG1 segment. Other Implementation Diagnoses (Inpatient) An alternate possibility would be to add date of onset instead of an onset indicator. However, diagnosis information can also be modeled as a clinical observation. In that case, date of onset is already captured as the clinically significant date for the observation

Diagnosis Ready for DG1 3&1 Full This is clearly the primary Chiefly Implementation 5 diagnosis. Responsible for Services Provided (Outpatient)

Other Ready for DG1 3&1 Full Diagnoses Implementation 5 (Outpatient)

External Ready for DG1 3&6 Partial The preferable implementation is Cause of Injury Implementation to follow the lead of the NCVHS and use ICD9 E-codes.

Therefore this information could be supported using the DG1. It would be helpful to get HL7 to support an additional diagnosis type code (DG1.06) to support processing of this value.

Birth Weight of Ready for None Represent this attribute as a Newborn Implementation clinical observation using the OBX segment.

Principal Ready for PR1 3,6 Full Procedure Implementation &15 (Inpatient)

Other Ready for PR1 3,6 Full Procedures Implementation &15 (Inpatient)

Dates of Ready for PR1 5 Full Procedures Implementation (Inpatient)

Procedures Ready for PR1, Partial The ORM - Order Message is and Services Implementation ORC, used to communicate orders to a (Outpatient) OBR performing department. This same message can be used to communicate all the services ordered or recorded as performed for a patient.

Discussions should take place with HL7 to determine if a new Order Control code is needed (it probably will be). Procedures that are assigned an ICD9 or CPT-4 procedure code can be supported with the PR1 segment.

Medications Ready for RXO 1,2, Full It is important to note that the RXO Prescribed Implementation 4,2 is used in the context of the ORM 3 message.

Disposition Ready for PV1 36 None The element definition should be (Outpatient) Implementation expanded to make it clear that both out patients and inpatients are included.

Today the standard cites a user defined table for the allowed values. This needs to be replaced by a standard table and the attention of the appropriate HL7 committees should be drawn to this requirement.

Injury Related Ready for PV2 15 Full

8 Data Element NCVHS Status HL7 HL7 Complianc Comments Name of Data Segme Seq e Element nt . to Employment Implementation ACC 5

Living/Resident Needs some PD1 2 Partial Steve Wagner notes that the HL7 ial work field captures living arrangement, Arrangement but not really residential arrangement. However, the standard should be changed to accommodate the increased scope.

It is important to communicate the set of codes contemplated by NCVHS to the appropriate HL7 committees. Subsequently, these can be included in the HL7 standard.

Facility Needs some PV1 3 Full Once a HCFA identifier has been Identification work specified, it can be used within PV1.03 without any changes to the standard.

Type of Needs some PV1 3 Full Once a HCFA identifier has been Facility/Place work specified, it can be used within of Encounter PV1.03 without any changes to the standard. Once a HCFA identifier has been specified, it can be used within PV1.03 without any changes to the HL7 standard.

Health Care Needs some PV1 52 Full Note, the requirement here is to Practitioner ID work define the procedures for defining (Outpatient) and maintaining practitioner identifiers. The HL7 standard will not need to change.

Attending Needs some PV1 7 Full Note, the requirement here is to Physician ID work define the procedures for defining (Inpatient) and maintaining practitioner identifiers. The HL7 standard will not need to change.

Operating Needs some PR1 12& Full Note, the requirement here is to Clinician ID work 14 define the procedures for defining (Inpatient) and maintaining practitioner identifiers. The HL7 standard will not need to change.

Health Care Needs some PRA 5 Full Steve Wagner notes that PRA.5 Practitioner work (contained in Chapter 15 – Specialty Personnel Management in HL7 Version 2.4) identifies a practitioner's specialties, but there isn't a place in the PV1 segment to associate the practitioner specialty with the encounter.

However, there are functional issues to be resolved before doing this. If a practitioner has multiple specialties, how does one determine which of these is applied in a specific case? Note, the NCVHS Report simple refers to identification of the practitioner specialty.

Disposition of Needs some PV1 36 Full Full standards support of this Patient work element requires definition of (Inpatient) attribute domain - the proper set of allowed values. This should be brought to the attention of NCVHS and of he HL7 Vocabulary Technical Committee.

Patient's Needs some PV1 20 Full Full standards support of this Expected work element requires definition of Sources of attribute domain - the proper set of Payment allowed values. This should be brought to the attention of NCVHS and of he HL7 Vocabulary Technical Committee.

Total Billed Needs some PV1 47 Full Charges work

Personal/Uniq Needs PID 3 Full ue ID substantial work

Self-Reported Needs Full This can be best managed as a Health Status substantial work clinical observation using the OBX segment.

Functional Needs PV1 15 Full Steve Wagner notes that the Status substantial work existing data element can be expanded to cover need once defined by NCVHS.

However, as HL7 develops, clinically information such as this will be best managed as a clinical observation using the OBX segment.

Current or Needs None Could be added to PD1 segment. Most Recent substantial work Occupation and Industry Full standards support of this element requires definition of attribute domain - the proper set of allowed values. This should be brought to the attention of NCVHS and of he HL7 Vocabulary Technical Committee.

Type of Needs PV1 2 Full Existing data element can be Encounter substantial work expanded to cover need once defined by NCVHS.

Full standards support of this element requires definition of attribute domain - the proper set of allowed values. This should be brought to the attention of NCVHS and of he HL7 Vocabulary Technical Committee.

Patient's Needs PV2 12 Full Steve Wagner notes that the Stated Reason substantial work existing data element can be for Visit or expanded to cover need once Chief defined by NCVHS. Complaint (Outpatient)

This can be best managed as a clinical observation using the OBX segment.