Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.cplire.ru/rus/telemed/HL7/WhatIsHL7.doc Дата изменения: Tue Dec 10 19:03:40 2002 Дата индексирования: Tue Oct 2 09:10:10 2012 Кодировка: Поисковые слова: туманность андромеды

What is HL7?
(http://www.hl7.org/about/)


General


HL7 mission
Health Level Seven is one of several 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. Our mission is to:

"To provide standards for the exchange, management and integration of data
that support clinical patient care and the management, delivery and
evaluation of healthcare services. Specifically, to create flexible, cost
effective approaches, standards, guidelines, methodologies, and related
services for interoperability between healthcare information systems."

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.

What Does the Name HL7 Mean

"Level Seven" refers to the highest level of the International Standards
Organization's (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.

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 as 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



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 costs.

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.

XML

Health Level Seven has been actively working with XML technology since
the formation of the SGML/XML Special Interest Group in September of
1996. Since that time, the SGML/XML group has evolved into two separate
groups:
. the XML Special Interest Group - which supports the HL7 mission
through recommendations on use of Extensible Markup Language (XML)
standards for all of HL7's platform- and vendor-independent
healthcare specifications.
. the Structured Documents Technical Committee - which support the HL7
mission through development of structured document standards for
healthcare.

Both of these groups have produced work items that have been ratified by
the HL7 membership. In 1999, HL7 endorsed a recommendation for using XML
as an alternative syntax for HL7 V2.3.1 messages. This recommendation was
informative in nature (not required for compliance) and was thus not
submitted to ANSI for approval. However, an XML encoding for Version 2.4
will be balloted and submitted for approval to ANSI in early 2001.



In September 2000, the HL7 membership ratified Version 1 of the Clinical
Document Architecture, which defines an XML architecture for exchange of
clinical documents. The encoding is based on XML DTDs included in the
specification and its semantics are defined using the HL7 RIM (Reference
Information Model) and HL7 registered coded vocabularies. This is a
normative document that will be submitted to ANSI for approval.

The initial release of Version 3, slated for publication in December
2001, will use only XML encoding. The first of the suite of documents to
comprise Version 3, the Version 3 Abstract Data Types and its
accompanying XML Implementation Technology Specification, passed the
Committee Level Ballot in September of this year, but will return for
another Committee Level Ballot for January 2001.

HL7 actively participates in and supports the W3C, the organization
responsible for the development of XML.

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 HIPAA
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.















Specifications



The Messaging Standard

Version 3.0

Version 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 initial release of Version 3, slated for publication in December
2001, will use only XML encoding. The first of the suite of documents to
comprise Version 3, the Version 3 Abstract Data Types, its accompanying
XML Implementation Technology Specification, and the V3 Messages XML
Implementation Specification will be balloted by the HL7 membership prior
to the January 2001 meeting.

Version 2.4

APPROVED AS AN ANSI STANDARD OCTOBER 6, 2000.

HL7 v.24 introduces Conformance Query profiles in chapters 5, and adds
messages for laboratory automation, application management and personnel
management. Additionally, a new event, specific to OPPS and APC
requirements was added. This event, Transmit Ambulatory Payment, includes
two new segments, the Grouping/Reimbursement Visit Segment and the
Grouping Reimbursement Procedure Segment.

Version 2.3.1

APPROVED AS AN ANSI STANDARD April 14, 1999.

HL7 V.23.1 includes an updated TQ (timing/quantity) datatype to manage
order occurrences, updates to the OBR segments and ORU message to
facilitate public health surveillance reporting, updates to tables,
segments and data types to accommodate international paradigms for
reporting names and pharmacy orders, and the addition of a new field to
the ORC segment to satisfy the HCFA Medical Necessity requirements for
outpatient services, and an update to the FT segment to satisfy federal
requirements for Level 2 Modifiers.

Version 2.3

APPROVED AS AN ANSI STANDARD April 14, 1999.

HL7 V.2.3 includes an updated TQ (timing/quantity) datatype to manage
order occurrences, updates to the OBR segments and ORU message to
facilitate public health surveillance reporting, updates to tables,
segments and data types to accommodate international paradigms for
reporting names and pharmacy orders, and the addition of a new field to
the ORC segment to satisfy the HCFA Medical Necessity requirements for
outpatient services, and an update to the FT segment to satisfy federal
requirements for Level 2 Modifiers.

APPROVED AS AN ANSI STANDARD May 13, 1997

HL7 V.2.3 introduces document management messages, messages for
appointment servicing and resource scheduling, messages for patient
referrals and messages to track patient goals.

The Clinical Document Architecture

APPROVED AS AN ANSI STANDARD November 2000.

The CDA, which was until recently known as the Patient Record
Architecture (PRA), provides an exchange model for clinical documents
(such as discharge summaries and progress notes)-and brings the
healthcare industry closer to the realization of an electronic medical
record. The CDA Standard is expected to be published as an ANSI approved
standard by the end of the year.

By leveraging the use of XML, the HL7 Reference Information Model (RIM)
and coded vocabularies, the CDA makes documents both machine-readable-so
they are easily parsed and processed electronically-and human-readable-so
they can be easily retrieved and used by the people who need them. CDA
documents can be displayed using XML-aware Web browsers or wireless
applications such as cell phones.



The Clinical Context Management Specification (CCOW)

Version 1.3

Introduces the following enhancements:
. Definition for an annotation agent (a component that is allowed to
add data to the clinical context)
. Definition for a user's digital certificate subject (which is the
first annotation subject)
. Definition of the observation subject (which identifies a real-world
clinical observation)

Version 1.2

APPROVED AS AN ANSI STANDARD September 21, 2000

Introduced the following enhancements:
. Definition for an annotation agent (a component that is allowed to
add data to the clinical context)
. Definition for a user's digital certificate subject (which is the
first annotation subject)
. Definition of the observation subject (which identifies a real-world
clinical observation)

Version 1.1

APPROVED AS AN ANSI STANDARD March 15, 2000

Introduced the following enhancements:
. Definition an Encounter subject
. Support for defining custom subjects
. Addition of BNF notation for describing syntax of the various
strings used throughout the specification
. Details for supporting ActiveX implementations using DCOM and
Windows Terminal Server.

Version 1.0

APPROVED AS AN ANSI STANDARD July 26, 1999

This was the first version of the Clinical Context Management
Specification that was ballot by HL7.







The Arden Syntax for Medical Logic Systems

APPROVED AS AN ANSI STANDARD July 26, 1999

The Arden Syntax for Medical Logic Systems Version 2.0 was the initial
version of the standard balloted by HL7. Version 1.0 was balloted and is
maintained by the ASTM.

Developed by HL7's Arden Syntax and Clinical Decision Support technical
committee, this standard is a language for representing and sharing
medical knowledge among personnel, information systems and institutions.
It is designed for organizations that require or develop systems that
automatically assist physicians in decisions and alerts. The logic for
making these decisions or issuing these alerts is encoded into health
knowledge bases called MLM, each of which contains sufficient knowledge
to make a single decision. Contradiction alerts, management suggestions,
data interpretations, treatment, protocols, and diagnosis scores are
examples of the health knowledge bases than can represented using the
Arden Syntax.

HL7 Intellectual Property

Health Level Seven, Inc., asserts and retains copyright in all works
contributed by members and non-members relating to all versions of the
Health Level Seven standards and related materials unless other
arrangements are specifically agreed upon in writing.