Inventory of Health Care Information Standards

Publication Date

Dec 31, 1996

Pertaining to

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (P.L. 104-191)

Executive Summary

Introduction

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was signed into law on August 21, 1996. The administrative simplification portion of HIPAA requires the Secretary of Health and Human Services (HHS) to adopt standards for the electronic transmission of specific administrative health transactions. These standards will apply to health plans, health care clearinghouses, and health care providers who transmit any health information in electronic form in connection with the following transaction:

Health Claims or equivalent encounter information
Health Claims Attachments
Enrollment and Disenrollment in a Health Plan
Eligibility For a Health Plan
Health Care Payment and Remittance Advice
Health Plan Premium Payments
First Report of Injury
Health Claim Status
Referral Certification and Authorization
Coordination of Benefits

Unless there is no existing standard, or a different standard will substantially reduce administrative costs to health care providers and health plans, the Secretary must adopt "a standard that has been developed, adopted, or modified by a standard setting organization."

The American National Standards Institute's Healthcare Informatics Standards Board (ANSI HISB) provides an open, public forum for the voluntary coordination of healthcare informatics standards among all United States' standard developing organizations. Every major developer of healthcare informatics standards in the United States participates in ANSI HISB. The ANSI HISB has 34 voting members and more than 100 participants, including ANSI-accredited and other standards developing organizations, professional societies, trade associations, private companies, federal agencies, and others.

In response to the passage of HIPAA, ANSI HISB offered its services to the Secretary of HHS to prepare an inventory of existing healthcare information standards that pertained to the transactions specified by P.L. 104-191. It also offered to assign them into appropriate HIPAA transaction categories and supporting standards sections. The Secretary accepted the offer and this report is the result.

The purpose of this report is to supply the Secretary of HHS with an inventory of existing healthcare informatics standards appropriate for the administrative simplification requirements of HIPAA and to map them into the relevant categories. To obtain the information for this report, HISB developed a set of templates (Appendix A) asking for the following characteristics for each standard or set of standards:

Category/classification of standard
Standards Development Organization
ANSI accreditation status
Name of standard
Contact for more information
Description of standard
Readiness of standard
Indicators of market acceptance
Level of specificity
Relationships with other standards
Identifiable costs

These templates were distributed to HISB participants with a request for a quick turnaround. Responses were received from ANSI-accredited standards developers, other organizations, and government agencies. The responses were coordinated into the administrative simplification standards categories, reviewed by HISB for appropriate classification and accuracy, and returned to the submitting standards organizations following the review for revision and resubmission. The final judgment for the placement of the existing standards in these categories and the accuracy of the information rests with the standard developing organization submitting the information, such as level of specificity and market acceptance. This report does not recommend specific standards but provides relevant comparative information to support the Secretary's analyses and decisions.

The vision for improved efficiency and effectiveness of the U.S. health care system through applications of information technology to health care is shared by Congress, the Secretary of HHS, and ANSI HISB. Administrative and clinical data standards are nationally important to improve the uniformity, accuracy, and automation of patient care data. Such data will support the development and dissemination of timely information needed to make good health care and payment decisions. By providing this report on existing administrative data standards and making it widely available, ANSI HISB hopes to contribute to a foundation that will improve the cost and medical effectiveness of health care in the public and private sectors, nationally and internationally.

Acknowledgments

ANSI HISB acknowledges the contributions provided by the following individuals:

Jeff Blair - Overall coordination and template design

Jean Narcisi - Response coordination and creation of the report

Alison Turner - Secretarial Coordination within ANSI

The following individuals provided input into the report:

Solomon Appavu

Christopher G. Chute, MD

J. Michael Fitzmaurice, PhD

Debbie Jenkins

Robert Owens

Rick Peters, MD

Daniel Staniec

C. Peter Waegemann

Transaction Standards

Health Claims or Equivalent Encounter Information

Accredited Standards Committee (ASC) X12, Health Care Task Group

The main objective of ASC X12 is to develop standards to facilitate electronic interchange relating to such business transactions as order placement and processing, shipping and receiving, invoicing, payment, cash application data, insurance transactions, and other data associated with the provision of products and services. The aim of ASC X12 is to structure standards so that computer programs can translate data to and from internal formats without extensive reprogramming. In this way, by using internally developed or commercially available software and private or public-access communication networks, ASC X12 believes that all sizes of firms and institutions using intelligent computational devices can benefit from the use of the standard. The efficiencies of standard interchange format can minimize the difficulties and expenses that could be incurred if each institution were to impose its own formats on every institution with which it does business. In ASC X12, the various subcommittees develop new standards that become recommendations for the full ASC X12 membership. The full ASC X12 membership must go through a consensus process before a proposed standard (or any change to a standard) is published as a Draft Standard for Trial Use. After a reasonable trial period, these standards are submitted to ANSI to start the process of consensus approval and registration.

ASC X12 has eleven Subcommittees including ASC X12N - Insurance. The ASC X12 subcommittees have maintained liaison with and obtained membership from a broad spectrum of businesses, government agencies, and institutions throughout the world. Communication is maintained with many organizations having experience in similar activities. A list of those participating in the development of the standards may be secured by contacting the Data Interchange Standards Association (DISA), Secretariat to ASC X12.

ANSI Accreditation: X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

The main objective of ASC X12 is to develop Electronic Data Interchange (EDI) standards to facilitate electronic business transactions (i.e. order placement and processing, shipping and receiving, invoicing, payment, cash application data, insurance transactions). ASC X12 endeavors to structure standards in a manner that computer programs can translate data to and from internal formats without extensive reprogramming.

This strategy allows companies to maximize their resources required for internally developed or commercial software (recommended) and private or public-access communication networks. ASC X12 believes that all sizes of companies using intelligent computational devices can benefit from the use of the standard. The efficiencies of standard interchange format can minimize the difficulties incurred from each organization using its own formats to transact business. Within ASC X12, the various subcommittees are responsible for developing standards in their area of expertise. Once a subcommittee has developed a draft standard the full ASC X12 membership reviews and approves it according to the operating policies and procedures. All standards (new or changed) require the consensus approval of the full ASC X12 membership. The approved standard becomes a draft standard for trial use for a reasonable trial period. After the trial period the draft standards are submitted to ANSI to become an American National Standard (ANS).

ASC X12N Health Care Claim (837)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Health Care Claim (837) is to support the administrative reimbursement processing as it relates to the submission of health care claims for both health care products and services.

B) This transaction set can be used to submit health care claim billing information, encounter information, or both, from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit health care claims and billing payment information between payers with different payment responsibilities where coordination of benefits is required or between payers and regulatory agencies to monitor the rendering, billing, and/or payment of health care services within a specific health care/insurance industry segment.

C)This transaction is used for administrative reimbursement for health care products and services for medical, hospital, dental, pharmaceutical, durable medical equipment claims as well as for workers compensation jurisdictional reporting.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has been developed with widespread input from the health care industry incorporating all business needs into its functionality.

F)The ANSI ASC X12 is the only nationally recognized EDI standards development organization in the United States for all types of electronic commerce. ASC X12 is the organization assigned by ANSI to represent the United States in the development of International EDI standards.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Health Care Claim (837) is not a guideline.

B)The Health Care Claim (837) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in October of 1992 as Version 003030.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

D)This standard does not require an implementation guide. ASC X12 has published four Type II Tutorial reports or tutorials for version 003041 in October of 1994, version 003050 in October 1995, version 003051 in February 1996, and version 003060 in April of 1996. To facilitate consistent implementation across the health care industry, the X12 Insurance Subcommittee is currently in the process of completing five implementation guides for version 003070 encompassing medical, hospital, dental, pharmaceutical claims, and workers compensation jurisdictional reporting with an anticipated publication date of June 1997.

E)There will be only one implementation guide per claim type for each version of the standards the X12 Health Care Task Group selects in accordance with the industry.

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

I)The standard is complete. The current version of the standard is 003070. As business needs dictate, enhancements may be made to the standard three times per year, one major release along with two subsequent sub-releases. The X12 Health Care Task Group has developed procedures to determine when to move to the next version of the standard as well as when to retire past versions. The Health Care Task Group will also determine the need for new versions of the implementation guides (not more frequently than once per year).

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

A) The X12 standards are made available via many sources including from the Data Interchange Standards Association, Washington Publishing (ASC X12 Insurance Subcommittee's publisher), industry user groups and associations, and the Internet. Due to the multiplicity and diversity of these distribution methods, it is not possible to determine how many copies have been distributed and to whom.

B)All Medicare carriers and intermediaries have implemented ASC X12 standards for claims. Many other payers have followed HCFA's lead and implemented the standard as well.

C)Yes. ASC X12 represents international standards development. North American and other countries have implemented ASC X12 standards for purchasing and financial transactions. It would be to their benefit to further leverage their investment in EDI translation software, hardware and communication infrastructure to utilize the health care transactions.

Over 300 payer, provider, vendor, and plan sponsor organizations currently participate in the development of the ASC X12 standards and implementation guides to meet the business needs of the entire health care industry. These organizations have experienced the benefits of mature standards because costs associated with developing and maintaining proprietary formats far exceed the investment necessary to implement a single set of health care EDI transactions.

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

C)ASC X12 standards incorporate the business requirements for exchanging information contained within other standards. The ASC X12 standards provides a vehicle for communicating other standards within the standards.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

B)Internal code sets are included within the ASC X12 standards publications and implementation guides. When external code sets are referenced within these documents, the source where the code sets can be obtained is listed.

C)When possible, the implementation guides will either include the external code sets or provide further information on how to obtain the external code sets. Internal code sets are included within the implementation guides.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

E)ASC X12 internal code sets follow the same processes defined for the development and maintenance of the EDI transactions. External code lists are maintained by the external code source's internal development procedures.

Relationships With Other Standards:

A) ASC X12 strives to coordinate and incorporate the needs of the other standards development organizations such as Health Level 7 (HL7), National Council for Prescription Drug Programs (NCPDP), and the American Society for Testing and Materials into the ASC X12 standards.

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

G)Given the scope and responsibility for the development and maintenance of the EDI standards for the United States and the international community with respect to United States international standards, ASC X12 is only privy to the business needs which are brought forward and coordinated with other health care organizations. At this time, we are unaware of any gaps in the current standards for insurance.

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

A) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

B)The cost/timeframe for education and training will depend upon the individuals and skill levels of the individuals within an organization. Some organizations have completed education and training within one week while others have taken longer.

C)The cost/timeframe for implementation depends upon the internal systems capabilities, systems development philosophy, hardware platform selected, EDI translator software, communication methodology and individual resources within an organization. Costs can range anywhere from free for a personal computer solution to well over $150,000 for midsize and mainframe systems. Some organizations have implemented the standards within a matter of days while other have taken months to achieve the same end result.

D)The current use of proprietary formats such as the National Standard Format (NSF) and the costs of maintaining these formats far outweigh the costs associated with implementing a single set of the health care industry standards from ASC X12.

ASC X12N Interactive Healthcare Claim/Encounter (IHCLME)

Contact For More Information: Data Interchange Standards Association (DISA)

703-548-7005.

Description of Standard:

A) The objective of the Interactive Healthcare Claim/Encounter (IHCLME) is to support the administrative reimbursement processing as it relates to the submission of health care claims for both health care products and services in an interactive environment.

B) This message can be used to submit health care claim billing information, encounter information, or both, from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses interactively with the possibility for automatic adjudication and an immediate response.

C)This message can be used for the administrative reimbursement of health care products and services for medical, hospital, dental, pharmaceutical and durable medical equipment claims.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has been developed with widespread input from the health care industry incorporating all business needs into its functionality.

F)The ANSI ASC X12 is the only nationally recognized EDI standards development organization in the United States for all type of electronic commerce. ASC X12 is the organization assigned by ANSI to represent the United States in the development of International EDI standards.

G)This standard is developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Interactive Healthcare Claim/Encounter (IHCLME) is not a guideline.

B)The message is expected to be approved as a Draft Standard for Trial Use (DSTU) in October 1997.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005 once approved.

E)There will be only one implementation guide for the Interactive Healthcare Claim/Encounter (IHCLME).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

I)The standard has been defined and currently is undergoing review by the members of the X12 Health Care Task Group. As business needs dictate, enhancements may be made to the standard three times per year, one major release along with two subsequent subreleases. The X12 Health Care Task Group has developed procedures to determine when to move to the next version of the standard, as well as, when to retire past versions. The Health Care Task Group will also determine the need for new versions of the implementation guides (not more frequently than once per year).

J)Currently no enhancements are under development.

AA) This standard must be balloted by ANSI X12 followed by a ballot within UN/EDIFACT.

BB) This message is expected to be approved as a Draft Standards for Trail Use (DSTU) in October 1997.

Indicator of Market Acceptance:

B)Every government contractor has been funded by the Health Care Financing Administration (HCFA) to implement the ASC X12 standards. Many other payers have followed HCFA's lead and implemented the standards as well.

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

· Current Procedural Terminology (CPT) Codes from American Medical

Association

Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

A) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

ASC X12 Interactive Healthcare Claims Encounter (IHCLME) is used to transmit claims/encounters interactively, coordinating with the possibility for automatic adjudication and an immediate response. Identifying data requirements, determining business scenarios, grouping data needs into segments and defining the structure of the messages. Claims being considered for interactive transactions include pharmacy, institutional, professional and dental. One message will cover all four claim types. The response message covers the claim status and adjudication information. These will be EDIFACT messages utilizing ASC X12 data dictionaries. This message is currently under development.

National Council for Prescription Drug Programs (NCPDP)

The scope of the standards that NCPDP develops are those for information processing for the pharmacy services sector of the health care industry.

ANSI Accredited:

NCPDP was accredited by ANSI on August 6, 1996. The type of accreditation was the Accredited Organization Method.

NCPDP Standard Claims Billing Version 2.0

This batch format is compatible to and consistent with the standard Universal Claim Form to

enable logical progression from a manual paper claims submission system to an automated

billing process. The Standard Claims Billing format utilizes both data elements and program

logic that include the following items or understandings:

Use of industry accepted data elements (National Drug Code Number (NDC), National Association of Boards of Pharmacy Number (NABP) Processor number, etc.).
Contingency allowance for future enhancements.
Compatibility of the format to most existing processing systems.

NCPDP Telecommunications Standard Format Version 3.2

NCPDP recommends the use of a standardized format for electronic communication of claims between pharmacy providers, insurance carriers, third-party administrators, and other responsible parties. This standard addresses the data format and content, the transmission protocol, and other appropriate telecommunication requirements and was developed to accommodate the eligibility verification process at the point-of-sale and to provide a consistent format for electronic claims processing. The standard supports the submission and adjudication of third party prescription drug claims in an on-line, real-time environment.

NCPDP Version 3 Release 2 was a standard created by the NCPDP Telecommunication Work Group (Work Group One). The objective of the standard is to provide a standard format for on-line real time adjudication for pharmacy claims. Functions include billing of pharmaceutical products including compound medications; billing of professional drug utilization review situations. Users of the standard include administrative/reimbursement and clinical environment. Pharmacies submit claims for drugs and professional services and when applicable receive clinical DUR information derived from payer/prescription benefit manager databases. The standard is used in all operating system environments and claims are submitted and then adjudicated directly from pharmacy to payer and via network. The standard satisfies the needs of public and private prescription benefit plans for well over 100,000,000 health plan members. In addition, this standard facilitates a specific type of business communication between a large number of diverse parties within the third party environment. To do this successfully, it must accomplish the following tasks:

Support the needs of as wide a base of potential users as possible.
Maximize use of existing relevant standards wherever possible (e.g. Version 1.0 of this standard).
Be flexible enough to change as needs and technology change.
Be unambiguous.
Be easy to implement by payers and pharmacy management software developers.

User Environment:

A given organization might serve multiple roles (for example, Administrator and Processor). Certain roles might be split between multiple organizations, the administrator and processor could be different.

This standard addresses the submission of a claim and/or professional service by a dispenser to an administrator/processor, and identifies the response of the administrator/processor to the dispenser. For the purpose of this document, the term "processor" will be used to identify the identity actually performing the authorization/adjudication function.

Types of Messages:

This standard addresses two types of communication between the dispenser (sender) and the processor (receiver). These communication types are claim submission/response and claim reversal/response. These are described in detail below:

Claim Submission/Response:

This transaction is used by the dispenser to request the administrator verify the eligibility of a specific claimant according to the appropriate plan parameters. The message sent by the dispenser contains four types of data:

1) Control Data: This identifies the message type, destination, etc.

2) Dispenser Data: This identifies the provider of the service.

3) Claimant Data: This identifies the person for whom the service is being provided.

4) Prescription Data: This describes the specific service being provided by the Dispenser.

Each claim submission message contains control, dispenser, and claimant data, and up to four occurrences of prescription data. A special case message is where there are zero occurrences of the prescription data. This identifies a request to only verify the eligibility of the claimant.

Depending upon the particular claim submission message, the processor can provide one of the following general types of responses:

Eligibility verification only- This occurs when the processor is verifying the eligibility of the claimant. The claim must be submitted for processing at another time.
Claim capture only- This occurs when the processor acknowledges receipt of the claim, but is not making any judgment regarding eligibility of the claimant.
Claim capture, eligibility verification, and adjudication- This occurs when the processor captures and processes the claim, and returns to the originator the dollar amounts allowed under the terms of the plan.

Claim Reversal/Response:

This transaction is used by the dispenser to request the administrator to reverse a previously submitted claim. The results of a successfully submitted reversal are as if the claim was not submitted in the first place. The message sent by the dispenser contains four types of data:

1) Control Data: This identifies the message type, destination, etc.

2) Dispenser Data: This identifies the provider of the service.

3) Prescription Data: This describes the specific service being provided by the Dispenser.

Each claim reversal message contains control, dispenser, and one occurance of prescription data.

The claim reversal response tells the dispenser if the administrator was able to reverse the claim or not.

Business Flow:

The prescription information is transmitted electronically either through a value-added network switch or directly to a payer or pharmacy benefit management company, where the various transaction functions described above are completed. A paid or rejected response is sent back either through a value-added network switch or directly to the pharmacy in a matter of seconds. This is completed in an on-line real-time environment.

Application Function/Domain Completeness:

Version 3.2 was completed in February 1992 and ongoing maintenance continues. A Drug Utilization Review (DUR) component and a Professional Pharmacy Services (PPS) component have been added to enhance the standard to fit the business needs of the pharmacy community. Drug Utilization Review provides information to the pharmacist regarding potential drug interactions of the prescription drug being billed with the claimant's drug history. In addition, a compound standard has also been developed.

TABLE OF NCPDP TELECOMMUNICATION

STANDARD VERSION/RELEASE

Standard Version/ Release	Standard Approved by NCPDP	Dictionary Complete	Implementation Guide Complete	Widely Used & Implemented	Highlights
3.2	Feb. 1992	Yes	Yes	Yes	1 billion transactions in 1996
3.3	Feb. 1996	March 1997	No	Somewhat	Compound Drugs
3.4	June 1996	March 1997	No	Somewhat	Prior Authorization
3.5	Oct. 1996	March 1997	No	No	New Data Elements
4.0	Feb. 1997	March 1997	No	No	New/Revised Data Elements

This standard has no competing standard to date. The membership of NCPDP has established this widely accepted and implemented standard for on-line real-time prescription claims processing. Implementing this standard required the coordinated efforts and timely response of software developers, payers/claims processors, managed care organizations, pharmacy providers, and numerous other organizations. This standard is being used to process over 1 billion prescription drug claims per year.

Readiness of Standard:

A)NCPDP Version 3.2 is not a guideline, but a completed standard. This standard was submitted recently to ANSI to become an American National Standard.

B)This standard has been implemented by the vast majority of the pharmacy benefits industry since 1992. It was developed to be a natural progression from the previously implemented version.

C)The standard can be obtained by contacting NCPDP's office at (602) 957-9105.

D)NCPDP Version 3.2 has a separate implementation guide. Work is under way for 3.3 and 3.4 implementation guides.

E)There is only one implementation guide. There are no major options that impact compatibility.

F)Yes, a conformance standard is specified (certification procedures). It is important to note that trading partners accomplish this, not NCPDP

G)Yes, conformance test tools are available.

H)The test tools are developed by trading partners based on business agreements.

I)The standard is complete and undergoes periodic enhancements.

J)A compound drug enhancement was recently completed, as well as different data elements for new versions and releases.

AA) A data element request form (DERF) process (data maintenance) has been developed at NCPDP to enable the standard to be modified by the NCPDP membership to fit the business needs of the industry.

BB) This standard is modified periodically upon review of DERFs.

Indicator of Market Acceptance:

A) The standard is virtually used by every pharmacy processor, PBM (Pharmacy Benefit Management Company) submitting on-line real-time pharmacy claims. Every Pharmacy Practice Management Software Vendor in the United States supports the standard. Over 1,000,000,000 claims from 100,000,000 health plan members were submitted in 1996 using the standard. The standard will be used in South Africa in early 1997. In addition, 43 State Medicaid Agencies utilize our standard for their business needs.

B)The language will be English only.

Level of Specificity:

A) Version 3.2 allows for both fixed length transactions or variable length transactions. Implementation of variable length transactions gives the sender and receiver the option of compressing or eliminating optional data elements to reduce message length where these data elements are not required by the processor. As of Version 3.3, fixed length transactions are no longer supported.

B)There is no implementation guideline for the Compound standard for V3.2. There is one for Compounds (V3.3) and Prior Authorization (V3.4).

A) Data sets referenced include :

FDA's National Drug Code (NDC)
NABP #s - National Association for Boards of Pharmacy Number, an universal identifier for pharmacies in the United States
DAW codes - Dispense as written codes

A) The code sets are updated as new data elements are approved by the membership.

A) The data dictionary can be acquired by contacting NCPDP's office at 602-957-9105.

A) There is an instruction sheet.

A) It is used by virtually all users of the standard. (in the hundreds).

I) It is not under development.

Relationships With Other Standards:

A) PPS and DUR are used as part of the NCPDP standard.

A) The X12 835 is used to report on the remittances for claims submitted.

A) Not applicable.

A) No, this standard is not consistent with international standards.

A) There are no gaps.

A) Not applicable.

Identifiable Costs:

The costs for licenser, cost of acquisition, cost time frames for education, training, and implementation are contingent upon the usage and trading partner agreements.

Contact For More Information:

NCPDP, Inc. 4201 North 24th Street, Suite 365, Phoenix, AZ 850160-6268,

Phone (602) 957-9105,

Lee Ann C. Stember - President,

Daniel J. Staniec, R.Ph., MBA Executive Vice President of External Affairs

Health Care Financing Administration (HCFA)

ANSI Accredited:

Not ANSI accredited. Have not applied for accreditation.

HCFA National Standard Format (NSF), Version 002.00

Contact for More Information:

Joy Glass - Email Jglass@hcfa.gov, 410-786-6125, FAX 410-786-4047

Description of Standard:

The NSF consists of fixed-length (320 bytes) records. Each record has a unique identifier and logically related data elements.

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

B) Function - The NSF is used to electronically submit health care claims and encounter information from providers of health care services to payers. It is also used to exchange health are claims and payment information between payers with different payment responsibility.

C) User Environment - NSF users consist of a variety of health care providers, such as, professional, dental, chiropractic, Indian health service providers, and suppliers of medical equipment and supplies. A variety of payers also use the format to exchange claim and payment information.

D) Systems Environment - The NSF is a file format and is platform/operating system independent.

E) Application Function/Domain Completeness - All codes used in the NSF are complete.

A) The NSF 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. In FY96, 668,650,936 Medicare claims were submitted electronically. Ninety eight (98) percent of those claims were in the NSF. The NSF does not have to be translated prior to application processing. The use of compression techniques eliminates at least 50% overhead when transmitting the NSF. With compression, the NSF is more economical than an ANSI X12 837 to transport.

Readiness of Standard:

A)The NSF is a guideline for building electronic claims. The NSF supports policy requirements for users. The NSF defines processes using validation statements. The NSF provides a structured design for building claims.

B) The NSF was fully implemented for Medicare in 1991 and continues to be supported. The NSF has been implemented by about 200 other payers.

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

D) The NSF 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 NSF 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) HCFA's Office of Analysis and Systems has developed a software conformance/enforcement tool for the NSF.

H) Other Indicators of Readiness: The NSF has been available since 1991.

Indicator Of Market Acceptance:

1)Medicare implemented the standard in 1991. Copies of the NSF are requested almost daily. The NSF is available on a bulletin board. Diskettes were previously distributed. Since the NSF is free of charge, the number of copies distributed is not maintained.

2)The following government agencies have implemented the NSF:

a) Medicare

b)Medicaid

c)Indian Health Services

d)Champus

e)Numerous Blue Shield plans and some 200 organizations use the NSF.

1) We are not aware of other countries that implemented the NSF.

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

Level of Specificity:

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

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

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

D thru H) The NSF includes a code set for the place of service, podiatry codes, and type of service. The NSF assumes the following codes sets:

CODE SET	AVAILABLE FORM
Health Care Procedure Codes (HCPCS)	HCFA
Provide Specialty Codes	HCFA
ICD-9 CM Procedure Codes	National Center For Health Statistics
CPT Codes
Physicians Current Procedure Terminology Manual
National Drug Code
Blue Book, Price Alert, National	Drug Data File
Claim Adjustment Reason Code	BCBS Association
Health Care Professional Shortage Area	HCFA
National Association of Insurance Committee Code	NAIC Code List Manual
Medicare Inpatient/Outpatient Message	HCFA
Investigational Device Exemption Number	FDA

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 NSF prior to claims processing. The NSF does not have to be translated and, in turn, reduces administrative costs.

Identifiable Costs:

The NSF is distributed free of charge. The NSF can be implemented within 3 to 6 months of receipt of the standard specifications. Implementation costs vary depending on how a payer implements the standard. Health care provider costs are minimal. The average cost for software is less than $200, and sometimes as little as $25.00. Implementation costs can range from $100,00 to $500,000. If a complete system rewrite is performed, the cost could be $500,000. If the change is at the interface, the cost could be less than $100,000. These costs include comprehensive systems testing.

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:

CODE SETS	AVAILABLE FROM
Health Care Procedure Codes (HCPCS)	HCFA
ICD-9 CM Procedure Codes	National Center for Health Statistics
CPT Codes
Physicians Current Procedure Terminology Manual
Claim Adjustment Reason Code	BCBS Association
Medicare Inpatient/Outpatient Message	HCFA
Investigation Device Exemption Number	FDA
Revenue, Value and Occurrence Codes	National Uniform Billing Committee

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:

	Ms. Sharon Stanford
	Asst. Director, Guidelines and Standards Development
	American Dental Association
	211 East Chicago Avenue
	Chicago, Illinois 60611
	Phone: (312) 440-2509
	Fax: (312) 440-7494
	email: stanfors@ada.org

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.

HL7 Event Type Codes

Value	Description
A01	ADT/ACK - Admit / visit notification
A02	ADT/ACK - Transfer a patient
A03	ADT/ACK - Discharge/end visit
A04	ADT/ACK - Register a patient
A05	ADT/ACK - Pre-admit a patient
A06	ADT/ACK - Change an outpatient to an inpatient
A07	ADT/ACK - Change an inpatient to an outpatient
A08	ADT/ACK - Update patient information
A09	ADT/ACK - Patient departing - tracking
A10	ADT/ACK - Patient arriving - tracking
A11	ADT/ACK - Cancel admit/visit notification
A12	ADT/ACK - Cancel transfer
A13	ADT/ACK - Cancel discharge/end visit
A14	ADT/ACK - Pending admit
A15	ADT/ACK - Pending transfer
A16	ADT/ACK - Pending discharge
A17	ADT/ACK - Swap patients
A18	ADT/ACK - Merge patient information
A19	QRY/ACK - Patient query
A20	ADT/ACK - Bed status update
A21	ADT/ACK - Patient goes on a "leave of absence"
A22	ADT/ACK - Patient returns from a "leave of absence"
A23	ADT/ACK - Delete a patient record
A24	ADT/ACK - Link patient information
A25	ADT/ACK - Cancel pending discharge
A26	ADT/ACK - Cancel pending transfer
A27	ADT/ACK - Cancel pending admit
A28	ADT/ACK - Add person information
A29	ADT/ACK - Delete person information
A30	ADT/ACK - Merge person information
A31	ADT/ACK - Update person information
A32	ADT/ACK - Cancel patient arriving - tracking
A33	ADT/ACK - Cancel patient departing - tracking
A34	ADT/ACK - Merge patient information - patient ID only
A35	ADT/ACK - Merge patient information - account number only
A36	ADT/ACK - Merge patient information - patient ID and account number
A37	ADT/ACK - Unlink patient information
A38	ADT/ACK - Cancel pre-admit
A39	ADT/ACK - Merge person - external ID
A40	ADT/ACK - Merge patient - internal ID
A41	ADT/ACK - Merge account - patient account number
A42	ADT/ACK - Merge visit - visit number
A43	ADT/ACK - Move patient information - internal ID
A44	ADT/ACK - Move account information - patient account number
A45	ADT/ACK - Move visit information - visit number
A46	ADT/ACK - Change external ID
A47	ADT/ACK - Change internal ID
A48	ADT/ACK - Change alternate patient ID
A49	ADT/ACK - Change patient account number
A50	ADT/ACK - Change visit number
A51	ADT/ACK - Change alternate visit ID
B01	PPR/ACK - Patient problem
C01	CRM - Register a patient on a clinical trial
C02	CRM - Cancel a patient registration on clinical trial (for clerical mistakes only)
C03	CRM - Correct/update registration information
C04	CRM - Patient has gone off a clinical trial
C05	CRM - Patient enters phase of clinical trial
C06	CRM - Cancel patient entering a phase (clerical mistake)
C07	CRM - Correct/update phase information
C08	CRM - Patient has gone off phase of clinical trial
C09	CSU - Automated time intervals for reporting, like monthly
C10	CSU - Patient completes the clinical trial
C11	CSU - Patient completes a phase of the clinical trial
C12	CSU - Update/correction of patient order/result information
G01	PGL/ACK - Patient goal
I01	RQI/RPI - Request for insurance information
I02	RQI/RPL - Request/receipt of patient selection display list
I03	RQI/RPR - Request/receipt of patient selection list
I04	RQD/RPI - Request for patient demographic data
I05	RQC/RCI - Request for patient clinical information
I06	RQC/RCL - Request/receipt of clinical data listing
I07	PIN/ACK - Unsolicited insurance information
I08	RQA/RPA - Request for treatment authorization information
I09	RQA/RPA - Request for modification to an authorization
I10	RQA/RPA - Request for resubmission of an authorization
I11	RQA/RPA - Request for cancellation of an authorization
I12	REF/RRI - Patient referral
I13	REF/RRI - Modify patient referral
I14	REF/RRI - Cancel patient referral
I15	REF/RRI - Request patient referral status
M01	MFN/MFK - Master file not otherwise specified (for backward compatibility only)
M02	MFN/MFK - Master file - Staff Practitioner
M03	MFN/MFK - Master file - Test/Observation
varies	MFQ/MFR - Master files query (use event same as asking for e.g., M05 - location)
M04	MFD/ACK - Master files delayed application acknowledgement
M05	MFN/MFK - Patient location master file
M06	MFN/MFK - Charge description master file
M07	MFN/MFK - Clinical study with phases and schedules master file
M08	MFN/MFK - Clinical study without phases but with schedules master file
O01	ORM - Order message (also RDE, RDS, RGV, RAS)
O02	ORR - Order response (also RRE, RRD, RRG, RRA)
Q06	OSQ/OSR - Query for order status
P01	BAR/ACK - Add and update patient account
P02	BAR/ACK - Purge patient account
P03	DFT/ACK - Post detail financial transaction
P04	QRY/DSP - Generate bill and A/R statements
P05	BAR/ACK - Update account
P06	BAR/ACK - End account
P07	PEX - Unsolicited initial individual product experience report
P08	PEX - Unsolicited update individual product experience report
P09	SUR - Summary product experience report
PC1	PPR - PC/ Problem Add
PC2	PPR - PC/ Problem Update
PC3	PPR - PC/ Problem Delete
PC4	PRQ - PC/ Problem Query
PC5	PRR - PC/ Problem Response
PC6	PGL - PC/ Goal Add
PC7	PGL - PC/ Goal Update
PC8	PGL - PC/ Goal Delete
PC9	PGQ - PC/ Goal Query
PCA	PGR - PC/ Goal Response
PCB	PPP - PC/ Pathway (Problem-Oriented) Add
PCC	PPP - PC/ Pathway (Problem-Oriented) Update
PCD	PPP - PC/ Pathway (Problem-Oriented) Delete
PCE	PTQ - PC/ Pathway (Problem-Oriented) Query
PCF	PTR - PC/ Pathway (Problem-Oriented) Query Response
PCG	PPG - PC/ Pathway (Goal-Oriented) Add
PCH	PPG - PC/ Pathway (Goal-Oriented) Update
PCJ	PPG - PC/ Pathway (Goal-Oriented) Delete
PCK	PTU - PC/ Pathway (Goal-Oriented) Query
PCL	PTV - PC/ Pathway (Goal-Oriented) Query Response
Q01	QRY/DSR - Query sent for immediate response
Q02	QRY/ACK - Query sent for deferred response
Q03	DSR/ACK - Deferred response to a query
Q05	UDM/ACK - Unsolicited display update
R01	ORU/ACK - Unsolicited transmission of an observation
R02	QRY - Query for results of observation
R03	Display-oriented results, query/unsol. Update (for backward compatibility only)
R04	ORF - Response to query; transmission of requested observation
RAR	RAR - Pharmacy administration information query response
RDR	RDR - Pharmacy dispense information query response
RER	RER - Pharmacy encoded order information query response
RGR	RGR - Pharmacy dose information query response
ROR	ROR - Pharmacy prescription order query response
S01	SRM/SRR - Request new appointment booking
S02	SRM/SRR - Request appointment rescheduling
S03	SRM/SRR - Request appointment modification
S04	SRM/SRR - Request appointment cancellation
S05	SRM/SRR - Request appointment discontinuation
S06	SRM/SRR - Request appointment deletion
S07	SRM/SRR - Request addition of service/resource on appointment
S08	SRM/SRR - Request modification of service/resource on appointment
S09	SRM/SRR - Request cancellation of service/resource on appointment
S10	SRM/SRR - Request discontinuation of service/resource on appointment
S11	SRM/SRR - Request deletion of service/resource on appointment
S12	SIU/ACK - Notification of new appointment booking
S13	SIU/ACK - Notification of appointment rescheduling
S14	SIU/ACK - Notification of appointment modification
S15	SIU/ACK - Notification of appointment cancellation
S16	SIU/ACK - Notification of appointment discontinuation
S17	SIU/ACK - Notification of appointment deletion
S18	SIU/ACK - Notification of addition of service/resource on appointment
S19	SIU/ACK - Notification of modification of service/resource on appointment
S20	SIU/ACK - Notification of cancellation of service/resource on appointment
S21	SIU/ACK - Notification of discontinuation of service/resource on appointment
S22	SIU/ACK - Notification of deletion of service/resource on appointment
S23	SIU/ACK - Notification of blocked schedule time slot(s)
S24	SIU/ACK - Notification of open ("unblocked") schedule time slot(s)
S25	SQM/SQR - Query schedule information
T01	MDM/ACK - Original document notification
T02	MDM/ACK - Original document notification and content
T03	MDM/ACK - Document status change notification
T04	MDM/ACK - Document status change notification and content
T05	MDM/ACK - Document addendum notification
T06	MDM/ACK - Document addendum notification and content
T07	MDM/ACK - Document edit notification
T08	MDM/ACK - Document edit notification and content
T09	MDM/ACK - Document replacement notification
T10	MDM/ACK - Document replacement notification and content
T11	MDM/ACK - Document cancel notification
T12	QRY/DOC - Document query
V01	VXQ - Query for vaccination record
V02	VXX - Response to vaccination query returning multiple PID matches
V03	VXR - Vaccination record response
V04	VXU - Unsolicited vaccination record update
W01	ORU - Waveform result, unsolicited transmission of requested information
W02	QRF - Waveform result, response to query
X01	PEX - Product experience

Attachment 2

HL7 Order Control Codes and Their Meaning

Value	Description	Originator	Field Note
NW	New order	P	I
OK	Order accepted & OK	F	I
UA	Unable to Accept Order	F	n

CA	Cancel order request	P	a
OC	Order canceled	F
CR	Canceled as requested	F
UC	Unable to cancel	F	b

DC	Discontinue order request	P	c
OD	Order discontinued	F
DR	Discontinued as requested	F
UD	Unable to discontinue	F

HD	Hold order request	P
OH	Order held	F
UH	Unable to put on hold	F
HR	On hold as requested	F

RL	Release previous hold	P
OE	Order released	F
OR	Released as requested	F
UR	Unable to release	F

RP	Order replace request	P	e,d,h
RU	Replaced unsolicited	F	f,d,h
RO	Replacement order	P,F	g,d,h,l
RQ	Replaced as requested	F	d,e,g,h
UM	Unable to replace	F

PA	Parent order	F	I
CH	Child order	F,P	i

XO	Change order request	P
XX	Order changed, unsol.	F
UX	Unable to change	F
XR	Changed as requested	F

DE	Data errors	P,F
RE	Observations to follow	P,F	j
RR	Request received	P,F	k
SR	Response to send order status request	F
SS	Send order status request	P
SC	Status changed	F,P
SN	Send order number	F	l
NA	Number assigned	P	l
CN	Combined result	F	m

RF	Refill order request	F, P	o
AF	Order refill request approval	P	p
DF	Order refill request denied	P	q
FU	Order refilled, unsolicited	F	r
OF	Order refilled as requested	F	s
UF	Unable to refill	F	t
LI	Link order to patient care message	u
UN	Unlink order from patient care message	u

Attachment 3

UB92 Segments

The UB2 segment contains data necessary to complete UB92 bills. Only UB92 fields that do not exist in other HL7 defined segments appear in this segment. Patient Name and Date of Birth are required; they are included in the PID segment and therefore do not appear here. When the field locators are different on the UB92, as compared to the UB82, the element is listed with its new location in parentheses ( ).

UB2 attributes

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
1	4	SI	O			00553	Set ID - UB2
2	3	ST	O			00554	Co-Insurance Days (9)
3	2	IS	O	Y/7	0043	00555	Condition Code (24-30)
4	3	ST	O			00556	Covered Days (7)
5	4	ST	O			00557	Non-Covered Days (8)
6	11	CM	O	Y/12	0153	00558	Value Amount & Code
7	11	CM	O	Y/8		00559	Occurrence Code & Date (32-35)
8	28	CM	O	Y/2		00560	Occurrence Span Code/Dates (36)
9	29	ST	O	Y/2		00561	UB92 Locator 2 (State)
10	12	ST	O	Y/2		00562	UB92 Locator 11 (State)
11	5	ST	O			00563	UB92 Locator 31 (National)
12	23	ST	O	Y/3		00564	Document Control Number
13	4	ST	O	Y/23		00565	UB92 Locator 49 (National)
14	14	ST	O	Y/5		00566	UB92 Locator 56 (State)
15	27	ST	O			00567	UB92 Locator 57 (National)
16	2	ST	O	Y/2		00568	UB92 Locator 78 (State)
17	3	NM	O			00815	Special Visit Count

PID attributesFigure 3-2. PID attributes

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
1	4	SI	O			00104	Set ID - Patient ID
2	20	CX	O			00105	Patient ID (External ID)
3	20	CX	R	Y		00106	Patient ID (Internal ID)
4	20	CX	O	Y		00107	Alternate Patient ID - PID
5	48	XPN	R			00108	Patient Name
6	48	XPN	O			00109	Mother's Maiden Name
7	26	TS	O			00110	Date/Time of Birth
8	1	IS	O		0001	00111	Sex
9	48	XPN	O	Y		00112	Patient Alias
10	1	IS	O		0005	00113	Race
11	106	XAD	O	Y		00114	Patient Address
12	4	IS	B			00115	County Code
13	40	XTN	O	Y		00116	Phone Number - Home
14	40	XTN	O	Y		00117	Phone Number - Business
15	60	CE	O		0296	00118	Primary Language
16	1	IS	O		0002	00119	Marital Status
17	3	IS	O		0006	00120	Religion
18	20	CX	O			00121	Patient Account Number
19	16	ST	O			00122	SSN Number - Patient
20	25	CM	O			00123	Driver's License Number - Patient
21	20	CX	O	Y		00124	Mother's Identifier
22	3	IS	O		0189	00125	Ethnic Group
23	60	ST	O			00126	Birth Place
24	2	ID	O		0136	00127	Multiple Birth Indicator
25	2	NM	O			00128	Birth Order
26	4	IS	O	Y	0171	00129	Citizenship
27	60	CE	O		0172	00130	Veterans Military Status
28	80	CE	O			00739	Nationality
29	26	TS	O			00740	Patient Death Date and Time
30	1	ID	O		0136	00741	Patient Death Indicator

Attachment 4

Product Experience Segments

PES - product experience sender segment

PES attributes

SEQ	LEN	DT	OPT	RP/ #	TBL #	ITEM #	ELEMENT NAME
1	80	XON	O			01059	Sender Organization Name
2	60	XCN	O	Y		01060	Sender Individual Name
3	200	XAD	O	Y		01062	Sender Address
4	44	XTN	O	Y		01063	Sender Telephone
5	75	EI	O			01064	Sender Event Identifier
6	2	NM	O			01065	Sender Sequence Number
7	600	FT	O	Y		01066	Sender Event Description
8	600	FT	O			01067	Sender Comment
9	26	TS	O			01068	Sender Aware Date/Time
10	26	TS	R			01069	Event Report Date
11	3	ID	O	Y/2	0234	01070	Event Report Timing/Type
12	1	ID	O		0235	01071	Event Report Source
13	1	ID	O	Y	0236	01072	Event Reported To

PEO - product experience observation segment

Details related to a particular clinical experience or event are embodied in the PEO segment. This segment can be used to characterize an event which might be attributed to a product to which the patient was exposed. Products with a possible causal relationship to the observed experience are described in the following PCR (possible causal relationship) segments. The message format was designed to be robust and includes many optional elements which may not be required for a particular regulatory purpose but allow a complete representation of the drug experience if needed.

A PEX message can contain multiple PEO segments if the patient experienced more than one event but must contain at least one PEO segment.

PEO attributes

SEQ	LEN	DT	OPTC	RP/ #	TBL #	ITEM #	ELEMENT NAME
1	60	CE	O	Y		01073	Event Identifiers Used
2	60	CE	O	Y		01074	Event Symptom/Diagnosis Code
3	26	TS	R			01075	Event Onset Date/Time
4	26	TS	O			01076	Event Exacerbation Date/Time
5	26	TS	O			01077	Event Improved Date/Time
6	26	TS	O			01078	Event Ended Data/Time
7	106	XAD	O			01079	Event Location Occurred Address
8	1	ID	O	Y	0237	01080	Event Qualification
9	1	ID	O		0238	01081	Event Serious
10	1	ID	O		0239	01082	Event Expected
11	1	ID	O	Y	0240	01083	Event Outcome
12	1	ID	O		0241	01084	Patient Outcome
13	600	FT	O	Y		01085	Event Description From Others
14	600	FT	O	Y		01086	Event From Original Reporter
15	600	FT	O	Y		01087	Event Description From Patient
16	600	FT	O	Y		01088	Event Description From Practitioner
17	600	FT	O	Y		01089	Event Description From Autopsy
18	60	CE	O	Y		01090	Cause Of Death
19	46	XPN	O			01091	Primary Observer Name
20	106	XAD	O	Y		01092	Primary Observer Address
21	40	XTN	O	Y		01093	Primary Observer Telephone
22	1	ID	O		0242	01094	Primary Observer's Qualification
23	1	ID	O		0242	01095	Confirmation Provided By
24	26	TS	O			01096	Primary Observer Aware Date/Time
25	1	ID	O		0243	01097	Primary Observer's identity May Be Divulged

PCR - possible causal relationship segment

The PCR segment is used to communicate a potential or suspected relationship between a product (drug or device) or test and an event with detrimental effect on a patient. This segment identifies a potential causal relationship between the product identified in this segment and the event identified in the PEO segment.

More than one PCR segment can be included in the message if more than one product is possibly causally related to the event.

PCR attributes

SEQ	LEN	DT	OPT	RP/ #	TBL #	ITEM #	ELEMENT NAME
1	60	CE	R			01098	Implicated Product
2	1	IS	O		0239	01099	Generic Product
3	60	CE	O			01100	Product Class
4	8	CQ	O			01101	Total Duration Of Therapy
5	26	TS	O			01102	Product Manufacture Date
6	26	TS	O			01103	Product Expiration Date
7	26	TS	O			01104	Product Implantation Date
8	26	TS	O			01105	Product Explanation Date
9	8	IS	O		0239	01106	Single Use Device
10	60	CE	O			01107	Indication For Product Use
11	8	IS	O		0239	01108	Product Problem
12	30	ST	O	Y/3		01109	Product Serial/Lot Number
13	1	IS	O		0239	01110	Product Available For Inspection
14	60	CE	O			01111	Product Evaluation Performed
15	60	CE	O		0247	01112	Product Evaluation Status
16	60	CE	O			01113	Product Evaluation Results
17	8	ID	O		0248	01114	Evaluated Product Source
18	26	TS	O			01115	Date Product Returned To Manufacturer
19	1	ID	O		0242	01116	Device Operator Qualifications
20	1	ID	O		0250	01117	Relatedness Assessment
21	2	ID	O	Y/6	0251	01118	Action Taken In Response To The Event
22	2	ID	O	Y/6	0232	01119	Event Causality Observations
23	1	ID	O	Y/3	0253	01120	Indirect Exposure Mechanism

PSH - product summary header segment

PSH attributes

SEQ	LEN	DT	OPT	RP/ #	TBL #	ITEM #	ELEMENT NAME
1	60	ST	R			01233	Report Type
2	60	ST	O			01234	Report Form Identifier
3	26	TS	R			01235	Report Date
4	26	TS	O			01236	Report Interval Start Date
5	26	TS	O			01237	Report Interval End Date
6	12	CQ	O			01238	Quantity Manufactured
7	12	CQ	O			01239	Quantity Distributed
8	1	ID	O		0329	01240	Quantity Distributed Method
9	600	FT	O			01241	Quantity Distributed Comment
10	12	CQ	O			01242	Quantity in Use
11	1	ID	O		0329	01243	Quantity in Use Method
12	600	FT	O			01244	Quantity in Use Comment
13	2	NM	O	Y/8		01245	Number of Product Experience Reports Filed by Facility
14	2	NM	O	Y/8		01246	Number of Product Experience Reports Filed by Distributor

PDC - product detail country segment

PDC attributes

SEQ	LEN	DT	OPT	RP/ #	TBL #	ITEM #	ELEMENT NAME
1	80	XON	R			01247	Manufacturer/Distributor
2	60	CE	R			01248	Country
3	60	ST	R			01249	Brand Name
4	60	ST	O			01250	Device Family Name
5	60	CE	O			01251	Generic Name
6	60	ST	O	Y		01252	Model Identifier
7	60	ST	O			01253	Catalogue Identifier
8	60	ST	O	Y		01254	Other Identifier
9	60	CE	O			01255	Product Code
10	4	ID	O		0330	01256	Marketing Basis
11	60	ST	O			01257	Marketing Approval ID
12	12	CQ	O			01258	Labeled Shelf Life
13	12	CQ	O			01259	Expected Shelf Life
14	26	TS	O			01260	Date First Marked
15	26	TS	O			01261	Date Last Marked

FAC - facility segment

FAC attributes

SEQ	LEN	DT	OPT	RP/ #####	TBL #	ITEM #	ELEMENT NAME
1	20	EI	R			01262	Facility ID
2	1	ID	O		0331	01263	Facility Type
3	200	XAD	R			01264	Facility Address
4	44	XTN	R			01265	Facility Telecommunication
5	60	XCN	O	Y		01266	Contact Person
6	60	ST	O	Y		01267	Contact Title
7	200	XAD	O	Y		01268	Contact Address
8	44	XTN	O	Y		01269	Contact Telecommunication
9	60	XCN	R			01270	Signature Authority
10	60	ST	O			01271	Signature Authority Title
11	200	XAD	O			01272	Signature Authority Address
12	44	XTN	O			01273	Signature Authority Telecommunication

National Uniform Claim Committee (NUCC)

The National Uniform Claim Committee was organized in May 1995 to develop, promote, and maintain a standard data set for use by the non-institutional health care community to transmit claim and encounter information to and from all third-party payers. The data set includes data elements, definitions, and code sets. Providers and suppliers may submit the NUCC data set using either a paper or electronic envelope.

The NUCC has received a formal consultative role regarding standards for health care transactions selected by the Secretary of Health and Human Services (HHS) as specified in the administrative simplification section of the Health Insurance Portability and Accountability Act of 1996 (P.L. 104-191). As specified in Act, American National Standards Institute (ANSI) accredited organizations must consult with the NUCC, the National Uniform Billing Committee (NUBC), the Workgroup for Electronic Data Interchange (EDI), and the American Dental Association (ADA). If the Secretary selects a standard different from one developed by an ANSI-accredited organization, she also must consult with the NUCC, NUBC, WEDI, and ADA.

The NUCC is chaired by the American Medical Association (AMA) with the Health Care Financing Administration (HCFA) as a critical partner. The Committee includes representation from key provider and payer organizations, as well as standards setting organizations, state and federal regulators, and the NUBC. As such, the NUCC is intended to have an authoritative voice regarding national standard data content and data definitions for non-institutional health care claims and encounters. The following organizations serve on the Committee as voting members:

American Medical Association
Health Care Financing Administration
Alliance for Managed Care
American Association of Health Plans
ANSI ASC X12 Insurance Subcommittee
Blue Cross and Blue Shield Association
Health Insurance Association of America
Medical Group Management Association
National Association for Medical Equipment Services
National Association of Insurance Commissioners
National Association of State Medicaid Directors
National Uniform Billing Committee

The NUCC will finalize its recommended data set in the first quarter of 1997 and make it available to the public. The NUCC also will provide formal comments into the ANSI ASC X12 Professional Implementation Guide for the Claim (837). Subsequently, the NUCC will address all other transactions specified in P.L 104-191.

ANSI Accredited:

The NUCC is not ANSI accredited; however, ANSI ASC X12 Insurance Subcommittee is a voting member of the NUCC, and several NUCC members are active in X12 and the HISB and are members of ANSI.

National Uniform Claim Committee Recommended Data Set for a Non-Institutional Claim or Encounter

Description of Standard:

The NUCC data set is intended for the transmission of claim and encounter information to and from all third-party payers, regardless of whether the envelope is paper or electronic.

Readiness Of Standard:

The NUCC will make its recommendation available to the public in the first quarter of 1997.

Identifiable Costs:

No or minimal costs.

Contact For More Information:

Mark J. Segal, Ph.D.

Chair, National Uniform Claim Committee

Director, American Medical Association

515 N. State Street

Chicago, IL 60610

Phone: 312/464/4726

Fax: 312/464/5836

eMail: Mark_Segal@ama-assn.org

Indicator Of Market Acceptance:

Voting members of the NUCC represent key provider and public and private payer organizations. Constituencies of these organizations were surveyed twice during the development of NUCC recommendations.

Health Claim Attachments

There are several standards developing organizations working on clinical data models, technical reports, guidelines and standards for clinical data. Some of these SDOs include HL7, ADA, X12, IEEE, ACR/NEMA/DICOM, and ASTM. Information regarding some of the standards being developed by HL7 and ADA appeared in the previous claims and encounter section and detailed information regarding their other projects appears in the Appendix explaining the activities to promote interoperability of standards - frameworks, architectures and models. Additional information regarding ASTM appears in the Security section. Claim attachment information pertaining to X12, IEEE, DICOM, and ASTM standards is listed below.

Accredited Standards Committee (ASC) X12 Insurance Subcommittee, Health Care Task Group

ANSI Accreditation - X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

ASC X12 Patient Information (275)

Contact for more information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard;

A) The objective of the Patient Information (275) is to support the exchange of demographic, clinical and other supporting patient information to support administrative reimbursement processing as it relates to the submission of health care claims for both health care products and services.

B) This transaction set can be used to communicate individual patient information requests and patient information (either solicited or unsolicited) between separate health care entities in a variety of settings to be consistent with confidentiality and use requirements.

C)This transaction is used to provide additional patient information to support administrative reimbursement for health care products and services.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Patient Information (275) is not a guideline. However the X12 Insurance Subcommittee is currently developing implementation guides.

B)The Patient Information (275) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in June of 1995 as Version 0030?2.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Patient Information (275) transaction.

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

B)Yes. ASC X12 represents international standards development. North American and other countries have implemented ASC X12 standards for purchasing and financial transactions. It would be to their benefit to further leverage their investment in EDI translation software, hardware and communication infrastructure to utilize the health care transactions.

C)Over 300 payer, provider, vendor, and plan sponsor organizations currently participate in the development of the ASC X12 standards and implementation guides to meet the business needs of the entire health care industry. These organizations have experienced the benefits of mature standards as costs associated with developing and maintaining proprietary formats far exceed the investment necessary to implement a single set of health care EDI transactions.

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D) ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships with other standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

A) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

IEEE 1157 MEDIX Project

Institute of Electrical and Electronics Engineers, Medical Information Bus (MIB) General

Committee

ANSI Accreditation:

IEEE is a charter member of ANSI and is an Accredited Standards Developing Organization.

IEEE 1073, Standard for Medical Device Communications

A family of documents that defines the entire seven layer communications requirements for the "Medical Information Bus" (MIB). This is a robust, reliable communication service designed for Intensive Care Unit, Operating Room, and Emergency Room bedside devices.

Approved Standards:

1) IEEE 1073.3.1 - Standard for Medical Device Communications, Transport Profile - Connection Mode: This document defines the services and requirements for a bedside subnetwork. It defines services similar to those defined in Ethernet and TCP/IP. Combined

with 1073.4.1, it defines the hardware required to offer hospitals to ensure ease of use for clinician initiated automatic data capture from bedside devices. An approved ANSI Standard since August, 1995.

2) IEEE 1073.4.1 - Standard for Medical Device Communications, Physical Layer, Cable Connected: This document defines the cables, connectors, data rates, and bit level encoding for the MIB. It is coupled with IEEE 1073.3.1 to complete the "lower layers" for 1073. An approved ANSI Standard since August, 1995.

3) IEEE 1073 - Standard for Medical Device Communications, Overview and Framework:

This document serves as an overview of the 1073 family of standards and a roadmap of which

documents, present and planned, contain information on different facets of communication. It defines the underlying philosophy in the 1073 family of standards. Approved by the IEEE Standards Board in March, 1996.

On-going Standards Work:

IEEE 1073.1 - Standard for Medical Device Communications, Medical Device Data Language (MDDL) Overview and Framework: This document defines the ISO Standards and conventions for using Object-Oriented Technology to define communications services for bedside medical devices. This is expected to go to ballot in late 1996.
IEEE 1073.1.1 - Standard for Medical Device Communications, MDDL Common Definitions: This document defines the common definitions for the object oriented communications services for medical devices.
IEEE 1073.1.2 - Standard for Medical Device Communications, MDDL Virtual Medical Device, Generalized: This document defines the general features of all virtual medical devices, in an object oriented environment. This is highly harmonized with CEN TC251, PT021 First Working Draft "Vital Signs Representations".
IEEE 1073.1.3 - Standard for Medical Device Communications, MDDL Virtual Medical Device, Specialized: This document defines the general features of specialized virtual medical devices for specific device categories. This is highly harmonized with CEN TC251, PT021 First Working Draft "Vital Signs Representation".
IEEE 1073.1.3.1 - Standard for Medical Device Communications, MDDL Virtual Medical Device, Specialized, Infusion Device: Defines the specific object oriented communications services for infusion devices. This project should have a first draft by the end of 1996.
IEEE 1073.1.3.2 - Standard for Medical Device Communications, MDDL Virtual Medical Device, Specialized, Vital Signs Monitor: Defines the specific object oriented communications services for vital signs monitors.
IEEE 1073.1.3.1 - Standard for Medical Device Communications, MDDL Virtual Medical Device, Specialized, Ventilator: Defines the specific object oriented communications services for ventilators. This project was started in April, 1996.
IEEE 1073.2 - Standard for Medical Device Communications, Application Profile, Overview and Framework: Describes the common theory and rules for all application profiles to be defined for the 1073 family. This was approved by the ballot group in late 1995, but is in editing stage. Should be approved by IEEE Standards Board in September, 1996.
IEEE 1073.2.0 - Standard for Medical Device Communications, Application Profile, Medical Device Encoding Rules: An optimization of ISO Basic Encoding Rules made for bedside medical devices. This should go to ballot in late 1996.
IEEE 1073.2.1 - Standard for Medical Device Communications, Application Profile, Minimum Set: Defines the minimum application profile for bedside medical devices. The service provided allows for one way capture of device data. This should go to ballot in late 1996.
IEEE 1073.2.2 - Standard for Medical Device Communications, Application Profile, Basic Capabilities: Defines the basic set of communications services for an application profile for bedside medical devices. The services provided allow for two way getting and setting of attribute values, and for creating and deleting of objects.

Contact For More Information:

Bob Kennelly

Chair, IEEE 1073 General Committee

LinkTech

30 Orville Drive

Bohemia, NY 11716

(P) 516-567-5656, ext. 7482

(F) 516-563-2819

(E) bobk@linktech.ilcddc.com

Description of Standard:

The IEEE 1073 Family of Standards serves to achieve the following: Objectives: To standardize data communications for patient connected bedside devices, optimized for the acute care setting, to allow clinicians to set up device communications in a "plug and play" fashion.

Functions:

The function of this family of standards is to permit real time,

continuous, and comprehensive capture of device data from patient connected bedside devices. This data includes physiological parameter measurements and device settings.

User Environment:

This family of standards is used in any setting containing patient connected bedside devices, but was optimized in its design for acute care settings such as intensive care, operating rooms, and emergency rooms.

Systems Environment:

IEEE 1073 defines a bedside sub-network where devices communicate with a bedside communications controller. The standard is strongly based on ISO Open Systems Interconnect, and as such is able to be compatible with most computer industry standard implementations. Prototype implementations have been done with DOS, Windows, Windows NT, TCP/IP and Ethernet.

Application Function/Domain Completeness:

The lower layers, or hardware, for this standard is completed as an IEEE and ANSI Standard. Drafts exist for many of the upper layer pieces required to do prototyping. Several documents are going to ballot in 1997.

In what way(s) is this standard superior to other standards in this category/classification?

The IEEE 1073 is the first attempt to standardize device interfaces. The previous data interfaces provided by device manufacturers were based on RS-232, in which only the very basic voltage levels and data rates are defined. Each device manufacturer needed to invent heir own language for device communications. Device manufacturers frequently changed this language in large and small ways across product lines and product revisions. The result was an entirely impossible quagmire of differing device interfaces for devices that tend to be portable and able to plug into multiple ports, each requiring a specific device driver to talk. It is similar to needed a different phone plug for each area code you want to call.

Readiness of Standard:

A) The IEEE 1073 family of standards are design standards that must be implemented during device design, or in after market converters. The implementation of 1073 allows for comprehensive, automatic collection of device data, which will affect clinician practice.

B)IEEE 1073 is presently implementable, and is in the process of being done at McKay-Dee Hospital in Ogden, Utah. The lower layers standards are supported by commercially available silicon and boards. The upper layers exist as drafts, using available object oriented models. To implement 1073 in 1996, a hospital must know its device type population, and design tables in their HIS to interpret the specific message structure, format, and content from their medical devices. The delivery of this message is standardized today.

C)The IEEE 1073 Standards are available from IEEE by calling 908-562-3800.

D)There is presently no implementation guide for the IEEE 1073 Standards.

E)There is presently no implementation guide for the IEEE 1073 Standards.

F)A conformance test plan and method is intended future work of the IEEE 1073 General Committee.

G)There are no conformance test tools available for IEEE 1073.

H)There are no conformance test tools available for IEEE 1073.

I)The lower layers of the standard are completed and implementable today. The lower layers are analogous to using ethernet and TCP/IP. The upper layers are still being developed, with several documents expected to be approved in 1997.

J)There are no extensions being developed, since the scope for this standard includes all communication layers for bedside medical devices.

AA) Ballot groups for 5 upper layer documents are being formed and will be closed by the end of 1996. Balloting for these documents will occur in the second quarter of 1997, with approval by the IEEE Standards Board in September or December 1997.

BB) Upon approval of the documents in 1997, a full implementation of IEEE 1073 will be achievable. Prototype implementations will be done in the first half of 1997.

Indicator of Market Acceptance:

A)As of January 1996, approximately 400 copies of the approved standards had been sold by IEEE.

B)IEEE 1073 is in the early adopter stage in the market. There are people at LDS Hospital, Univ. of West Virginia, Univ. Texas Houston Medical School, Texas Children's Hospital, and Naval Hospital San Diego doing prototyping work. One medical device vendor, Siemens, is shipping product in Europe with IEEE 1073 embedded.

C)There is prototype and evaluation work on IEEE 1073 being done in UK, Germany, Spain, Norway, and Japan.

D)There is growing demand for 1073 from US Hospitals, which is being recognized by US device vendors, and being considered for their new product designs. Also, the Hewlet-Packard led Andover Working Group has stated their intent to do prototype implementations of 1073 in 1997.

Level of Specificity:

Notes:

A) IEEE 1073 is a family of standards that describe in specific detail what needs to be implemented to be compliant.

B)The lower layers of 1073 are very specifically defined and are supported by a commercially available integrated circuit product. The upper layer drafts define very specific message contents and structure for specific types of bedside medical devices.

C)IEEE 1073 references many ISO communications standards to define the communications protocol. These include ISO Standards for RS-485, HDLC, Basic Encoding Rules, ASN.1, and the Guide to Developing Managed Objects.

D)There is a defined nomenclature within IEEE 1073 that defines the parameter name and a code structure for physiologic parameters and device settings.

E)The code set is a subset of the Medical Device Data Language (MDDL), and is listed as the MDDL Nomenclature, IEEE 1073.1.1

F)IEEE 1073.1.1 is a draft available from IEEE. It has also been submitted to LOINC for inclusion in that work.

G)There is presently no users' guide for the code set. However, one of the vendor members of the general committee has developed a tool in-house that may be released for public use in 1997.

H)The IEEE 1073 nomenclature is not presently being used in any commercial application.

I)IEEE 1073.1.1 should be balloted in 1997.

Relationships With Other Standards:

A)IEEE 1073 is a bedside subnetwork that collects device data. In any application that requires this data, 1073 has a relationship with that standard. The relationship will most likely be expressed through application gateways. Such examples may include: conversion of device data to HL7 format for inclusion of device parameters in an HL7 based clinical data depository; conversion of device data into an X12 message for inclusion in billing applications; use of device data by an electronic medical record standardized any other SDO.

B)IEEE 1073 has been having its meeting in conjunction with the HL7 working group meetings to ensure rapid convergence of ideas.

C)The most important aspect of our coordination efforts is elimination of workscope overlap. For example, at the last HL7 meeting we received a presentation on LOINC that resulted in formal submittal of our work to LOINC.

D)The only assumed condition we have is that our work will be viewed as valuable and taken as a contribution.

IEEE 1073 is entirely based on the ISO Open System Interconnect model and multiple ISO communications standards such as HDLC, BER, ASN.1, MOSI, GDMO.

E)The remaining gaps are mainly in areas of implementations to ensure that the goals of standardization are achievable in actual practice.

F)The nearest term efforts on implementations will be done in the Andover Working Group.

Identifiable Costs:

Please indicate the cost or your best estimate for the following:
Cost of licensure: There is no licensure cost for IEEE 1073.
Cost of acquisition : Medical device with embedded IEEE 1073 interfaces should have minimal cost difference from present purchase prices. The hospital infrastructure to support
bedside data capture will likely be similar to the costs of putting PC's at bedsides.
Cost/timeframes for education and training: Unknown
Cost/timeframes for implementation: Unknown

Please note any other cost considerations: The probable investment in IEEE 1073 infrastructure for hospitals will be small compared to the benefits from being able to have comprehensive data on the conditions of the most gravely ill, and costly, patients.

Digital Imaging Communication in Medicine (DICOM) Standards Committee

Membership: Professional specialty societies, industry (National Electrical Manufacturers Association and other industry), and government, industry, and trade association liaison members.

ANSI Accreditation:

NEMA is an ANSI-Accredited standards developing organization. The DICOM Standards Committee, through NEMA, can develop American National Standards via the ANSI Canvass Procedure. The DICOM Standards Committee is considering applying for ANSI Accredited Standards Committee status in 1997.

DICOM Standard. NEMA PS3.x - 1992, 1993, 1995

Contact For More Information

DICOM Secretariat: NEMA

Mr. David Snavely, 1300 North 17th Street, Suite 1847, Rosslyn, VA 22209

e-mail: dav_snavely@nema.org

DICOM Liaison Working Group Secretariat: American College of Radiology

Mr. James Potter, 1891 Preston White Drive, Reston, VA 22091

e-mail: jamesp@acr.org

DICOM Structured Reporting Secretariat: College of American Pathologists

Ms. Karen Kudla, 325 Waukegan Road, Northfield, IL 60093-2750

e-mail: kkudla@cap.org

DICOM Visible Light Working Group Secretariat: Am. Soc. of Gastro. Endoscopy

Dr. Louis Korman, Washington VA Medical Center

e-mail: lkorman@erols.com

DICOM ANSI HISB Liaison: W. Dean Bidgood, Jr., M.D., M.S.

Box 3321, Duke University Medical Center, Durham, NC 27710

e-mail: bidgood@nlm.nih.gov

Description of Standard

DICOM specifies a generic digital format and a transfer protocol for biomedical images and image-related information. The specification is usable on any type of computer and is useable to transfer images over the Internet. DICOM interfaces are available for nearly all types of imaging devices sold by all of the leading vendors of radiology imaging equipment. DICOM is now being adopted for use outside of radiology (for example, in pathology, internal medicine, veterinary medicine, and dentistry).

The most commonly used diagnostic and therapeutic biomedical image types are fully covered by DICOM. DICOM has been adopted by the U.S. Veterans Affairs Administration and the U.S. Armed Forces.

DICOM enables interchange of text information, coded information, measurements, images, and other binary data. The systems domain focus is on all aspects of image management. Interfacing with other text-based information systems is also specified. Trial implementation of a new structured report interface will begin in January, 1997.

Readiness of Standard

All radiology image specifications of DICOM are fully implementable. The visible light (color) image types and the structured reporting interfaces will be available for trial implementation in January, 1997. Additional draft specifications for radiation oncology, PostScript™ Print management, Positron Emission Tomography, image data compression, security, image presentation (standardized display) parameters are under development at the time of this writing.

DICOM is an implementable standard. There is no official implementation guide. Public domain software implementations are available on the Internet. Several companies offer implementation software "tool kits" for sale. Further information about DICOM resources may be obtained on the NEMA WWW site: (http://www.nema.org).

Indicator of Market Acceptance

DICOM is the dominant non-prominent data interchange message standard in biomedical imaging. All major radiology equipment vendors have implemented the standard. Acceptance is growing rapidly outside of radiology. Interconnectivity among many vendors has been demonstrated to the public in many international meetings since 1992.

Level of Specificity

DICOM is a highly specific and explicit specification. The standard specifies all data interchange parameters from hardware factors (industry standards adopted) up through the bit/byte stream, services, protocols, to the domain knowledge layer. A very practical and useful level of interoperability can be achieved with the standard. The need for local configuration agreements is minimized. The SNOMED DICOM Microglossary™ is the preferred coding system -to- message data element Mapping Resource. SNOMED (Systematized Nomenclature of Human and Veterinary Medicine, © College of American Pathologists) and LOINC (Logical Observation Identifiers, Names, and Codes) database are the preferred coding systems. DICOM also supports locally-defined (or private) coding systems.

Relationships With Other Standards

DICOM has a close relationship to the HL7 Standard in the area of Imaging System - Information System interfacing. DICOM has entered into standards developing partnership with the SNOMED Authority of the College of American Pathologists. Ultrasound, cardiovascular, and other DICOM measurement codes are being developed in close cooperation with the LOINC Committee. Internationally, DICOM is compatible with the CEN/TC 251 WG4 MEDICOM Standard and the Japanese JIRA and MEDIS-DC Standards for network interchange of images and image-related information.

Enhancement of the Information System - Imaging System interface specifications of DICOM and related standards is underway at the time of this writing. DICOM offers advanced capabilities for management of binary data objects (such as images) that are not available in the current versions text-based data interchange standards (HL7 and X-12).

Identifiable Costs

The printed specification of the DICOM Standard is available from NEMA for approximately $300. Implementation training is available from private consulting and training companies. Due to the complexity of imaging technology, the DICOM specification is complex. Significant training is required in order to write compatible software. However, the availability of software implementation "tool kits" from several commercial sources has greatly simplified the implementation of DICOM for most vendors.

ASTM Committee E31 on Healthcare Informatics

The category/classification of this standard is: Data Content Vocabulary for Computer-Based Patient Records

The standards development organization is ASTM. ASTM is an ANSI accredited standards development organization.

Organized in 1898, ASTM (the American Society for Testing and Materials) has grown into one of the largest voluntary standards development systems in the world. ASTM is a not-for profit organization that provides a forum for producers, users, ultimate consumers, and those having a general interest (representatives of government and academia) to meet on common ground and write standards for materials, products, systems, and services. From the work of 132 standards-writing committees, ASTM publishes more that 9000 standards. ASTM headquarters has no technical research or testing facilities; such work is done voluntarily by 35,000 technically qualified ASTM members located throughout the world. ASTM provides continuing education and training in the use and application of ASTM standards through Technical and Professional Training courses. In 1987, ASTM formed the Institute for Standards and Research (ISR). The purpose of the Institute is to provide a mechanism for conducting research to improve the quality and timeliness of ASTM standards. It does no research, but serves as the intermediary between the standards-writing community and the public or private agencies that could provide appropriate research and technical services, or supply funding for such research.

Accreditation

ASTM is an ANSI Accredited by the Organization Method. All ASTM Committee E31 standards are approved as American National Standards

ASTM E1384-96 Standard Guide for Content and Structure of the Computer-Based Patient Record

Contact: Manager - Committee E31, ASTM

100 Barr Harbor Drive

West Conshohocken, PA 19373

Ph: 610-832-9500

Fax: 610-832-9666

Standard Description

This standard guide is intended to provide the framework vocabulary for the computer-based patient record content. It proposes a minimum essential content drawn from a developing annex of dictionary elements.

Elements are populated using master tables which range from standard code systems to reference tables harmonized with HL-7 Version 2.2. It calls for unique data views specified

for clinical settings. The standard contains an annex of dictionary items intended as a reference standard for designers and developers.

Functions: Implementation Independent Content Organization

Master Tables

Data Views

User Environment: Administrative And Clinical Users

Software Developers - Data Base Design

Educators - Health Informatics

Systems Environment: Does Not Specify System Environment

Evolving Standard - Ongoing Development

Most Complete CPR Content Standard

Value

There are no other standards that address the overall content vocabulary for computer-based patient records. This standard offers an initial data model intended for application in all healthcare settings. It currently serves as a reference model for vendors and institutions working to build data base content for CPRs.

Readiness of the Standard

A) This standard is a guideline that addresses policy and design. Since it offers an overall data model, users would incorporate the elements of the standard that apply to their situation. For example, requests for this standard come from designers working on the data content of the CPR. The proposed content is being used as a base data model and for data definitions.

B)This standard does not require a separate implementation guide. It should be used in conjunction with the Standard Specification for Coded Values for the Computer-Based Patient Record E1633 to achieve more specificity. Vocabulary data elements are defined in E1384, which include limited code values and pointers to E1633 for the specific master tables and code systems and values needed for the data elements. Code sets are assumed, referenced in E1633 for data elements; and harmonized with code sets in HL-7 where feasible.

C)How can the standard be obtained? ASTM standards are available through the ASTM Customer Service Department by calling 610-832-9585. Standards can also be ordered through the ASTM Web Site at www. astm.org

The standard is fully usable now as a reference guide for designers/developers of Computer-Based Patient Records.

Milestones

Milestones identified are additional content, harmonization with companion standards and joint development work on new vocabulary. The most recent ballot was in l996. Proposed revisions are already in development and updates will be balloted in l997.

Indicator Of Market Acceptance

A)If the standard is a guideline, how many copies have been requested and distributed? Approximately 2300 copies of the E31 standards have been distributed.

B)If the standard is an implementable standard, how many vendors, healthcare organizations, and/or government agencies are using it?

This type of information is difficult to obtain for the E31 standards. It is indicated where available under the document specific information to follow.

This standard is included in the ASTM l996 Book of standards made available to people who join ASTM. Currently, the membership of E31 Committee on Healthcare Informatics is over 300. Actual numbers of interested individuals who have requested this standard far exceeds the membership.

The Veterans Administration reports using this as a reference standard.

Other indicators of market acceptance include users who are currently involved in developing CPR applications within individual hospitals and hospital consortiums; vendors who are working on CPR data repository models; and CPR project planners who are in the process of defining content standards for their enterprise.

This standard is also included in a l996 publication that has been adopted by all Health Information Administration programs in the United States.

Level of Specificity

This standard is a guide. It calls for standard content expressed in a uniform manner. It does not provide data dictionary specificity. It identifies the common information framework that is part of patient records in multiple settings.

Relationship With Other Standards

As indicated, this standard depends on ASTM E1633 for specified coded values; uses some HL-7 data elements and a limited number of master tables. Ongoing analysis is performed to continue work on harmonizing elements with collaborative work, e.g. the Minimum Data Set from the National Committee on Vital and Health Statistics. Harmonization with message standards are proposed for revisions where possible. Functionality will be strengthened by coordination. Conditions assumed for coordination to be effective include joint work initiatives among standards developers and representatives from the user community who currently use this standard.

E1384 can be obtained from ASTM at:

100 Barr Harbor Drive, West Conshohocken, PA 19428

(610) 832-9500 Web Site: http://www.astm.org

Category/Classification Of The Standard

Health Claim Attachments

ASTM E1769-95 Standard Guide for Properties of Electronic Health Records and Record Systems

Contact For More Information

Manager - Committee E31, ASTM

100 Barr Harbor Drive

West Conshohocken, PA 19373

Ph: 610-832-9500

Fax: 610-832-9666

Description Of Standard

This standard defines the requirements, properties, and attributes of a computer-based patient record. It serves as an agreement among all the parties about the goals and constraints of the computer-based patient record, and provides criteria for making tradeoffs and decisions about how the record will be configured. The guide defines a computer-based record as the structured set of demographic, environmental, social, financial, and clinical data elements in electronic form needed to document the healthcare given to a single patient. It discusses how information is entered, dealing with such questions as who can enter, how is information identified, how is it validated, and who is accountable. It describes data attributes, such as permanence, accessibility, reliability, internal consistency, and security. System response time and the ability to process data are considered. Output criteria are addressed, including who can access information, the level of fact detail available, customization of display, multimedia outputs, and export to other systems. The system must protect the rights of the patient to confidentiality and the rights of the care provider to privacy. The concept of connecting together various encounter records of a patient to produce a longitudinal patient record is described. Systems to implement computer-based medical records must support local clinical functions. In addition, they should also be considered nodes of a national clinical network. The data content of the records must meet the needs of all legitimate users, such as payers, regulatory agencies, public health workers, researchers, and quality of care/outcome studies personnel. The records must be mobile and accessible to all authorized users. This ensures easy transport of records when patients move or change care providers. It also permits the extraction of billing, monitoring, and research data into other computer systems. Full logical compatibility among data banks is essential for these purposes.

Readiness Of Standard

The standard is published and is an American National Standard. How can the standard be obtained? ASTM standards are available through the ASTM Customer Service Department by calling 610-832-9585. Standards can also be ordered through the ASTM Web Site at www. astm.org

Indicators Of Market Acceptance

Approximately 2300 copies of the E31 standards have been distributed.

A wide variety of vendors are implementing EHR systems. The standard describes many of the features which are being incorporated into these systems and includes many features which have yet to be implemented by vendors. There has been no feedback to the standards committee from vendors indicating any objection to the features described in the standard other than the technical difficulty of achieving some of the functions described therein.

Level Of Specificity

The standard describes EHR functions at a functional level. It makes no attempt to recommend a specific implementation strategy but rather attempts to outline how the various functions described can interact to provide a functional EHR.

Relationship With Other Standards

Related ASTM standards, notably E 1384, provide information on topics such as the data elements which should be included in an EHR system. Numerous additional standards such as HL7 for data exchange and various coding schemes to determine data content are also relevant.

Identifiable Costs

The cost to implement this standard depends heavily on the technology and methodologies chosen by a specific vendor.

Category/Classification Of The Standard

Health Claim Attachments

ASTM E1633-95 Standard Specification for Coded Values Used in the Computer-Based Patient Record

Contact For More Information

Manager - Committee E31, ASTM

100 Barr Harbor Drive

West Conshohocken, PA 19373

Ph: 610-832-9500

Fax: 610-832-9666

Description Of Standard

This specification identifies the lexicons to be used for the data elements identified in the Annex portion of Standard E1384, Guide for the Content and Structure of the Computer-Based Patient Record. It is intended to unify the representations for (1) the identified data elements for the computer-based patient record, (2) data elements contained in other standard statistical data standards, (3) data elements used in other healthcare data message exchange format standards, or (4) in data gathering forms for this purpose, and (5) in data derived from these elements so that data recorded in the course of patient care can be exchangeable and provide consistent devel0pment of CPR content vocabulary that can also provide an accurate source for statistical and resource management data. Code values are specified using master tables which range from standard code value sets identified directly for the data element to standard code systems such as ICD9 to reference tables harmonized with HL7 Version 2.2. It promotes consistent data views specified for clinical settings. The standard is intended as a reference standard for designers and developers.

Functions: Implementation independent content organization

Identifies data representation for vocabulary elements

Includes an initial catalog of coded value sets

References known mater tables

User Environment: Administrative and clinical users

Software developers - data base design

Educators - health informatics

Systems Environment: Does not specify system environment

Evolving standard - ongoing development is focused on alignment with value sets used in companion standards

Value: Provides the 2nd edition of detailed representation for the listed data

elements contained in the vocabulary content in Standard ASTM E1384. It currently serves as a reference model for vendors and institutions working to build data base content for CPRs.

Readiness Of Standard

This standard is a specification that addresses data structure and data dictionary design. Since it combines with E1384 to offer an overall data model, users would incorporate the elements of the standard that apply to their situation. Requests for this standard come from designers working on the data content of the CPR. The proposed content is being used as a base data model and for data definitions.

This standard does not require a separate implementation guide. It should be used in conjunction with the Standard E1384. Vocabulary data elements are defined in E1384, which include limited code values and point to this specification for the specific delineations for the data form, coded values to be used in representing the element and where appropriate, and more formally identified master tables and code systems needed for the data elements. Code sets are assumed, referenced in E1633 for data elements and harmonized with code sets is ASTM Standards E 1238, E1239 and HL7 where feasible.

The standard is fully usable now as a reference guide for designers/developers of computer-based patient records.

Milestones identified are continued code value expansions, harmonization with companion standards and joint development work on new vocabulary. The most recent ballot was 1996. Proposed revisions and updates will be balloted in early 1997.

Indicators Of Market Acceptance

Approximately 2300 copies of the E31 standards have been distributed.

The Veterans Administration reports using this as a reference standard. Other indicators include users who are currently involved in developing CPR applications within individual hospitals and hospital consortiums; vendors who are working on CPR data repository models; and CPR project planners who are in the process of defining content standards for their enterprise.

This standard is also included in a 1996 publication that has been adopted by all Health Information Administration programs in the United States. Another text due out in 1997 on data dictionaries for healthcare recommends usage of this specification in conjunction with E1384 for constructing data dictionaries in healthcare organizations.

Level Of Specificity

This standard calls for content to be expressed in a uniform manner. It does provide some data dictionary specificity. It identifies the common representation for data to be part of computer-based patient records in multiple settings.

Relationship With Other Standards

As indicated, this standard is written to provide the detailed specificity to ASTM E1384 for specified code values. Major work on this standard continues to be comparison and reconciliation with other standards and evolving data sets such as the Minimum Data Set from the National Committee on Vital and Health Statistics; and the National Provider Identification efforts underway in the Health Care Financing Administration. Harmonization with message standards and data element values included in X12 are proposed for revisions where possible. Functionality will be strengthened by coordination. Conditions assumed for coordination to be effective include joint work initiatives among standard developers and representatives from the user community who currently use this standard.

Enrollment and Disenrollment in a Health Plan

Accredited Standards Committee (ASC) X12, Health Care Task Group

ASC X12 Benefit Enrollment and Maintenance (834)

Contact for more information - Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard

A) The objective of the - Benefit Enrollment and Maintenance (834) is to support the administration of enrollment and disenrollment of covered individuals within various insurance products.

B) This transaction set can be used to enroll and disenroll covered individuals for insurance products such as health, life, flexible spending accounts, and retirement products.

C)This transaction is used for administration of insurance benefit plans.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard

A) The Benefit Enrollment and Maintenance (834) is not a guideline. However X12 has published implementation guides.

B)The Benefit Enrollment and Maintenance (834) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in February of 1992 as Version 003021.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

D)Each X12 transaction must have an implementation guide and a complete and unambiguous data dictionary if identical implementations are to be obtained. The X12 began writing implementations guides during calendar year 1996 for version 3070. None have yet been tested between operating trading partners. No draft data dictionary is yet available.

E)There is only one implementation guide for the Benefit Enrollment and Maintenance (834).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance

Level of Specificity

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

H)The cost/timeframe for education and training will depend upon the individuals and skill levels of the individuals within an organization. Some organizations have completed education and training within one week while others have taken longer.

I)The cost/timeframe for implementation depends upon the internal systems capabilities, systems development philosophy, hardware platform selected, EDI translator software, communication methodology and individual resources within an organization. Costs can range anywhere from free for a personal computer solution to well over $150,000 for midsize and mainframe systems. Some organizations have implemented the standards within a matter of days while other have taken months to achieve the same end result.

National Council for Prescription Drug Programs (NCPDP)

NCPDP Member Enrollment Standard

NCPDP recommends the use of a standardized format for member enrollment among insurance carriers, third-party administrators, and other providers. The Member Enrollment Standard was developed to enhance the enrollment verification process and provide a consistent format for enrollment verification processing.

Eligibility for a Health Plan

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

ANSI Accreditation: X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

ASC X12, Health Care Eligibility/Benefit Inquiry (270), ASC X12, Health Care Eligibility/Benefit Information (271)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Health Care Eligibility/Benefit Inquiry (270) - Health Care Eligibility/Benefit Information (271) is to provide for the exchange of eligibility inquiry and response to individuals within a health plan.

This transaction set can be used by health care providers to request and receive coverage and payment information on the member/insured in a batch environment where real time processing is not required.

B)This transaction is used to provide additional patient eligibility information to support administrative reimbursement for health care products and services.

C)This standard may be used from any operating system, network, or hardware platform.

D)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

E)The ANSI ASC X12 is the only nationally recognized EDI standards development organization in the United States for all type of electronic commerce. ASC X12 is the organization assigned by ANSI to represent the United States in the development of International EDI standards.

F)Standards. These standards are developed using a consensus process by the users in the health care industry.

G)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Health Care Eligibility/Benefit Inquiry (270) - Health Care Eligibility/Benefit Information (271) is not a guideline. However the X12 Insurance Subcommittee is currently developing implementation guides.

B)The Health Care Eligibility/Benefit Inquiry (270) - Health Care Eligibility/Benefit Information (271) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in February of 1993 as Version 003031.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Health Care Eligibility/Benefit Inquiry (270) - Health Care Eligibility/Benefit Information (271) transaction.

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

B)Every Medicare carrier and intermediary has implemented ASC X12 standards for healthcare eligibility. All carriers have implemented the 270/271 for eligibility. Many other payers have followed HCFA's lead and implemented the standard as well.

D)Over 300 payer, provider, vendor, and plan sponsor organizations currently participate in the development of the ASC X12 standards and implementation guides to meet the business needs of the entire health care industry. These organizations have experienced the benefits of mature standards as costs associated with developing and maintaining proprietary formats far exceed the investment necessary to implement a single set of health care EDI transactions.

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

ASC X12, Health Care Task Group

Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI), Interactive Health Care Eligibility/Benefit Response (IHCEBR)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) - Interactive Health Care Eligibility/Benefit Response (IHCEBR) is to provide for the exchange of eligibility inquiry and response to individuals within a health plan.

B) This interactive message can be used by health care providers to request and receive coverage and payment information on the member/insured in an online real time environment.

C)This message is used to provide additional patient eligibility information to support administrative reimbursement for health care products and services.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard

A) The Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) - Interactive Health Care Eligibility/Benefit Response (IHCEBR) is not a guideline. However the X12 Insurance Subcommittee is currently developing implementation guides.

B)The Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) - Interactive Health Care Eligibility/Benefit Response (IHCEBR) standard is fully implementable. The message was approved as a Draft Standard for Trial Use (DSTU) in October of 1994 as Version 003050.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) - Interactive Health Care Eligibility/Benefit Response (IHCEBR).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator Of Market Acceptance

B)Every Medicare carrier and intermediary has implemented ASC X12 standards for payment and remittance advice. Many other payers have followed HCFA's lead and implemented the standard as well.

Level of Specificity

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

The cost/timeframe for implementation depends upon the internal systems capabilities, systems development philosophy, hardware platform selected, EDI translator software, communication methodology and individual resources within an organization. Costs can range anywhere from free for a personal computer solution to well over $150,000 for midsize and mainframe systems. Some organizations have implemented the standards within a matter of days while other have taken months to achieve the same end result.

Health Care Payment and Remittance Advice

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

ANSI Accreditation: X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

ASC X12N Health Care Claim Payment/Advice (835).

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Health Care Claim Payment/Advice (835) is to support reimbursement processing for health care products and services.

B) This transaction set can be used to make a payment, send an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a health care provider either directly or via a financial institution.

C)This transaction is used for administrative reimbursement for health care products and services.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard

A) The Health Care Claim Payment/Advice (835) is not a guideline. However X12 has published implementation guides.

B)The Health Care Claim Payment/Advice (835) standard is fully implementable.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There are currently two versions of the implementation guide for the Health Care Claim Payment/Advice (835) one for version 003051 and one for version 003070.

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance

B)Every Medicare carrier and intermediary has implemented ASC X12 standards for claim and remittance advice. All carriers have implemented the 270/271 for eligibility. Many other payers have followed HCFA's lead and implemented the standard as well.

Level of Specificity

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

Health Care Premium Payments

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

Consolidated Service Invoice/Statement (811), Payment Order/Remittance Advice (820)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Consolidated Service Invoice/Statement (811) - Payment Order/Remittance Advice (820) is to facilitate health plan premium billing and payment.

B)These transaction sets can be used by health care prayers and plan sponsors for the purpose of premium billing (Consolidated Service Invoice/Statement 811) and collection (Order/Remittance Advice 820).

C)These transactions are used for the administrative reimbursement for health plans between health care payers and plan sponsors.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Consolidated Service Invoice/Statement (811) - Payment Order/Remittance Advice (820) is not a guideline. However the X12 Insurance Subcommittee is currently developing implementation guides.

B)The Consolidated Service Invoice/Statement (811) - Payment Order/Remittance Advice (820) standard is fully implementable. The transaction has been approved as a Draft Standard for Trial Use (DSTU).

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Consolidated Service Invoice/Statement (811) - Payment Order/Remittance Advice (820) for the purposes of health plan premium payments.

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

First Report of Injury

Accredited Standards Committee X12 Insurance Subcommittee, Property And Casualty Task Group

ANSI Accreditation

X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

Report of Injury, Illness or Incident (148)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standard:

A) The objective of the Report of Injury, Illness or Incident (148) is to facilitate the first report of an injury, incident or illness.

B)This transaction set can be used to report information pertaining to an injury, illness or incident to entities interested in the information for statistical, legal, and claims and risk management processing requirements.

C)This transaction is used for administrative reporting requirements.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has been developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Report of Injury, Illness or Incident (148) is not a guideline. However the X12 Insurance Subcommittee is currently developing an implementation guide.

B)The Report of Injury, Illness or Incident (148) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU).

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Report of Injury, Illness or Incident (148).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

A) The X12 standards are made available via many sources including the Data Interchange Standards Association, Washington Publishing (ASC X12 Insurance Subcommittee's publisher), industry user groups and associations, and the Internet. Due to the multiplicity and diversity of these distribution methods, it is not possible to determine how many copies have been distributed and to whom.

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

G) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

Health Level Seven (HL7)

Emergency room message being developed with Centers for Disease Control (CDC). See detailed information regarding HL7 in the Claims section.

ASTM Committee E31 on Healthcare Informatics

ANSI Accreditation

ASTM is an ANSI Accredited by the Organization Method. All ASTM Committee E31 standards are approved as American National Standards.

E1744-95, Standard Guide for a View of Emergency Medical Care in the Computerized Patient Record

Contact For More Information

Manager - Committee E31, ASTM

Barr Harbor Drive

West Conshohocken, PA 19373

Ph: 610-832-9500

Fax: 610-832-9666

Description of Standard

This guide covers the identification of the information that is necessary to document emergency medical care in a computerized patient record that is part of a paperless patient record system designed to improve efficiency and cost-effectiveness. It details the use of data elements already established for emergency care in the field or in a treatment facility and places them in the context of the object models for health care that will be the vehicle for communication standards for health care data. The codes for the data elements referred to in the document will be developed in consideration of national or professional guidelines whenever available. The EMS definitions are based on those generated from the national consensus conference sponsored by NHTSA and from ASTM F30.03.03 on EMS management information systems. The Emergency Department (ED) definitions will consider those recommended by the Data Elements for Emergency Department Systems workshop sponsored by CDC, NHTSA, and other public and private organizations. The hospital discharge definitions will be developed in consideration of existing requirements for Medicare and Medicaid payment. The ASTM process allows for the definitions to be updated as the national consensus changes. When national or professional definitions do not exist, or whenever there is a conflict in the definitions, the committee will recommend a process for resolving the conflict or present the various definitions within the document along with an explanation for the purpose of each definition.

This view reinforces the concepts set forth in E-1239 and E-1384 that documentation of care in all settings must be seamless and be conducted under a common set of precepts using a common logical record structure and common terminology. The computerized patient record focuses on the patient and includes information about the occurrence of the emergency, symptoms requiring emergency medical treatment, medical/mental assessment/diagnoses established, treatment rendered, outcome and disposition of the patient after emergency treatment. It consists of subsets of the data computerized by multiple care providers at the time of onset/scene and enroute, in the emergency department, in the hospital or other emergency health care settings. The computerized patient record focuses on the documentation of information that is necessary to support patient care but does not define appropriate care.

Readiness of Standard

This guide is a "view" of the data elements to document the types of emergency medical information that would be valuable if available in the computerized patient record. As a view of the computerized patient record, the information presented will conform to the structure defined in other ASTM standards for the computerized patient record. This guide is intended to amplify Guides E 1239, E 1384, and F 1629 and the formalisms described in Practice E 1715. It is implementable in that it consists of a list of data elements important to emergency medical care that vendors can include in their data systems. The guide does not include attribute values for each of the data elements. However, most of these data elements are already defined in the other documents as indicated in Section VI. (The EMS definitions are based on those generated from the national consensus conference sponsored by NHTSA and from ASTM F30.03.03 on EMS management information systems. The Emergency Department (ED) definitions will consider those recommended by the Data Elements for Emergency Departments Workshop sponsored by CDC, NHTSA, and other public and private organizations. The hospital discharge definitions will be developed in consideration of existing requirements for Medicare and Medicaid payment.) The guide is currently being revised to include the attribute values. The guide may be obtained for a fee from ASTM.

Indicators of Market Acceptance

Approximately 2300 copies of the E31 standards have been distributed.

The Guide will be incorporated into the overall standards for the computerized patient record and is not designed to stand alone.

Level of Specificity

Same as information under VII.

Relationships with other Standards

There are no other similar Standards related to emergency medical care that have been developed by an authorized SDO. Defacto standards developed by the organizations listed in VI include data sets that have been developed during a formal consensus process (EMS), through broad participation by all stakeholders (ED) or through the payment of public funds (hospital). The definitions developed during these efforts will be incorporated into the next revision of E-1744.

Health Claim Status

Accredited Standards Committee X12 Insurance Subcommittee, Property and Casualty Task Group

ANSI Accreditation: X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

Health Care Claim Status Request (276), Health Care Claim Status Notification (277)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description of Standards

A) The objective of the Health Care Claim Status Request (276) - Health Care Claim Status Notification (277) is to determine the status of a submitted claim.

B)This transaction set pair can be used to request the status of a submitted claim by the health care provider using the Health Care Claim Status Request (276) and the payer to respond to these inquiries using the Health Care Claim Status Notification (277). The Health Care Claim Status Notification (277) can be used independently of the Health Care Claim Status Request (276) for the purposes of an unsolicited claim status from the payer to the health care provider as well as payer requests for additional information from the health care provider.

C)This transaction is used to support administrative reimbursement for health care products and services.

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has been developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard

A) The Health Care Claim Status Request (276) - Health Care Claim Status Notification (277) is not a guideline. However the X12 Insurance Subcommittee is currently developing an implementation guide.

B)The Health Care Claim Status Request (276) - Health Care Claim Status Notification (277) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in October of 1993 as Version 003040.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Health Care Claim Status Request (276) - Health Care Claim Status Notification (277).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

A) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

D)Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

Relationships With Other Standards

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

A) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

ASC X12 Claim Status (276/277) was approved October 1993. This transaction is used to determine the status of a submitted claim. The Implementation Guide is in development and is expected to be approved June 1997.

Referral Certification and Authorization

Accredited Standards Committee X12 Insurance Subcommittee, Property and Casualty Task Group

ANSI Accreditation: X12 was accredited as an ANSI accredited standards committee in 1979. Subsequent X12 procedure changes have required ANSI re-accreditation which was last granted in 1987.

Health Care Service Review Information (278)

Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.

Description Of Standard:

A) The objective of the Health Care Service Review Information (278) is used for referral certification and authorization.

B)This transaction set can be used to request and transmit demographic, utilization, certification and referral information. Includes no Utilization Management treatment information.

C)This transaction is used to support administration of health care services review between payers, providers, plan sponsors, and utilization review organizations..

D)This standard may be used from any operating system, network, or hardware platform.

E)The standard has be developed with widespread input from the health care industry incorporating all business needs into its functionality.

G)Standards. These standards are developed using a consensus process by the users in the health care industry.

H)The standards developed by ASC X12 may be translated to/from application systems using off the shelf translation software products which are used by all industries utilizing the ASC X12 standards.

Readiness of Standard:

A) The Health Care Service Review Information (278) is not a guideline. However the X12 Insurance Subcommittee is currently developing implementation guides for this transaction.

B)The Health Care Service Review Information (278) standard is fully implementable. The transaction set was approved as a Draft Standard for Trial Use (DSTU) in October of 1994 as Version 003050.

C)The standard can be obtained by contacting the Data Interchange Standards Association (DISA) at 703-548-7005.

E)There currently is only one implementation guide for the Health Care Service Review Information (278).

F)The implementation guides will specify the conformance to the standards.

G)Yes, conformance tools are commercially available.

H)The same tools used for conformance may also be used as testing tools.

J)Currently no enhancements are under development.

AA) This standard has been completed.

BB) This standard has been completed and undergoing industry implementation.

Indicator of Market Acceptance:

Level of Specificity:

A) The ASC X12 EDI transactions have been developed to meet the specific business needs identified by the standards developers and the health care industry.

B)See attached table of contents from the ASC X12 Insurance Committee's implementation guides.

D)ASC X12 maintains over one thousand internal code sets to support the standards. Along with the internal code sets the ASC X12 standards reference over 350 external code sources such as:

Current Procedural Terminology (CPT) Codes from American Medical Association
Current Dental Terminology (CDT) Codes from American Dental Association
International Classification of Diseases Clinical Modification - (ICD-9-CM) Diagnosis from U.S. National Center for Health Statistics.

H) There are too many code sets to describe here. Refer to the ASC X12 standards publication.

I)Internal code sets are included within the ASC X12 standards publications and implementation guides. When external code sets are referenced within these documents, the source where the code sets can be obtained is listed.

J)When possible, the implementation guides will either include the external code sets or provide further information on how to obtain the external code sets. Internal code sets are included within the implementation guides.

AA) Internal code sets are available to all users of the ASC X12 standards. Usage of the external code sets will vary by source and their ability to promote the usage of their code sets.

BB) ASC X12 internal code sets follow the same processes defined for the development and maintenance of the EDI transactions. External code lists are maintained by the external code source's internal development procedures.

Relationships With Other Standards:

B)See A).

C)See A).

D)Open communication in the development of the standards amongst the standards development organizations.

E)ASC X12 is the ANSI appointed standards development organization responsible for international EDI standards within the United States

F)None

Identifiable Costs:

A) None applicable. ASC X12 does not license it standards.

B)The cost of acquiring the ASC X12 standards publication varies depending upon the source of the publications. Currently they are available from:

Data Interchange Standards Association (DISA) 703-548-7005.
Washington Publishing Corporation 800-972-4334
Industry user groups and associations
The Internet (http://www.disa.org, http://www.wpc-edi.com)

A) The typical cost ranges from free to $415.00 for the full ASC X12 standards publication in either paper form or CD-ROM.

ASC X12 Healthcare Service Review (278) was approved February 1996. This transaction is used to request and transmit demographic, utilization, certification and referral information. The Implementation Guide is in development and is expected to be approved June 1997.

Supporting Standards

World Health Organization (WHO)

The WHO Collaborating Center for the Classification of Diseases for North America, located at the National Center for Health Statistics, is responsible for the coordination of all official disease classification activities in the United States relating to the ICD and its use, interpretation and periodic revision.

ANSI Accreditation:

The WHO Collaborating Center for North America is not an ANSI accredited body. The Collaborating Center is part of an international network of Collaborating Centers coordinated by the World Health Organization (WHO).

International Classification of Diseases, Ninth Revision (ICD-9)

International Classification of Diseases, Tenth Revision (ICD-10)

There are no separate templates for ICD-9 and ICD-10. On the following page, however, is a template developed by the National Center for Health Statistics (NCHS) for ICD-9 CM and ICD-10 CM.

National Center for Health Statistics (NCHS)

International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM)

International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM)

International Classification of Diseases Procedure Coding System (ICD-10-PCS)

Name of Standard: (1) International Classification of Diseases (ICD); Ninth Revision, Clinical Modification (ICD-9-CM) currently in use for morbidity reporting.

Contact For More Information

Marjorie S. Greenberg (MSG1@NCH11A.EM.CDC.GOV, 301-436-4253 Ext. 107, Fax 301-436-4233) or Donna Pickett (DFP4@NCH11A.EM.CDC.GOV, 301-436-7050 Ext.142, Fax 301-436 4233)

Description of Standard

The ICD-9-CM is the latest version of a classification that originated as the International List of Causes of Deaths, adopted in 1893 by the International Statistical Institute. The classification was revised at ten-yearly intervals and at the Sixth Revision Conference in 1948, the first undertaken by the WHO, its scope was extended to include non-fatal conditions and its use was recommended for morbidity statistics as well as for mortality. Subsequent revisions have enhanced its usefulness for morbidity applications by increasing the specificity of rubrics and by emphasizing manifestations of disease. Effective January 1979, the ICD-9-CM became the sole classification system used for morbidity reporting in the United States.

The ICD-9-CM, widely accepted and used in the health care industry, has been adopted by the federal government and the private sector for a number of purposes: data collection, quality of care analyses, resource utilization, research and reimbursement, and statistical reporting.

ICD-10-CM is currently under development, with a planned implementation date of October 1, 2000.

Readiness of Standard:

There are official coding guidelines used to instruct users on the classification. The ICD-9-CM classification and the guidelines are in the public domain and are available on CDROM from the Government Printing Office.

Is it implementable? (If so, is it fully or partially implementable?, explain)

The guidelines and classification are both in current use.

How can the standard be obtained?

The ICD-9-CM classification and the official national coding guidelines are in the public domain and are widely available. Both can be obtained through the Government Printing Office or through various publishers.

Does it require a separate implementation guide? (If so is the guide approved by the SDO?

Not applicable

Is there only one implementation guideline (or are there major options that impact compatibility)?

Not applicable

Is a conformance standard specified?

Not applicable

Are conformance test tools available?

Not applicable

Source of test tools?

Not applicable

If the standard is under development, what parts of it are ready now?

Work on the clinical modification (CM) of the International Classification of Diseases and Related Health Problems (ICD-10) is currently underway; it will undergo review in the Department of Health and Human Services in 1997. The final version is scheduled to be available by October 1, 1998.

What extensions are now under development?

What are the major milestones toward standards completion?

What are the projected dates for final balloting and/or implementation?

The planned implementation of ICD-10-CM, in conjunction with the Health Care Financing Administration's Procedure Coding System (ICD-10-PCS), is tentatively scheduled for October 1, 2000.

Please note any other indicators of readiness that may be appropriate.

Indicator of Market Acceptance

Both the classification and guidelines for it are in wide use with thousands of copies being used nationally for the submission of health insurance claims and for statistical data collection, performance measures, research, etc.

If the standard is an implementable standard, how many vendors, healthcare organizations and/or government agencies are using it?

N/A

Is this standard being used in other countries (which are they)?

The ICD-9 is used internationally for cause of death tabulation. The ICD-9-CM, the morbidity version of the ICD-9, is used in the United States primarily, but Australia and Israel use the ICD-9-CM for morbidity. These countries will be implementing the ICD-10 for both morbidity and mortality prior to the United States.

Please note any other relevant indicator of market acceptance within the public or private sector.

Many private vendors produce a variety of software and book products based on the ICD-9-CM.

Level of Specificity

If your standard is a guideline, how detailed is it?A.

The guidelines for the ICD-9-CM are broad guidelines for coding. They are not teaching manuals.

If it is an implementable standard, describe how detailed its framework is and its level of granularity.

N/A

Does the standard(s) reference or assume other standards to achieve more specificity?

N/A

If it includes or assumes code sets, which ones are they?

The ICD-9-CM is code set.

What is the description of the code set?

A medical statistical classification

How is the code set acquired?

Is there a users' guide or some other assistance available on the code set?

WHO published an official rule book for mortality rules. The U.S. publishes official guidelines for the use of the ICD-9-CM for morbidity applications.

If the code set is currently in use, what is the extent of its use (e.g., approximate number of users)?

All health care claims must list the ICD-9-CM diagnosis code.

If the code set is under development, what are the projected dates of completion and implementation?

N/A

Relationships with other standards

Volume 3 of ICD-9-CM is the classification of procedures used in the inpatient setting. CPT is used by physicians and hospital-based outpatient departments for the coding of procedures. The Health Care Financing Administration is developing ICD-10-PCS to replace Volume 3.

Identify specific standards reconciliation or coordination activities.

NCHS serves as the North American Collaborating Center for the Classification of Diseases (ICD) and for the International Classification of Impairments, Disabilities, and Handicaps (ICIDH). NCHS is responsible for the coordination of all official disease classification activities in the United States relating to the ICD and its use, interpretation and periodic revision. [See also III (A)].

The ICD-9-CM Coordination and Maintenance Committee is the process by which the classification (Volumes 1, 2, and 3) is maintained and updated each year. The Coordination and Maintenance process ensures stability of the classification system and it s comparability with its parent system, ICD-9. Established in 1985, this Committee was formed to provide a public forum to discuss possible updates and revisions to the ICD-9-CM.

What portion of the specification and functionality is affected by this coordination? N/A

What conditions are assumed in order for this coordination to be effective?

All requests for modification are handled through the ICD-9-CM Coordination and Maintenance Committee. The Committee discusses such topics as the need to update the ICD-9-CM due to changes in medical technology, the need to provide greater specificity in classifying diagnoses (adding clinical detail and accuracy), and the need to correct inaccuracies in the classification. No official changes are made without being brought before this committee.

Although the Committee is a federal committee, suggestions for modifications come from both the public and private sectors, and interested parties are asked to submit recommendations for modification prior to a scheduled meeting.

Modifications are not considered without the expert advice of clinicians, epidemiologists, and nosologists (both public and private sectors).

Is this standard consistent with international standards? If so, which standards?

Yes. The ICD-9-CM is consistent with ICD-9, and ICD-10-CM similarly will be consistent with ICD-10.

What gaps remain among related standards that should be addressed?

Describe what is being done to address these gaps.

Identifiable Costs

Notes: ICD-10-CM

A. Please indicate the cost or your best estimate for the following:

- Cost of licensure

None, the classification is in the public domain

Cost of acquisition (if different from licensure)
Cost/timeframes for education and training/implementation

A two-year timeframe is planned to allow for training and system modifications and software development for the transition to ICD-10-CM.

- Please note any other cost considerations.

American Medical Association (AMA)

Physicians' Current Procedural Terminology (CPT)

Physicians' Current Procedural Terminology , Fourth Edition (CPT) is a listing of descriptive terms and identifying codes for reporting medical services and procedures. The purpose of the terminology is to provide a uniform languages that will accurately describe medical, surgical and diagnostic services, and will thereby provide an effective means for reliable nationwide communication among health professionals, patients and third-parties. The first edition of CPT appeared in 1966.

Developing Organization

CPT was created and is authored by the American Medical Association (AMA).

ANSI Accreditation

The AMA is a member of ANSI. CPT is copyrighted by the AMA.

Names

Physicians' Current Procedural Terminology, Fourth Edition (CPT)

Description

CPT contains the American Medical Association's listing of descriptive terms and identifying codes. It also contains numeric modifiers, notes, guidelines and an index designed to provide explanatory information and facilitate the correct usage of the coding system.

Contact For More Information

Celeste G. Kirschner

Director, Coding and Nomenclature

American Medical Association

515 N. State Street

Chicago, IL 60610

Phone: 312-464-5932

Fax: 312-464-5849

Indicator of Market Acceptance

CPT is used as the reporting mechanism by physicians and many other health professionals in the United States. It is the coding system used by Medicare and virtually all third party payors, including workers compensation and Medicaid. Hospitals use CPT codes to report outpatient service to Medicare. Its usage internationally is growing, particularly by United States companies that have international components. CPT was recently selected as the coding system of choice by the Medical Association of South Africa. CPT is Level I of HCPCS (HCFA Common Procedure Coding System).

Level of Specificity

CPT contains over 7300 codes to describe medical and surgical procedures. CPT is divided into 6 major sections, including Evaluation and Management Services, Anesthesia, Surgery, Radiology, Pathology and Medicine. The section heads, subheads, and titles provide an implicit hierarchy. The Surgery section is subdivided anatomically. The Medicine Section is divided by medical subspecialties. A series of two digit modifiers are also included to make the coding system more specific, to allow the reporting of a procedure under specific circumstances. For example, modifiers may be used to describe the use of assistant surgeons, a bilateral procedure, or a return to the operating room during the postoperative period.

Maintenance of CPT

CPT is authored by the American Medical Association. The CPT Editorial Panel is made up of 15 physicians, 10 nominated by the AMA and one each nominated by the Blue Cross and Blue Shield Association, the Health Insurance Association of America, the Health Care Financing Administration and the American Hospital Association. A non-physician representative of the Health Care Professionals Advisory Committee (HCPAC) also serves as a member of the Panel.

The Panel's Executive Committee includes the chairman, the vice chairman and three other members of the Panel, as elected by the entire Panel. One of the three members-at-large of the executive committee must be a third-party payer representative. The AMA provides staff support for the CPT Editorial Panel and appoints a staff secretary.

Supporting the Editorial Panel in its work is the CPT Advisory Committee. Committee members are primarily physicians nominated by the national medical specialty societies represented in the AMA House of Delegates. The Health Care Professional Advisory Committee allows for participation of organizations representing limited license practitioners and allied health professionals. Most members of the Advisory Committee serve as Chair of a specialty society committee and thus form a network of approximately 1000 physicians and other health professionals actively working to maintain the clinical integrity of the system.

Readiness

Current Procedural Terminology (CPT) is available in the following print and electronic formats:

1 volume spiral-bound edition;

1 volume soft bound edition;

1 volume spiral-bound Professional edition;

1 volume three-ring bound Professional edition

Electronic versions in EBCDIC or ASCII for full and short description magnetic tape formats; also available in diskette format, short or long description which can be used with any software that allows import of an ASCII file. A CD-ROM version, that includes CPT, is available for 1997.

In addition, CPT is currently licensed to many software system vendors and publishing companies.

Identifiable Costs

CPT is available at low cost through the AMA or through the AMA's licensing activities. CPT can be purchased from the AMA in print formats for as low as $38. CPT can be licensed from the AMA in electronic formats for as low as $149. Licenses are granted to those that distribute CPT in print and electronic formats. Licenses for CPT in print products are granted for as low as $10 per product. Licenses for CPT in electronic products are granted for $50 per product license with a minimal additional user fee for multi-user versions. The codes are revised yearly.

College of American Pathologists

Systematized Nomenclature of Human and Veterinary Medicine (SNOMED) International:

SNOMED® International is recognized throughout the world as a comprehensive, multiaxial nomenclature classification system created for the indexing of the entire medical vocabulary, including symptoms, diagnoses, and procedures. Its design provides the framework for representing the activities, observations, and diagnoses found in the medical record and coding them into a computer-processable form. The structure of SNOMED® International, together with its ability to index and retrieve comprehensive patient information, makes this system a strong candidate for the standard vocabulary and data model that is essential for the computer-based patient record.

Developing Organization

SNOMED® International is owned and managed by the College of American Pathologists (CAP). The CAP is a national medical specialty society serving more than 15,000 physician members and the laboratory community in the United States and internationally. College fellows elect a 12-member Board of Governors and three officers who serve as the governing body. Supporting the Board of Governors are a hierarchy of Councils, Commissions and Committees. These groups develop and oversee College and projects and programs. Administrative support and overall coordination and implementation of College programs is provided by staff located at the CAP Headquarters office in Northfield, Illinois.

The Council on Practice and Education is responsible for the operation of several CAP committees including the SNOMED® Editorial Board (SEB). Through the work of the SNOMED® Editorial Board chaired by College member, Roger A. Cote, MD, new terms and codes are continuously added to the SNOMED® vocabulary, with at least two updates provided annually. Via relationships with other medical specialty societies, the SEB is responsible for the design, development and maintenance of the SNOMED® vocabulary.

ANSI Accreditation

SNOMED® International is not a standard. It is a registered trademark owned and copyrighted by the College of American Pathologists. As an organization, the CAP is not directly involved in standards development.

Name:

SNOMED® International

Contact For More Information:

Karen Kudla

SNOMED Program Manager

College of American Pathologists

325 Waukegan Road

Northfield, IL 60093

Phone: 847-832-7446

Fax: 847-832-8170

E-Mail: kkudla@cap.org

Description

SNOMED® International is a comprehensive, multiaxial nomenclature classification system created for the indexing of the entire medical vocabulary, including signs and symptoms, diagnoses, and procedures. Introduced in September 1993 and traceable to its roots in the early 1960s as the Systematized Nomenclature of Pathology (SNOP), SNOMED® is being rapidly accepted worldwide as the standard for indexing medical record information. It has been translated from English into 12 other languages. The American Veterinary Medical Association and the American Dental Association have recognized SNOMED®'s strength as a comprehensive nomenclature and have endorsed its use. In addition, the American College of Radiology/National Equipment Manufacturers Association will be using a subset of SNOMED® in their Digital Imaging and Communications in Medicine standard (DICOM).

Of the major factors required for successful computer-based patient record development, a common medical vocabulary for use in records and standards for integrating multiple and disparate sources of information are critical elements. The eleven modules of the current version of SNOMED® contain more than 144,000 terms and term codes, with new updates provided to SNOMED® users at least twice per year. Many electronic records proponents are concluding that SNOMED® International offers the best prospects for a standardized vocabulary.

Readiness

SNOMED® International is available in the following print and electronic formats: four-volume hard-bound printed set electronic version on CD-ROM in a tab-delimited ASCII format

In addition, the following information systems vendors are licensed to distribute SNOMED® International:

ACT Medisys

ANATROL

Antrim Corporation

Cerner Corporation

Citation Computer Systems

Collaborative Medical Systems

Computer Trust Corp.

Dentente Corporation

Dynacor Inc.

Dynamic Healthcare Tech, Inc.

Galen Group, Ltd.

Health Data Science Corp.

Healthpoint GP

Kaiser Permanente

Laboratory Consulting, Inc.

MedicaLogic

Orbis Systems

Psyche Systems

Science Applications Int'l Corp.

Sunquest Information Systems

Univ. Of Alabama at Birmingham

Indicator of Market Acceptance

SNOMED® International is widely used and distributed throughout the United States and worldwide. SNOMED® International was ranked on top in a study conducted by the Computer-based Patient Record Institute (CPRI) which evaluated all available coding systems for their ability to be used as a common medical terminology.

SNOMED® International has been translated into Greek, Chinese, Czech, French, German, Hungarian, Italian, Japanese, Norwegian, Portuguese, Russian, Slovakian, and Spanish.

The American Veterinary Medical Association and the American Dental Association have recognized SNOMED®'s strength as a comprehensive nomenclature and have endorsed its use. In addition, the American College of Radiology/National Equipment Manufacturers Association will be using a subset of SNOMED® in their Digital Imaging and Communications in Medicine standard (DICOM).

Level of Specificity

SNOMED® International is a detailed coded nomenclature and classification of preferred medical terms and concepts, consisting of more than 144,000 terms and term codes divided into eleven linked hierarchical modules: Topography; Morphology; Function; Living Organisms; Chemicals, Drugs, and Biological Products; Physical Agents, Activities and Forces; Social Context; Diseases/Diagnoses; Procedures; and general Linkage Modifiers

Identifiable Costs

SNOMED® International is available to individuals for a single fee.

In addition, licenses are granted to distribute SNOMED® International for commercial or institutional use. Licensing fees are determined by the number of users per site, and are renewed annually

American Dental Association (ADA)

Current Dental Terminology (CDT)

The ADA's Current Dental Terminology (CDT) is a manual that is intended to be of practical use to those in dental offices who deal with patients' dental plans, by providing assistance in accurately reporting dental treatment and procedures to third-party payers. The document used for reporting treatment is the American Dental Association's Code on Dental Procedures and Nomenclature which is contained in the CDT. The Code is structured so that it can be used by dentists and/or their staff to report care provided to patients. Within CDT, many code numbers are accompanied by additional information or explanations to help clarify how the codes should be applied.

Developing Organization

CDT is maintained by the American Dental Association through its Council on Dental Benefit Programs.

ANSI Accreditation

CDT is not a standard. It is a copyrighted document of the American Dental Association. However, as an organization, the ADA is directly involved in standards development as sponsor and secretariat of the ASC MD156.

Name

Current Dental Terminology (CDT)

Contact For More Information

Thomas Conway

American Dental Association

211 East Chicago Avenue

Chicago, Illinois 60611

Phone: 312/440-2752

Fax: 312/440-2520

eMail: conwayt@ada.org

Description

The CDT contains the American Dental Association's codes for dental procedures and nomenclature and is the nationally accepted set of numeric codes and descriptive terms for reporting dental treatments. CDT also contains a description of the ADA Dental Claim Form; clinical and dental benefit terminology; and a description of the tooth numbering system.

Readiness

CDT is available in the following print and electronic formats:

1 volume spiral bound manual;

Electronic version in MS DOS diskette, an ASCII file, and a database program. Must have IBM compatible computer with at least 512K RAM.

In addition, CDT is currently licensed to many practice management software systems vendors.

Indicator of Market Acceptance

CDT is used as a reporting tool by all practicing dentists in the United States. It is also used by third-party payers for claims processing. The ADA's procedure codes are also included in the HCFA Procedural Coding System (HCPCS) as the dental (D) codes.

Level of Specificity

CDT includes the ADA's Code on Dental Procedures and Nomenclature consisting of over 400 distinct dental procedures. The codes and nomenclature have been divided into 12 categories of service: Diagnostic, Preventive, Restorative, Endodontics, Periodontics, Prosthodontics; removable, Maxillofacial Prosthetics, Implant Services, Prosthodontics;fixed, Oral Surgery, Orthodontics, and Adjunctive General Services.

Identifiable Costs

CDT is available to individuals for $29.95. Licenses are granted for $500 for a five year period to those that distribute CDT in software systems, continuing education programs and other products. The codes are revised on a five-year cycle.

Advisory Committee on Dental Electronic Nomenclature Indexing and Classification (ACODENIC)

Microglossary of SNOMED for Dentistry

The American Dental Association established this advisory committee to develop standardized clinical terminology for the dental profession in an electronic environment. All segments of the health care process must be addressed, such as patient history, presenting conditions, physical findings, services, risk factors, outcomes, or other important details. In addition, all facets of health care, independent of profession, discipline or specialty must be included in standardized terminology. Therefore, the Advisory Committee has engaged in the difficult task of creating a clinical terminology and coding system which will provide the dental profession with varying degrees of utility.

In order to accomplish this charge, the American Dental Association recognized the strength of the SNOMED International system and began working with the College of American Pathologists on the development of a microglossary of SNOMED for dentistry. The ADA's Microglossary is currently in development and is expected to be completed in 1997. The ADA is participating with a sample of terms from the Microglossary in the Large Scale Vocabulary Test conducted by the National Library of Medicine (NLM). The proposed dental terms are being tested against the NLM's Unified Medical Language System (UMLS). The goal of the NLM Large Scale Vocabulary Test is to contribute to an understanding of the controlled terminology that will be needed for electronic health care systems, whether these are for direct patient care, clinical or health services research, or public health surveillance. The Test seeks to determine the extent to which a combination of existing health-related terminologies cover vocabulary needed in health information systems. The terminology that the participants submit to should provide the basis for realistic resouce estimates for developing and maintaining a comprehensive "standard" health vocabulary that is based on existing terminologies. In addition, the ADA's dental terms were recently used to update the dental terminology for the NLM's 1997 Medical Subject Headings (MeSH). MeSH is the vocabulary used to index articles in the National Library of Medicine's MEDLINE database and its derivative publications, including Index Medicus and the American Dental Association's Index to Dental Literature.

The ADA's procedure codes will also be mapped to the SNOMED terms in the Dental Microglossary.

3) Comprehensive Glossary of Dental Terms - Standardized terminology must have explicit definitions. A collective guide is important for consistent interpretation of terms by the profession and aggregate data analysts. Therefore, the American Dental Association's ACODENIC is also developing a comprehensive glossary of dental terms. In addition to defining the terms in the Microglossary, the definitions will be useful for the NLM's MeSH and UMLS knowledge sources.

Center for Nursing Classification, University of Iowa College of Nursing

Nursing Interventions Classification (NIC)

The Nursing Interventions Classification (NIC) is a comprehensive, standardized language describing treatments that nurses perform in all settings and in all specialties. NIC interventions include both the physiological (e.g. Acid-Base Management) and the psychosocial (e.g. Anxiety Reduction). There are interventions for illness treatment (e.g. Hyperglycemia Management), illness prevention (e.g. Fall Prevention), and health promotion (e.g. Exercise Promotion). Interventions are for individuals or for families (e.g. Family Integrity Promotion). Indirect care interventions (e.g. Emergency Cart Checking) and some interventions for communities (e.g. Environmental Management: Community) are also included.

Each NIC intervention has a unique number which can facilitate computerization. NIC interventions have been linked with NANDA nursing diagnoses and the Omaha System problems and are in the process of being linked with Nursing Outcomes Classification (NOC) patient outcomes . There is a form and a review system for submitting suggestions for new or modified interventions.

Developing Organization

The classification work is part of the Center for Nursing Classification at the University of Iowa College of Nursing. Research methods used to develop the Classification include content analysis, expert survey, focus group review, similarity analysis, hierarchical cluster analysis, multidimensional scaling, and field testing. More than 40 national nursing organizations have reviewed NIC and assisted with intervention development and validation and taxonomy construction and validation. The research, conducted by a large team of investigators, has been partially supported for the past seven years by the National Institute of Nursing Research, National Institutes of Health.

ANSI Accreditation

NIC is not a standard. It is a standardized language organized in a 3 level taxonomic structure for ease of use. It is published by Mosby Year Book who owns the copyright. Neither the University of Iowa which produces NIC nor Mosby is involved in the development of standards.

Name

Nursing Interventions Classification (NIC)

Contact For More Information

William Donahue, Program Associate

Center for Nursing Classification

College of Nursing

The University of Iowa

Iowa City, IA 52240

Phone: 319-335-7054/7051

Fax: 319-335-7051

E-mail william-donahue@uiowa.edu

OR classification-center@uiowa.edu

Description

NIC contains 433 interventions each with a definition and a detailed set of activities that describe what it is a nurse does to implement the intervention. Each intervention is coded with a unique number. The interventions are organized in 26 classes and 7 domains. NIC facilitates the implementation of a Nursing Minimum Data Set. The use of NIC to plan and document care will facilitate the collection of large data bases which will allow us to study the effectiveness and cost of nursing treatments. The use of standardized language provides for the continuity of care and enhances communication among nurses and among nurses and other providers. NIC provides nursing with the treatment language that is essential for the computerized health care record. The domains and classes provide a description of the essence of nursing. NIC is helpful in representing nursing to the public and in socializing students to the profession. The coded interventions can be used in documentation and in reimbursement. The language is comprehensive and can be used by nurses in all settings and in all specialties.

Readiness

NIC is available in the following print publication: Iowa Intervention Project (1996). Nursing Interventions Classification (NIC), 2nd ed. St. Louis: Mosby Year Book.

The following vendors are licensed to distribute NIC: ERGO, Mission, Kansas, 319: 384-3377.

JRS Clinical Technology, Stamford, CT, 203:322-1823.

In addition, there are numerous journal publications about NIC that detail aspects of development or use. An anthology of NIC publications and an implementation manual containing helpful guides and forms related to implementation from selected user agencies are available from the Center for Nursing Classification.

Indicator of Market Acceptance

NIC is recognized by the American Nurses' Association and is included in the National Library of Medicine's Metathesaurus for a Unified Medical Language. Both the Cumulative Index to Nursing Literature(CINAHL) and Silver Platter have added NIC to their nursing indexes. NIC is included in the Joint Commission on Accreditation for Health Care Organization's (JCAHO) as one nursing classification system that can be used to meet the standard on uniform data. The National League for Nursing has made a 40 minute video about NIC to facilitate teaching of NIC to nursing students and practicing nurses. Many health care agencies are adopting NIC for use in standards, care plans, and nursing information systems; nursing education programs are beginning to use NIC; authors of major texts are beginning to use NIC to discuss nursing treatments; and researchers are using NIC to study the effectiveness of nursing care. Interest in NIC has been demonstrated in several other countries, notably, Canada, Denmark, Iceland, Japan, Korea, Switzerland, and The Netherlands.

Level of Specificity

NIC groups approximately 13,000 nurse activities into 433 standardized intervention terms each with a unique code. NIC has numerous uses including in care planning, documentation, standards construction, critical paths, competency evaluation, job descriptions, curriculum and course syllabus construction. The use of NIC in nursing information systems allows for the collection of standardized data to be used in effectiveness research and in determining the costs of nursing.

Identifiable Costs

NIC is available in book form to individuals for a single fee, which in January 1997 was $35.95. In addition, licenses are granted to distribute NIC for commercial or institutional use by contacting Robin Carter at Mosby Year Book, 800:325-4177, ext. 4412 (robin.carter@mosby.com) Licensing fees are determined by the number of users per site and are renewed with each new edition of the book (approximately every 4 years). Permission to use NIC in printed material can be obtained by contacting Liz Fathman at Mosby Year Book, 800:325-4177, ext. 4866 (liz.fathman@mosby.com).

International Conference on Harmonization

Representation includes: US Food and Drug Administration

European Union

Japan's Ministry of Health and Welfare

PhRMA (Pharmaceutical Research and Manufacturers of America)

JPMA (Japanese Pharmaceutical Manufacturers Association)

EFPIA (European Federation of Pharmaceutical Industries

Association)

ANSI Accreditation

Not ANSI Accredited

International Medical Terminology (IMT)

Contact For More Information

Kathryn A. Huntley

Standardized Nomenclature Program Manager

Food and Drug Administration

HF-21 Rm 16B-45

5600 Fishers Lane

Rockville, MD 20857

(301) 594-6491 (voice)

(301) 594-0829 (fax)

khuntley@bangate.fda.gov

Description of Standard

The International Medical Terminology (IMT) is a medical terminology designed to support the classification, retrieval, presentation, and communication of medical information throughout the medical product regulatory cycle. The foundation of the IMT is the Medical Dictionary for Drug Regulatory Affairs (MEDDRA) developed by the UK Medicines Control Agency (MCA) in its Adverse Drug Reactions On-line Information Tracking System (ADROIT).

The IMT is superior to other medical terminologies in its scope, size, and specificity. Included in the IMT are terms describing diseases, diagnoses, signs, symptoms, therapeutic indication names, and qualitative results of investigations (e.g. laboratory tests, radiological studies), medical and surgical procedures, and terms describing medical, social, and family history. The IMT consists of a five level hierarchy, starting with 26 System Organ Classes (SOCs), that represent the highest level groupings of the terminology. Including all levels it contains approximately 40,000 terms. The Preferred term (PT) is the internationally agreed upon level at which regulatory information is to be exchanged. The IMT contains approximately 8,800 PTs, vastly improving the specificity of exchanged regulatory information over previous thesauri.

The current version of the IMT is available in multiple formats:

ASCII text files
Access Database
On the FDA's Standardized Nomenclatures Database (SND).
The thesaurus is also available in paper format.

Readiness of Standard

A.This is not a guideline

B.The implementable version will be a combination of products, the terminology and a maintenance organization. The terminology will be completed March 1997 the maintenance organization will be operational December 1997.

C.The 1.5 version of the terminology is obtainable through the FDA at no cost. The final version will be available through the maintenance organization.

D.There will be a user manual, help desk support etc. through the maintenance organization.

E.There will be a single version, multiple translations i.e. Japanese, Spanish, French and German to begin.

F.No

G.No.

H.None

I.The 1.5 version of the terminology is available for review. The FDA has rewritten 8 of the 26 System Organ Classes. The structure of terminology will not change just the terms populating the various levels below the System Organ Class level.

J.The final review of the US proposals, and the review and repopulation of the mid-levels to aid in data aggregation and display as well as the assignment of codes.

AA. ICH Expert Working Group meeting the first week of January 1997, the presentation to the ICH Steering Committee the first week of March 1997.

BB. ICH Steering Committee meeting March 1997, Selection of the Maintenance Organization July 1997, Terminology available December 1997

CC. none

Indicator of Market Acceptance

A. 308 copies of Version 1.0 and 386 copies of Version 1.5 have been distributed in North America to date. There are also distribution points in Japan and Europe.

B. none currently

C.A closely related product is currently being used in the ADROIT system of the UK's Medicines Control Agency.

D.The development of this standard under the ICH umbrella is very important in that once agreed upon by the regulators they are committed to implementing it. That means the regulatory authorities of Europe, United states and Japan will implement therefore the industries in those regions will also implement it. It is being reviewed by the World Health Organization for use by WHO countries and also by the WHO Drug Monitoring Program in Upsala Sweden.

Within the US, the National Cancer Institute's Cancer Therapy Evaluation Program is planning to adopt this terminology for use in collecting cancer clinical trial data.

Level of Specificity

(A) The IMT is not a guideline.

(B) The IMT's hierarchy consists of five levels and was designed to facilitate both coding and retrieval of medical information. These levels include System Organ Class (SOC), the broadest term; High Level Group Term (HLGT); High Level Term (HLT); Preferred Term (PT); and Lowest Level Term (LLT). Concepts in the vocabulary are grouped based upon inclusive relationships. The hierarchy can be used to locate concepts at a desired degree of specificity.

The following is a description of the IMT hierarchical levels from the most specific, or granular, to the broadest.

LLT - The Lowest Level Terms provide the most specific terms in the vocabulary. The LLTs are not used for reporting, but help define the scope of the preferred term to which they are linked, and provide a collection of terms used in verbatim reports to describe adverse experiences or medical history. In the IMT, the LLTs contain both synonyms and quasi-synonyms. In a strictly controlled thesaurus, the finest division of vocabulary consists only of synonyms and lexical variants (spelling and word order variations). In practical medical coding vocabularies, however, this rule is not rigorously enforceable. Terms that have similar meanings, or which describe similar concepts, are often grouped under the same preferred term.

PT - The preferred term is the internationally agreed upon level at which regulatory information is to be exchanged. The PT represents a single, unambiguous, clinical concept. Terms at this level should be at a level of specificity to code regulated indications and to capture signals of specific significant adverse events. The LLTs under each PT indicate the intended scope of the term. A PT may be linked to one or more SOCs, but is assigned to only one Primary SOC under which it is grouped for cumulative data outputs to prevent duplicate counting.

HLT - A High Level Term groups together PTs which are related by anatomy, pathology, physiology, etiology or function for data retrieval and presentation purposes only. An HLT may be linked to one or more HLGT(s) or SOC(s).

HLGT - High Level Group Terms, like the HLTs, are broad concepts used for grouping clinically related terms for data retrieval and presentation. They may be linked to one or more SOC(s).

SOC - The System Organ Class represents the broadest collection of concepts for retrieval in the vocabulary. SOCs group concepts according to anatomical or physiological system, e.g. Gastrointestinal disorders; body organ, e.g. Disorders of the eye; mechanism, e.g. Infections and infestations; and purposes, e.g. Surgical and medical procedures.

It does not reference other standards.

FDA recommendation for the IMT coding scheme (this is only a recommendation and has not been finalized):

IMT use a sequential numbering (non-expressive, numeric code) method with a length of at least 8 for the terminology coding scheme.
Unique codes be applied to all terms across all categories.
After term changes to MEDDRA Version 1.5 are complete, a numeric code be applied to terms sequentially by alphabetical order as the last step in the development process for the IMT.
Use 10000001 as the first code applied to the first term sorted alphabetically in order to enforce a length of 8.

User Guide to be developed.

Schedule for IMT Implementation:

ICH approval - 3/97
Wide Availability - 12/97

Relationships With Other Standards

Terms from other commonly used medical thesauri have also been added to the IMT to make the transition from these other vocabularies to the IMT easier. These include the Food and Drug Administration Coding Symbols for a Thesaurus of Adverse Reaction Terms (COSTART), the World Health Organizations Adverse Reaction Terminology (WHO-ART), the International Classification of Diseases, version 9, Clinical Modifications (ICD-9-CM), the Japanese Adverse Reaction Thesaurus (JART), and the Hoechst Adverse Reaction Terminology (HARTS).

There are some medical concepts that are not included in the IMT. The following areas are considered outside the scope of this regulatory terminology:

Drug product terminology (i.e., complete listing of drug names);
Equipment, device or diagnostic product terminology (i.e., complete listing of medical devices, diagnostic equipment or in vitro diagnostic products);
Device failure terminology;
Clinical trial study design terminology;
Patient demographic terminology;
Qualifiers that refer to populations rather than individual patient results (e.g., rare, frequent);
Numerical values associated with investigations or observations (e.g., numeric laboratory test results)
Descriptors of severity (e.g., severity, mild).

Identifiable Costs

Cost of licensure is yet undetermined but the goal is to make the internationally maintained terminology as inexpensive and readily available as possible. In all regions consideration must be given to the developing nations under WHO as well as the start up and specialty industries throughout the world.

Health Care Claim Adjustment Reason Code/Health Care Claim Status Code Committee

ANSI Accreditation

Health Care Claim Adjustment Reason Codes and Health Care Claim Status Codes are considered external codes by ANSI ASC X12, and the Committee is not an SDO. The committee was formed in 1994 by industry representatives to X12, to create a mechanism for management of the codes used for the enumerated transactions.

Health Care Claim Adjustment Reason Codes

A series of standard alphanumeric codes, and messages, that detail the reason why the payer made and adjustment to the health care claim payment. These codes are used in the ANSI ASC X12 Claim (837) and Payment/Advice (835) transaction sets, and in the UB92 and NSF flat file claim and associated payment transactions.

Developing Organization

These codes are developed and maintained by the Health Care Claim Adjustment Reason Code/Claim Status Code Committee. This committee is comprised of one voting member from the following groups:

American Dental Association
American Hospital Association
American Medical Association
Blue Shield Plans
Blue Cross Plans
Commercial Health Insurance Carriers
Health Care Financing Administration - Medicaid
Health Care Financing Administration - Medicare
Health Insurance Association of America
National Council for Prescription Drug Programs
Property and Casualty Insurance Industry
American Association of Health Plans
Association For Electronic Healthcare Transactions (AFHECT)
One X12N workgroup co-chair from each affected workgroup (835, 837, 276/277)

The committee is responsible for maintaining the quality and business applicability of the code lists for an electronic data interchange environment. It's objective is to meet the business needs of the user community while eliminating redundancy in the codes. The Blue Cross and Blue Shield Association serves as Secretariat for the committee.

Contact for more information:

Frank Pokorny

Manager, Electronic Commerce and National Standards

Blue Cross and Blue Shield Association

676 North St. Clair

Chicago, IL 60611

Phone: 312-330-6223

Fax: 312-440-5674

E-mail: us993fjp@ibmmail.com

Description

A series of approximately 175 standard numeric and alphanumeric codes, and messages, that detail the reason why the payer made and adjustment to the health care claim payment. An individual code may be up to three characters long. A set of that apply equally to services, products, drugs and equipment. Codes for Medicare A have the letter "A" in the first position; Medicare B show the letter "B".

Readiness

Codes are currently in use and revisions are made thrice annually, effective on February 28, June 30 and October 31 of each year. The most recent version of the code list will be able to be applied to all versions of the ASC X12 Draft Standards, except as limited within the code lists.

Health Care Claim Adjustment Reason Codes and the Health Care Claim Status Codes are available in electronic and print formats:

Electronic file -

Washington Publishing Company World Wide Web Site

http://www.wpc-edi.com

Paper Copy -

Blue Cross and Blue Shield Association

Inter-Plan Teleprocessing Service

676 North St. Clair

Chicago, IL 60611

Indicator of Market Acceptance

Health Care Claim Adjustment Reason Code is currently in wide use within the health care community for both EDI and flat file transactions, and for both private/commercial and government programs. Codes are developed and agreed upon by committee action

Level of Specificity

A set of approximately 175 numeric and alphanumeric codes that apply equally to services, products, drugs and equipment. Codes for Medicare A have the letter "A" in the first position; Medicare B show the letter "B". Codes are available on lists in simple ascending order, and by functional groups: treatment; insurance procedural; insurance contractual; other.

Identifiable Costs

Code lists are available at no charge from either the Washington Publishing Web Site or the Blue Cross and Blue Shield Association.

Health Care Claim Status Codes

A series of standard alphanumeric codes, and messages, that detail the status of a claim that has been submitted for payment. These codes are used in the ANSI ASC X12 Claim Status Response (277) and Payment/Advice (835) transaction sets, and in the flat file transactions associated with the UB92 and NSF formats.

Description

A composite data element comprised of the following aphanumeric and numeric data elements:

Health Care Claim Status Category Code -- Mandatory
Health Care Claim Status Code -- Mandatory
Entity Identfier Code -- Optional - Used when an entity is associated with the Health Care Claim Status Code

An individual code may be up to seven (7) characters long.

Readiness

Health Care Claim Adjustment Reason Code and Health Care Claim Status Codes are available in electronic and print formats:

Electronic file -

Washington Publishing Company World Wide Web Site

http://www.wpc-edi.com

Paper Copy -

Blue Cross and Blue Shield Association

Inter-Plan Teleprocessing Service

676 North St. Clair

Chicago, IL 60611

Indicator of Market Acceptance

Health Care Claim Status Code is currently in wide use within the health care community for both EDI and flat file transactions, and for both private/commercial and government programs. Codes are developed and agreed upon by committee action.

Level of Specificity

Health Care Claim Status Category Code is a 2 position alphanumeric field that is mandatory. These codes are divided into six broad categories:

supplemental messages
acknowledgments
pending
finalized
requests for additional information
general questions

Health Care Claim Status Code is a three position numeric code that is mandatory. There are approximately 450 codes currently available. Each code's description is understood to automatically refer to service, procedure, treatment, supply, test, visit and medication.

Entity Identfier Code is a two position alphanumeric field that is optional - Used when an entity is associated with the Health Care Claim Status Code

An individual code may be up to seven (7) characters long.

Identifiable Costs

Code lists are available at no charge from either the Washington Publishing Web Site or the Blue Cross and Blue Shield Association.

Logical Observation Identifier Names and Codes (LOINC) Consortium

Logical Observation Identifier Names and Codes (LOINC)

Developing Organization

LOINC is a consortium of laboratories, system vendors, hospitals, and academic institutions organized by the Regenstrief Institute and supported by grants from the John A. Hartford Foundation of New York, the Agency for Health Care Policy and Research, and the National Library of Medicine.

ANSI Accreditation

LOINC is a consortium, not a formal SDO. However, it is designed to work in conjunction with the HL7/ASTM and CEN observation (result) messages.

Name

Logical Observation Identifiers Names and Codes (LOINC).

Contact For More Information

Stan Huff <coshuff@ihc.com>

36 South State St, Suite 800

Salt Lake City, UT 84111

Phone: 801 442 4885

Fax: 801 263 3657

Clem McDonald <clem@regen.rg.iupui.edu>

Regenstrief Institute

Indiana University School of Medicine

1001 W. 10th St. 5th fl RHC

Indianapolis, IN 46202

Phone: 317 630 7070

Fax: 317 630 6962

To obtain the Users' Guide, and full LOINC database in report, ASCII text, or dBase formats:

http://www.mcis.duke.edu/standards/termcode/loinc.htm

DESCRIPTION

(1) Laboratory LOINC

LOINC concentrates on the identification and naming of test and clinical observations, things like diastolic blood pressure, serum glucose, blood culture, or "heart physical exam." LOINC does not deal formally with the values reported for these observations/measurements, some of which are valued as numbers, and some of which are valued as codes or text. Most of these coded answers are expected to be provided from other sources, such as SnoMed, CPT4, ICD9CM, and other code systems.

The laboratory component of the data base is fairly complete with respect to the tests listed in Table 1.

Table 1 Subject matter covered by Lab LOINC

Chemistry

Coagulation

Hematology

Microbiology including cultures, microscopic examinations, RNA and DNA probes,

Antibody and antigen measures

Antimicrobial susceptibility testing

Toxicology and drug testing

Surgical pathology

Blood banking

Blood counts and Urinalysis

Fertility

Each record in the LOINC data base identifies one distinct observation. Each record contains the LOINC identifier, which is a meaningless number with a self check digit, and a multi-part formal name which includes component (e.g., glucose, intra-arterial diastolic), type of property (e.g., mass concentration, pressure), timing (e.g., point measure 24 hour), system (e.g., serum, brachial artery), scale (e.g., quantitative, qualitative), and method (e.g., dip stick, ausculatory).

In addition, the data base contains related names (near synonyms), molecular weights, indicators of terms that have been retired, a pointer to the terms that replace them, and related codes from other systems, e.g., the chemical abstract code for chemical substances.

With the data base comes a manual that provides formal rules for naming the parts of an observation, and a full definition of the data base.

LOINC does not yet include names for order sets, e.g., CHEM12.

Figure 1 Example Laboratory LOINC codes

1919-0 ASPARTATE AMINOTRANSFERASE:CCNC:PT:FLU:QN

3255-7 FIBRINOGEN:MCNC:PT:PPP:QN:COAG

4531-0 COMPLEMENT TOTAL HEMOLYTIC:PT:BLD:QN

9782-4 ADENOVIRUS SP IDENTIFIED:PRID:PT:XXX:QL:ORGANISM SPECIFIC CULTURE

4991-6 BORRELIA BURGDORFERI DNA:ACNC:PT:XXX:SQ:AMP/PROBE

6324-8 BRUCELLA ABORTUS AB:TITR:PT:SER:QN:AGGL

6337-0 CANDIDA ALBICANS AG:ACNC:PT:SER:SQ:ID

9822-8 MICROORGANISM IDENTIFIED PRID:PT:DIAF:QL:STERILE BODY FLUID CULTURE

6981-5 AZITHROMYCIN:SUSC:PT:ISLT:SQN:GRADIENT STRIP

5573-1 ALUMINUM:MFR:PT:HAR:QN

6473-3 MICROSCOPIC OBSERVATION:PRID:PT:TISS:QL:TRICHROME STAIN

The same general approach has been applied to common clinical measures as to laboratory observations. The same six major parts of the name, some with subparts, are used.

Table 2 Subjects covered in clinical LOINC

Blood pressure (systolic, diastolic, and mean)

Heart rate (and character of the pulse wave)

Respiratory rate

Critical care measures

(Cardiac output, resistance, stroke work, ejection fraction, etc.)

Body Weight (and measures used to estimate ideal body weight)

Body Height

Body temperature

Circumference of chest, thighs, legs, etc.

Intake and output

Major headings of history and physical

Major headings of discharge summary

Major headings of an operative note

Electrocardiographic measures

Clinical LOINC code numbers are taken from the same sequence of numbers as the Lab LOINC codes.

For many clinical measures, measurements are distinguished for estimated, reported, and measured values. (E.g., a patient's report of his or her body weight is a different variable from a measured result or the physician's estimate.) Also varying degrees of pre-coordination are provided for the observation, the body site at which it was obtained, and the method. E.g., a cardiac output based on the Fick method is distinguished from a cardiac output based on a 2D cardiac echo.

Physiologic measures are often monitored continuously over time, and the instrument reports summary "statistics" over that reporting period. The summary statistics can include minimum, maximum, and mean over a time period for vital signs measurements and fluid intake and output. When we address measures taken over time, we usually include 1 hour, 8 hour, 10 hour, 12 hour, and 24 hour summaries. The middle three durations are included to cover the varying durations of work shifts within and across institutions.

The parts of clinical measurement names are the same as for laboratory measures. The fourth part, the system, usually identifies an organ system or a particular part of the anatomy. For a measure of systolic left ventricular pressure, the system would be "Cardiac ventricle.left." In contrast to laboratory tests, where the component is usually some chemical entity, the clinical measurement component usually identifies the specific aspect of a property that is measured. For example, the property type might be pressure. Then the component would identify the pressure measured as intravascular diastolic. In general the component is used to distinguish the various points or ranges, or inflections of a physiologic tracing, and to define precisely which of a number of possible dimensions of length or area are being measured in imaging.

Laboratory measures tend to be more regular than clinical measures. The system is usually a specimen and the component a chemical or molecular moiety. For most clinical measurements, the component is also an attribute of a patient or an organ system within a patient. However, attributes of non-patient entities are often of interest in the case of clinical measurements. For example, we might want to know the class of instrument used to obtain the measurement.

Figure 2 Example Clinical LOINC terms

8285-5 CIRCUMFERENCE.OCCIPITAL-FRONTAL:LEN:PT:HEAD:QN:TAPE MEASURE

8496-2 INTRAVASCULAR DIASTOLIC:PRES:PT:BRACHIAL ARTERY:QN

9940-8 Q WAVE DURATION:TIME:PT:LEAD V1:QN:EKG

8660-3 HISTORY OF SYMPTOMS & DISEASES:FIND:PT:CARDIOVASCULAR SYSTEM:QL:REPORTED

8651-2 HOSPITAL DISCHARGE DX:IMP:PT:^PATIENT:QL

9129-8 FLUID OUTPUT.CHEST TUBE:VOL:PT:PLEURAL SPACE:QN

Readiness

The LOINC database of over 10,000 observations/measurement/test result codes is available for free use on the Internet.

There is only one official version of the LOINC standard. Codes are never re-used when the meaning of a term changes. Updates and additions are made at two to three month intervals.

Indicators Of Market Acceptance

The laboratory component of LOINC was installed on the Internet in April of 1995, and has been greeted enthusiastically since. It has been endorsed by the American Clinical Laboratory Association (ACLA) and recommended for adoption by its members. The ACLA is the association of large referral laboratories, and its members are responsible for more than 60% of US outpatient laboratory volume. Corning MetPath and LabCorp, two of the largest commercial laboratories, have adopted LOINC as their code system for reportable test results, as has LifeChem and Associated Regional and University Pathologists (ARUP). In addition, Indiana University labs, University of Colorado, Intermountain Health Care, University of Missouri, and Barnes/Jewish Hospital are in the process of converting their reporting to LOINC codes. The province of Ontario, Canada has made a tentative commitment to the LOINC codes for a province-wide coding standard.

The LOINC codes have been used as the basis for HCFA's ICD10-PCS laboratory codes. They have been incorporated in HCFA's quality assurance testing pilot software, and they have been adopted by the Centers for Disease Control and Prevention/State and Territorial Epidemiologist project for transmitting communicable diseases reports electronically.

Level of Specificity

The identifiers are specific in up to eight dimensions. The goal is to match the level of specificity provided by the master files of the systems that report these kinds of results. Laboratory test results are distinguished (and specific) to the analyte (e.g., glucose), the type of property (e.g., mass concentration), the timing aspects (e.g., 24 hour specimen), the specimen, (e.g., urine), and the method - as needed. In the case of serology tests, which tend to include method information in their name, LOINC includes the methods. In the case of chemistry tests, that tend not to include method information in their name, the LOINC codes tend not to be specific about method. The data base now includes over 10,000 laboratory and clinical observations.

Identifiable Costs

The LOINC data base and Users' Guide is available for free use for any purpose by users and vendors from the Internet Web site listed above. It is copywritten in order to prevent the development of multiple variants.

Georgetown University Home Care Project

Home Health Care Classification (HHCC) System

Home Health Care Classification (HHCC) System is a system designed to assess and document home health and ambulatory care using its standardized HHCC nomenclature. Its documentation method tracks home health and ambulatory care. It is based on a conceptual framework using the nursing process to access a patient holistically. HHCC nomenclature consists of six data dictionaries:

20 home health care components to assess and classify care;
145 nursing diagnoses (50 major categories & 95 subcategories);
3 expected outcome goals that modify nursing nursing diagnoses;
160 nursing interventions (60 major & 100 subcategories);
4 nursing action types that modify nursing interventions and converts the dictionary to 640 unique nursing interventions;
3 actual outcomes that evaluate the care process.

A patient/client is also assessed using 20 medical diagnoses and/or surgical procedure categories, and 10 socio-demographic data elements.

HHCC System can be used to identify: (a) care needs in terms of care components and their respective nursing diagnoses and interventions; and (b) resource use in terms of nursing and other health providers (physical, occupational, and speech therapy, medical social worker, and home health aide). The medical assessment categories and socio-demographic data elements are descriptive variables that can be correlated with clinical care data.

HHCC is also designed to record the clinical care pathways for an entire episode of care. The care events can be used to determine care costs, and can provide a payment method for managed care services. HHCC System runs on microcomputer using a portable notebook to facilitate ease of use for data collection and then downloaded to a computer-based workstation for processing.

References are available upon request.

Purpose: The Home Health Care Classification (HHCC) - Nursing Diagnoses and Nursing Interventions was developed by Saba as part of the Georgetown University Home Car Project. It was developed to classify, code for computer processing and analyze study data. The HHCC is being used to document and describe home health nursing care, as well as determine cost and measure outcomes.

Structure: The Home Health Care Classification (HHCC) - Nursing Diagnoses and Nursing Interventions are classified according to 20 Home Health Care Components:

Activity 11. Physical Regulation
Bowel Elimination 12. Respiratory
Cardiac 13. Role Relationship
Cognitive 14. Safety
Coping 15. Self-Care
Fluid Volume 16. Self-Concept
Health Behavior 17. Sensory
Medication 18. Skin Integrity
Metabolic 19. Tissue Perfusion
Nutritional 20. Urinary Elimination

HHCC of Nursing Diagnoses: The scheme consist of 145 nursing diagnoses (50 two digit major categories and 95 three-digit subcategories). Each nursing diagnosis has a modifier to code three possible expected outcomes: 1=improved, 2=stabilized, or 3=deteriorated.

HHCC of Nursing Interventions: It consists of 160 unique nursing interventions (60 two digit major categories and 95 three-digit subcategories). Each nursing intervention has a modifier to code four types of nursing action: 1=access, 2-direct care, 3=teach, and/or 4=manage. The type of action modifier adds the implementation facet to the HHCC of Nursing Intervention Taxonomy expanding it to 640 possible nursing intervention codes.

The HHCC is structured according to the Tenth Revision of the International Classification of Diseases (ICD-10). Each classification label consists of a five character alphanumeric code. The HHCC Care Component is alphabetic and the first character, the Nursing Diagnosis or Nursing Intervention is represented by a second and third digit for major categories, and in some instances a fourth numeric digit for minor subcategories, and the fifth digit is used to represent a modifier for each scheme.

Availability: Virginia K. Saba, EdD, RN, FAAN

Georgetown University

School of Nursing

3700 Reservoir Road, NW

Washington, DC 20007

Tel: (202) 687-46479

Perspective on Code Sets Within Transaction Standards

This perspective was presented to the ANSI HISB on December 13, 1996 by Christopher Chute, M.D., co-chairman of the Codes and Vocabulary Sub-committee of the ANSI HISB TCC.

Analysis of Code Sets Within Transaction Standards

Data Standards Roster

Code Sets within Transaction Standards

The Codes and Vocabulary Sub-committee reports the obvious finding that existing Transactions Standards have embedded within their specification scores of implicit and explicit value tables for data elements. Common examples include values for demographic variables such as race, gender, or marital status. More clinically pertinent codes include Admission Type and Condition Codes. Some standards contain large numbers of specified codes, for example the ANSI X12 837 Health Care Claim template includes or references 441 discreet code tables within that single standard.

Two problems present themselves: 1) Cross mapping named fields or elements among transaction standards; and 2) for each cross mapped element, resolving the code set values among embedded codes sets across transaction standards. The Table below simplistically illustrates a result of this process for one of the 441 code tables in X12N 837 - Admission Type.

Admission Type

UB-92	X12N	HL/7	Values
		A	Accident
1	=UB92	E	Emergency
		L	Labor and Delivery
		R	Routine
2	=UB92		Urgent
3	=UB92		Elective

Table: Code values for fields "Admission Type"

This subcommittee recommends that HHS assume or commission a detailed evaluation of the complex problem of embedded code sets among transactions standards. For the major transaction standards and their clinical systems sources (e.g. X12N, UB-92, NSF, HL/7, and ASTM E-1384) we suggest:

) Embedded Code Sets be identified and characterized.
) Code sets should be clustered across standards for similarity on the basis of element name, table content, or semantic function.
) For each cluster of similar code sets, the values should be tabulated in a way to clearly represent overlap, discord, and union. The Table layout above might provide a practical format.
) An analysis of content conflict on the basis of these similarity tables should be presented.
) Recommended resolutions of code table conflicts should be proposed.

The resultant report would be an enormously valuable resource for Standards Developer Organizations and the overall ANSI HISB to review and collaboratively revise. DHHS might then act upon the revised recommendations from the Standards community to adopt common code table standards across transaction records and their clinical source systems.

Unique Identifiers (including allowed uses)

Purpose & Scope

The purpose of the Unique Health Identifiers is to uniquely identify Individuals, Employers, Health Plans and Health Care Providers within the health care system.

A. Individuals

Current practice consists of Medical Record Numbers issued and maintained by individual provider organizations which is also known as Master Patient Index (MPI). HIS vendors have begun to develop software to facilitate cross reference to MPIs across an enterprise often known as Corporate MPI.

1.1. Unique Identifier Standards for Individuals:

1.1.1. UHID by ASTM

ASTM is the only Standards Development Organization that has developed and published standards in this area. Other options listed below are candidate identifiers frequently discussed by industry experts.

1.2. Other Unique Identifier Options for Individuals:

1.2.1. Social Security Number (SSN)

1.2.2. Biometrics IDs

1.2.3. Directory Service

1.2.4. Personal Immutable Properties

1.2.5. Patient Identification System based on existing Medical Record Number and Practitioner Prefix

1.2.6. Public Key - Private Key Cryptography Method

Employers, Health Plans and Health Care Providers

None of the Standards Developing Organizations have developed standards in the area of identifying employers, health plans and health care providers. However, HCFA and several other organizations have developed identifiers in this area with input from Federal and state agencies that administer health programs and other stake holders of the industry including standards developing organizations (SDOs).

B. Employers:

2.1 Unique Identifier Standards for Employers:

None Exists

2.2 Unique Identifier Options for Employers:

2.1.1. PAYERID

C. Health Plans:

3.1 Unique Identifier Standards for Health Plans:

None Exists

3.2 Unique Identifier Options for Health Plans:

3.2.1. PAYERID

D. Health Care Providers:

4.1. Unique Identifier Standards for Health Care Providers:

None Exists

4.2. Unique Identifier Options for Health Care Providers:

4.2.1. National Provider Identifier

4.2.2. Unique Physician Identifiers (UPIN)

4.2.3. NABP Pharmacy Number (NABP#)

4.2.4. Health Industry Number (HIN)

Individuals

Unique Identifier Standards for Individuals:

1.1.1. UHID by ASTM

Category/Classification of Standard

Unique Identifiers (including allowed uses) for Individuals

II. Standard Development Organization (SDO): ASTM

III. ANSI Accreditation, ANSI Accreditation applied for or not

ANSI Accredited

IV. Name of the Standard

Standard Guide for Properties of a Universal Health

Identifier (UHID) "E1734"

V. Contact for more information

Name: Terry Luthy

Address: ASTM 100 Barr Harbor Drive

West Conshohocken, PA 19428

E-mail: tluthy@local.astm.org

Phone: 610-832-9737

Fax: 610-832-9666

VI. Description of Standard

The UHID Scheme consists of a sequential identifier, a delimiter, check digits and an encryption scheme to support data security. This Standards Guide covers a set of requirements outlining the properties of a national system of Universal Health Identifier (limited to the population of United States). It includes positive identification of patients, automated linkage of various computer-based records, mechanism to support data security of privileged clinical information and the use of technology to keep health care operating cost at a minimum.

VII. Readiness of Standard

The Guide provides a detailed implementation sample for the UHID and evaluates the implementation against the criteria outlined by the standards. The method is being implemented by two (2) VA hospitals in Florida.

VIII. Indicators of Market Acceptance

ASTM E1714 is an approved American National Standard. Regarded as an ideal standards guide for the Unique Patient Identifier. The VA hospital network (VISN) is planning to expand the implementation of ASTM Standards based identifier. More than 350 copies of the standards have been distributed.

IX. Level of Specificity

The UHID Scheme consists of a sequential identifier, a delimiter, check digits and an encryption scheme to support data security. It supports multiple encrypted IDs for an individual.

X) Relationship With Other Standards

N/A

XI) Identifiable Costs

ASTM Standards volume 14.01 for Health care informatics that include this Standards Guide can be purchased for a nominal fee.

1.2. Other Unique Identifier Options for Individuals:

1.2.1. Social Security Number (SSN)

I. Description of Standard

The original scope of SSN was to function as a Social Security Account Number (SSAN). Its scope since the 1935 legislation has been expanded. It is now in use as a personal identifier in a wide area of applications including use by local, state and federal authorities, financial institutions, and numerous consumer organizations.

II. Readiness of Standard

Strength: The existing SSA structures, trained personnel, detailed standard procedural guidelines, cost economies, rapid implementation etc. are all in favor of the use of SSN as a valid patient identifier.

Weakness: Many organizations including those who support the use of SSN as a Health Identifier have identified several serious defects that must be fixed before it can be used as a valid Unique Health Identifier. Examples are:

Not unique
No exit control
Lack of check-digits
Significant error level
Privacy & confidentiality risks
Lack of legal protection

6. Lack of capacity for future growth

7. Lack of mechanism for emergency use and timely issue.

8. Provision for non citizens, etc.

The Computer-based Record Institute (CPRI) supports a modified SSN with important changes to the process of issue of SSN including check-digits, encryption scheme, a trusted authority, and legislative measures, etc..

III. Contact for more information:

Social Security Administration

6401 Security Blvd, Baltimore, MD 21235

IV. Indicators of Market Acceptance

Used by VA hospitals and Medicare Administration as a patient identifier. Used by many health care organizations as part of the patient demographic information.

V. Identifiable costs: Expenditure borne by the Government.

1.2.2. Biometrics IDs

I. Description of Standard

Several sophisticated methods of biometrics identification methods have been proposed, including finger print, retinal pattern analysis, voice pattern identification and DNA analysis.

II. Readiness of Standard

Law enforcement and Immigration departments use some of the biometrics identification methods. However, the necessary standards, procedures, and guidelines are non-existent for use in health care. Some of the concerns relating to this option are organ transplant, amputation and diseases affecting organs e.g. retinopathy.

III. Contact for more information:

N/A

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: Considered very expensive. Specific details not available.

1.2.3. Directory Service

I. Description of Standard

This method is proposed by Dr. William L. McMullen of Mitre Corporation. It will use existing patient identifiers to provide linkages to records of individuals across systems. The system includes social characteristics (name, SSN, address, driver license etc.) human characteristics (finger print, retina scan etc.) and other groupings such as sex, race, DOB, etc. The directory service would reconcile interactively and heuristically the proper association of the patient identification data at the current point of care with any one of the other prior points of care. This step would be supported by automated capabilities that would facilitate locating the other patient records for which a record linkage is valid. The current point of care location would then be linked with any of the other selected point of care locations by electronically exchanging their network addresses.

II. Readiness of Standard

N/A

III. Contact for more information:

The Mitre Corporation

7525 Colshire Drive

McLean, VA 22102-3481

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: Considered expensive. Specific

details not available.

1.2.4. Personal Immutable Properties

I. Description of Standard

Dr. Paul Carpenter and Dr. Chris Chute of Mayo Clinic have proposed a model Unique Patient Identifier (UPI) which consists of a series of three universal immutable values plus a check digit. The three values are a seven-digit date of birth field, a six-digit place of birth code, a five-digit sequence code (to identify the individual born on the same date in the same geographic area) and 4) a single-check digit. For emergency situations the use of temporary UPI with the prefix "T" is recommended.

II. Readiness of Standard

N/A

III. Contact for more information:

Dr. Paul Carpenter or Dr. Chris Chute

Mayo Clinic

Rochester, MN 55905

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: N/A

1.2.5. Patient Identification System Based on Existing Medical Record Number

and Practitioner Prefix:

I. Description of Standard

Medical Records Institute proposes the use of existing provider institution generated medical record number with a provider number prefix. The solution requires consensus on a practitioner identification system but eliminates the cost of creating, implementing and maintaining nationwide (patient) numbering system. The unique practitioner ID would identify the location of the patient database, and the medical record number would identify the patient's record within that database. The solution also includes the patient designation of a practitioner of choice to be the curator who functions as the gateway for the linking and updating of information.

II. Readiness of Standard

N/A

III. Contact for more information:

Medical Records Institute

567 Walnut Street, P.O. Box 600770

Newton, MA 02160

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: N/A

1.2.6. Public Key - Private Key Cryptography Method

3. Cryptography-based health care identifiers:

Dr. Peter Szolovits, Massachusetts Institute of Technology proposes a Health care Identifier System based on public-key cryptography method. Anyone who wants to use this method needs to acquire two keys that allow arbitrary messages to be encoded and decoded. These two keys contain mathematical functions that are inverses of each other. The method consists of a patient private-key and a organizational (provider) public-key together generating and maintaining IDs that are both organization specific as well as unique to individual patients within that organization. The ID can be revealed to other institutions or practitioners only with the private-key of the patient. Both centralized and decentralized controls are possible. Under the decentralized scheme the patient has the ultimate control over the degree to which the lifetime collection of medical information is made available to others. Under the centralized scheme an umbrella organization (trusted authority) handles all patient private-keys via an ID Server, and the patient will have the public-key.

At the request of authorized institutions the ID Server will generate Patient ID with the use of both the patient's private-key and public-key. Under both schemes, the use of smart card and computer are required.

II. Readiness of Standard

N/A

III. Contact for more information:

Dr. Peter Szolovits

Massachusetts Institute of Technology

Laboratory for Computer Science

545 Technology Square

Cambridge MA 02139

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: N/A

Employers

2.1 Unique Identifier Standards for Employers:

None Exists

2.2 Unique Identifier Options for Employers:

2.1.1. PAYERID

I. Description of Standard

The PAYERID has a nine numeric digit identifier which includes a 6-digit base number, a 2-digit suffix and a check digit. For those plans and employers requiring many different numbers the ID is issued as a 6-digit base number, a 2-digit suffix and a check digit. For those not requiring different numbers, it is issued in the form of one or more 8-digit numbers with a check-digit. The PAYERID was planned a national identification system to facilitate health care claims. In view of the HIPAA 1996 Legislation, HCFA will be proposing PAYERID as the standard health identifier for both health plans and employers.

II. Readiness of Standard

HCFA's Schedule for implementing PAYERID is listed below.

Notice of Proposed Rule Making (NPRM) February '97

Voluntary use of PAYERID for Medicare Claims April '97

Publish Final Regulation July '97

Require for Medicare January '98

Require for Industry July '99

III. Contact for more information:

Robert Moore

HCFA

7500 Security Blvd.

Baltimore, MD 21244

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs: N/A

Health Plans

3.1 Unique Identifier Standards for Health Plans:

None Exists

3.2 Unique Identifier Options for Health Plans:

3.2.1. PAYERID

Same as 2.2.1 above.

Health Care Providers

4.1. Unique Identifier Standards for Health Care Providers:

None Exists

4.2. Unique Identifier Options for Health Care Providers:

4.2.1. National Provider Identifier (NPI)

I. Description of Standard

The NPI is an eight-position alphanumeric identifier. The eighth position is an International Standards Organization-approved check digit, which will allow a calculation to detect keying or transmission errors. The National Provider System will assign the NPI and will also assign two-position alphanumeric location identifiers to indicate practice locations of the provider. Neither the NPI nor the location identifiers will have embedded intelligence. That is, information about the provider, such as the type of provider or state where the provider is located, will not be conveyed by the NPI. This information will be recorded in the system, but will not be part of the identifier. Individual and group providers will receive location identifiers for their office practice locations. Individuals and groups will not receive location identifiers for the hospitals or other organization providers where they practice, since these organization providers will receive their own NPIs. The NPIs of individual providers who are members of a group will be linked to the NPI of the group. The relationships defined among organization providers differ, depending upon the specific business rules of different health programs. The National Provider System will enumerate organization providers at the elemental level, so that different health programs can link these providers according to their program-specific business rules. Each organization provider in a separate location will receive a separate NPI. Each member of an organization chain and each part of an organization provider that needs to be identified will receive a separate NPI. The National Provider System will have a query facility that will link organization providers that have a common Employer Identification Number. Organization providers will have only one active location identifier.

II. Readiness of Standard

HCFA's schedule for implementation of NPI is listed below.

Notice of Proposed Rule Making Published in

Federal Register 02/21/97

Final Regulation Published in Federal Register 07/02/97

NPIs Issued to Medicare Providers No Later Than 08/01/97

Required Use of NPI for Medicare claims 12/01/97

III. Contact for more information

Robert Moore

HCFA

7500, Security Blvd.

Baltimore, MD 21244

IV. Indicators of Market Acceptance

N/A

V. Identifiable costs

None

4.2.2. Unique Physician Identifier Number (UPIN)

Description of Standard

HCFA created UPIN as required by COBRA to identify physicians who provide services for which payment is made under Medicare. UPIN is a six-place alphanumeric identifier. The UPIN Registry is the carrier that maintains the UPIN. A total of 704,926 UPINs have been assigned to 2,088,309 physicians.

Readiness of Standard

UPIN addresses only a small segment of the provider community i.e. physicians with dedicare practice. HCFA's current proposal of National Provider File/NPI replaces UPIN with NPI.

Contact For More Information

Robert Moore

HCFA

7500, Security Blvd.

Baltimore, MD 21244

Indicators of Market Acceptance

N/A

Identifiable costs

None

4.2.3. National Association of Boards of Pharmacy Number

(NABP Number)

I. Description of Standard

Each licensed pharmacy in the United States is assigned a unique seven-digit number by the National Council for Prescription Drug Programs (NCPDP), in cooperation with the National Association of Boards of Pharmacy. The purpose of this system is to enable a pharmacy to identify itself to all third-party processors by one standard number. The first two digits of the NABP Number denotes state designation. The second group four digits identify the pharmacy and assigned sequentially from 0001 up. The last digit is a check-digit.

II. Readiness of Standard

NABP Number is currently in use by pharmacies in United

States.

III. Contact for more information

Noe Gomez

NCPDP/NABP

4201 North 24th Street, Suite 365

Phoenix, AZ 85016

IV. Indicators of Market Acceptance

NABP Number is currently in use by pharmacies in United

States.

V. Identifiable Costs

None

4.2.4. Health Industry Number (HIN)

I. Description of Standard

HIN is used as an identifier for contract administration in the health industry supply chain, as a prescriber identifier for claims processing and for market analysis applications. It enumerates prescriber by location, provider establishments and other entities in the health industry supply chain. The Identifier includes a "base HIN" consisting of seven (7) character identifier and a two (2) character suffix to identify the location of the prescriber.

II. Readiness of Standard

HIN has been in use since 1987 in the health industry

supply chain and in state-administered claims processing.

III. Contact for more information

Robert A. Hankin, Phd, President,

HIBCC

5110 North 40th Street, Suite 250

Phoenix, AZ 85018

IV. Indicators of Market Acceptance

According to HIBCC, HIN is endorsed or being implemented by the following:

American Hospital Association (AHA)

American Medical Association (AMA)

American Nurses Association (ANA

American Society for Automation in Pharmacy (ASAP)

American Veterinary Distributors Association (AVDA)

Animal Health Institute (AHI)

Centers for Disease Control & Prevention (CDC)

Health Industry Distributors Association (HIDA)

Health Industry Group Purchasing Association (HIGPA)

Health Industry Manufacturers Association (HIMA)

Healthcare Information and Management Systems Society (HIMSS)

National Wholesale Druggists' Association (NWDA)

Pharmaceutical Research and Manufacturers Association (PhRMA)

State of Tennessee, TennCare Program

US Department of Defense (DoD), Defense Personnel Support Center (DPSC)

V. Identifiable Costs

There is no cost to entities enumerated on the database.

Security, Safeguards and Electronic Signatures

Overview of Health Care Security and Confidentiality Standards Development Efforts and Status - January 1997

Standards Development Organizations (SDOs) and governmental entities in the United States, Europe, Japan, Singapore, Australia, and New Zealand are currently developing standards to insure the security, confidentiality, and privacy of health care data as it resides in systems or as it is being passed in message transactions between systems. The focus of these groups is to develop security policies and procedures related to threats to system security and also to define security services. Threats to system security include disclosure, deception, disruption, and usurpation. Security services include authentication, confidentiality, integrity, availability, authenticity, authorization, non-repudiation, security administration, audit and digital signatures.

Health care specific security efforts have primarily focused on the utilization of security technologies from the general computer industry, adopting existing technologies, and providing further definition and clarification only in regard to specific domains and attributes that are unique to health care. In analyzing threat, security services, and confidentiality in the health care environment, there are only five key areas where health care security differs somewhat in analysis, definition, or requirements outside of existing non-health care specific security technologies:

Health care documents can have multiple signatures and have specific signature rules defined by user role;
Health care is a domain where a common framework for interoperability requires a greater degree of uniformity over access control (confidentiality) than most other domains;
Auditing in health care serves a legal as well as a security function.
Threats to privacy and confidentiality in health care are primarily from inside the domain ("insider threat" is greater than 75 to 80% of risk in health care), rather than from outside the domain.
Security, privacy and confidentiality of existing records (essentially paper records) is provided by a generally uniform, across state, and informal set of ethics of professional practice among the associated health care professions.

In addressing these health care specific "exceptions" the following steps are underway, or require action:

a) In setting standards for digital signatures in the health care domain additional signature attributes to support multiple signatures and signature rules are being defined;

b)Comprehensive adoption of security standards in health care, not piecemeal implementation, is advocated to provide security to data that is excahnged between health care entities;

c)Audit and audit trail data (so called, "derivative data" from direct data access, and system use) needs to be considered in the legal establishment of privacy and access rights under privacy legislation;

d)Again, in addressing threat, as under (b) above, a comprehensive implementation of security standards across a domain or system is important, as a piecemeal approach, such as the implementation of point-to-point security alone (message-based security), will not provide privacy and confidentiality protection from insider threat within a domain;

e)Confidentiality policy, as well as access control and authorization policies are an essential part of secure systems. Their establishment is being addressed within the framework of security standards efforts through the direct participation of health care specialty representatives composed of clinical health care professional organizations and societies, medical records professionals, health care transcription professionals, regulatory organizations, government agencies, the JCAHO and NCQA, insurance providers and health plans, and health care information system vendors and consultants.

Even taking into account the above issues, health care security standards efforts are perhaps best analyzed and reviewed in relation to a general system security framework, not essentially oriented to health care, as follows:

a) Identification and Authentication

b)Authorization and Access Control (Confidentiality)

c)Accountability (Non-Repudiation and Auditing)

d)Integrity and Availability

e)Security of Communication

f)Security Administration

By definition, if a system, or communications between two systems (such as health care transactions), where implemented with technology(s) meeting standards in each of the categories of this framework, that system would be essentially secure. This is an important distinction in that no single SDO is addressing all aspects of health care information security and confidentiality, and specifically, no single SDO is developing standards that cover every category of this framework. Cooperation between SDOs developing health care security standards, coordinated in the US through ANSI HISB, and between ANSI HISB and CEN TC251 regarding European standards efforts, is very active at this time, in an attempt to end up with a comprehensive standards framework to match the security framework outlined above. Please note that there is security standards work underway in each category of the framework above that should be completed by the middle to end of 1997, providing, when taken together, a complete set of standards for security in the health care domain.

The most comprehensive health care security standards development is currently being carried out by CEN TC251 in Europe and by the ASTM E31 in the United States. The American Standards Committee (ASC X12), Health Level 7 (HL7), and ACR NEMA / DICOM are currently involved in the development of standards for secure transmission of data and transactions. Health care organizations that are not accredited SDOs, such as the Computer-based Patient Record Institute (CPRI) and CORBAmed are active in assisting and promoting the standards development process through their participation in ANSI HISB and through the development of policy within documents (CPRI) and standards certification by (CORBAmed).

What follows is an overview of work being done by SDOs and other entities in the United States and Europe (in alphabetic order, by organization):

ACR NEMA / DICOM

The DICOM Committee (formerly known as the ACR/NEMA committee) has created a Working Group on Security that is considering additions to the DICOM standard to support the secure exchange of medical images and related information between two entities communicating over a public network (e.g. the Internet). The Working Group was asked to provide short term solutions using existing technology while developing long term strategies for utilizing DICOM within a secure environment based on anticipated clinical and regulatory needs. The Working Group has been coordinating its work with work being done by a similar Ad Hoc committee set up by CEN TC 251 WG 4 in Europe, as well as with work being done by groups affiliated with JIRA and MEDIS-DC in Japan who are developing demonstrations of secure image data transmissions to meet the needs of the Japanese health care institutions. The DICOM, European, and Japanese groups held a series of meetings and teleconferences in the later half of 1996 where a joint work plan was formulated and common goals set.

The CEN TC 251 WG 4 Ad Hoc on Security, in cooperation with the DICOM Working Group on Security and the Japanese groups, is developing usage scenarios which will direct long term planning towards comprehensive security within the health care field, and in particular within medical imaging. Realizing that a comprehensive secure environment may be many years away, the DICOM Working Group decided to pursue a short term goal of providing limited security using existing technology. It is hoped to incorporate such solutions in technology demonstrations being planned by the Japanese through MEDIS-DC and JIRA. The short term goal of the DICOM Working Group on Security is to draft extensions to DICOM which embed digital signatures in DICOM data objects for data source authentication and as data integrity checks. In addition, the extensions would provide an option to layer DICOM message exchange services on top of a secure transport protocol such as SSL 3.0 in order to provide confidentiality during data transfers, to authenticate the parties involved in the information exchange, and to further insure integrity during transmission. When practical, these extensions to DICOM would use existing technology in order to expedite implementation. The Ad Hoc Committee hopes to finalize a draft of these extensions in 1997.

ACR NEMA / DICOM contact:

Lawrence Tarbox, Ph.D.

Imaging Department

Siemens Corporate Research

755 College Rd. East

Princeton, NJ 08540

ltarbox@scr.siemens.com

(609) 734-3396 [voice]

(609) 734-6565 [fax]

Accredited Standards Committee (ASC) X12

The American Standards Committee X12, Electronic Data Interchange (EDI)/EDIFACT, has a number of security standards under development that are primarily targeted at messaging. X12's work in message security takes a non-health care-specific approach and is managed by X12 Subcommittee C (X12C) the data security task group of X12 that is co-chaired by Don Petry, and which coordinates efforts with the UN/EDIFACT Security Joint Working Group, chaired by Terry Dosdale of the United Kingdom.

Current X12C efforts include:

X12.42, Cryptographic Service Message (815) (usually referred to as the 815). The 815, which has been published and has a Reference Model in development, is used to provide the data format required for cryptographic key management in support of authentication and encryption. 815 includes the automated distribution and exchange of keys.

X12.376 Secure Authentication & Acknowledgment (993) (usually referred to as the 993). Currently in development, 993 is used by the recipient of a transaction set to authenticate and acknowledge the origin, content, or sequence of data received with the originator of the transactions.

X12.58 Security Structures, which has been published and has a Reference Model in development, is used to define the data formats required for authentication and encryption to provide integrity, confidentiality and verification of the originator at the functional group and transaction set levels.

ISO/IEC 9735, under the general title Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules, which is currently in draft form, to be reviewed at the X12 meetings in San Francisco in early February of this year, has five parts specifically targeting message security. These parts are: Part 5 - Security rules for batch EDI (authenticity, integrity and non-repudiation of origin); Part 6 - Secure authentication and acknowledgment message; Part 7 - Security rules for batch EDI (confidentiality); Part 9 - Security key and certificate management message; and Par 10 - Security rules for interactive EDI. The security aspects of ISO 9735 are targeted for finalization by march of 1997, and will be forwarded to ISO for final approval through the ISO Fast Track process.

American Standards Committee (ASC) contact:

Regina Girouard

Manager, Secretariat Services

Data Interchange Standards Association, Inc. (DISA)

1800 Diagonal Road, Suite 200

Alexandria, VA 22314

rgirouard@disa.org

703-548-7005 (x165) [voice]

703-548-5738 [fax]

ASTM

The American Society for Testing and Materials (ASTM) Committee E31 on Computerized Systems established a Division on Security and Confidentiality in early 1996 to facilitate the acceleration of health care security and confidentiality standards development within the ASTM and to coordinate security standards development efforts with other SDOs. The Division on Security and Confidentiality primarily coordinates the efforts of three sub-committees:

E31:17 - Privacy, Confidentiality, and Access

E31:20 - Data and System Security for Health Information

E31.22 - Medical Transcription and Documentation.

These three sub-committees within ASTM currently have seventeen (17) standards either under ballot or in draft or outline form that are targeted for completion by spring and summer 1997.

The objective of ASTM sub-committee E31.17 - Privacy, Confidentiality, and Access, is to establish a set of guidelines and standards for the procedural, technical, and administrative management of health information. In addition, the sub-committee is charged with identifying the rights and privileges of individual users, and the subjects of, health information. This latter focus is oriented towards taking a comprehensive view of "confidentiality" as incorporating the protection, not only of the "subject" of patient-specific health information (the patient), but also of health care providers and health care organizations. It is important to note that E31.17 is not concentrating on a definition of the rights of "privacy". Privacy is the domain of legislation, and ethical and moral professional practice of health care providers. Confidentiality, involves the framework in which to protect data privacy to meet legislative and professional practice guidelines.

One of the critical issues that has come up in the work of E31.17 over the last few years is a recognition of a lack of uniform standards, not only for the management of computer based health records (electronic, automated, et. al.), but explicitly for the management of paper-based, and derivative paper-based (photocopy, FAX, computer printed) health records. E31.17 efforts, therefore, are targeted at defining uniform standards for the management of health information, regardless of the "media" used for access, display, exchange, or administration of health records. In addition, the E31.17 sub-committee is treating all health information, including financial and administrative health information, under the same standards and guidelines, so that all health information is covered by a comprehensive set of confidentiality, security, disclosure, and access guidelines, appropriate to the type of data (clinical, administrative, financial).

E31.17 security standards completed or under development are as follows:

Balloted

· Standard Guide for Confidentiality, Privacy, Access and Data Security Principles for Health Information Including Computer Based Patient Records

Draft

· Documentation of Access for Individually-Identifiable Health Information

· Standard Guide for Confidentiality and Security Training of Persons Who Have Access to Health Information

· Standard Guide for Amendments/Additions to Health Information by Health Care Providers, Administrative Personnel, and by the Subjects of Health Information

· Standard Guide to the Transfer/Disclosure of Health Information in an Emergency Treatment Event

· Standard Guide for the Use and Disclosure of Health Information

· Policy Guide for the Transfer/Re-disclosure of Health Information Between Health Plans

· Rights of the Individual in Health Information

· Standard Guide to the Use of Audit Trails, and for Access and Disclosure Logging/Tracking in the Management of Health Information

The objective of ASTM sub-committee E31.20 - Data and System Security for Health Information, is to establish a technical framework and infrastructure, outlined in a set of guidelines and standards, to specify security and confidentiality implementations that will protect the privacy of health care information. The sub-committee, through its strong representation of industry experts, is focused on using existing techniques and technologies, such as digital signatures, to build a health care security infrastructure. In addition, the sub-committees efforts are directed at providing standards for health care security and confidentiality that are based upon existing and emerging standards in other industries.

E31.20 security standards completed or under development are as follows:

Published (ANSI Approved)

· E 1762 - Standard Guide for Authentication of Healthcare Information

Ballot Pending

· Standard Specification for Authentication of Healthcare Information Using Digital Signatures

Draft

· Authentication and Authorization to Access Healthcare Information

· Internet and Intranet Security for Healthcare Information

· Secure Timestamps for Healthcare Information

· Data Security, Reliability, Integrity, and Availability for Healthcare Information

· Distributed Authentication and Authorization to Access Healthcare Information

The objective of ASTM sub-committee E31.22 - Medical Transcription and Documentation, is to establish a set of guidelines and standards for the procedural, technical, and administrative management of dictated and transcribed health information. In addition, the sub-committee is charged with identifying the rights and privileges of individual users (transcriptionists, health records personnel, and health care providers), and the subjects of, health information. This latter focus is oriented towards taking a comprehensive view of "confidentiality" as incorporating the protection, not only of the "subject" of patient-specific health information (the patient), but also of health care providers, transcriptionists, health records personnel, and health care organizations.

E31.22 security standards completed or under development are as follows:

Draft

· Security and Confidentiality of Dictated and Transcribed Health Information

American Society for Testing and Materials (ASTM) contact:

Teresa Cendrowska

ASTM

100 Bar Harbor Drive

West Conshohocken, PA 19428-2959

tcendrow@astm.org

610-832-9500 [main office number]

610-832-9718 [voice - direct]

610-832-9666 [fax]

Computer-based Patient Record Institute (CPRI)

The Computer-based patient Record Institute (CPRI) through its Work Group on Confidentiality, Privacy and Security, under co-chairs Kathleen Frawley, JD and Dale Miller, has, under ongoing development, a set of security-related efforts oriented towards the establishment of guidelines, confidentiality agreements, security requirements, and frameworks. The CPRI, while not currently an ANSI accredited SDO, works very closely with accredited SDOs in the establishment of security and medical record standards, and enjoys significant cross-representation on SDO security committees.

CPRI security and framework development is completed, or underway, in the following areas:

Published

· Guidelines for Establishing Information Security Policies at Organizations Using Computer-based Patient Record Systems

· Guidelines for Information Security Education Programs at Organizations Using Computer-based Patient Record Systems

· Guidelines for Managing Information Security Programs at Organizations Using Computer-based Patient Record Systems

· Glossary of Terms Related to Information Security for Computer-based Patient Record Systems

· Security Features for Computer-based Patient Record Systems

· Sample Confidentiality Statements and Agreements for Organizations Using Computer-based Patient Record Systems

· Computer-based Patient Record Description of Content

· Computer-based Patient Record System Description of Functionality

· Computer-based Patient Record Project Evaluation Criteria

· Computer-based Patient Record Project Scenarios

Under Development

· Guidelines for Access Control in Computer-based Patient Record Systems

· Guidelines for Implementation of Electronic Authentication in Computer-based Patient Record Systems

Under Consideration (tentatively targeted for development in the second half of 1997)

· Guidelines for the use of the Internet for Computer-based Patient Record Systems

· Ethics Related to Health Information Security and Confidentiality in Computer-based Patient Record Systems

· Guidelines for Conducting Audit Control in Computer-based Patient Record System Security

· Guidelines for Business Resumption Planning in Computer-based Patient Record Systems

Computer-based Patient Record Institute (CPRI) contact:

Margret Amatayakul

Executive Director

Computer-based Patient Record Institute

1000 E. Woodfield Rd., Suite 102

Schaumburg, IL 60173

cprinet@aol.com

847-706-6746 [voice]

847-706-6747 [fax]

CEN TC251 Working Group 6 on Security, Privacy, Quality and Safety

CEN TC251 Working Group 6 (WG6), under the Chairmanship of Dr. Gunnar Klein

of Sweden (recently appointed to chairman for CEN TC251) is charged with managing the development of security and confidentiality standards for the European Commission. CEN TC 251 WG6 represents a consolidated effort to develop comprehensive standards in security and confidentiality for health information. CEN TC251 WG6 has completed a pre-standard Security Categorization and Protection of Healthcare Information Systems (COMPUSEC) and a digital signature standard. The digital signature standard mandates the use of RSA's digital signature and authentication algorithm. Additional standards work is currently underway in CEN TC251 WG6 in trusted systems in conjunction with TRUSTHEALTH a project within the Telematics Applications Programme, supported by the European Commission. TRUSTHEALTH is a project to build and test technical security services to support data confidentiality, document origin authentication, time stamps, access authentication, and professional authorization access controls.

Additional CEN TC 251, and/or European Commission health care security-related projects include: ISHTAR (Implementation of Secure Healthcare Telematics Applications in Europe); HAWSA; DAICARD3; MEDSEC; EUROMED-ETS (distributed trusted third party services); and, SEMRIC (Secure Medical Record Information Communication).

European Committee for Standardization Technical Committee CEN TC251 contact:

Gunnar Klein

Chairman CEN TC251

GKAB

Renstiernas Gata 14

S-116 28 Stockholm

Sweden

gunnar@klein.se or 73754.2411@compuserve.com

46-8-702 93 60 [voice]

46-8-702 93 61 [fax]

Health Level Seven (HL-7)

Health Level Seven (HL-7) formed the Secure Transactions Special Interest Group (SIGSecure) to address the development of secure HL7 transactions at its August 1996 meeting. This SIG will focus on the use of HL7 in communications environments where there is a need for authentication, encryption, non-repudiation, and digital signature. This group will direct its efforts on insuring the mechanisms are available for implementing a secure HL7 transactions and not on standardizing security policies. The HL7 organization is also interested in participating with the efforts of the Internet Engineering Task Force. A CommerceNet trial using email protocols (MIME) to encapsulate HL7 messages is being explored for feasibility.

SIGSecure will identify user requirements and a threat model, the services needed to meet those requirements, the mechanisms for providing those services, and the specific implementations for those mechanisms. The scope will be limited to providing network and Internet security mechanisms for HL7 transactions at the application level, independent of underlying transport. SIGSecure has a stated goal of leveraging existing standards to the maximum extent possible with a priority given to International, National (ANSI), and Publicly Available Specifications. It addition it will coordinate with other SDOs to avoid duplication and to promote harmonization.

Health Level Seven HL7 SIGsecure contacts (Co-Chairs):

Jack Harrington

Hewlett Packard Company

3000 Minuteman Road

Andover, MA 01910-1085

jackh@an.hp.com

508-687-1501 [main office]

508-659-3517 [voice - direct]

508-686-1319 [fax]

Mary E. Kratz

University of Michigan Medical Center

B1240 Taubman Center

1500 E. Medical Center Drive

Ann Arbor, MI 48109-0308

mkratz@umich.edu

313-763-6871 [voice]

313-763-0629 [fax]

IEEE

The Institute of Electrical and Electronic Engineers (IEEE) Medical Data Interchange (MEDIX) does not currently have an active group addressing security and confidentiality issues. This, according to Bob Kennelly of MEDIX, is due to the focused domain of IEEE/MEDIX that is essentially the sub-nets between bedside monitoring devices and monitors in intensive care, operating room, and inpatient settings. IEEE/MEDIX is interested in participating in cooperative efforts in the development of secure messaging standards.

National Council for Prescription Drug Programs (NCPDP)

The National Council for Prescription Drug Programs (NCPDP), as with IEEE/MEDIX, does not currently have an active group addressing security and confidentiality. This is also due to the focused domain under which they are currently working. The NCPDP is also interested in participating in cooperative efforts in the development of secure messaging standards.

Low Cost Distribution Mechanism

No input was received for this section.

Appendix A, Templates

Template for Transaction Standards

The purpose of this template is to assist the individuals in the ANSI HISB Inventory of Standards Workgroup and members of Standard Development Organizations (SDOs) to summarize the characteristics of health care information standards in a consistent manner.

Once filled in, each template will be included in the ANSI HISB Inventory of Standards Report to be presented to the DHHS in December 1996.

The scope of the Inventory of Standards Report are those healthcare transaction standards and supporting standards identified in the Healthcare Insurance Portability and Accountability Act of 1996, which must be selected by the DHHS within 18 months of enactment.

Please prepare your responses in Microsoft Word and send your draft template input to the Medical Records Institute at peterw@medrecinst.com by November 11.

I. Category/Classification of Standard

Note:

A. Use classifications identified in the Healthcare Insurance Portability and Accountability Act of 1996 such as "claims or equivalent encounter information"

and "coordination of benefits information", etc.

II. Standards Development Organization (SDO)

Note:

A. Include SDO name and domain developing committee if appropriate.

III. ANSI Accreditation, ANSI Accreditation applied for or not ANSI

Accredited

Note:

A. If your organization is ANSI accredited, what is the type and scope of accreditation? For example, is it Accredited Organization Method, Accredited Standards Committee Method or is it Accredited Sponsor using Canvas Method? If not, have you applied for accreditation?

IV. Name of Standard

Note:

A. Include the name followed by the number of the standard, if a number is available.

V. Contact for more information

Note:

A. Include name, E-mail address, phone and fax number.

VI. Description of Standard

Notes:

A. Include separate statements for:

objectives
functions
user environment (reimbursement, administrative,

clinical and/or other functional areas)

- systems environment (operating systems, network,

hardware or other requirements)

- Application function/domain completeness (Within the

defined scope of this standard, what functions/codes

are complete?

- In what way(s) is this standard superior to other

standards in this category/classification?

- any other relevant characteristics

VII. Readiness of Standard

Notes:

A. Is it a guideline? If so, does it address policy, process, practice or design?

B.Can it be implemented? (If so, can it be fully or partially implemented?, explain)

C.How can the standard be obtained?

D.Does it require a separate implementation guide? (If so is the guide approved by the SDO?

E.Is there only one implementation guideline (or are there major options that impact compatibility)?

F.Is a conformance standard specified?

G.Are conformance test tools available?

H.Source of test tools?

I.If the standard is under development, what parts of it are ready now?

J.What extensions are now under development?

AA. What are the major milestones toward standards completion?

BB. What are the projected dates for final balloting and/or implementation?

CC. Please note any other indicators of readiness that may be appropriate.

VIII. Indicator of Market Acceptance

Notes:

A. If the standard is a guideline, how many copies have been requested and distributed?

B.If the standard is an implementable standard, how many vendors, healthcare organizations and/or government agencies are using it?

C.Is this standard being used in other countries (which are they)?

Please note any other relevant indicator of market acceptance within the public or private sector.

IX. Level of Specificity

Notes:

A. If your standard is a guideline, how detailed is it?

B.If it is an implementable standard, describe how detailed its framework is and its level of granularity.

C.Does the standard(s) reference or assume other standards to achieve more specificity?

D.If it includes or assumes code sets, which ones are they?

E.What is the description of the code set?

F.How is the code set acquired?

G.Is there a users' guide or some other assistance available on the code set?

H.If the code set is currently in use, what is the extent of its use (e.g., approximate number of users)?

I.If the code set is under development, what are the projected dates of completion and implementation?

X. Relationships with other standards

Notes:

A. Identify other standards and the relationship(s) with other standards such as inclusion, dependency, interface overlap, conflict or coordination.

B.Identify specific standards reconciliation or coordination activities.

C.What portion of the specification and functionality is affected by this coordination?

D.What conditions are assumed in order for this coordination to be effective?

E.Is this standard consistent with international standards? If so, which standards?

F.What gaps remain among related standards that should be addressed?

G.Describe what is being done to address these gaps.

XI. Identifiable Costs

Notes:

A. Please indicate the cost or your best estimate for the following:

Cost of licensure
Cost of acquisition (if different from licensure)
Cost/timeframes for education and training
Cost/timeframes for implementation
Please note any other cost considerations.

Template for Frameworks, Architectures and Models

The purpose of this template is to assist the individuals in the ANSI HISB to create an inventory of frameworks, architectures and models to be included in the HISB Inventory of Standards Report to the DHHS.

The scope of the frameworks, architectures and models to be included in the Inventory of Standards Report are those FAMS which promote interoperability among healthcare information standards. These may include FAMS such as the Common Data Model of the IEEE Joint Working Group, the HL7 Draft Reference Model, CORBAMED, Health Industry Generic Architectures and others.

I. Category/Classification: Is this a framework, architecture or model?

II. Standards Development Organization (SDOs): Include SDO names and domain developing committees if appropriate.

III. ANSI Accreditation: Is this FAM led by an ANSI accredited organization?

IV. Name of framework, architecture or model:

I. Contact for more information: Include name, E-mail address, phone and fax number.

I. Description of framework, architecture or model. Include separate statements for:

Purpose
Scope and/or environment

· Type

How this FAM has/will be used
Modeling or other tools required
Other relevant information

VII. Readiness of framework, architecture or model:

A) Has it been published?

B) Is it a draft or a final version?

C) Has it been implemented? If so, where and when?

D) If the FAM is under development, what portions are available now?

E) What are the target dates for additional portions or versions of this FAM?

F) Is the use of this FAM dependent on the availability/selection of a tool?

G) Is the use of the FAM dependent on an RFI, an RFP or other evaluation or selection process?

H) Please note any other indicators of readiness that may be appropriate.

I. Indicator of Market Acceptance:

A) If the FAM is published, how many copies have been requested and distributed?

B) If the FAM can be implemented, how many vendors, healthcare organizations and/or government agencies have used it?

A) Is this FAM being used in other countries, which are they?

D) Which SDOs are committed to comply with or use this FAM?

E) Please note any other relevant indicator of market acceptance within the public or private sector

IX. Level of Specificity: Describe the ISO level, the detail and/or the specificity of this FAM

X. Identifiable Costs.

Notes: A) Please indicate the cost or your best estimate for the

following:

Cost of licensure:
Cost of acquisition (if different from licensure):.
Cost/timeframes for education and training:
Cost/timeframes for implementation.
Please note any other cost considerations.

Appendix B, Activities to promote inter-operability

Frameworks/Architectures and Models

IEEE P1157.1 -Joint Working Group for a Common Data Model

I. Category/Classification

Framework

II. Standards Development Organization (SDOs)

Institute of Electrical and Electronics Engineers (IEEE)

P1157.1 (MEDIX) Joint Working Group for a Common Data Model

III. ANSI Accreditation

IEEE is an ANSI accredited organization

IV. Name of framework, architecture or model

Trial Use Standard for Healthcare Data Interchange - Information Model Methods

V. Contact for More Information:

George W. Beeler, Jr.

Email: beeler@mayo.edu

voice, 507-284-9129

fax, 507-284-0796.

VI. Description of framework, architecture or model

The following paragraphs derive directly from the scope and purpose statement of the draft standard.

Scope:

This standard specifies the recommended approach for modeling the health care environment in an object-oriented paradigm. It is intended for use by organizations developing standards for information interchange between health care information systems. This standard specifies the graphical and textual notations used in defining the information model, and procedures for defining conformance and compliance. This standard also specifies procedures for evolving the information model.

Purpose

This standard defines notations and recommends procedures for development of standardized components of an overall object-oriented information model to be used in health care data interchange. The use of consistent notation and procedures facilitates modular development of the overall model and facilitates the development of a family of standards to provide for health care data interchange

The intent of this framework specification is to provide a common way for healthcare information standards organization to develop their information models, in order to facilitate comparison and sharing of those models between SDO's. Implementation of this standard requires no particular tooling. Complete specification of information model can be derived from a literary expression created with a word processor.

It should be noted that the development of this framework was done as a Joint Working Group drawing members from ASC-X12N, ASTM, DICOM, HL7, and IEEE.

VII. Readiness of framework, architecture or model

Two drafts of this framework have been published - in 1994 and 1996. The 1996 draft has been freely circulated to interested parties in a variety of healthcare information interchange organizations.

Electronic reproductions of the April 1996 release can be obtained at http://www.mcis.duke.edu/standards/ieee/jwg-model/ in files stdmain.pdf and stdanex.pdf.

This framework has been implemented in the modeling activities of at lease HL7, ASC-X12N, and DICOM.

The full framework is available. Extensions to incorporate use-case modeling and related models are under consideration. The P1157.1 committee intends to seek a ballot on this document in 1997.

This framework is not dependent on the availability or selection of any particular tool. Indeed, several tools currently on the market will support modeling in this methodology. The use of the framework is not dependent on any RFI or RFP process.

VIII. Indicator of Market Acceptance

Over 150 paper copies have been produced and distributed. It is not known how many electronic copies have been acquired. The methodology has been implemented in at least three SDO's as part of their own information modeling activities. This framework is not known to be in use in other countries.

HL7 is committed to using this framework as part of its larger message development framework for Version 3.

IX. Level of Specificity

I am uncertain of the intent of this question and therefore cannot respond.

X. Identifiable Costs

Cost of acquisition will involve simply the purchase cost of a copy of the standard from the IEEE on the order of $100 to $400. Additional costs to adopt a compatible framework within any given SDO are entirely dependent upon the technological and political preparedness of that SDO to move to a formalized, model-based methodology.

IEEE:

Project #: P1157.1

Title: Standard for Healthcare Data Interchange - Information Model Methods

Scope: The scope of this document is to specify the approach used within the P1157 family of standards for modeling the health care environment in an object-oriented paradigm. This document specifies the graphical and textural notations used in defining the information model, procedures for registration of globally unique identifiers, and procedures for defining conformance and compliance. This document also specifies procedures for evolving the information model and for defining local specializations. The scope of the family of standards is to provide for healthcare data interchange in the open systems environment.

Purpose: This document defines notations and procedures for development of standardized components of an overall object-oriented information model for use in P1157 healthcare data interchange. The use of consistent notation and producers facilitates modular development of the overall model. The purpose of the P1157 family of standards is to provide for healthcare data interchange in the open systems environment.

Project #: P1157.1.1

Title: Standard for Healthcare Data Interchange - Common Healthcare Objects

Scope: The scope of this document is the specification of common healthcare objects which are the basis for specialization by other standards in the P1157.1 Information Model.

Purpose: The purpose of this document is to provide a common repository for base object classes which are used by multiple standards in the P1157.1 Information Model. The use of a common set of base objects is intended to promote consistency in the specializations defined by other standards in the P1157.1 Information Model.

Project #: P1157.1.2

Title: Standard for Healthcare Data Interchange -Registration Admission/Discharge/Transfer

Scope: The scope of this document is the specification of an object-oriented model of the subject domain of patient Registration, Admission, Transfer, and Discharge.

Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain of Registration, Admission, Discharge, Transfer.

Project #: P1157.1.3

Title: Standard for Healthcare Data Interchange - Laboratory

Scope: The scope of this document is the specification of an object-oriented model of the subject domain of Laboratory including, but not limited to, Chemistry, Hematology, Immunology, and Microbiology. There may also be application in Anatomical pathology, that is, Cytology, Histology, and Autopsy.

Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain of Laboratory.

Project #: P1157.1.4

Title: Standard for Healthcare Data Interchange - Radiology

Scope: The scope of this document is the specification of an object-oriented model of the subject domain of Radiology.

Purpose: The purpose of this document is to provide an object oriented model which supports the specification of healthcare data interchange transactions involving the subject domain or Radiology.

Project #: P1157.2

Title: Standard for Healthcare Data Interchange -Interchange Format Methods

Scope: The scope of this document is the definition of the methods used for specification of standardized transactions in theP1157 family of standards. This document defines the models for mapping from the information model defined by the P1157.1.n standards to standardized transactions for healthcare data interchange. Wherever possible, the interchange formats and representation profiles used by this family standards will consist of specialization's of F-type International Standardized Profiles (ISPs)as defined by ISO TR 10000.

Purpose: This document provides a model for message specification at the application level for the P1157 family of standards. The model forms the basis for specification of messages based upon particular interchange formats and representation profiles. The goal is to leverage F-type ISPs wherever possible, focusing on specialization for the needs of healthcare data interchange where necessary.

Project #: P1157.2.1

Title: Standard for Healthcare Data Interchange -EDI/EDIFACT Interchange Formats

Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon the interchange formats defined by ANSI X.12 EDI and ISO 9735EDIFACT. The messages defined by this standard are based upon the Healthcare Information Model defined by the P1157.1.n standards.

Purpose: The purpose of this document is to define the implicit and explicit event driven mapping of the Healthcare Information Model defined by the P1157.1.n standards to the interchange formats defined by ANSI X.12 EDI and ISO 9735 EDIFACT.

Project # : P1157.2.2

Title: Standard for Healthcare Data Interchange -ODA/ODIF/SGML Interchange Formats

Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon the document architecture and interchange formats defined by the ISO8613 ODA/ODIF family of standards and the ISO 9069 SGML Document Interchange Format.

Project #: P1157.2.3

Title: Standard for Healthcare Data Interchange - CMIS/CMIP Interchange Formats

Scope: The scope of this document is the specification of standardized transactions for healthcare data interchange based upon ISO 9595 Common Management Information Service and ISO 9596 Common Management Information Protocol.

Purpose: The purpose of this document is to define the implicit and explicit event driven mapping of the Healthcare Information Model defined by the P1157.1.n standards to application transactions supported by the services and protocols defined by CMIS/CMIP.

Project #: P1157.3

Title: Standard for Healthcare Data Interchange -Communication Profile Methods

Scope: The scope of this document is to define the procedures for specification within the P1157 family of standard of standardized functional profiles for healthcare data interchange. The profiles correspond to the A/B Application profiles, T/UT transport Profiles, and R Relay Profiles as defined by ISO TR10000.Wherever possible, the standardized profiles defined in this family of standards will be based upon specializations of International Standardized profiles (ISPs).

Purpose: The purpose of this document is to define a common set of procedures for use in specification of the communication profiles for healthcare data interchange. Wherever possible, theP1157 family of standards will leverage International Standardized Profiles.

Project #: P1157.4

Title: Standard for Healthcare Data Interchange - Semantics and Knowledge Representation of the Medical Record

Scope: The scope of this standard is the specification of the architecture for representation and interchange of the medical record in the open systems environment. Specific issues associated with preservation of the semantics of the medical record in healthcare data interchange will be addressed in this standard.

Purpose: The purpose of this document is to provide an architectural model for interchange of the medical record in the open systems environment. The goal is to build upon and extend the framework for healthcare data interchange which is developed by other standards in the P1157 family of standards.

Project #: P1157.5

Title: Recommendation for Healthcare Data Interchange - User Needs

Scope: The scope of this document is to describe the needs of users in the healthcare sector in the area of healthcare data interchange.

Purpose: This document describes the user needs with respect to healthcare data interchange. As such it serves as an introduction and tutorial for the P1157 family of standards. Overview of IEE 1157 MEDIX Project

Contact for more information:

Jack Harrington

Chair, IEEE P1157

Principal Systems Architect

(P) 508-659-3517

(F) 508-686-1319

(E) jackh@an.hp.com

Check out our Web page at

http://www.linkmib.com/linkmib

Health Level 7 Reference Information Model

I. Category/Classification

Information model

II. Standards Development Organization (SDOs)

Quality Assurance/Data Modeling Committee of Health Level Seven (HL7).

III. ANSI Accreditation

HL7 is an ANSI accredited standards developing organization.

IV Name of framework, architecture or model

Health Level 7 Reference Information Model (RIM).

V Contact for More Information:

George W. Beeler, Jr.

Email: beeler@mayo.edu

voice: 507-284-9129

fax: 507-284-0796

VI Description of framework, architecture or model

This will be an object-oriented information model of the classes present in the healthcare domain about which Health Level 7 messages are transmitted. Its purpose will be to provide the precise definition of the content of HL7 messages. The Reference Information Model will be part of a set of models which include a Use-Case Model, the Reference Information Model, an Interaction Model, and a Message Specification Model. Each of these is linked and interdependent.

The scope of the Reference Information Model is the healthcare domain in general, with particular attention to clinical care activities within healthcare. This is the same scope as the HL7 organization. This model has not yet been implemented. It will see its initial draft presentation and evolution at the HL7 working group meetings in January 1997. No special tooling is required to read and review the model, as it will be fully specified by its literary and graphic expressions. A processable form of the model will available as a database in Microsoft Access.

VII Readiness of framework, architecture or model

The Reference Information Model is currently undergoing its initial draft development pointing towards review and use within the Technical Committees of HL7 in January of 1997. Draft version 0.6 of the HL7 RIM can be found at http://wwww.mcis.duke.edu/standards/hl7/data-model/hl7/modelpage.html. This web-site provides access to a literary expression in Microsoft Word, html expressions, graphic expressions, and the Access database.

The current release is a draft version. As with every data model, there will never be a "final version." The reference information model will evolve as the developments within HL7 continue to expand. Implementation of this model involves its use in the definition of healthcare information interchange messages. This process will begin in January 1997.

The present release of the RIM is relatively complete in scope. It will undergo further development in terms of adding additional detail to the Version 0.6 currently available. Additional releases of the DRAFT RIM are planned on a monthly basis between now and the HL7 working group meetings in January. Subsequent to that, the Reference Information Model will probably be updated in preparation for each subsequent HL7 working group meeting. HL7 has not yet determined whether (or how) to manage releases of the RIM for use external to the HL7 Working Group MDF process.

The use of the model is not dependent upon a particular set of tools. However, for an organization to use the full message development framework, tooling will be a necessary support activity. The selection of such tools for use by HL7 will occur during 1997. The use of the model is not dependent on any RFI or RFP process.

VIII Indicator of Market Acceptance

Because the Reference Information Model is being published electronically, we do not have a count on how many have been requested or distributed. This development of this model drew upon models from a number of vendor and healthcare provider organizations. It has been provided back as a courtesy to those same organizations. It is uncertain the degree to which they will take advantage of it.

Presumably, the reference information model will be used by the HL7 affiliates in Germany, the Netherlands, Canada, and New Zealand. No other SDO's are committed at this time.

IX Level of Specificity

I am uncertain of the intent of this question and therefore cannot respond.

X Identifiable Costs

Expenses have not yet been fully established, but it assumed that licensure costs would be nominal, on the order of $250, if HL7 elects to publish versions of the RIM for external use.

HL7 Version 3 Message Development Framework

I. Category/Classification

Framework

II. Standards Development Organization (SDOs)

Developed by the Quality Assurance/Data Modeling Committee of Health Level 7

III. ANSI Accreditation

HL7 is ANSI Accredited

IV Name of framework, architecture or model

Message Development Framework for HL7 Version 3

V. Contact for More Information:

George W. Beeler, Jr.

Email: beeler@mayo.edu

voice: 507-284-9129

fax: 507-284-0796

IV. Description of framework, architecture or model

The intent of this framework is to provide a methodology for developing healthcare information interchange messages. This methodology will be used for HL7 Versions 3.0 and beyond. The framework defines all of the steps in the message development process to be used by HL7. It includes the criteria for passing from step to step and the methods of documentation of the deliverables at each step.

The scope of applicability of the framework is healthcare information interchange standards. The messages defined as a result of this process may be implemented either as ASCII strings in a variety of formats or as data structures that can be interchanged with a variety of object-based protocols.

The framework is based upon a set of fully defined inter-linked models of the healthcare and messaging environment. It includes a Use Case Model for the standard; an Information Model for the healthcare domain about which messages are being sent; an Interaction Model that specifies the roles of systems that are exchanging information according to these standards; and a Message Specification Model which can be transformed to support a variety of information interchange protocols.

The framework has been used in prototype situations within HL7. It will be implemented as a working framework in January 1997. The necessary tooling to support the framework and the methodologies within the framework will be selected but have not been selected at this point.

VII. Readiness of framework, architecture or model

Versions of this framework have been published and distributed at HL7 meetings. The most recent version (as of November 6, 1996) can be found at http://www.mcis.duke.edu/standards/hl7/pubs/version3/mdf_0896.zip. A subsequent draft will be released about January 1, 1997.

This is a draft framework. Even after it is implemented, it will undergo continuing evolution. It has only been implemented in prototype circumstances. It will be brought into full use in January 1997.

The draft referenced above is relatively complete, but the level of detail varies in different sections of the framework. As noted, the more or less final version is intended for delivery at the HL7 meetings the third week of January 1997.

This framework is not dependent on the availability of any particular tool. It will, however, be necessary to provide tooling for an organization such as HL7 to take full advantage of such a framework. There is no dependence on an RFI or RFP process.

The overall process upon which this framework is based derives from the CEN TC251 activities. Although the process is not applied to a large organization, the CEN efforts do provide an existence proof that this methodology will lead to usable message standards.

VIII Indicator of Market Acceptance

As this framework has been published electronically, we cannot tell how many copies have been requested or distributed.

The suggestion that we respond as to plans for vendors or government agencies to use this specification seems at odds with the declared scope for the inventory said "those FAMS which promote interoperability among healthcare information standards." This framework is designed to be used within a standards organization to develop compatible, model-based message specifications. Thus, it seems unclear how many vendors or government agencies might use this framework. At present, we know only of plans to use it within HL7.

A similar methodology was developed by CEN TC251. The HL7 MDF is based on that prior work and has acknowledged that work.

IX Level of Specificity

I am uncertain of the intent of this question and therefore cannot respond.

X Identifiable Costs

Costs for using this framework are not fully known. Cost of licensure from HL7 will be nominal, on the order of $250 to purchase a copy of the specification. Time frames for education, training, and implementation are entirely dependent upon the readiness of the organization adopting this framework to step up to the technological concepts embedded within it. It needs a group that is at least comfortable with object-based modeling and object-related specifications.

American Dental Association (ADA) Computer-Based Oral Health Record

The ADA also sponsors participation in ANSI activities of the International Organization for Standardization (ISO) Technical Committee 106 on dentistry and acts a 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 of Dental Research (IADR) acted as advisory 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).

Name of Standard Framework, Architecture or Model: (1) Proposed ANSI/ADA Specification 1000: Standard Clinical Data Architecture for the Structure and Content of a Computer-based Patient Record. This standard is being developed for based Oral Health Record (COHR). The objective was to develop COHR features which would offered the greatest utility to the profession as a whole, addressed issues of open architecture and would be technology independent. The baseline version 1.0 of the COHR Concept Model was released in February 1996. While the process and data models described in the COHR were specific to dentistry, these models were developed with the understanding that dentistry is a microcosm representative of the entire health care environment. Early in the modeling of the COHR the ADA addressed integrated care delivery and coordinating care among the various health care professions and delivery environment. The COHR was developed as a progression of analytical models founded on clinical and public health principles. It described the health care environment, the fundamental processes of health care delivery and the data needed to support these processes. The COHR Concept Model was subsequently converted into a logical data model by the ASC MD156. The logical model was expanded and modified through input from physicians, nurses and allied health personnel. This modification evolved the COHR logical model into a generic clinical data architecture for patient health care information independent of health care profession or delivery environment.

Description of Standard Framework, Architecture or Model:

Purpose: To present an organizing framework for the specification of a clinical data architecture and components via a fully attributed logical data model.

Scope and/or environment: This specification applies to the application data interface (the conceptual interface in the Codasyl Three Tier Architecture) of computer system architecture.

A. Type: Fully attributed logical data model.

In what way will this FAM be implemented/used? To guide development of databases for patient information, clinical repositories, etc.

B. Modeling or other tools required: None.

Objectives: This specification will ultimately make healthcare information seamlessly available at the time and point of care to all authorized users, in a form best used, and with no compartmentalization by profession, specialty, discipline, or care delivery environment. Seamless data interface among system users serving private practice, academia, research, industry, and government programs will offer significant benefits to all system users.

Functions: This specification presents a generic conceptual model of the clinical process, and the data required to enable these processes. From this concept model a logical data model is developed for a clinical data architecture appropriate for use in computer-based patient records and other applications.

Healthcare domain completeness: This specification is independent of health care profession and specialty. It is appropriate for the health care supporting industries, for the educational and research establishment, and for veterinary care.

Provider/payer user environment: The specification is independent of and appropriate across the range of practice philosophy, patient management approach, and reimbursement mechanism.

Systems environment: The specification applies uniformly to flat file, x-base, relational and object-oriented data management approaches.

Systems domain focus: The specification details the architecture of the Application-Data Interface of clinical systems, and therefore provides a foundation data structure useable by standards operating at a higher level of the CODASYL architecture.

Other relevant characteristics: The specification was prepared using a formal conceptual process and data modeling, with preparation of the logical data model and data characteristics through consensus of subject matter experts, consistent with the ANSI Accredited Canvass Method.

Readiness of Standard Framework, Architecture or Model:

Implementation guides and concordances with prominent existing and emerging standards will be prepared. Clinical software intended for use in dentistry may be voluntarily submitted by the vendor for conformance evaluation by the ADA under an evaluation program similar to its seal of approval program. The specification is under development: data models are complete, first two of 18 parts have been drafted and revised from public comment. Remaining parts of the specification are being prepared for public review in 1997.

A. Has it been published? Yes, initial parts but the American Dental Association, Summer of 1996.

B. Is it a draft or a final version? Draft for public comment.

C. Has it been implemented? If so, where and when? No

D. If the FAM is under development, what portions of it are available now?

Parts 1000.0 and 1000.1 are now available.

E. What are the target dates for additional portions or versions of the FAM?

Parts 1000.2 through 1000.17 will be completed by the Summer of 1997.

F. Is the use of this FAM dependent on the availability/selection of a tool? No.

G. Is the use of the FAM dependent on an RFI, an RFP or other evaluation or selection of a tool? No.

Indicator of Market Acceptance:

A. How many copies have been requested and distributed? Over 1000 copies of the draft documents have been distributed for review. Approximately 2000 copies of the foundation concept model document in two printings were distributed for public review and comment during 1995-96.

B. Which SDO's are committed to comply with or use this FAM? American Dental Association.

C. Please not any other relevant indicators of market acceptance within the public or private sector. The specification is being coordinated with ASTM E31-19 as an implementation vehicle for ASTM E31-1384 and other standards.

Level of Specificity:

The specification applies to the middle tier of the CODASYL Three-Tier Architecture. The specification identifies the metadata for entities and attributes needed to construct a physical database containing clinical data, e.g. data name, type and length, format, values, null option, and entity data usage. The specification requires ASCII character set, and where precluded by language UNICODE is required. The specification is code set independent: the data model allows user selection of any existing code set such as CDT, ICD-9, CPT, SNOMED, etc., and user definable code sets for use in reference or look-up tables. The specification requires the use of several ANSI and ISO standards.

Relationships with other standards:

The prominent existing and emerging standards relevant to this specification are ASTM (1239, 1384, 1633, 1715, 1744, 1769, and others, along with proposed standards for the longitudinal automated record and drug therapy documentation), NCPDP, ANSI X-12, DICOM, HL7, and ISO (8601, etc.).

No overlap or conflict exists since the relevant standards apply to a higher level of the CODASYL system architecture. Relevant ISO standards are required in this specification.

Documents and data dictionaries are being assembled from the standards organizations for harmonization: identical data names are used where possible, and cross mapping will be provided where commonality is not feasible. Harmonization is currently underway between DICOM, ASTM E31.19 and ASC MD156. ASC MD156 is also participating in ASTM E31.23 modeling.

Identifiable Costs:

Acquisition of the specification will be through normal publication routes by ANSI or the ADA. There is no license fee associated with the specification. However, ANSI or the ADA may charge for the publication of the specification and its implementation guides and concordances. The specification is expected to reduce cost of design and development of clinical information systems by providing a database blueprint and design metadata.

Other

Computer-based Patient Record Institute

III. ANSI Accreditation, ANSI Accreditation applied for or not ANSI

Accredited

Note: A) If your organization is ANSI accredited, what is the type

and scope of accreditation? For example, is it

Accredited Organization Method, Accredited Standards

Committee Method or is it Accredited Sponsor using

Canvas Method? If not, have you applied for

accreditation?

Not ANSI Accredited

IV. Name of Standard

Note: A) Include the name followed by the number of the standard,

if a number is available.

CPRI Computer-based Patient Record Description of Content

V. Contact for more information

Note: A) Include name, E-mail address, phone and fax number.

Margaret Amatayakul

Executive Director

Computer-based Patient Record Institute

1000 East Woodfield Road., Suite 102

Schaumburg, IL 60173

TEL. 847-706-6746

FAX. 847-706-6747

E-MAIL. CPRINET@AOL.COM

VI. Description of Standard

Notes: A) Include separate statements for:

- objectives:

Objectives:

The objectives of Computer-based Patient Record Description of Content provides detailed information about the dimensions of the computer-based patient record. It defines information content, information representation, and time span. As well, it briefly describes migration from paper-based medical record systems to the expansive vision of the computer-based patient record presented by the Institute of Medicine (The Computer-based Patient Record: An Essential Technology for Health Care, National Academy Press, April 1991).

Functions

The primary function of Computer-based Patient Record Description of Content is to assist in understanding of the scope of the content of the computer-based patient record.

- user environment (reimbursement, administrative,

clinical and/or other functional areas)

User Environment

Computer-based Patient Record Description of Content is applicable to any provider implementing computer-based patient records, or any vendor developing CPR systems.

- systems environment (operating systems, network,

hardware or other requirements)

- Application function/domain completeness (Within the

defined scope of this standard, what functions/codes

are complete?

Functionality

Computer-based Patient Record Description of Content may be used alone, or in conjunction with other CPRI descriptive materials. It is not dependent upon other standards.

- In what way(s) is this standard superior to other

standards in this category/classification?

Competing Standards

To our knowledge there is no other descriptive document serving this purpose.

- any other relevant characteristics

VII. Readiness of Standard

Notes: A) Is it a guideline? If so, does it address policy, process, practice or design?

Guideline:

Computer-based Patient Record Description of Content addresses design.

B) Is it implementable? (If so, is it fully or partially implementable?, explain)

Implementable

Computer-based Patient Record Description of Content is implementable by any organization that wishes to use it as a tool for planning.

C) How can the standard be obtained?

Obtainable

Computer-based Patient Record Description of Content is available on CPRI's web site (http://www.cpri.org). Paper copy can be obtained for a nominal fee from the Computer-based Patient Record Institute.

D) Does it require a separate implementation guide? (If so

is the guide approved by the SDO?

Implementation Guide

Not required.

E) Is there only one implementation guideline (or are there

major options that impact compatibility)?

Comformance Standard Specification

Since this is a guideline, conformance testing is not applicable

F) Is a conformance standard specified?

G) Are conformance test tools available?

H) Source of test tools?

I) If the standard is under development, what parts of it

are ready now?

Development Stage

Computer-based Patient Record Description of Content is final and was released in April 1996.

J) What extensions are now under development?

Extensions

Discussions are underway to develop an object-oriented view of computer-based patient records which may ultimately, but not at this time, substitute for this work.

K) What are the major milestones toward standards

completion?

L) What are the projected dates for final ballotting and/or

implementation?

M) Please note any other indicators of readiness that may

be appropriate.

VIII. Indicator of Market Acceptance

Notes: A) If the standard is a guideline, how many copies have been

requested and distributed?

Market Acceptance

No information is available about sales of this relatively new product.

B) If the standard is an implementable standard, how many

vendors, healthcare organizations and/or government

agencies are using it?

C) Is this standard being used in other countries (which

are they)?

D) Please note any other relevant indicator of market

acceptance within the public or private sector.

IX. Level of Specificity

Notes: A) If your standard is a guideline, how detailed is it?

B) If it is an implementable standard, describe how

detailed its framework is and its level of granularity.

C) Does the standard(s) reference or assume other standards

to achieve more specificity?

D) If it includes or assumes code sets, which ones are they?

E) What is the description of the code set?

F) How is the code set acquired?

G) Is there a users' guide or some other assistance

available on the code set?

H) If the code set is currently in use, what is the extent

of its use (e.g., approximate number of users)?

I) If the code set is under development, what are the

projected dates of completion and implementation?

X. Relationships with other standards

Notes: A) Identify other standards and the relationship(s) with

other standards such as inclusion, dependency, interface overlap, conflict or coordination.

B) Identify specific standards reconciliation or

coordination activities.

C) What portion of the specification and functionality is

affected by this coordination?

D) What conditions are assumed in order for this

coordination to be effective?

E) Is this standard consistent with international standards?

If so, which standards?

F) What gaps remain among related standards that should be

addressed?

G) Describe what is being done to address these gaps.

XI. Identifiable Costs

Notes: A) Please indicate the cost or your best estimate for the

following:

Cost of licensure
Cost of acquisition (if different from licensure)

Cost

Paper copy of Computer-based Patient Record Description of Content is available from CPRI at a cost of $15. See above for web site availability.

Cost/timeframes for education and training
Cost/timeframes for implementation
Please note any other cost considerations.

CPRI Project Evaluation Criteria

V. Contact for more information

Note: A) Include name, E-mail address, phone and fax number.

Margaret Amatayakul

Executive Director

Computer-based Patient Record Institute

1000 East Woodfield Road., Suite 102

Schaumburg, IL 60173

TEL. 847-706-6746

FAX. 847-706-6747

E-MAIL. CPRINET@AOL.COM

VI. Description of Standard

Notes: A) Include separate statements for:

- objectives:

Objectives:

CPR Project Evaluation Criteria is a product developed for use in the Nicholas E. Davies CPR Recognition Program conducted by the CPRI. In addition to serving as the specific criteria providers must meet for this recognition, the document may be used outside of the recognition program to:

Promote the vision of CPR systems through concrete examples.
Understand and share documented value of CPR systems on health care quality, costs, and access.
Promote development and use of health care information standards.
Provide visibility and recognition for high-impact CPR systems.
Share successful implementation strategies and organizational benefits derived from CPR systems.

Functions:

The primary function of CPR Project Evaluation Criteria outside of the Davies CPR Recognition Program is to help providers understand the scope of CPR systems and evaluate their progress toward that goal.

- user environment (reimbursement, administrative,

clinical and/or other functional areas)

User Environment

CPR Project Evaluation Criteria is designed to be used primarily in the understanding of computer-based patient records as they may be implemented in provider settings. They are not intended to be used to describe a specific product. CPR system implementation depends upon not only technology, but the environment in which the CPR system is implemented. The criteria includes that for management, functionality, technology, and impact.

- systems environment (operating systems, network,

hardware or other requirements)

- Application function/domain completeness (Within the

defined scope of this standard, what functions/codes

are complete?

- In what way(s) is this standard superior to other

standards in this category/classification?

Competing Standards

To our knowledge there is no other tool that provides criteria for evaluating implementation of CPR systems in provider settings.

- any other relevant characteristics

VII. Readiness of Standard

Notes: A) Is it a guideline? If so, does it address policy,

process, practice or design?

Guideline:

CPR Project Evaluation Criteria address design.

B) Is it implementable? (If so, is it fully or partially

implementable?, explain)

Implementable

CPR Project Evaluation Criteria is implementable by any organization that wishes to use it as a tool for planning, any consulting firm that wishes to use it to assist clients in evaluating progress toward implementing CPR systems, and by vendors to establish provider expectations.

C) How can the standard be obtained?

Obtainable

CPR Project Evaluation Criteria can be obtained for a nominal fee from the Computer-based Patient Record Institute.

D) Does it require a separate implementation guide? (If so

is the guide approved by the SDO?

Implementation Guide

Not required.

E) Is there only one implementation guideline (or are there major options that impact compatibility)?

Conformance Standard Specification

Traditional conformance testing does not apply, however, the CPR Project Evaluation Criteria have been pilot tested and have been used in three years of Davies CPR Recognition Program implementation.

F) Is a conformance standard specified?

G) Are conformance test tools available?

H) Source of test tools?

I) If the standard is under development, what parts of it

are ready now?

Development Stage

CPR Project Evaluation Criteria is in Version 2.1, released in March 1996.

J) What extensions are now under development?

Extensions

CPR Project Evaluation Criteria may be revised as experience with the Davies CPR Recognition Program may suggest the need, as reflected by industry advances.

K) What are the major milestones toward standards

completion?

L) What are the projected dates for final ballotting and/or

implementation?

M) Please note any other indicators of readiness that may

be appropriate.

VIII. Indicator of Market Acceptance

Notes: A) If the standard is a guideline, how many copies have been

requested and distributed?

Market Acceptance

Many copies of CPR Project Evaluation Criteria have been sold, as well as distributed as part of the Davies CPR Recognition Program. In this program, providers who have been recognized attest to the usefulness of the review process and the importance of the recognition. Recognized providers have included: Intermountain Health Care, Columbia-Presbyterian Medical Center, Department of Veterans Affairs, and Brigham & Women=s Hospital. Providers to be recognized in 1997 have not been selected as of the writing of this report.

B) If the standard is an implementable standard, how many

vendors, healthcare organizations and/or government

agencies are using it?

C) Is this standard being used in other countries (which

are they)?

D) Please note any other relevant indicator of market

acceptance within the public or private sector.

IX. Level of Specificity

Notes: A) If your standard is a guideline, how detailed is it?

B) If it is an implementable standard, describe how

detailed its framework is and its level of granularity.

C) Does the standard(s) reference or assume other standards

to achieve more specificity?

D) If it includes or assumes code sets, which ones are they?

E) What is the description of the code set?

F) How is the code set acquired?

G) Is there a users' guide or some other assistance

available on the code set?

H) If the code set is currently in use, what is the extent

of its use (e.g., approximate number of users)?

I) If the code set is under development, what are the

projected dates of completion and implementation?

X. Relationships with other standards

Notes: A) Identify other standards and the relationship(s) with

other standards such as inclusion, dependency, interface

overlap, conflict or coordination.

B) Identify specific standards reconciliation or

coordination activities.

C) What portion of the specification and functionality is

affected by this coordination?

D) What conditions are assumed in order for this

coordination to be effective?

E) Is this standard consistent with international standards?

If so, which standards?

F) What gaps remain among related standards that should be

addressed?

G) Describe what is being done to address these gaps.

XI. Identifiable Costs

Notes: A) Please indicate the cost or your best estimate for the

following:

Cost of licensure
Cost of acquisition (if different from licensure)

Cost

CPR Project Evaluation Criteria is available from CPRI at a cost of $100.

Cost/timeframes for education and training
Cost/timeframes for implementation
Please note any other cost considerations.

CPRI Computer-based Patient Record System Description of Functionality

V. Contact for more information

Note: A) Include name, E-mail address, phone and fax number.

Margaret Amatayakul

Executive Director

Computer-based Patient Record Institute

1000 East Woodfield Road., Suite 102

Schaumburg, IL 60173

TEL. 847-706-6746

FAX. 847-706-6747

E-MAIL. CPRINET@AOL.COM

VI. Description of Standard

Notes: A) Include separate statements for:

- objectives:

Objectives:

The objectives of Computer-based Patient Record System Description of Functionality provides detailed information about the functionality (the CPR system) surrounding the core element (the CPR). It briefly describes the major benefits to be realized from a CPR system and defines the functions of data capture, data storage, information processing, information communication, security, and information presentation. The work summarizes concepts first described by the Institute of Medicine patient record study committee in The Computer-based Patient Record: An Essential Technology for Health Care, National Academy Press, April 1991.

Functions

The primary function of Computer-based Patient Record System Description of Functionality is to assist in understanding of the scope of the functionality of the computer-based patient record system.

User Environment

Computer-based Patient Record System Description of Functionality is applicable to any provider implementing computer-based patient records, or any vendor developing CPR systems.

Functionality

Computer-based Patient Record System Description of Functionality may be used alone, or in conjunction with other CPRI descriptive materials. It is not dependent upon other standards.

Competing Standards

To our knowledge there is no other descriptive document serving this purpose.

VII. Readiness of Standard

Notes: A) Is it a guideline? If so, does it address policy,

process, practice or design?

Guideline:

Computer-based Patient Record System Description of Functionality addresses design.

Implementable

Computer-based Patient Record System Description of Functionality is implementable by any organization that wishes to use it as a tool for planning.

Obtainable

Computer-based Patient Record System Description of Functionality is available on CPRI=s web site (http://www.cpri.org). Paper copy can be obtained for a nominal fee from the Computer-based Patient Record Institute.

Implementation Guide

Not required.

Conformance Standard Specification

Since this is a guideline, conformance testing is not applicable

Development Stage

Computer-based Patient Record System Description of Functionality is final and was released in September 1996.

Extensions

Discussions are underway to develop an object-oriented view of computer-based patient records which may ultimately, but not at this time, substitute for this work.

VIII. Indicator of Market Acceptance

Notes: A) If the standard is a guideline, how many copies have been

requested and distributed?

Market Acceptance

No information is available about sales of this relatively new product.

IX. Level of Specificity

X. Relationships with other standards

Notes: A) Identify other standards and the relationship(s) with

other standards such as inclusion, dependency, interface

overlap, conflict or coordination.

B) Identify specific standards reconciliation or

coordination activities.

C) What portion of the specification and functionality is

affected by this coordination?

D) What conditions are assumed in order for this

coordination to be effective?

E) Is this standard consistent with international standards?

If so, which standards?

F) What gaps remain among related standards that should be

addressed?

G) Describe what is being done to address these gaps.

XI. Identifiable Costs

Notes: A) Please indicate the cost or your best estimate for the

following:

Cost of licensure
Cost of acquisition (if different from licensure)

Cost

Paper copy of Computer-based Patient Record System Description of Functionality is available from CPRI at a cost of $15. See above for web site availability.

Cost/timeframes for education and training
Cost/timeframes for implementation
Please note any other cost considerations.

CPR Project Scenarios

V. Contact for more information

Note: A) Include name, E-mail address, phone and fax number.

Margaret Amatayakul

Executive Director

Computer-based Patient Record Institute

1000 East Woodfield Road., Suite 102

Schaumburg, IL 60173

TEL. 847-706-6746

FAX. 847-706-6747

E-MAIL. CPRINET@AOL.COM

VI. Description of Standard

Notes: A) Include separate statements for:

- objectives:

Objectives:

The objectives of CPR Project Scenarios are to illustrate the scope of computer-based patient record systems, and to serve as a useful tool for strategic planning, requirements descriptions, and for creating test sets for live system demonstrations.

Functions

The primary function of CPR Project Scenarios is to illustrate, in understandable terms, the scope of computer-based patient records systems in multiple different views.

- user environment (reimbursement, administrative,

clinical and/or other functional areas)

User Environment

CPR Project Scenarios is designed to be used primarily in the understanding of computer-based patient records as they may be implemented for a variety of purposes. Illustrated are physician access from home, ambulatory care with patient as remote user, weekend urgent care, rural health care, inpatient care for emergency surgery, visiting nurse providing home care, public health reporting, and research.

- systems environment (operating systems, network,

hardware or other requirements)

- Application function/domain completeness (Within the

defined scope of this standard, what functions/codes

are complete?

Functionality

CPR Project Scenarios may be used alone, or in conjunction with other CPRI descriptive materials. They are not dependent upon other standards.

- In what way(s) is this standard superior to other

standards in this category/classification?

Competing Standards

To our knowledge there is no other tool that provides scenarios for visioning and strategic planning, education programs, etc.

- any other relevant characteristics

VII. Readiness of Standard

Notes: A) Is it a guideline? If so, does it address policy,

process, practice or design?

Guidelines:

CPR Project Scenarios address design.

B) Is it implementable? (If so, is it fully or partially

implementable?, explain)

Implementable

CPR Project Scenarios is implementable by any organization that wishes to use it as a tool for planning.

C) How can the standard be obtained?

Obtainable

CPR Project Scenarios can be obtained for a nominal fee from the Computer-based Patient Record Institute.

D) Does it require a separate implementation guide? (If so

is the guide approved by the SDO?

Implementation Guide

Not required.

E) Is there only one implementation guideline (or are there

major options that impact compatibility)?

Conformance Standard Specification

Since this is a guideline, conformance testing is not applicable

F) Is a conformance standard specified?

G) Are conformance test tools available?

H) Source of test tools?

I) If the standard is under development, what parts of it

are ready now?

Development Stage

CPR Project Scenarios is final and was released in April 1996.

J) What extensions are now under development?

Extensions

CPR Project Scenarios may be expanded as further examples of uses are developed.

K) What are the major milestones toward standards

completion?

L) What are the projected dates for final ballotting and/or

implementation?

M) Please note any other indicators of readiness that may

be appropriate.

VIII. Indicator of Market Acceptance

Notes: A) If the standard is a guideline, how many copies have been

requested and distributed?

Market Acceptance

No information is available about sales of this relatively new product.

B) If the standard is an implementable standard, how many

vendors, healthcare organizations and/or government

agencies are using it?

C) Is this standard being used in other countries (which

are they)?

D) Please note any other relevant indicator of market

acceptance within the public or private sector.

IX. Level of Specificity

Notes: A) If your standard is a guideline, how detailed is it?

B) If it is an implementable standard, describe how

detailed its framework is and its level of granularity.

C) Does the standard(s) reference or assume other standards

to achieve more specificity?

D) If it includes or assumes code sets, which ones are they?

E) What is the description of the code set?

F) How is the code set acquired?

G) Is there a users' guide or some other assistance

available on the code set?

H) If the code set is currently in use, what is the extent

of its use (e.g., approximate number of users)?

I) If the code set is under development, what are the

projected dates of completion and implementation?

X. Relationships with other standards

Notes: A) Identify other standards and the relationship(s) with

other standards such as inclusion, dependency, interface

overlap, conflict or coordination.

B) Identify specific standards reconciliation or

coordination activities.

C) What portion of the specification and functionality is

affected by this coordination?

D) What conditions are assumed in order for this

coordination to be effective?

E) Is this standard consistent with international standards?

If so, which standards?

F) What gaps remain among related standards that should be

addressed?

G) Describe what is being done to address these gaps.

XI. Identifiable Costs

Notes: A) Please indicate the cost or your best estimate for the

following:

Cost of licensure
Cost of acquisition (if different from licensure)

Cost

CPR Project Scenarios is available from CPRI at a cost of $25.

- Cost/timeframes for education and training

Wright State University College of Nursing and Health

III. ANSI Accreditation

The Patient Core Data Set development organization is not ANSI accredited. PCDS development is complete and future efforts include seeking national acceptance and accreditation.

IV. Name of Standard:

Patient Core Data Set

V. Contact for more information:

Alice Renner

Wright State University

College of Nursing and health

3640 Colonel Glenn Highway

Dayton, OH 45435

Phone: 937-775-2591

Fax: 937-775-4571

E-mail: arenner@wright.edu

VI. Description of Standard:

Through support of the Agency of Health Care Policy and Research, Public Health Service, Blue Chip Computers Company in collaboration with Wright State University-Miami Valley College of Nursing and Health completed SBIR research for a comprehensive design of an Integrated Patient Information System (IPIS). [ Blue Chip Computers Company, Inc., Integrated Patient Information System, SBIR Grant, Contract Number 282-94-2039, Funded by DHHS Public Health Service, Agency for Health Care Policy and Research] Research findings confirmed the hypothesis that the inadequacy of current patient information systems can be attributed to the following fundamental causes: (1) The lack of uniform standards of patient minimum data sets; (2) The lack of systems interoperability and overall data integration in existing patient information systems; and (3) The lack of continuity of the patient health records and data exchange capability. The Wright State University consultants undertook the development of a Patient Core Data Set (PCDS) in response to the lack of uniform standards of minimum data sets and lack of standards in data transfer for continuity of care. The PCDS consists of a common core of data elements to be collected for all patients receiving health care. The PCDS provides the uniform standard of electronic patient data exchange among different health care institutions needed by a variety of users through compatibility with HL7 and ASTM electronic data interchange standards. The ability to exchange patient data accurately and timely can eliminate unnecessary duplication of tests, diagnoses and treatments.

(a) Objectives - The objectives of the Patient Core Data Set are to provide for the development of a longitudinal record of a patient's health and medical history through the use of a common set of 50 standard data elements with uniform definitions, and coding consistent with ASTM and HL7 standards. The data elements are divided into three areas: patient identification, service, and health.

The goal of the PCDS is to provide for a longitudinal record of a patient's health and medical history by making access to data from each health care episode easily accessible. Ideally following an episode, the core data set would be transferred to the patient's primary practitioner's office for updating the patient's record and/or to a regional or state data repository. However, until this becomes a reality, the PCDS residing in any facility could be easily queried upon request from another facility and because of the standardization could be expediently transferred from facility to facility.

(b) Function - The PCDS is essential information for a variety of health professionals, including clinicians, administrators, researchers, and policy makers. It is intended for transfer across all patient-care settings. As a core data set, the PCDS is not designed to be sufficient to meet the total data needs of any one user group. It is, however, recommended for inclusion in all computer-based patient records. All elements of the PCDS must be present to describe patient care across settings.

(c) User environment - The transfer of PCDS information allows comparability of patient data across clinical populations, health-care settings, and local, state and national regions. The PCDS is intended for outcome studies of health care effectiveness and clinical practice guideline usage. For example, clinical practice could be guided by information obtained from analysis of the effectiveness of a specific treatment modality. Patterns of service utilization and resource allocation can be investigated by health-care administrators. Furthermore, aggregate data collected on health risks and life-style behaviors have the potential to influence health policy decision making. Additional pieces of information may be needed beyond the PCDS by the various users, but should be obtained from the complete computerized patient medical record.

(d) Systems environment - This standard may be used from any operating system, network or hardware platform.

(e) Application function/domain completeness - The elements within the data set are complete.

(f) In what way(s) is this standard superior to other standards in this category/classification? - The PCDS is the only completed data set to date that incorporates the concept of "core data" for all patients across all health care settings. Core data is defined as data that meets the essential needs of multiple users, that is transferred across all patient-care settings, and that provides for continuity of care by forming the basis of a patient's computerized longitudinal medical record. Although various health constituencies have developed their own uniform data sets, these sets exist in isolation as each set has been created for specific purposes of the constituency that developed it. PCDS allows comparability of patient data across clinical populations, healthcare settings, and local, state and national regions. PCDS provides guidelines for both the user and the programmer. and includes the following information for each data element: name, number, definition, data uses, discussion, data type and field length, repetition, coding scheme, and relevant data standards and guidelines. The research team made a concerted effort to incorporate standards for computerized patient records in the PCDS and to make it compatible with HL7 and ASTM electronic data interchange standards. Future research efforts include mapping the PCDS data elements to elements in other common data sets, and revision over time based on field testing, other pertinent research, and developments in the field of health care data standards.

Readiness of Standard:

(a) Is it a guideline? - PCDS is a standard for building the longitudinal computerized patient record. The PCDS contains 50 data elements in three categories: patient identification, service, and health. PCDS includes the following information for each data element: name, number, definition, data uses, discussion, data type and maximum field length, repetition, coding scheme, and relevant data standards and guidelines. The exchange of information supports administration, clinical practice, research, and health policy making.

(b) Is it implementable? - The PCDS has been implemented in an integrated patient information system developed for a prenatal clinic and labor and delivery unit of a hospital.

(c) How can the standard be obtained? The standard can be obtained by contacting:

Alice Renner

Wright State University

College of Nursing and Health

3640 Colonel Glenn Highway

Dayton, OH 45435

Phone: (937) 775-2591

Fax: (937) 775-4571

E-mail:arenner@wright.edu

(d-e) Does it require a separate implementation guide? - The data set does not require a separate implementation guide a copy of the PCDS provides information on implementation with each element. PCDS provides guidelines for both the user and the programmer and includes the following information for each data element: name, number, definition, data uses, discussion, data type and field length, repetition, coding scheme, and relevant data standards and guidelines.

(f) Is a conformance standard specified? - The PCDS specifies conformity, but recognizing that conformity will only come with a federal mandate, provides for alternate coding systems to be identified in the data exchange between computer systems. Standardization is more easily accomplished in the areas of patient identification and service elements, than in the clinical data area. Reporting of patient identification and service elements have been mandated for reporting for Medicare and Medicaid reimbursement since the 1980s, resulting in a degree of standardization. Clinical data, however, has been the last data to be computerized by healthcare facilities and much clinical data is still relegated to the paper record.

(g-h)Source of test tools?- None available to date.

(I) If the standard is under development, what parts of it are ready now? - The entire data set is available for use.

(j) What extensions are now under development? - Research continues on the relevance of each data element to the concept of "core data." The data set is dynamic and revision will be based on further national input and field testing which will result in additions or deletions of elements, or specificity of detail of an element. Other pertinent research and developments in the field of health care data standards will impact the PCDS.

(k) What are the major milestones towards standards completion?- The following are major activities in the research and development of the PCDS toward making it ready for consideration as a standard:

The development team researched and evaluated existing health care data sets and used this as a basis for forming the PCDS. During development of the PCDS, a content validity survey was conducted to obtain both local and national input on the data set, evaluate the relevance of the elements to the data set and obtain recommendations for additions and changes to the data set. The evaluation tool that was used is based on the article: Lynn, M.R. (1986) Determination and quantification of content validity. Nursing Research. 35(6), 382-385. The tool provides determination of the content representativeness or content relevance by the application of a two-stage (development or judgment) process. Quantification of content validity is achieved through the use of the index of content validity (CVI) which is determined from the ratings of the relevance of the data elements using a 4-point ordinal rating scale. The content validity surveys provided much valuable information for the development of the data set.

Because the data set had to be useful to a variety of users including administrators, clinicians, researchers, and health policy makers, the consultants sought experts from these areas with proficiency in health care informatics. Fourteen national experts participated in the workgroup sessions held June 27-29, 1996. The experts included the Executive Director of the Medical Records Institute and chair of the national committees: ASTM E31.20, Standards Committee on Electronic Signatures in Health Care and the American National Standards Institute – Task Force on International Cooperation; the chairman of ASTM E31 Healthcare Informatics; the chair of ASTM E31.12 Computer-Based Records committee; the chair of Health Level 7; an expert and consultant on the Long Term/Home Health Delivery System and author of the Saba Home Health Care Classification System, nurse researchers involved in standards development for nursing data elements for nursing interventions and outcomes; representatives form the Agency for Health Care Policy and Research; the Joint Commission on Accreditation of Healthcare Organizations; experts in outcomes research, a developer of an enterprise computer system for several hospitals and clinics; and health policy researchers.

The Wright State consultants are also investigating the formation of an American Society for Testing and Materials (ASTM) committee for the PCDS similar to the committee for the computerized patient record. The data set was developed to be compatible with the E31 Health Informatics standards and these standards are referenced in the data set.

Because the HL7 has become the defacto standard for data exchange in health care informatics, compatibility with Health Level 7 (HL7) protocol for health information exchange was also important in the development of the PCDS. The consultants plan future work with HL7 experts to identify the corresponding HL7 segment data fields with the PCDS data fields. Inclusion of the information on coding according to the standards for data interchange will help acceptance and use of the data set.

What are the projected dates for final balloting and/or implementing?

N/A

Indicator of Market Acceptance:

The data set development has just been completed and the set has been included in a report to the Agency for Healthcare Policy and Research. The PCDS has not been made distributed to date.

Level of Specificity:

(a) How detailed is your standard? - The PCDS has been developed to meet specific needs of a variety of health care professionals including clinicians, administrators, researchers, and health policy makers.

(b) How detailed is the framework and its level of granularity? - A separate implementation guide is not available at this time. Each data element is described in detail with a discussion of the conceptual basis or any other specific aspects of data collection not covered in the documentation for that element. The level of detail of the clinical elements in particular may be increased in future revisions of the data set if additional testing indicates that the detail is not sufficient to meet the crucial needs of clinicians.

(c) Does the standard reference or assume other standards to achieve specificity? -

The PCDS does reference other standards to achieve specificity. It is compatible with and references ASTM and Health Level 7 protocol standards for data transmission of information collected for the data set.

(d-h) If it includes or assumes code sets, which ones are they and how are the code sets acquired? - The PCDS uses the following code sets:

CODE SETS	ACQUIRED FROM
Health Care Procedure Codes (HCPCS)	HCFA
ICD-9-CM Procedure Codes	National Center for Health Statistics
CPT Codes - Physicians Current Procedure Terminology	American Medical Association
Patient Identification/Occurrence Codes	National Uniform Billing Committee
Health Level 7	Health Level Seven
Logical Observation Identifier Names and Codes (LOINC)	Duke University
ASTM E1238-94 and E1384-96	American Society for Testing Materials
National Drug Code
World Health Organization Drug Records	World Health Organization
North American Nursing Diagnosis Association (NANDA)	North American Nursing Diagnosis Association
Nursing Intervention Classification System	University of Iowa (Mosby Publishing Co.)
Nursing Outcomes Classification System	University of Iowa
National Provider Identification File	HCFA
Systematized Nomenclature of Medicine (SNOMED)	College of American Pathology

X. Relationships with other standards

(a-c) Identify other standards and the relationships with other standards:- The standards that have been referenced in the PCDS are as follows:

ASTM 1238-94

ASTM 1384-96

Health Level 7

The coding of the data elements in the PCDS and suggested format for electronic exchange of the information are consistent with these standards.

Identifiable Costs:

(a) Cost of licensure - No license is necessary at this time to use the PCDS

(b) Cost of acquisition - The cost of reproducing the data set and distribution costs have not been determined yet, but should be minimal.

(c) Cost/timeframes for education and training - The cost/timeframe for education and training will depend upon the individuals and the skill levels of the individuals. The coding of the database is discussed in the data set and only the most widely used code sets have been incorporated in the data set

(d) Cost and timeframes for implementation - The cost/timeframe for implementation depends upon the systems capability, hardware platform, and internal resources available for implementation.

ASTM E1460-92

Standard Specification for Defining and Sharing Modular Health Knowledge Bases (Arden Syntax for Medical Logic Systems)

V. Contact for more information

Terry Luthy

American Society for Testing and Materials (ASTM)

100 Barr Harbor Drive

West Conshohocken, PA 19428-2959

phone: (610)832-9500

fax: (610)832-9666

email: tluthy@mail.astm.org

Harm Scherpbier, MD

Chairman ASTM E31.15

SMS

51 Valley Stream Parkway

Malvern PA 19355

phone (610)219-4762

fax: (610)219-3124

email: harm.scherpbier@smed.com

VI. Description of Standard

Notes:

A. Include separate statements for:

objectives
functions
user environment (reimbursement, administrative,

clinical and/or other functional areas)

- systems environment (operating systems, network,

hardware or other requirements)

- Application function/domain completeness (Within the

defined scope of this standard, what functions/codes

are complete?

- In what way(s) is this standard superior to other

standards in this category/classification?

- any other relevant characteristics

Objectives: promote and facilitate the sharing of medical logic in the form of Medical Logic Modules. A Medical Logic Module contains sufficient knowledge to make a single decision. Contraindication alerts, management suggestions, data interpretations, treatment protocols, and diagnosis scores are examples of health knowledge that can be represented using MLMs.

Using the Arden Syntax, health providers and health delivery systems can share MLMs, independent of the clinical information system at their site.

Functions: The Arden Syntax is a standard syntax to represent MLMs. Each MLM contains administrative information about the author of the MLM, library information about the purpose of the MLM with links to medical reference literature, and a knowledge section containing the knowledge in a standard language. The knowledge section contains the data needed from a clinical information system to process the MLM, the trigger event causing the MLM to execute, the logic, and the action to be taken if the MLM needs to alert a clinician about a patient situation.

User Environment: primarily clinical, also administrative and research.

Systems Environment: the Arden Syntax is independent of the systems environment. Implementations exist on mainframes, PCs, client/server systems, etc.

Application function/domain completeness: the Arden Syntax 92 version is complete. Future extensions include further standardization of the data needed to process an MLM, which is dependent on other standardization efforts in clinical data modeling and vocabularies (outside the scope of this standard). Other areas of knowledge representation will be included in future versions.

In what way is standard superior to other standards in this category: There are no other standards in this category.

VII. Readiness of Standard

Notes:

A. Is it a guideline? If so, does it address policy, process, practice or design?

It is an official standard.

B. Is it implementable? (If so, is it fully or partially implementable?,explain)

Several implementations exist, both in academia as well as by commercial clinical software vendors. The standard is both fully as well as partially (or incrementally) implementable. In other words, some developers choose to implement the entire Arden Syntax at once, others choose to start with commonly userd Syntax functions, adding others later (incrementally).

A. How can the standard be obtained?

Order from ASTM (address and phone see above).

D. Does it require a separate implementation guide? (If so is the guide approved by the SDO?

No.

E. Is there only one implementation guideline (or are there major options that impact compatibility)? N/A

A. Is a conformance standard specified?

Not at this time.

A. Are conformance test tools available?

Not at this time.

A. Source of test tools?

Several commercial syntax checkers are available.

I. If the standard is under development, what parts of it are ready now?

N/A - Standard has a complete 1992 version.

A. What extensions are now under development?

See above:

A. What are the major milestones toward standards completion?

N/A

L. What are the projected dates for final ballotting and/or

implementation? N/A

M. Please note any other indicators of readiness that may be appropriate.

VIII. Indicator of Market Acceptance

Notes:

A. If the standard is a guideline, how many copies have been requested and distributed?

B. If the standard is an implementable standard, how many vendors, healthcare organizations and/or government agencies are using it?

Academic institutions: approx. 7 that I'm aware of (both US and international), probably others that I'm not aware of.

Commercial software vendors: >6, including most large clinical information systems vendors, either have products on the market today or to be released 1997.

A. Is this standard being used in other countries (which are they)?

Sweden, UK, Germany. Possibly others that I'm not aware of.

D. Please note any other relevant indicator of market acceptance within

the public or private sector.

IX. Level of Specificity

Notes:

A. If your standard is a guideline, how detailed is it?

Very strictly defined syntax.

B. If it is an implementable standard, describe how detailed its

framework is and its level of granularity.

Fully defined syntax for writing clinical logic. Only exception of tight definition: the definition of the data needed in an MLM is not standardized. The syntax allows local implementors to use any query language and vocabulary to retrieve the data needed in an MLM. This allows the current Arden Syntax to be used in very diverse clinical information environments. Work is in process to tighten the definition of data, but this is a long term process.

C. Does the standard(s) reference or assume other standards to achieve

more specificity? No.

A. If it includes or assumes code sets, which ones are they? N/A

E. What is the description of the code set?

F. How is the code set acquired?

G. Is there a users' guide or some other assistance available on the

code set?

H. If the code set is currently in use, what is the extent of its use

(e.g., approximate number of users)?

I. If the code set is under development, what are the projected dates

of completion and implementation?

X. Relationships with other standards

A. Identify other standards and the relationship(s) with other standards such as inclusion, dependency, interface overlap, conflict or coordination.

Currently: no dependencies

B. Identify specific standards reconciliation or coordination activities.

Future activities to further specify the data definitions: work with standards organizations to provide clinical data model ( for example HL7), query language, and vocabularies (for example LOINC, SNOMED, ICD9, etc.).

C. What portion of the specification and functionality is affected by this coordination?

The data slot - the slot where needed data are specified.

Standard is available to international users, and is currently used by international organizations.

A. What gaps remain among related standards that should be addressed?

Clinical data model: no complete clinical data model exists today.

Vocabularies: various vocabularies exist, some overlapping. For the Arden Syntax to work optimally, there needs to be a single, complete, non-overlapping standard for each vocabulary domain, for example one vocabulary for lab results, one for medications, etc.. The coordination and creation of these vocabularies is outside of the Arden Syntax scope. We rely on other SDOs to create these vocabularies.

XI. Identifiable Costs

Notes:

A. Please indicate the cost or your best estimate for the following:

Cost of licensure
Cost of acquisition (if different from licensure)
Cost/timeframes for education and training
Cost/timeframes for implementation
Please note any other cost considerations.

License cost: none

Acquisition cost - depends on number of copies. Single copy approx. $32.00, discount on larger quantities.

Cost/ timeframes for education, training, and implementation: different for each organization.

Topics

Healthcare Safety Net | Healthcare Coverage & Access

Inventory of Health Care Information Standards

Executive Summary

Introduction

Acknowledgments

Transaction Standards

Health Claims or Equivalent Encounter Information

Accredited Standards Committee (ASC) X12, Health Care Task Group

ASC X12N Health Care Claim (837)

ASC X12N Interactive Healthcare Claim/Encounter (IHCLME)

National Council for Prescription Drug Programs (NCPDP)

NCPDP Standard Claims Billing Version 2.0

NCPDP Telecommunications Standard Format Version 3.2

TABLE OF NCPDP TELECOMMUNICATION

STANDARD VERSION/RELEASE

Standard

Version/

Release

Standard Approved

by NCPDP

Dictionary Complete

Implementation Guide

Complete

Widely Used & Implemented

Highlights

Health Care Financing Administration (HCFA)

HCFA National Standard Format (NSF), Version 002.00

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

American Dental Association (ADA) Accredited Standards Committee MD 156

ADA Implementation Guide for ASC X12 837

Health Level Seven, Inc. (HL7)

Health Level Seven Versions 1.0 through 3.0

HL7 Event Type Codes

HL7 Order Control Codes and Their Meaning

Attachment 3

Attachment 4

National Uniform Claim Committee (NUCC)

National Uniform Claim Committee Recommended Data Set for a Non-Institutional Claim or Encounter

Indicator Of Market Acceptance:

Health Claim Attachments

Accredited Standards Committee (ASC) X12 Insurance Subcommittee, Health Care Task Group

ASC X12 Patient Information (275)

Description of Standard;

Readiness of Standard:

Indicator of Market Acceptance:

Level of Specificity:

Relationships with other standards:

Identifiable Costs:

IEEE 1157 MEDIX Project

IEEE 1073, Standard for Medical Device Communications

Digital Imaging Communication in Medicine (DICOM) Standards Committee

DICOM Standard. NEMA PS3.x - 1992, 1993, 1995

ASTM Committee E31 on Healthcare Informatics

ASTM E1384-96 Standard Guide for Content and Structure of the Computer-Based Patient Record

ASTM E1769-95 Standard Guide for Properties of Electronic Health Records and Record Systems

ASTM E1633-95 Standard Specification for Coded Values Used in the Computer-Based Patient Record

Enrollment and Disenrollment in a Health Plan

Accredited Standards Committee (ASC) X12, Health Care Task Group

ASC X12 Benefit Enrollment and Maintenance (834)

National Council for Prescription Drug Programs (NCPDP)

NCPDP Member Enrollment Standard

Eligibility for a Health Plan

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

ASC X12, Health Care Eligibility/Benefit Inquiry (270), ASC X12, Health Care Eligibility/Benefit Information (271)

ASC X12, Health Care Task Group

Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI), Interactive Health Care Eligibility/Benefit Response (IHCEBR)

Health Care Payment and Remittance Advice

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

ASC X12N Health Care Claim Payment/Advice (835).

Health Care Premium Payments

Accredited Standards Committee X12 Insurance Subcommittee, Health Care Task Group

Consolidated Service Invoice/Statement (811), Payment Order/Remittance Advice (820)

First Report of Injury

Accredited Standards Committee X12 Insurance Subcommittee, Property And Casualty Task Group

Report of Injury, Illness or Incident (148)

Health Level Seven (HL7)

ASTM Committee E31 on Healthcare Informatics

E1744-95, Standard Guide for a View of Emergency Medical Care in the Computerized Patient Record

Health Claim Status

Accredited Standards Committee X12 Insurance Subcommittee, Property and Casualty Task Group

Health Care Claim Status Request (276), Health Care Claim Status Notification (277)