Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

Transaction Standards

Health Claims or Equivalent Encounter Information

HCFA Uniform Bill-92 (UB-92), Version 4.1

Contact For More Information:

Jean M. Harris - Email JHarris2@hcfa.gov, 410-786-6168, FAX 410-786-4047

Description of Standard:

The UB92 consists of fixed-length (192 bytes) records. Each record has an unique identifier and logically related data elements.

Objective - The UB92 was designed to standardize and increase the submission of electronic claims and coordination of benefits exchange.

Function - The UB92 is used to electronically submit claims for health care received in an institutional setting to payers. It is also used to exchange health Care claims and payment information between payers with different payment responsibility.

User Environment - UB92 users are institutional providers. A variety of payers also use the format to exchange claim and payment information.

Systems Environment - The UB92 is a file format and is platform/operating system independent.

Application Function/Domain Completeness - All codes used in the UB92 are complete.

The UB92 is "user friendly" and easily implemented. It contains detailed record and data descriptions as well as unambiguous data definitions. It is widely used by providers of health care and payers. It is conservatively estimated that 60,000 providers use the UB92. In FY96, 141,872,119 Medicare institutional claims were submitted electronically. Ninety six point eight (96.8) percent of those claims were in the UB92. The UB92 does not have to be translated prior to application processing. The use of compression techniques eliminates at least 50% overhead when transmitting the UB92. With compression, the UB92 is more economical than an ANSI X12 837 to transport.

Readiness of Standard:

A. The UB92 is a guideline for building electronic claims. The UB92 supports policy requirements for users. The UB92 defines processes using procedure statements.

B. The UB92 was fully implemented for Medicare in 1993 (the UB83 was implemented in 1983) and continues to be supported. The UB92 has been implemented by about 73 other major payers.

C. The UB92 is available on the HCFA BPO bulletin board 410-786-0215. The file name is UB92BBS.EXE and is located in area 3. There are no restrictions and it is free of charge.

D. The UB92 implementation guide is built into the specifications, and people may build standard claims from it.

E. Some payers provide a guide to identify payer specific requirements.

F. The UB92 specifies conformity. Because it is in the public domain some people choose not to conform. This would easily be fixed if it was recognized by Federal statute. The specifications are clear and conformity is easy to achieve.

G &

H. HCFA's Office of Analysis and Systems has developed a software conformance/enforcement tool for the UB92.

I thru

M. The UB92 has been available since 1993.

Indicator of Market Acceptance:

A. Medicare implemented the standard (UB83) in 1983. Copies of the UB92 are requested frequently. The UB92 is available on a bulletin board. Diskettes were previously distributed. Since the UB92 is free of charge, the number of copies distributed is not maintained.

B. The following government agencies have implemented the UB92:

• Medicare
• Medicaid

Numerous Blue Cross plans use the UB92. Approximately, 73 other payers have implemented the standard.

C. We are not aware of other countries that implemented the UB92.

D. We constantly receive praise from software vendors, clearinghouses and health care providers regarding the usefulness of the UB92 and ease of implementation.

Level of Specificity:

A. The UB92 is very detailed. Record descriptions exist, as well as unambiguous data element definitions and format descriptions.

B. The UB92 framework is detailed down to the smallest named unit of information.

C. The UB92 does not reference or assume other standards to achieve more specificity.

D thru

H. The UB92 includes a code set for the patient status, accommodation revenue codes, ancillary revenue codes, and condition codes. The UB92 assumes the following code sets:

Relationship with Other Standards:

A. The ANSI X12 837 health care claim is not suitable for use in an application program and must be translated into the UB92 prior to claims processing. The UB92 does not have to be translated and, in turn, reduces administrative costs.

Identifiable Costs:

The UB92 is distributed free of charge. Typically, it takes one year from statement of intent for the UB92 to be in full production. Implementation costs vary depending on how a payer implements the standard. If a complete system rewrite is performed, the cost could be $1,000,000. If the change is at the interface, the cost could be as little as $100,000. These costs include comprehensive systems testing.

American Dental Association (ADA) Accredited Standards Committee MD 156

The American Dental Association (ADA) is sponsor and secretariat of the Accredited Standards Committee (ASC) MD156 for Dental Materials, Instruments and Equipment. In 1992 there was interest in the standardization of clinical information systems. After evaluating current informatics activities, the ADA initiated several projects relating to clinical technology. A task group of the ASC MD156 was created by the Association to initiate the development of technical reports, guidelines, and standards on electronic technologies used in dental practice.

Components of the task group include five working groups for clinical information systems. The working groups were established to promote the concept of a dental computerized clinical work station and allow the integration of different software and hardware components into one system in order to provide for all of a clinician's information needs. Clinical information systems include all areas of computer-based information technologies such as digital radiography, digital intraoral video cameras, digital voice-text-image transfer, periodontal probing devices, CAD/CAMs, etc. By establishing standards for these modules, the need for several stand-alone systems in the dental office will be eliminated.

Each working group encompasses a broad spectrum of projects under a central theme. Within each working group, subcommittees are responsible for the specific projects. Each subcommittee has been researching standards already in existence to determine if they could be applicable to dentistry. Participants are also interfacing with standards groups active in medical informatics.

The ADA also sponsors participation in ANSI activities of the International Organization for Standardization (ISO) Technical Committee 106 on dentistry and acts as secretariat for ANSI for Working Group 2 of ISO/TC 106. Thus, the ADA works both nationally and internationally in the formation of standards for dentistry.

ANSI Accredited:

The American Dental Association has been sponsoring a standards program for dental materials, instruments and equipment since 1928. From 1928 to 1953, all specifications for dental materials, instruments and equipment were developed at the National Bureau of Standards by the federal government in cooperation with the ADA. Between 1953 and 1970, the Dental Materials Group of the International Association for Dental Research (IADR) acted as advisor to the ADA in developing specifications. In 1970, American National Standards Committee MD156 (ANSC MD156) was established by the American National Standards Institute, replacing the Dental Materials Group.

In 1983, the ANSC MD156 became an accredited committee by ANSI making the committee the Accredited Standards Committee MD156 (ASC MD156).

To date, 56 specifications for dental materials, instruments and equipment have been adopted by ANSI as American National Standards. In addition, the ADA acts as proprietary sponsor on a project to handle standards for dental radiographic film. This activity is conducted under the Accredited Canvas Method of ANSI.

ADA Implementation Guide for ASC X12 837

The standards which are being developed for electronic insurance transactions focus on the "envelope" used to transmit data electronically. The ADA has been working with the ASC X12 in order to define the data content placed in that envelope. The ADA has been responsible for the data content as it pertains to dental claims while the National Uniform Claim Committee (NUCC) and the National Uniform Billing Committee (NUBC) focus on the non-institutional and institutional data sets.

The ADA released an Implementation Guide for dental claims submission based upon the ANSI ASC X12 837 transaction set. The Association provided the data content for a dental claim based upon the ADA Dental Claim Format for the Implementation Guide. The Guide will assist practice management vendors, third-party payers and clearinghouses in the execution of the ASC X12 standards. Future versions of the 837 Dental Implementation Guide will be developed by ASC X12. However, the ADA will continue to provide the data content for the development of an Implementation Guide for dental applications.

The ADA developed two versions of the Implementation Guide (Versions 3041 and 3051) which were adopted by the ASC MD156 and recommended for use by practice management vendors for electronic dental claims transactions. Future versions of the Guide will be developed within the ASC X12. However, the ASC MD156 will continue to work with the ASC X12 Insurance Subcommittee.

1) ANSI/ADA 1000 A Standard Clinical Data Architecture for the Structure and Content of a Computer-based Patient Record. Detailed information pertaining to the ANSI 1000 standard is included in Appendix B entitled Activities to Promote Interoperability of Standards - Frameworks, Architectures, and Models.

Description of Standard:

The ADA Dental Implementation Guide is based upon the ASC X12 837 claims submission transaction. It was developed to assist users such as practice management vendors, third-party payers, and clearinghouses, in the execution of the 837 for dental claims transactions.

Readiness of Standard:

The ASC X12 claims submission 837 is being used for submitting some dental claims. However, utilization of the standard is very low at this time. Currently, most dental claims are submitted using proprietary formats. The 837 is the first standard to be developed for claims transactions. Therefore, the Association encourages that electronic dental claims transactions continue to be submitted in the current electronic formats, whether the transactions are proprietary formats or the 837, and a migration should occur to require ASC X12 formats only. The 837 transaction is the only approved ANSI draft standard for trial use. However, the ASC X12 Interactive Claim standard will soon be finalized and when approved it will be the preferred standard to be used for dental claims transactions.

Identifiable Costs:

The ADA's Implementation Guide version 3051 is free of charge from the ADA. Future versions of the Dental Implementation Guide will be available through DISA.

Contact For More Information:

Health Level Seven, Inc. (HL7)

Category/Classification of Standard

• Health Claims Or Equivalent Encounter Information - Health Level Seven provides healthcare organizations such as hospitals and clinics the ability to consolidate patient billing information between computer systems. HL7 also provides the ability to transmit appropriate healthcare claims to the Health Care Financing Administration using their proprietary formats: UB82 for HL7 Versions 1.0 through 2.1 and the UB92 for HL7 Versions 2.2 and 2.3. In particular the UB82 part of the HL7 Standard predates the X12 835 transaction set by five years. If "equivalent encounter information" is to mean the clinical data associated with an encounter, then HL7 is currently uniquely positioned to have an existing standard to send this data. It is reasonable to expect that this type of clinical data would be included in the NCQA and HEDIS reporting requirements.
• Health Claims Attachments - In all versions, HL7 provides data interchange formats for consolidating patient-specific clinical information to support most healthcare claims, including physician's orders, prescriptions, laboratory and clinical tests, diagnostic procedures (excluding imaging) and resulting outcomes. HL7 version 2.2 is the only ANSI approved clinical data interchange standard in these areas. HL7 has also defined segments to transmit data (including clinical data) associated with an injury or accident.
• First Report Of Injury - In collaboration with the Centers for Disease Control (CDC), Health Level Seven is developing an Emergency Room data interchange format to report specific first encounter disease information.
• Referral Certification And Authorization - Health Level Seven has specific segments and trigger events to perform the data interchange necessary for referral and authorization. This request most frequently requires detailed clinical data over several encounters. Health Level Seven is uniquely positioned to meet these requirements.

Health Level Seven became an ANSI accredited SDO, Accredited Organization Method, on June 12, 1994.

Health Level Seven Versions 1.0 through 3.0

1)Health Level Seven Version 1.0 (published in 1987)

2)Health Level Seven Version 2.0 (published in 1989)

3)Health Level Seven Version 2.1 (published in 1990)

4)Health Level Seven Version 2.2 Application Protocol for Electronic Data Exchange in Healthcare (published in 1994, ANSI approved on February 8, 1996)

5)Health Level Seven Version 2.3 Application Protocol for Electronic Data Exchange in Healthcare is currently in the final stages of revision (expected publish date is March, 1997; currently in process for ANSI approval)

6)Health Level Seven Version 3.0 Application Protocol for Electronic Data Exchange in Healthcare is in the development stage (anticipated publish date is December 1998)

Contact For More Information:

Mark McDougall

Executive Director

Health Level Seven

3300 Washtenaw Avenue, Suite 227

Ann Arbor, MI 48104-4250

Phone: (313) 677-7777

Fax: (313) 677-6622

E-mail: hq@hl7.org

Description of Standard:

Objectives

To facilitate the interchange of health informatics and administrative and financial data needed to support clinical practice. By creating messages with sufficient granularity of data to support clinical practices, HL7 also creates support for the interchange of health informatics data needed for research (e.g., clinical trials messages; the use of the results messages to build clinical research databases), public health (e.g., the use of immunization query/reporting to track immunization needs of populations, the use of product experience messages to support drug and equipment adverse effects), and epidemiology (detailed clinical data can be collected on specific diseases).

Functions

HL7 supports the following functions. (Please refer to Attachments 1 and 2 for a complete listing of HL7 event type codes and HL7 order control codes, respectively; to Attachment 3 for a listing of UB2 segments; and to Attachment 4 for product experience segments.) Those specific to Version 2.3 are denoted by an asterisk (*):

• Administrative functions, including messages for:
• administrative support for clinical practice
• ADT (admitting, discharge, and transfer within an institution)
• registration (inpatient, outpatient, group and private practice)
• Financial support for clinical practice including:
• notifying a billing/financial system of work performed
• adding / updating patient accounts
• purging patient accounts
• generating bills and accounts receivable statements (a display query)
• generating and transmitting UB92 data (including charges, payments and adjustments)
• updating account*
• ending account*
• Scheduling*, including resources for:
• inpatient
• outpatient
• clinic
• private practice
• Orders, including but not limited to:
• clinical laboratory
• radiology
• pharmacy (various types and levels including inpatient and outpatient)

· EKG

· EEG

• dietary
• requisitions
• Results, including, but not limited to:
• clinical laboratory
• radiology
• pharmacy
• images (by reference in HL7 Version 2.2, and directly in HL7 Version 2.3)
• discharge summaries
• op-notes
• clinic notes
• pharmacy administrations
• Support for reporting results containing waveform data* (e.g. EEG, ICU 'strip' data, etc.)
• Immunization queries and reporting*, including
• patient identification
• next of kin
• patient visit
• insurance information
• common order
• pharmacy administration
• pharmacy route
• observation/result
• notes (regarding immunization)
• Clinical trials definition and reporting*
• Product experience reporting* (e.g. adverse drug/equipment reporting messages), including
• sender
• observation
• causal relationship
• product summary
• product detail
• facility
• Clinical master files support
• Clinical referrals*
• Problems, goals, and pathways*
• Clinical transcription*
• General query support for all of the above areas in both display and record-oriented formats

User Environment

The user environment for HL7 includes administrative, financial, and clinical information in support of clinical practice, research, adverse product experience, and epidemiology. The specific user 'environments' include any settings where this type of information needs to be transmitted between healthcare applications, such as:

• hospitals
• groups of hospitals (with associated clinics, and associated private or small practice groups)
• clinics
• private practices
• small group practices

Specific applications environments/settings where HL7 is currently being used include: workstation/desktop applications; message routing applications (e.g. 'gateways,' communications components such as the Andover Working Group's "Enterprise Communicator"), clinical data repositories (important components of the 'electronic medical record'), and systems comprised of these three software 'tiers.' Some of these already operate over the Internet.

Systems Environment

HL7 is a specification for healthcare informatics messages to be sent between applications, and thus, has no specific requirements for any of the above (i.e. no specific requirements for operating systems, network, hardware or other requirements). However, the HL7 Versions 2.2 and 2.1 do require an ASCII-based message encoding syntax, which is defined in Chapter 2 of the standard. HL7 Version 2.3 allows non-ASCII encoding schemes as defined in Chapter 2 of the standard, but does not directly support binary data. (Binary data objects may be referenced in HL7 Version 2.2 messages via the use of the 'Reference Pointer' data type.) HL7 Version 2.3 does contain a specific data type (ED, for encapsulated data) which allows for a MIME-encoding of binary data. By using this method, binary data may be transmitted in HL7 Version 2.3 messages.

It is important to note that even within HL7 Versions 2.1-2.3, the messages are defined abstractly, without reference to a specific encoding syntax. This allows implementors to use non-HL7 encoding syntaxes as needed (e.g., there is an HL7 Version 2.2 implementation using ASN.1 BER encoding syntax). This same paradigm will be followed in Version 3.0: the messages will be defined without regard to the encoding syntax used to send them between applications.

Although its messages will be defined abstractly, HL7 Version 3.0 plans to support 4 different 'encoding' layers: character based (an improved version of the current Version 2 encoding syntax), CORBA, OLE, and EDIFACT.

Application Function/Domain Completeness

With HL7 Version 2.3, HL7 has doubled the scope of messages supporting clinical practice, and the administrative and financial data needed to support clinical practice. HL7 believes that the core areas of clinical data are covered at this point. However, there is additional work to be completed. The members of HL7 have created the following special interest groups (SIGs) to define and research additions to the specification. The SIGs will determine if the area of interest can be addressed within one of the current HL7 technical committees, or whether a new technical committee needs to be formed. The list of current HL7 SIGs gives an indication of future areas that HL7 will address:

• Object brokering technologies (OBT) SIG (CORBA, OLE). Their goal is to demonstrate "proof of concept" for new technologies. A second demonstration was held at HIMSS '96. Full HL7 support requires completion of the HL7 object data model. The Andover Working Group is using a version of this approach that supports both CORBA and OLE versions of HL7 Version 2.2 messages.
• Automated Data (enhanced coverage of waveforms, ICU-systems, etc.)
• Home Health
• Image Management (with DICOM and related input)
• Professional Certification
• Security
• Codes and Vocabularies
• Clinical Decision Support (e.g. Arden Syntax)

· SGML

In addition, the Quality Assurance/Data Modeling technical committee, which is doing the bulk of the work on the methodology for HL7 Version 3.0, will split into two separate technical committees, one concerned with the Version 3.0 methodology (including object data modeling), and the other concerned with quality assurance.

HL7 Version 3.0 will be based on an object modeling framework, including the message development framework created by the IEEE Joint Working Group on the Common Data Model, and also using work developed by CEN TC-251, WG-3, Project Team 25, for developing messages from object models. This work has been expanded and adapted to HL7's needs by HL7's Quality Assurance/Data Modeling technical committee. Many of the relevant documents are available on the Duke University Healthcare Informatics Standards Web Site (use http://www.mcis.duke.edu/standards/guide.htm for all standards, and use http://www.mcis.duke.edu/standards/HL7/hl7.htm for just HL7). In addition to the Message Development Framework and detailed instructional materials, HL7 has created a Reference Information Model that will be used to define and harmonize sub-models for each technical committee. Over the next year to 18 months, HL7 will use this work to develop Version 3.0.

The Version 3.0 approach has been demonstrated at two HIMSS's conferences and validated by the work of the Andover Working Group in their Enterprise Communicator specification and implementation. (Supported already by over 100 vendors and institutions.)

Way(S) In Which This Standard Is Superior To Other Standards In This Category/Classification

The HL7 standard is superior in its completeness of coverage of scope of messages supporting clinical practice, and the administrative and financial data needed to support clinical practice. It has gained market acceptance and very widespread use, not only within the U.S., but internationally in such countries as Canada, The Netherlands, Germany, Australia, New Zealand, Finland and Japan. It provides ease of implementation, flexibility, and has gained acceptance by major vendors and academic sites.

Other Relevant Characteristics

HL7 is actively working to harmonize its work with other SDO's and with other relevant areas. For example, HL7 recently formed a codes and vocabularies SIG which will work to standardize the code sets in use for clinical data fields and transactions. HL7 is participating in the IEEE JWG/Common Data Model and convenes meetings jointly with X12N. HL7 has an MOU with NCPDP and is working to harmonize the NCPDP's SCRIPT specification with the HL7 Pharmacy messages.

Readiness of Standard:

Is It A Guideline?

HL7 is not a guideline, but an actual standard for healthcare informatics messages supporting clinical practice, and the administrative and financial data needed to support clinical practice. Insofar as HL7 Version 2 messages are based on 'trigger events,' they address actual processes within the healthcare environment. HL7 Version 3.0 will be based on objects derived from analysis of scenarios and business cases in the healthcare environment: in that sense Version 3.0 will address actual processes of information flows within the healthcare environment. The exchange of such information can be used to support clinical practice, but does not per se, define practice. In the same sense, HL7 messages do not imply the design of applications, but can be used to create or request data which is needed by healthcare clinical applications.

Is It Implementable?

HL7 Versions 2.1 and 2.2 are fully implementable, since they have been balloted standards since 1990 and 1994 respectively. In addition to the standards themselves, HL7 has published Implementation Guides for Version 2.1 and 2.2. HL7 Version 2.3 will be finalized during the first quarter of 1997, at which time it will be fully implementable. As with Versions 2.1 and 2.2, HL7 will publish an Implementation Guides for Version 2.3. There are thousands of installations using HL7 Version 2.1 and 2.2, and many sites using 2.3 draft versions. In addition, an Access database will be available with Version 2.3 to help users create their own interface specifications. This database consists of tables for HL7 components, tables, fields, messages and segments and includes several predefined queries (e.g., alpha sort of tables, numeric sort of tables,

fields and components, etc.).

Version 3.0 is planned for release during the fourth quarter of 1998 and will provide both a standard and an Implementation Guide. In addition, formal conformance profiles will be available for Version 3.0.

How Can The Standard Be Obtained?

Copies of the HL7 standard V2.1, 2.2, and 2.3 are available for $125 each from HL7 Headquarters at:

3300 Washtenaw Avenue, Suite 227

Ann Arbor, MI 48104-4250

Phone: (313) 677-7777

Fax: (313) 677-6622

E-mail: hq@hl7.org

Does This Require A Separate Implementation Guide?

HL7 has published Implementation Guides for Version 2.1 and 2.2. HL7 Version 2.3 will be published during the first quarter of 1997, at which time it will be fully implementable. As with Version 2.1 and 2.2, HL7 will publish an Implementation Guide for Version 2.3.

Is There Only One Implementation Guideline?

For the 2.x versions of HL7 there is a single Implementation Guide. Version 3.0 will provide four Implementation Guide sections, one for each of the four implementable message specifications: character-based; OLE, CORBA, and OLE.

Is A Conformance Standard Specified?

The Conformance SIG is working on this part of the standard. A conformance standard will definitely be provided for Version 3.0, and the Conformance SIG may also develop conformance standards for HL7 Versions 2.x.

Are Conformance Test Tools Available?

Conformance test tools will be part of Version 3.0, and the Conformance SIG may also develop them for Version 2.3.

Source Of Test Tools?

The source of HL7 V3.0 test tools has not yet been selected. Additionally, the Conformance SIG may develop or contract them for Version 2.3.

If The Standard Is Under Development, What Parts Of It Are Ready Now?

Version 2.1 and 2.2 are available now; Version 2.3 is currently available in draft form and will be available in its final, published form during the first quarter of 1997.

What Extensions Are Now Under Development?

As indicated earlier, these include:

• Object brokering technologies
• Automated Data (enhanced coverage of waveforms, ICU-systems, etc.)
• Home Health
• Image Management (with DICOM and related input)
• Professional Certification
• Security
• Codes and Vocabularies
• Clinical Decision Support (e.g. Arden Syntax)

· SGML

· Andover Working Group's "Enterprise Communicator"

Major Milestones Toward Standards Completion?

Version 2.3:

· Final balloting

Version 3.0

• Completion of the "Strawman" Reference Information Model
• Completion of the Hierarchical Message Descriptions
• Completion of Implementable Message Specifications for OLE/CORBA and printable character streams

Projected Dates For Final Balloting And/Or Implementation.

• V2.3 - Final balloting will be completed by mid January, 1997. Anticipated publish date is March, 1997.
• V3.0 - Work will begin in January, 1997 with the objective of having the first ballots completed by the end of 1998.

Other Indicators Of Readiness That May Be Appropriate.

One company has been using the proposed Referral chapter specification (new with Version 2.3) in two state-wide and three regional healthcare information networks for the past two years. Much of the information in this chapter was derived from prototyping the work being accomplished in these information networks. They have utilized inter-enterprise transactions for 80% of the events in the Referral chapter. In addition, one hospital vendor has implemented the Scheduling transactions (also new with Version 2.3) and has been using them successfully since January, 1996.

Indicators of Market Acceptance:

Based on our membership records of over 1,600 total members in HL7, approximately 739 vendors, 652 healthcare providers, 104 consultants, and 111 general interest/payor agencies are utilizing the HL7 standard. HL7 standards have been installed thousands of times. For example, one vendor alone has installed 856 interfaces per HL7 standards as of mid 1996. In addition the HL7 standard is being used and implemented in Canada, Australia, Finland, Germany, The Netherlands, New Zealand, and Japan.

Another relevant indicator of market acceptance in the public sector is the Andover Working Group's implementation of the Enterprise Communicator (and the accompanying tightly coupled, zero optionality conformance specification for sections of HL7 Version 2.2): the Andover Working Group is a 'test implementation' of the Version 3.0 functionality (it has CORBA, OLE, and character-based encoding structures, and is scheduled for production during the fourth quarter of 1996 or the first quarter of 1997.

Level of Specificity:

Description Of Framework Detail And Level Of Granularity.

The granularity of the HL7 standard is sufficient to support clinical practice (i.e., it is much more granular that the reimbursement standards). It's framework, in terms of scope, is also sufficient to support clinical practices.

Does The Standard Reference Or Assume Other Standards To Achieve More Specificity?

The HL7 standard does not reference or assume other standards to achieve more specificity. HL7 is, in general, more granular than other standards. It allows the use of standard code sets as needed by implementors via the HL7 CE data type.

Assumed Code Sets.

Current HL7 assumes code sets for a small number of single 'data elements.' These are termed 'HL7 tables,' and are so marked and so defined within the current specification.

For other data elements, HL7 allows the use of either 'site-defined' (e.g., HL7 IS data type) or 'standard (external) code sets' (e.g., using the CE coded element data type).

HL7 has hundreds of users who are using the HL7 tables.

Sources Of Code Sets.

HL7 tables are defined within the HL7 standard. User defined tables are defined at implementation time. Standard (external) tables (e.g. SNOMED, ICD9, CPT) are defined externally by their source-creating institutions, and may be obtained from their usual suppliers.

Available Assistance On The Use Of Code Sets.

It is expected that the new HL7 Codes and Vocabularies SIG will make recommendations for code sets, including means for obtaining the various standard external code sets. It is also expected that Version 3.0 will specify more completely all three types of code sets (HL7, user-defined, and external standards). Chapter 7 contains an extensive list of external standard code sets (including where to obtain them).

Projected Dates Of Completion And Implementation For Code Sets Currently Under Development.

The vocabulary SIG is expected to publish these dates sometime after the January 1997 HL7 meeting.

Relationships With Other Standards:

Other Standards

• HL7 and X12N. No overlap.
• HL7 and NCPDP Script. Conceptual overlap in the area of prescription messages (including authorization and refills).
• HL7 and ASTM Lab information and Waveform messages. Conceptual overlap.

Standards Reconciliation Or Coordination Activities

• HL7 and X12N are convening simultaneously so that members may attend and learn what each group is doing. Harmonization at the object model level is being addressed in that both groups are members of the IEEE-JWG/Common Data Model. Both groups have agreed not to create overlapping, redundant messages. HL7 and NCPDP have created an MOU and are working to harmonize the NCPDP script messages and the HL7 Pharmacy messages in terms of content and vocabulary so that a one-pass, unambiguous, translator can translate from one form to another. (The market dictates this approach.)
• HL7 and ASTM lab messages have been harmonized by having members of both groups work on both standards, thus guaranteeing interoperability.
• HL7 and ASTM waveform messages have been harmonized by having members of both groups work on both standards, thus guaranteeing interoperability.
• HL7 and IEEE Medix have been co-meeting and working with the IEEE JWG/CDM to harmonize their data models.
• HL7 has been harmonizing with DICOM via the HL7 IMSIG (Image Management SIG).
• HL7 is working with various groups to harmonize code sets/vocabularies for clinical data.
• HL7 has also been engaged in unofficial coordination with CEN TC 251 WG3 by sharing members working on various projects (including US 'experts' attending WG3 meetings). HL7 would also like to do some formal reconciliation of the object data models used by WG3.

What Portion Of The Specification And Functionality Is Affected By This Coordination?

(See above).

What Conditions Are Assumed In Order For This Coordination To Be Effective?

Cooperation and openness from the other SDO's.

Is This Standard Consistent With International Standards? If So, Which Standards?

In terms of the scope of HL7, to our knowledge there are no ISO standards that cover the HL7 scope (see definition above). Version 3.0 will be compatible with EDIFACT, CORBA and OLE as encoding syntaxes. Additionally, the Andover Working Group has demonstrated a means to use CORBA or OLE with Version 2.3 messages.

What Gaps Remain Among Related Standards That Should Be Addressed?

Agreement on standard code sets/terminologies for various clinical items need to be addressed. In addition, the listing of HL7 SIGs above identifies gaps in the clinical support coverage.

Describe What Is Being Done To Address These Gaps.

See above.

Attachment 1

HL7 Event Type Codes

Attachment 2

HL7 Order Control Codes and Their Meaning