HIT Technology Standards

Overview 

HL7 Overview Handout

Health Level Seven is one of several American National Standards Institute (ANSI) -accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data.

Headquartered in Ann Arbor, MI, Health Level Seven is like most of the other SDOs in that it is a not-for-profit volunteer organization. Its members-- providers, vendors, payers, consultants, government groups and others who have an interest in the development and advancement of clinical and administrative standards for healthcare—develop the standards. Like all ANSI-accredited SDOs, Health Level Seven adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. A frequent misconception about Health Level Seven (and presumably about the other SDOs) is that it develops software. In reality, Health Level Seven develops specifications, the most widely used being a messaging standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data.

Members of Health Level Seven are known collectively as the Working Group, which is organized into technical committees and special interest groups. The technical committees are directly responsible for the content of the Standards. Special interest groups serve as a test bed for exploring new areas that may need coverage in HL7’s published standards. A list of the technical committees and special interest groups as well as their missions, scopes and current leadership is available on this web site.

HL7's Vision

To create the best and most widely used standards in healthcare.

HL7's Mission

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

HL7's Strategies:

1. Develop coherent, extendible standards that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning.
2. Develop a formal methodology to support the creation of HL7 standards from the HL7 Reference Information Model (RIM).
3. Educate the healthcare industry, policy makers, and the general public concerning the benefits of healthcare information standardization generally and HL7 standards specifically.
4. Promote the use of HL7 standards world-wide through the creation of HL7 International Affiliate organizations, which participate in developing HL7 standards and which localize HL7 standards as required.
5. Stimulate, encourage and facilitate domain experts from healthcare industry stakeholder organizations to participate in HL7 to develop healthcare information standards in their area of expertise.
6. Collaborate with other standards development organizations and national and international sanctioning bodies (e.g. ANSI and ISO), in both the healthcare and information infrastructure domains to promote the use of supportive and compatible standards.
7. Collaborate with healthcare information technology users to ensure that HL7 standards meet real-world requirements, and that appropriate standards development efforts are initiated by HL7 to meet emergent requirements.

What Does the Name HL7 Mean

"Level Seven" refers to the highest level of the International Organization for Standardization (ISO) communications model for Open Systems Interconnection (OSI) - the application level. The application level addresses definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.

The name Health Level 7 symbolizes the seven-layer International Standards Organization (ISO) Communications Model:

1. Physical: Connects the entity to the transmission media                             

2. Data Link: Provides error control between adjacent nodes

3. Network: Routes the information in the network

4. Transport: Provides end-to-end communication control

5. Session: Handles problems that are not communication issues

6. Presentation: Converts the information

7. Application: Provides different services to the applications

 Why HL7

There are several health care standards development efforts currently underway throughout the world. Why then, embrace HL7? HL7 is singular as it focuses on the interface requirements of the entire health care organization, while most other efforts focus on the requirements of a particular department. Moreover, on an ongoing basis, HL7 develops a set of protocols on the fastest possible track that is both responsive and responsible to its members. The group addresses the unique requirements of already installed hospital and departmental systems, some of which use mature technologies.

While HL7 focuses on addressing immediate needs, the group continues to dedicate its efforts to ensuring concurrence with other United States and International standards development activities. Argentina, Australia, Canada, China, Czech Republic, Finland, Germany, India, Japan, Korea, Lithuania, The Netherlands, New Zealand, Southern Africa, Switzerland, Taiwan, Turkey and the United Kingdom are part of HL7 initiatives. Moreover, HL7 is an American National Standards Institute (ANSI) approved Standards Developing Organization (SDO). HL7 strives to identify and support the diverse requirements of each of its membership constituencies: Users, Vendors, and Consultants. Cognizant of their needs, requirements, priorities and interests, HL7 supports all groups as they make important contributions to the quality of the organization. The committee structure, balanced balloting procedures and open membership policies ensure that all requirements are addressed uniformly and equitably with quality and consistency.

How is HL7 Organized

The organization is managed by a Board of Directors, which is comprised of eight elected positions and three appointed positions. The organization is comprised of Technical Committees and Special Interest Groups that are responsible for defining the HL7 standard protocol. Each Technical Committee and Special Interest group is chaired by two or more co-chairs. Collectively, the co-chairs comprise the Technical Steering Committee, which votes on issues related to the standard. Votes of the Technical Steering Committee are passed as recommendations to the Board of Directors, who make the final decision. HL7 members are encouraged to participate in all of these committees.

---

New and Ongoing Initiatives

HIPAA

Health Level Seven's initial involvement in the HIPAA legislation began in 1996 with the formation of the Claims Attachments special interest group (since re-named simply the Attachment special interest group.) The Attachment Special Interest Group was formed to standardize the supplemental information needed to support health care insurance, and other e-commerce transactions. The initial deliverable of this group was six recommended Claims Attachments for the Notice of Proposed Rule Making (NPRM) process. Future attachment projects include, but are not limited to, Home Health, Skilled Nursing Facility, Durable Medical Equipment (DME), End Stage Renal Disease (ESRD), and Pre-Authorization and Referrals. An important effort as guided by the Board of HL7 the, Attachment special interest group is tasked with assisting in the implementation of the Administrative Simplification provisions of HIPAA mandates, providing on-going support, and to represent HL7 in the HIPPA Designated Standards Maintenance Organization (DSMO) efforts. Its purpose is to encourage the use of HL7 for uniform implementation of this supplemental information. This SIG coordinates industry input to produce and maintain guides for HL7 messages that can stand alone or be embedded within ASC X12N transactions.

Final copies of all HIPAA-mandated standards can be obtained from the Washington Publishing web site.

The Reference Information Model (RIM)

The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. An object model created as part of the Version 3 methodology, the RIM is a large pictorial representation of the clinical data (domains) and identifies the life cycle of events that a message or groups of related messages will carry. It is a shared model between all the domains and as such is the model from which all domains create their messages. Explicitly representing the connections that exist between the information carried in the fields of HL7 messages, the RIM is essential to our ongoing mission of increasing precision and reducing implementation cost.

Templates

An HL7 template is a data structure, based on the HL7 Reference Information Model, and which expresses the data content needed in a specific clinical or administrative context. They are prescribed patterns by which multiple OBX segments may be combined to describe selected, gross observations. Some observations may be quite simple, such as the blood pressure concept in healthcare, which involves a set of expected observations (i.e., systolic, diastolic, patient position, method, etc.) Other more elaborate diagnostic procedures may involve hundreds of related pieces of information, including anatomy, orientation, sequences of measurements, etc. Templates provide a means of coupling the multiple OBX segments needed to send the observation with separately encapsulated rules for combining/validating them for the particular observation. Based on user need and preference, the template offers the user the advantage of defining the collection of OBX segments needed and the corresponding set of validation rules once, and once, defined, the structure can be used again and again. Since they are based on a specific user's needs/requirements, Templates can be "plug and play" at a given user site.

HL7 approved the formation of the Templates Special Interest Group at its September 2000 meeting. The group will create normative standards for the definition of HL7 templates. These standards will provide that an HL7 template be composed of data structures drawn from the HL7 RIM, that make use of HL7 vocabulary domains. The group will also define the procedures for administering a meta-data repository to serve as the home for templates defined by HL7 bodies, HL7 members, and other parties, and will develop procedures and educational material to guide interested parties in the development of HL7 templates.

Vocabulary

HL7 learned long ago that while data can be exchanged between systems, its usefulness is compromised unless there is a shared, well defined, and unambiguous knowledge of the meaning of the data transferred. Since much of the data being transferred is coded, either by HL7 or other organizations, HL7 began a focused effort via the formation of the Vocabulary Technical Committee to organize and maintain vocabulary terms used in its messages.

This group is working to provide an organization and repository for maintaining a coded vocabulary that, when used in conjunction with HL7 and related standards, will enable the exchange of clinical data and information so that sending and receiving systems have a shared, well defined, and unambiguous knowledge of the meaning of the data transferred. The purpose of the exchange of clinical data includes, but is not limited to: provision of clinical care, support of clinical and administrative research, execution of automated transaction oriented decision logic (medical logic modules), support of outcomes research, support of clinical trials, and to support data reporting to government and other authorized third parties. To achieve this goal, the Vocabulary Technical Committee will work cooperatively with all other groups that have an interest in coded vocabularies used in clinical computing. Some of the groups that we will seek to work closely with include: standards development organizations, creators and maintainers of vocabularies, government agencies and regulatory bodies, clinical professional specialty groups, vocabulary content providers, and vocabulary tool vendors.

CCOW

The Clinical Context Object Workgroup  (CCOW) provides a standard where multiple systems can be opened and integrated with a single login - so, for example, a provider logs into the system once, and the CCOW standard is used to open the SAME patient in ADT, CPOE, lab results, and documentation systems.  There are multiple systems opened, but the login is transparent to the busy user who finds multiple logins annoying.   This work is now housed within the HL7 organization, but an easier place to learn more about it can be found at http://en.wikipedia.org/wiki/CCOW

Specifications

The Messaging Standard   Version 3.0  (this is the heart and meat of HL7)

Version 3.0 represents a significant departure from "business as usual" for HL7. Offering lots of optionality and thus flexibility, the V2.x series of messages were widely implemented and very successful. These messages evolved over several years using a "bottom-up" approach that has addressed individual needs through an evolving ad-hoc methodology. There is neither a consistent view of that data that HL7 moves nor that data's relationship to other data. HL7's success is also largely attributable to its flexibility. It contains many optional data elements and data segments, making it adaptable to almost any site. While providing great flexibility, its optionality also makes it impossible to have reliable conformance tests of any vendor's implementation and also forces implementers to spend more time analyzing and planning their interfaces to ensure that both parties are using the same optional features. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7's primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors' conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

 Back to Top

---

DICOM  messaging standard for radiology images

DICOM (Digital Imaging and Communications in Medicine) is an information technology  standard used to ensure the interoperability of imaging systems. Throughout the world, it is used by hospital medical systems involved with medical images and their related documents and workflow.

ACR (the American College of Radiology) and NEMA (the National Electrical Manufacturers Association) formed a joint committee to develop a standard for digital imaging and communications in medicine according to the NEMA procedures. The standard was developed in liaison with other standardization organizations including CEN TC251 in Europe and JIRA in Japan, with review also by other organizations including IEEE, HL7 and ANSI in the USA.

DICOM is an evolving standard, and is updated four to five times each year, and republished about once every 1-2 years. Proposals for enhancements come from the DICOM committee member organizations based on input from users of the standard. These proposals are considered for inclusion in future editions of the standard. *A requirement in updating the standard is to mainitain effective compatibility with previous editions.*

Link to the current standard documents: ftp://medical.nema.org/medical/dicom/2008/ .

Who needs DICOM?

Hospitals, clinics, imaging centers and specialists. By purchasing only equipment and information systems that conform to the DICOM Standard, you can ensure that these tools will work together to produce, manage and distribute your images regardless of your previous, current or future vendors.

Manufacturers of imaging equipment and imaging information systems. DICOM conformance ensures that every medical imaging facility is a potential customer, because your equipment can work with any workflow or electronic health record systems.

Manufacturers of peripheral equipment (e.g., film scanners, printers, computer monitors and workstations, image archives). DICOM conformance ensures that your products can work with all current or future imaging modalities and related peripheral equipment – regardless of vendor. DICOM’s purpose is to meet each of these diverse requirements.

Physicians have better access to images and reports when DICOM standards are in place. This allows them to make a faster diagnosis, potentially from anywhere in the world.

Patients can potentially obtain faster and more effective care when the DICOM Standard is used to send their information through the healthcare enterprise.

Payers benefit from this faster and more effective process through potentially lowered cost of care.

 

 

 

 

 

 

 

 

 

 

 

 

 

(Image retrieved March 14, 2007 from www.alibaba.com/catalog/11266392/DICOM_3_0.html)     
 

---

IHE FAQ page http://www.ihe.net/About/ihe_faq.cfm

X12N -messaging standard for financial data, HIPAA mandated transactions

In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for interindustry electronic exchange of business transactions-electronic data interchange (EDI). The EDI standards are developed and maintained by the Accredited Standards Committee (ASC) X12. The standards are designed to work across industry and company boundaries. Changes and updates to the standards are made by consensus,

Electronic Data Interchange (EDI) is the computer-to-computer exchange of business data in standard formats. In EDI, information is organized according to a specified format set by both parties, allowing a "hands-off" computer transaction that requires no human intervention or rekeying on either end. All information contained in an EDI transaction set is, for the most part, the same as on a conventionally printed document.

ASC X12  delivers a dictionary of data elements, data segments, business transactions, messaging & enveloping. All of these elements are updated three times/year via established review & approval procedures. These transactions are used across industries to support financial, manufacturing, transportation, retail supply, and many other chains.

The Health Insurance Portability & Accountability Act (HIPAA) transaction regulation was published in 2000, adopting nine X12 transactions for the health care industry. ASC X12 signs MOU with the Department of Health & Human Services (HHS), Standards Development Organizations (SDOs) & Data Content Committees (DCCs) to manage the EDI standards adopted under HIPAA.

The X12 and UN/EDIFACT standards specify only the format and data content of e-business transactions. They do not define how interchange partners shall establish the required communications link to exchange EDI data. Users may choose any EDI and communications software that supports use of the standards. The standards do not address this choice; they simply establish the format and define the data contents of the EDI messages and control standards.

X12N standards include transactions for claims/encounters, attachments, enrollment, disenrollment, eligibility, payment/remittance advice, premium payments, first report of injury, claim status, referral certification/authorization, and coordination of benefits.

Within these standard transactions, the code set standard for diagnoses are those of the International Classification of Diseases - Clinical Modification (ICD-CM); procedures are categorized using Current Procedural Terminology (CPT) codes, Healthcare Common Procedure Coding System (HCPCS) or, for dental procedures, the Code on Dentral Procedures and Nomenclature (CDT).  

Back to Top

---

NCPDP messaging standard for pharmacy business functions, HIPAA mandated transactions

IEEE messaging standards for Bedside instruments, home of the medical information bus

IEEE 802 refers to a family of IIEE standards dealing with Local Area networks and Metropolital Area networks. More specifically, the IEEE 802 standards are restricted to networks carrying variable-size packets. The number 802 was simply the next free number IEEE could assign, though "802" is sometimes associated with the date the first meeting was held - February 1980. These are the standards used in most wireless technology within an institution and /or within a close geographical are. These standards were not suitable and robust enough to support bedside monitoring interoperability. Therefore new standards in the IEEE 1073 family were created.

 

IEEE 1073 What is a medical information bus? The P1073 medical information bus (MIB) family of three proposed IEEE standards, which provide vendor-independent interconnection and interoperability of medical devices and computer systems, is described. The MIB uses a layered network architecture that is compatible with International Standards Organization/Open Systems Interconnection (ISO/OSI) specifications. The standards primarily focus on the acute care environment at the patient's bedside, particularly when this environment is in the intensive care area of the hospital. However, the MIB is suitable for use in other areas such as the operating room or the general ward. The bus can also interface to any general clinical equipment for simple data communication and control purposes. The technology needs to include the following:

• wireless coexistence
• performance
• data integrity
• security
• electromagnetic compatibility (EMC).

 

The MIB standard allows clinicians to link patient-connected bedside medical devices to a bedside patient-monitoring device or a computer network in a simple fashion. The standard is designed for highly mobile medical devices such as infusion pumps, ventilators and patient monitors that are connected and disconnected to networks multiple times a day by healthcare providers who are not electronics technicians.

The Medical Device Communications Industry Group was formed in 1999 as a complimentary program of the IEEE-ISTO.

This group provides a forum for medical device vendors to work together to support and accelerate the development of the IEEE 1073 Standards, foster adoption of the family of standards by medical device vendors and healthcare providers as well as market and demonstrate the capabilities of standardized medical data communications. 

https://mentor.ieee.org/802.15/file/07/15-07-0725-01-0ban-communication-requirements-from-ieee-1073.ppt#1

 

http://www.ieee.org/web/standards/home/index.html

 Back to Top

http://www.x12.org/

http://privacy.med.miami.edu/glossary/xd_x12n.htm