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).
Contact For More Information: Data Interchange Standards Association (DISA) 703-548-7005.
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.
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.
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.
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:
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.
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.
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:
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.
Contact For More Information: Data Interchange Standards Association (DISA)
703-548-7005.
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.
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.
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 April 1997.
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.
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)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.
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.
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
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.
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.
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:
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.
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.
The scope of the standards that NCPDP develops are those for information processing for the pharmacy services sector of the health care industry.
NCPDP was accredited by ANSI on August 6, 1996. The type of accreditation was the Accredited Organization Method.
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:
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:
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.
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:
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:
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.
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.
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.
StandardVersion/Release |
Standard Approvedby NCPDP |
Dictionary Complete |
Implementation GuideComplete |
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.
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.
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.
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 :
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.
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) Not applicable.
A) No, this standard is not consistent with international standards.
A) There are no gaps.
A) Not applicable.
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
Not ANSI accredited. Have not applied for accreditation.
Joy Glass - Email Jglass@hcfa.gov, 410-786-6125, FAX 410-786-4047
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.
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.
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.
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.
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.
Jean M. Harris - Email JHarris2@hcfa.gov, 410-786-6168, FAX 410-786-4047
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.
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.
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:
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.
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 |
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.
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.
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.
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.
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.
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.
|
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 became an ANSI accredited SDO, Accredited Organization Method, on June 12, 1994.
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)
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
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 (*):
· EKG
· EEG
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:
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:
· 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.
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:
· SGML
· Andover Working Group's "Enterprise Communicator"
Major Milestones Toward Standards Completion?
Version 2.3:
· Final balloting
Version 3.0
Projected Dates For Final Balloting And/Or Implementation.
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.
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.
Other Standards
Standards Reconciliation Or Coordination Activities
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.
|
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/reso |