This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Product V3"

From HL7Wiki
Jump to navigation Jump to search
Line 35: Line 35:
 
====Administrative Management====
 
====Administrative Management====
 
*ANSI/HL7 V3 SC, R1-2003; HL7 Version 3 Standard: [[Product_SC|Scheduling]], Release 1
 
*ANSI/HL7 V3 SC, R1-2003; HL7 Version 3 Standard: [[Product_SC|Scheduling]], Release 1
−
*ANSI/HL7 V3 CR: R1-2004, R2-2004, R3-2005, R4-2008; Version 3 Standard: [[Product_CS|Claims and Reimbursements]]
+
*ANSI/HL7 V3 CR: R1-2004, R2-2004, R3-2005, R4-2008; Version 3 Standard: [[Product_CR|Claims and Reimbursements]]
 
**[http://www.hl7.org/dstucomments/ DSTU]: HL7 Version 3 Standard: [[Product_CR|Claims & Reimbursement]]; Special Authorization, Release 1; ends May 2011
 
**[http://www.hl7.org/dstucomments/ DSTU]: HL7 Version 3 Standard: [[Product_CR|Claims & Reimbursement]]; Special Authorization, Release 1; ends May 2011
 
*ANSI/HL7 V3 AB: R1-2005, R2-2008; HL7 Version 3 Standard: [[Product_AB|Accounting & Billing]]
 
*ANSI/HL7 V3 AB: R1-2005, R2-2008; HL7 Version 3 Standard: [[Product_AB|Accounting & Billing]]

Revision as of 17:39, 17 November 2009

Product Brief - V3: Version 3 Normative Edition Product Suite

back to Main_Page
back to Product_List

Product Suite

V3: Version 3 Normative Edition

Topics

Standard Category

Health Information Exchange Standards

Integration Paradigm

Messaging

Type

Normative, ANSI Standard

Products

Foundation

  • ANSI/HL7 V3 RCL: R1-2003, R2-2007; HL7 Version 3 Standard: Refinement, Constraint, and Localization to version 3 Messages
  • ANSI/HL7 V3 RIM, R1-2003; HL7 Version 3 Standard: Reference Information Model, Release 1
  • ANSI/HL7 V3 XMLITSDT, R1-2004; HL7 Version 3 Standard: XML Implementation Technology Specification - Data Types
  • ANSI/HL7 V3 UMLITSDT, R1-2004; HL7 Version 3 Standard: UML Implementation Technology Specification - Data Types
  • ANSI/HL7 V3 DT, R1-2004; HL7 Version 3 Standard: Data Types - Abstract Specification, Release 1
  • ANSI/HL7 V3 CTS, V1-2005, ISO/HL7 27951:2009(E); HL7 Version 3 Standard: Common Terminology Services, Release 1
  • ANSI/HL7 V3 GELLO, R1-2005; HL7 Version 3 Standard: GELLO: A Common Expression Language, Release 1
  • ANSI/HL7 V3 TRMLLP, R2-2006; HL7 Version 3 Standard: Transport Specification - MLLP, Release 2
  • ANSI/HL7 V3 RBAC, R1-2008; HL7 Version 3 Standard: Role-based Access Control Healthcare Permission Catalog, Release 1
  • ANSI/HL7 V3 TR ebXML, R1-2008; HL7 Version 3 Standard: Transport Specification - ebXML, Release 1
  • DSTU - HL7 V3 Templates - HL7 Version 3 Standard: Specification and Use of Reusable Constraint Templates, Release 2; ends Feb 2010, not promoting to Normative

Common Domains

Administrative Management

Specification Infrastructure/Messaging

Health and Clinical Management

Summary

Version 3 is HL7’s family of standards developed with a model-driven methodology. The release of HL7’s Version 3 Normative Edition marks a quantum leap in the functionality and interoperability of messaging standards. Version 3 is one of the first in the industry to embrace XML. Several countries have already begun significant Version 3 implementations, including the United Kingdom, Canada, the Netherlands, Mexico, Germany and Croatia.

Description

Version 3 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.

The Health Level Seven Version 3 (V3) Normative Edition—a suite of specifications based on HL7’s Reference Information Model (RIM)—provides a single source that allows implementers of V3 specifications to work with the full set of messages, data types, and terminologies needed to build a complete implementation. The 2008 edition represents the third publication of a complete suite of V3 specifications, each of which has received formal approval as either a Normative Standard or a Draft Standard for Trial Use. It includes standards for communications to document and manage the care and treatment of patients in a wide variety of healthcare settings. As such, it is a foundational part of the technologies needed to meet the global challenge of integrating healthcare information, in areas such as patient care and public health. Throughout the course of V3 development, HL7 has focused on a few salient features that are its hallmarks. In brief, these are:

  • A focus on semantic interoperability by specifying that information be presented in a complete clinical context that assures that the sending and receiving systems share the meaning (semantics) of the information being exchanged;
  • It’s designed for universal application so that the standards can have the broadest possible global impact and yet be adapted to meet local and regional requirements;
  • Model-based specifications that provide consistent representation of data laterally across the various HL7 domains of interest and longitudinally over time as new requirements arise and new fields of clinical endeavor are addressed;
  • Technology-neutral standards that allow HL7 and the implementers of HL7 standards to take advantage, at any point in time, of the latest and most effective implementation technologies available; and
  • It’s founded on a development methodology and metamodel that assures consistent development and the ability to store and manipulate the specifications in robust data repositories rather than as word-processing documents.

The Version 3 suite represents a new approach to clinical information exchange. It is built from the ground up around a single object model, the RIM, and a rigorous UML-based methodology that ties model to messages and finally to the message’s expression in XML syntax. The V3 specification is built around subject domains, for each of which it provides storyboard descriptions, trigger events, interaction designs, domain object models derived from the RIM, hierarchical message descriptors (HMDs) and a prose description of each element. Implementation of these domains further depends upon a non-normative V3 Guide and normative specifications for: data types; the XML implementable technical specifications (ITS) or message wire format; message and control “wrappers;” and transport protocols. Members logged in to the HL7 website may download V3 standards at: http://www.hl7.org/memonly/downloads.

Business Case (Intended Use, Customers)

Benefits

Why Version 3?

Healthcare costs evermore dominate national economies, and Draconian measures to control cost have hampered provider effectiveness and impacted citizen satisfaction and safety. Information Technology (IT) has helped, and is on the verge of being able to help much more. Version 3 will be a key part of the contribution of IT to healthcare's reaching new levels of

  • effective and cost-efficient patient care decisions
  • safety and cost savings that come from "doing it right," in the sense of preventing avoidable errors
  • the aggregation of health information for evidence-based medicine and data-based policy

Many general IT advances create the foundation for this new capability. These include:

  • The exponential increase of processing and storage capacity described by Moore's law
  • Enhancements in user interfaces such as voice entry and smarter programs that apply knowledge to limiting required information input
  • An increasing variety of devices for personal access to, and collection of information at the point of care and at points far distant from the point of care
  • The build-out of the Internet and related standards to create a ubiquitous, inexpensive infrastructure for secure communication of information among independent entities
  • The maturing of XML and related standards to provide a means for easy-to-program, highly extensible, robust exchange of information among information systems

These IT advances are important enablers, but the most intractable barrier to their use in healthcare has been the lack of standards for exchanging fine-grained, highly heterogeneous, structured clinical data among information systems created by different entities using different technologies. Since its inception in 1987, HL7 Version 2 has enabled information exchange among systems created by different entities. Indeed, Version 2 is so widely used that it will not soon go away and the Board is committed to continuing to evolve it as long as there is a clear need. However, where users have used Version 2 for fine-grained, structured clinical data, they have accomplished it through substantial investments in bilateral negotiations adapting it to establish specifications for representing fine-grained, clinical knowledge. Efforts to aggregate on a larger scale, for research or public health have had the same issue.

The strength of Version 3 messaging is precisely enabling the exchange of fine-grained data without the original research and bilateral negotiations that leading-edge organizations have attempted. Furthermore, you will find that we are reaching this in a way that is as future proof as any standards effort can be.

Implementations/ Case Studies (Actual Users)

  1. NHS-England has over 1 million primary care prescriptions issued per day; the vast majority are entered onto physicians own systems, and probably half now flow through the electronic prescription service.
  2. An EPS transaction in release 2 covers dispensing and re-imbursement, with messages flowing between physician, pharmacy, reimbursement centre and a central repository.
  3. Most spine transactions involve a demographics access; all are keyed on the NHS patient number. Hence a single transaction always has multiple messages.
  4. We do not store patient demographic details in the summary record; they are linked in through the demographic service.
  5. The statistics are for England.

Resources

Implementation FAQ : Getting Started (wiki page)

How do I begin?

Three conceptual models that form the basis of version 3 messages:

  1. The Reference Information Model (RIM), which is now an ANSI standard, has evolved into a simple abstract framework which addresses the wildly heterogeneous and interlinked nature of clinical data with only six important classes. We have similarly simplified the representation of administrative data.
  2. In the Domain Information Model (D-MIM) you will see how the abstract RIM is made specific to define the information elements for a domain or specialty area.
  3. In the Refined Message Information Model (R-MIM) you will see how the D-MIM is refined to define the information elements of a family of messages.

A fourth model, the vocabulary model, provides the tools to deal with previously intractable problems of multiple vocabularies across organizational or national boundaries.

The Hierarchical Message Description is a convenient way to organize a mass of details about the contents of specific messages, providing the most authoritative list of all the constraints and detailed semantic definitions not appropriate in the more abstract representations.

Finally, in the Implementable Technology Specification you will see how this information is represented as XML Schemas.

These deliverables are the basis of our belief that the Version 3 Messaging standards will be easily extended over time to incorporate new standards, deal with unanticipated requirements and even address areas of standardization other than application-to-application messages.

See also the HL7 wiki page for Overcoming the Learning Curve

Work Groups

Education

Certification Available
  • RIM Certified Specialist (See RIM Product Page for more details)

Presentations

From HIMSS 2009

Relationship to/ Dependencies on, other standards

  • none

Links to current projects in development

  • See individual domain areas for current work in progress
Retrieved from "https://wiki.hl7.org/w/index.php?title=Product_V3&oldid=29279"