What is HL7?

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.

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

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 was 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. In January 2005, the HL7 Membership ratified Release 2 of CDA.

The initial release of Version 3 will use only XML encoding.

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

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.

Version 2.5

APPROVED AS AN ANSI STANDARD JUNE 26, 2003.

The HL7 Version 2 Messaging Standard — Application Protocol for Electronic Data
Exchange in Healthcare Environments — is considered to be the workhorse of data
exchange in healthcare and is the most widely implemented standard for healthcare
information in the world.

HL7 Version 2.5 introduces a number of new events, segments and messages, as
well as a significantly expanded chapter on Control. Version 2.5 is more consistent
and supports more functionality than any of the previous versions. Modifications from
Version 2.4 include:

• Improved documentation of the data types

• The definition of a message profile methodology
• Better support for imaging (IHE) by means of a new segment and a new
order message
• Support for orders related to blood products
• A new message that supports diagnoses/procedure messages in 'update'
mode

Version 2.4

APPROVED AS AN ANSI STANDARD OCTOBER 6, 2000.

View Errata View Addendum

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.

The structure of the Version 2.4 publication is highlighted below.

Click here for a brief introduction to HL7 messaging.

Chapter Name Content

1 - Introduction Overview of HL7.
2 - Control Message Definitions, Interchange Protocols.
3 - Patient Administration Admit, Discharge, Transfer, and Demographics.
4 - Order Entry Orders for Clinical Services and Observations, Pharmacy,
Dietary, and Supplies.
5 - Query Rules applying to queries and to their responses.
6 - Financial Management Patient Accounting and Charges.
7 - Observation Reporting Observation Report Messages.
8 - Master Files Health Care Application Master Files.
9 - Medical Document Management Services and Resources.
Records/Information
Management
10 - Scheduling Appointment Scheduling and Resources.
11 - Patient Referral Primary Care Referral Messages.
12 - Patient Care Problem-Oriented Records.
13 - Laboratory Equipment status, specimen status, equipment inventory,
Automation equipment comment, equipment response, equipment
notification, equipment test code settings, equipment
logs/service.
14 - Application Application control-level requests, transmission of
Management application management information.
15 - Personnel Professional affiliations, educational details, language
Management detail, practitioner organization unit, practitioner detail,
staff identification.
Appendix A- Data All HL7 and User-defined tables and their values.
Definition Tables
Appendix B- Lower Layer Protocols for lower layer of OSI model.
Protocols
Appendix C-BNF Message BNF representations of abstract message definitions at
Descriptions the segment level.
Appendix D-Glossary Glossary of terms.

Version 2.3.1

APPROVED AS AN ANSI STANDARD April 14, 1999.

View Errata View Addendum

HL7 V.2.3.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.

The structure of the Version 2.3.1 publication is highlighted below.

Click here for a brief introduction to HL7 messaging.

Chapter Name Content
1 - Introduction Overview of HL7.
2 - Control Message Definitions, Interchange Protocols.
3 - Patient Administration Admit, Discharge, Transfer, and Demographics.
4 - Order Entry Orders for Clinical Services and Observations,
Pharmacy, Dietary, and Supplies.
5 - Query Rules applying to queries and to their responses.
6 - Financial Management Patient Accounting and Charges.
7 - Observation Reporting Observation Report Messages.
8 - Master Files Health Care Application Master Files.
9 - Medical Records/Information Document Management Services and Resources.
Management
10 - Scheduling Appointment Scheduling and Resources.
11 - Patient Referral Primary Care Referral Messages.
12 - Patient Care Problem-Oriented Records.
Appendix A- Data Definition All HL7 and User-defined tables and their values.
Tables
Appendix B- Lower Layer Protocols for lower layer of OSI model.
Protocols
Appendix C - Network Application control-level requests, transmission of
Management application management information.
Appendix C-BNF Message BNF representations of abstract message definitions
Descriptions at the segment level.
Appendix D-Glossary Glossary of terms.

Version 2.3

APPROVED AS AN ANSI STANDARD May 13, 1997

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.

The structure of the Version 2.3 publication is highlighted below.

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 structure of the Version 2.3 publication is highlighted below.

Click here for a brief introduction to HL7 messaging.

Chapter Name Content
1 - Introduction Overview of HL7.
2 - Control Message Definitions, Interchange Protocols.
3 - Patient Administration Admit, Discharge, Transfer, and Demographics.
4 - Order Entry Orders for Clinical Services and Observations,
Pharmacy, Dietary, and Supplies.
5 - Query Rules applying to queries and to their responses.
6 - Financial Management Patient Accounting and Charges.
7 - Observation Reporting Observation Report Messages.
8 - Master Files Health Care Application Master Files.
9 - Medical Records/Information Document Management Services and Resources.
Management
10 - Scheduling Appointment Scheduling and Resources.
11 - Patient Referral Primary Care Referral Messages.
12 - Patient Care Problem-Oriented Records.
Appendix A- Data Definition All HL7 and User-defined tables and their values.
Tables
Appendix B- Lower Layer Protocols for lower layer of OSI model.
Protocols
Appendix C - Network Application control-level requests, transmission of
Management application management information.
Appendix C-BNF Message BNF representations of abstract message definitions
Descriptions at the segment level.
Appendix D-Glossary Glossary of terms.

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

The structure of the Version 1.3 publication is highlighted below:

Chapter Name Content

Context Management Specifies the Health Level Seven Context Management
("CCOW") Specification Architecture (CMA). This architecture enables multiple
Technology- and Subject- applications to be automatically coordinated and
Independent Component synchronized in clinically meaningful ways at the point-
Architecture of-use. The architecture specified in this document
establishes the basis for bringing interoperability among
healthcare applications to the point-of-use, such as the
clinical desktop
Context Management Provides a specification of the standard context data
("CCOW") Specification items that are supported for all subjects in the HL7
Subject Data Definitions Context Management Architecture (CMA) as well as
custom subjects and items that are not defined explicitly
in this version of the CMA.
Context Management Specifies the user interface requirements and guidelines
("CCOW") Specification for Microsoft Windows™ -based and web browser-based
User Interface: Microsoft applications that are compliant with the HL7 Context
Windows and Web Browser Management Specification, Technology- And Subject-
Independent Component Architecture.
Context Management Specifies the details needed to develop Microsoft ActiveX
("CCOW") specification implementations of applications and components that
Component Technology conform to the HL7 Context Management Architecture
Mapping: ActiveX (CMA).
Health Level-Seven Specifies the details needed to develop web
Standard Context implementations of applications and components that
Management ("CCOW") conform to the HL7 Context Management Specification,
Specification Component Technology- And Subject- Independent Component
Technology Mapping: Web Architecture.

Version 1.2

APPROVED AS AN ANSI STANDARD September 21, 2000

Version 1.2 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)

The structure of the Version 1.2 publication is highlighted below:

Chapter Name Content

Context Management Specifies the Health Level Seven Context Management
("CCOW") Specification Architecture (CMA). This architecture enables multiple
Technology- and Subject- applications to be automatically coordinated and
Independent Component synchronized in clinically meaningful ways at the point-
Architecture of-use. The architecture specified in this document
establishes the basis for bringing interoperability
among healthcare applications to the point-of-use, such
as the clinical desktop.
Context Management Provides a specification of the standard context data
("CCOW") Specification items that are supported for all subjects in the HL7
Subject Data Definitions Context Management Architecture (CMA) as well as
custom subjects and items that are not defined
explicitly in this version of the CMA.
Health Level-Seven Standard Specifies the user interface requirements and
Context Management guidelines for Microsoft Windows™ -based and web
("CCOW") Specification User browser-based applications that are compliant with the
Interface: Microsoft Windows HL7 Context Management Specification, Technology-
and Web Browser version And Subject- Independent Component Architecture.
Health Level Seven Standard Specifies the details needed to develop Microsoft
Context Management ActiveX implementations of applications and
("CCOW") Specification components that conform to the HL7 Context
Component Technology Management Architecture (CMA). Using this
Mapping: ActiveX specification, the resulting applications and service
components will be able to communicate with each
other per the CMA even if they were independently
developed.
Health Level-Seven Standard Specifies the details needed to develop web
Context Management implementations of applications and components that
("CCOW") Specification conform to the HL7 Context Management Specification,
Component Technology Technology- And Subject- Independent Component
Mapping: Web Architecture.

Version 1.1

APPROVED AS AN ANSI STANDARD March 15, 2000

Version 1.1 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.
The structure of the Version 1.1 publication is highlighted below:

Chapter Name Content

Context Management Specifies the Health Level Seven Context Management
("CCOW") Specification Architecture (CMA). This architecture enables multiple
Technology- and Subject- applications to be automatically coordinated and
Independent Component synchronized in clinically meaningful ways at the point-of-
Architecture use. The architecture specified in this document
establishes the basis for bringing interoperability among
healthcare applications to the point-of-use, such as the
clinical desktop.
Context Management Provides a specification of the standard context data
("CCOW") Specification items that are supported for all subjects in the HL7
Subject Data Definitions Context Management Architecture (CMA) as well as
custom subjects and items that are not defined explicitly
in this version of the CMA.
Health Level-Seven Specifies the user interface requirements and guidelines
Standard Context for Microsoft Windows -based applications that are
Management ("CCOW") compliant with the HL7 Context Management
Specification User Specification, Technology- And Subject- Independent
Interface: Microsoft Component Architecture.
Windows
Health Level Seven Specifies the details needed to develop Microsoft ActiveX
Standard Context implementations of applications and components that
Management ("CCOW") conform to the HL7 Context Management Architecture
Specification Component (CMA). Using this specification, the resulting applications
Technology Mapping: and service components will be able to communicate with
ActiveX each other per the CMA even if they were independently
developed.

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 structure of the Version 1.0 publication is highlighted below:

Chapter Name Content

Context Management Specifies the Health Level Seven Context Management
("CCOW") Specification Architecture (CMA). This architecture enables multiple
Technology- and Subject- applications to be automatically coordinated and
Independent Component synchronized in clinically meaningful ways at the point-
Architecture of-use. The architecture specified in this document
establishes the basis for bringing interoperability among
healthcare applications to the point-of-use, such as the
clinical desktop.
Context Management Specifies the standard context data items that are
("CCOW") Specification available for applications to use in setting and accessing
Subject Data Definitions: the common clinical context.
Patient Subject
Context Management Specifies the standard context data items that are
("CCOW") Specification, available for applications to use in setting and accessing
Data Definition: User the common clinical context.
Subject
Health Level Seven Specifies the details needed to develop Microsoft ActiveX
Standard Context implementations of applications and components that
Management ("CCOW") conform to the HL7 Context Management Architecture
Specification Component (CMA). Using this specification, the resulting applications
Technology Mapping: and service components will be able to communicate with
ActiveX each other per the CMA even if they were independently
developed.
Context Management Specifies the user interface when using the common
Specification, User clinical context component as specified by the Clinical
Interface: Microsoft Context Object Workgroup (CCOW).
Window, OS.

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.