ORIGINAL PAPERIntegration of IEEE 1451 and HL7 Exchanging .docx

ORIGINAL PAPER
Integration of IEEE 1451 and HL7 Exchanging Information
for Patients’ Sensor Data
Wooshik Kim & Suyoung Lim & Jinsoo Ahn &
Jiyoung Nah & Namhyun Kim
Received: 19 March 2009 /Accepted: 26 May 2009 /Published
online: 17 June 2009
# The Author(s) 2009. This article is published with open access
at Springerlink.com
Abstract HL7 (Health Level 7) is a standard developed for
exchanging incompatible healthcare information generated
from programs or devices among heterogenous medical
information systems. At present, HL7 is growing as a
global standard. However, the HL7 standard does not
support effective methods for treating data from various
medical sensors, especially from mobile sensors. As
ubiquitous systems are growing, HL7 must communicate
with various medical transducers. In the area of sensor
fields, IEEE 1451 is a group of standards for controlling
transducers and for communicating data from/to various
transducers. In this paper, we present the possibility of
interoperability between the two standards, i.e., HL7 and
IEEE 1451. After we present a method to integrate them
and show the preliminary results of this approach.
Keywords Smart transducer. HL7 . IEEE 1451 .
Sensor network . u-healthcare

Introduction
HL7 is a messaging standard for exchanging medical
information that is becoming a world standard. Among
medical information such as a text or an image, HL7 deals
with text information (HL7 Organization. [http://www.hl7.
org]; HL7 Version 2.5.1 Messaging Standard). Recently, as
the ubiquitous era is approaching, a new type of informa-
tion, i.e., streaming data, has appeared. These data usually
come from sensors from various networks such as wireless
LANs, wired LANs, or cellular networks and increasingly
have important role in e-healthcare, u-healthcare, and other
health systems. Since various wireless networks are widely
spread and the performances of many devices such as
PDAs, notebooks, or cellular phones improve, the use of
sensors for patients will become popular as well, and thus
the quality of life for patients will improve. Sooner or later,
HL7 should include information from mobile patients,
mobile devices, and mobile sensors.
In the area of electrical and mechanical engineering,
sensors have been used for a long time to check and
monitor the status of machines and devices. In these areas,
there has been a group of standards IEEE 1451 which deal
with various aspects of sensors, such as the definition of
sensors and actuators, the format of data sheets, and how to
connect and disconnect the sensors from a system. Also,
these standards deal with communication protocols. Re-
cently, the advent of various sensors such as wireless
sensors has led the IEEE to develop a complete set of
standards that deal with these types of sensors [1–5]. The
family of IEEE 1451 standards will become a global
standard in all areas that use sensors.
This paper studies the possibilities of the interoperability

of the two standards; IEEE 1451 and HL7 v2.5. HL7 v2.5
is more suitable for processing steaming data than HL7 v3.
J Med Syst (2010) 34:1033–1041
DOI 10.1007/s10916-009-9322-5
W. Kim (*) : J. Ahn
Department of Information and Communication Engineering,
Sejong University,
98 Gunja-Dong, Gwangjin-Gu,
Seoul 143-747, South Korea
e-mail: [email protected]
S. Lim
MtekVision,
Seoul, South Korea
J. Nah : N. Kim
Department of Biomedical Engineering, College of Medicine,
Yonsei University,
Seoul, South Korea
http://www.hl7.org
Since the data structure of the TEDS (Transducer Electronic
data sheet), which is the core of IEEE 1451, and the format
of the HL7 message are different, we implemented a new
messaging format for communicating data among the TEDS
and HL7 v2.5 based applications or systems. Based on this,
we implemented this engine into a hardware platform
including a PDA, sensors, and wireless and wired LAN.
This paper is organized as follows. In Section 2, we
introduce the three standards: IEEE 1451, HL7, and IEEE
11073. In Section 3, we consider the interoperability of the

HL7 and IEEE 1451. Finally, in Section 4, we show the
results of implementation.
IEEE 1451, HL7, and IEEE 11073
IEEE 1451
The IEEE 1451 is composed of several standards that are
concerned with smart transducers. Transducers are usually
composed of sensors and actuators. The IEEE 1451 deals
with data formats, communication protocols of the trans-
ducers and other devices [1–4]. Here, the transducers are
said to be smart if they have three characteristics. The first
is that the transducers are described by machine-readable
transducer electronic data sheets (TEDS). The second is
that the control and data associated with the transducers are
digital. Finally, to work the transducer properly, we must
use triggering, status, and control [1].
The merits of using IEEE 1451 based transducers are as
follows. First, the IEEE 1451-based transducers provide
plug-and-play capabilities. In other words, the transducers
can be connected through physical communication media
without changing system software. When we attach or
detach transducers from a patient, we do not have to worry
about system functions such as configuration. The second
merit is that the data that describe the patients and sensors
that the patients are wearing can be stored in TEDS so that
the information for the identification of a patient is
automatically transmitted to a hospital or an emergency
center. Also, IEEE 1451-based transducers can reduce
human error, which may occur when operators send signals
by hand. Considering these reasons, IEEE 1451 based
transducers are useful in medical fields as well as other
professional disciplines.

The structure of the transducers and their networks
defined by the IEEE 1451 standards is shown in Fig. 1 [5].
On the left side, there are smart transducers which are
composed of sensors, actuators, A/D converters, and simple
signal processing units. The data measured from sensors are
transmitted to an NCAP (Network capable application
processor), which resides at the other side of the figure.
These data are again transmitted to other places via other
networks including LANs and cellular networks.
IEEE 1451 is composed of several standards. The
relationship among these standards is shown in Fig. 2.
Among the standards that compose the IEEE family of
standards, 1451.0 is the most important. This standard
provides a common framework or all the standards in the
IEEE 1451 family to be interoperable. It defines the
functions that are performed by a smart transducer interface
module (STIM) and the common characteristics for all
devices that implement the STIM. It also specifies the
formats for Transducer Electronic Data Sheets (TEDS) and
defines various commands to facilitate the setup and control
of the STIM as well as reading and writing of the data used
by the system and the STIMs. Application programming
interfaces (APIs) are defined to facilitate communications
Sensor
Signal
Conditioning
Analog-to-Digital
conversion
TEDS

Sensor
Interface
Local User
Interface
Communication
TEDS
Data storage
Sensor
Interface
1451.1 framework
Transducer
block
Transducer
block
Function
blocks
NCAP-
blocks
Network
Independent
Network
Dependent
Sensor
Signal

Conditioning
Analog-to-Digital
conversion
TEDS
N
e
tw
o
rk
Fig. 1 The structure of the
sensor modules and NCAP in
IEEE 1451
1034 J Med Syst (2010) 34:1033–1041
with the STIM and with other applications. IEEE 1451.1
defines a common object model and programming paradigm
for smart transducer systems. IEEE 1451.2 characterizes a
transducers-to-NCAP interface and TEDS for a point-to-point
configuration [1]. IEEE 1451.3 defines a transducer-to-
NCAP interface and TEDS for multi-drop transducers using
the Home PNA (Home Phoneline Networking Alliance)
communication protocol. IEEE 1451.4 defines a mixed-
mode interface for analog transducers with analog and digital
operating modes. IEEE 1451.5 has recently been approved
and defines a transducer-to-NCAP interface and TEDS for
wireless transducers. Wireless standards such as 802.11

(WiFi), 802.15.1 (Bluetooth), 802.15.4 (ZigBee), and
6LowPAN are being considered as physical interfaces [1,
4]. The IEEE P1451.6 defines a transducer-to-NCAP
interface and TEDS using the high-speed CANopen
network interface [1]. In addition to these, the IEEE
P1451.7 defines an interface and communication protocol
between transducers and RFID systems.
HL7
Medical entities such as hospitals, doctors, and others must
be able to send and receive various types of data such as
patient information, medical images, as well as biomedical
data such as ECG. Since medical data have different data
formats and interface methods, these data must be presented
in a standardized format to allow for exchange of
information (HL7 Organization. [http://www.hl7.org]; HL7
Version 2.5.1 Messaging Standard). HL7 (Health Level 7)
is an ANSI approved standard that allows for exchange of
medical data among computer applications. It is one of the
most successful messaging standards in the medical field.
The HL7 developed an international set of open standards
for a message format and semantically interoperable data
that allow different health information systems to easily and
effectively communicate with one another (HL7 Organiza-
tion. [http://www.hl7.org]; HL7 Version 2.5.1 Messaging
Standard). This standard deals with clinical observation,
laboratory, pharmacy, medical devices, imaging and insur-
ance transactions. It also provides the exchange, manage-
ment and integration of data that support patient care and
care management, as well as the delivery and evaluation of
healthcare services.
The standard currently addresses the interfaces among
systems that send or receive patient admissions/registration,

discharge or transfer (ADT) data, queries, resource and
patient scheduling, orders, results, clinical observations,
billing, master file update information, medical records,
scheduling, patient referral, and patient care. It does not
assume a particular architecture with respect to the
placement of data within applications. However, it is
designed to support a central patient care system as well as a
distributed environment. Although HL7 tries to cover numer-
ous aspects related to medical data, HL7 does not cover sensor
parts, especially from mobile patients or mobile devices. The
growth in e-healthcare and u-healthcare means that HL7 will
eventually accept data sensors, sensor networks, and mobile
patients and may even interoperate with existing standards
such as IEEE 1451.
IEEE 11073
IEEE 11073 is also a collection of standards that define all
aspects of the communication among medical devices and/
Fig. 2 IEEE 1451 family of standards
Fig. 3 Overall scenario
J Med Syst (2010) 34:1033–1041 1035
or other outside computers and especially of the communica-
tions with medical devices at the POC (Point of Care) [6, 7].
The main purpose of these standards is to provide a real time
plug and play property and interoperability for patient-
connected medical devices. They are also meant to facilitate
the efficient exchange of vital signs and medical device data

acquired at the point-of-care. IEEE 11073 is one of the most
actively studying standards and is under development.
This standard is developing under the assumption that all
the devices defined in IEEE 11073 should be interoperable
with HL7. So, we do not consider the interoperation of
IEEE 11073 and HL7. It is also possible for IEEE 1451 to
interoperate with IEEE 11073. We do not consider the
integration with IEEE 11073 with IEEE 1451 or HL7 in
this study.
Model for integration of IEEE 1451 and HL7
Overall scenario
The overall system that we are considering is shown in
Fig. 3 [8]. Here, we assume that a patient has possible
intermittent diseases such as stroke or epilepsy but wants to
live a normal life. To accomplish this, if there is a problem,
devices or sensors notice this and inform an emergency
center, hospital, or doctor. Therefore, the patient must wear
sensor modules equipped with communication modems
such as Zigbee or Bluetooth. These sensors measure
biomedical data such as ECG, SpO2, or body temperature
constantly and send them to a PDA that the patient is also
wearing on wire or by several wireless communication
methods such as Zigbee or Bluetooth. In this scenario, we
assume that the sensors are implemented and meet the
requirement of the IEEE 1451 standards. The wireless
sensors are implemented to meet the specification of IEEE
1451.5 and the sensors meet IEEE 1451.4.
The data collected at the PDA may be processed.
Some of the possible processing skills include calibra-
tion, extraction of features, decision on the status of the

patient, or compression. The processed, possibly com-
pressed, data or the raw data are eventually sent to a
hospital or an emergency center through cellular, wire-
less LAN, or wired LAN communications. Usually, when
the patient is at home or at work, the data are sent via a
wireless LAN or a wired LAN. This is one of the most
reliable and cheapest methods. If the patient is moving,
the data may be sent to the remote places via cellular
networks. The hospital or the emergency center constant-
ly monitors the data and calls doctors or an ambulance in
case of emergency.
Fig. 4 Interface between
IEEE1451 and HL7
Table 1 The structure of the IEEE 1451 TEDS and the items of
Template 39
TEDS structure Example biosensor information
Basic TEDS Manufacturer ID 1
Model number 2
Version number 1.1
Serial number 1123
Item of Template 39 Template ID 39
Sensitivity 0.01
[email protected] °C
Reference temp −40
MinPhyVal −40

MaxphyVal 123.8
MinElecVal 0
MaxElecVal 16,384
MapMeth 1
1036 J Med Syst (2010) 34:1033–1041
In hospitals and emergency centers, doctors, nurses,
technicians, treat all the patients’ data through standardized
way such as HL7 or DICOM, etc. Thus, for all the people
in medical area to access all the data from patients, they
should be translated into HL7 compatible form. Here, we
consider the translation of the sensor data into HL7
compatible form.
Model for exchanging messages between IEEE 1451
and HL7
One of the most important parts of the IEEE 1451 standard
is the TEDS [1–5]. The TEDS is the information structure
that contains critical sensor information that enables the
plug-and-play operation. This is important to initiate
transmission of the sensor data and specific information
about the patient. The data structure of the TEDS in the
IEEE1451 is different from that of the HL7. Thus, the two
systems cannot interoperate with each other. To guarantee
the interoperability, the data need to be translated into HL7
message format and vice versa. To do this, the data
structures of both IEEE 1451 and HL7 need to be
redefined.

In Fig. 4, we extracted the components that are related
with the transfer of medical data from Fig. 3. Since we
assumed that all the sensors are implemented to meet the
specification of the IEEE 1451 standard, the sensors carry
TEDS. In the TEDS, all the information on the patient,
smart sensors are stored and sent with the sensor data. The
data which are collected and transmitted to the PDA, are
Table 2 Proposed attribute table-OBX for interface between
IEEE1451 and HL7
SEQ LEN DT OPT RP/# TBL# Item# Element name
1 4 SI O 569 OBX Set ID-OBX
2 2 ID R 125 570 Value type
3 250 CE R 571 Observation identifier
4 20 ST R 572 Observation sub-ID
5 65536 NA or MA C 573 Observation value
6 250 CE X 574 Units
7 60 ST X 575 References range
8 5 ID O Y 78 576 Abnormal flags
9 5 NM X 577 Probability
10 2 ID X Y 80 578 Nature of abnormal test
11 1 ID R 85 579 Observation result status

12 26 TS X 580 Effective date of reference range values
13 20 ST X 581 User defined access checks
14 26 TS X 582 Date/time of the observation
15 250 CE X 583 Producer's ID
16 250 XCN O Y 584 Responsible observer
17 250 CE X Y 936 Observation method
18 22 EI O Y 1,479 Equipment instance identifier
19 26 TS O 1,480 Date/time of the analysis
20 2 NM R Manufacture ID
21 50 ST R Model number (sensor type)
22 2 NM R Version number
23 2 NM R Serial number
24 1 NM R Template ID
25 120 NM R Sensitivity
26 250 ST O Sens-ref. (unit)
27 20 NM O Ref. temp
28 50 NM R Minimum physical value
29 30 NM R Maximum physical value

30 60 NM R Minimum electrical value
31 80 NM R Maximum electrical value
32 250 NM C Y Mapping method
J Med Syst (2010) 34:1033–1041 1037
transmitted to the NCAP (Network capable application
processor) and eventually to the Hospital. In the NCAP and
the hospital, they have transcoders or transformers between
IEEE 1451 TEDS and HL7.
IEEE 1451 TEDS
IEEE 1451 defines the TEDS structure in a compact and
flexible way that allows for the handling of a wide range of
sensor types and requirements. In IEEE 1451.4, there are three
compliance levels called Tiers [3]. Tier 1 provides minimum
capability and includes Basic TEDS. Tier 2 and Tier 3 have
standard and extended system capabilities and can use
advanced templates. We consider Tier 2 and Tier 3 trans-
ducers. For the Tier 2 and Tier 3 transducers, in addition to
the basic TEDS, they may have IEEE-defined templates
called the standard template TEDS. The basic TEDS
contains the manufacturer ID, the model number, the version
number, and the serial number. The standard template TEDS
contains the key characteristics of sensors or actuators such
as type, sensitivity, measurement range, bandwidth, etc. The
standard template TEDS defines Template IDs, which are 25
Fig. 5 The process of sending
and receiving a message

between the engines
Fig. 6 Hardware platform (a) an armband attached on patients’
arms and (b) a PDA
1038 J Med Syst (2010) 34:1033–1041
to 43, according to general classification of the sensors.
These include accelerometer, microphones, resistance sen-
sors, thermistor, and potentiometric voltage divider. Each
template includes required characteristics for each specific
sensor. Among these, since the sensors used in this study are
mainly of voltage types, we use Template ID 39, which is a
potentiometric voltage divider type transducer template.
Table 1 shows an example that we intend to use for the
structure of the Basic TEDS and Template 39. If there are
different types of transducers, then we can use other
templates [3].
HL7 message format
For the HL7, a new type of message can be accepted and a
new segment group can be added. Also, a new data format
can be created with the HL7 (HL7 Organization. [http://www.
hl7.org]). The measured sensor signals such as ECG or EEG
can be represented in waveform and HL7 can support the
waveform data format. The WAV category OBX result
segment is used to transmit the actual waveform data (the
time-series digitized values from an analog-to-digital con-
verter (ADC) or other sources of sampled digital data). For
Fig. 7 Monitor screen of a
patient at the PDA and server
at the patient’s side. a Page for

the patient’s information. b Page
for monitoring patient’s sensor
data
J Med Syst (2010) 34:1033–1041 1039
the integration of IEEE 1451 and HL7, we use a trigger
event W01 and message type ORU. The W01 is a trigger
event that identifies ORU messages which can transmit
waveform data coming from the results of an ordered test or
series of observations. This may be used to identify ORU
messages sent as the eventual response to a QRY message
specifying a deferred mode query for waveform results/
observation with record-oriented format. One or more ORU
messages with the W01 trigger event may result from this
type of QRY message.
To exchange data, this study proposes the addition of 13
categories of the IEEE 1451 TEDS, a patient's biosensor
data, to the existing HL7 attribute table-OBX (HL7 Version
2.5.1 Messaging Standard). This means that four categories
of the Basic TEDS (e.g. manufacturer’s ID, model number,
version number, and serial number) and 9 categories of the
Templates 39 (e.g. Template ID, Sensitivity, Sens-Ref,
Minimum Physical Value, Maximum Electrical Value,
Minimum Electrical Value, Maximum Electrical Value,
Mapping method) are added to the existing 19 OBX fields.
A standard message was generated and encoded based on
the proposed TEDS-HL7 based Message protocol and was
transmitted to the hospital system. In Table 2, we show the
proposed attribute in the OBX table.

TEDS-HL7 software interface engine
Software that exchanges data based on HL7 standards is called
a software interface engine. Simple software interface engines
that can send and receive messages in the engine according to
the interworking of the 1451 and the HL7 standard are shown
in Fig. 5. As shown in Fig. 5, on the clients’ side, the user
TEDS-HL7 software interface engine translates the IEEE
1451 TEDS and the transducer data into HL7 messages and
transmits them. On the server side, the TEDS-HL7 based
software interface engine receives the translated HL7
messages and begins to parse them. If the message has no
problems, the engine issues an acknowledgement.
Implementation
Hardware and software Platform
To guarantee patient mobility and convenience, the patient
wears several sensors and a wireless modem on an
armband. Also, the patient is wearing a PDA which
collects, processes, and transmits all the data from the
sensor modules. In Fig. 6, we show the hardware platform.
The sensor module has a pulse sensor to measure patients’
pulse, a temperature sensor to determine the patient’s body
temperature, and a humidity sensor. This module also has a
Zigbee modem that can form a wireless sensor network.
The PDA is a Compaq iPAQ 5450 that has a built-in
WLAN modems. The temperature sensor is placed close to
the patient’s body to correctly measure body temperature.
The software we use is as follows. For the OS for the
operating sensor module and wireless sensor network, we
used TinyOS. The TinyOS is an open-source operating
system designed for wireless embedded sensor networks

Fig. 8 An example that shows the transmitted and received
message after translation. a ORU^W01 message based on
TEDS-HL7 message
protocol. b Received message at the remote site
1040 J Med Syst (2010) 34:1033–1041
(http://www.tinyos.net). It features component-based archi-
tecture which enables rapid innovation and implementation
while minimizing code size as required by the severe
memory constraints inherent in sensor networks. For the
development of PDA related software, we used the embedded
Visual C++3.0 and Platform Builder. For the develop-
ment of server related programs, we used Windows XP
as a Server OS and Visual C++6.0. The programs for
monitoring the strength of the signal were developed
through NDIS (Network Driver Interface Specification)
and SDK (Software Development Kit).
Implementation
In Figs. 7 and 8, we present some of the results. Figure 7a
shows a patient’s information. This can be displayed if we
press ‘Patient Inf.’ button at the top of the screen. On the
upper left side of Fig. 7a, we can see the patient’s personal
information including a picture, name, and SS#. On the
right side is a list of sensors that the patient is wearing.
If we select a sensor here, then we can see its information.
This also includes the information about the sensor that is
stored in the TEDS and is displayed beneath the list. At the
lower left corner, we have reserved this space to display the
patient’s medical history or possible symptoms. If we select
a sensor and press the ‘Monitoring’ button at the upper side

of (a), we can go to the monitoring page shown in Fig. 7b.
In (b), we can see the picture of the data that are coming
from the sensors. While monitoring the data, if we need
to record the data, then we can press ‘Capture’ button to
freeze and capture the current data. If we need to need to
translate the data into HL7 format, then we can press ‘HL7
Message Generation’ button. Also, if we need to send the
translated HL7 message to a server at a remote site, then
we can press ‘send’ button.
Figure 8a is a picture of the message that is translated
into HL7 format and transmitted to a remote center. Here,
we initiated a W01 as an event, and according to this, the
translated message from HL7 is shown at the lower part.
Here, we can see that the TEDS and other related information
is encoded along with sensor data. Figure 8b is the received
message at the remote side. From these results, it is possible
to produce a sensor standard, IEEE 1451 and medical
standard HL7 that can interoperate with each other.
Conclusion
In this paper, we studied the possibility of the interoperation
between the IEEE 1451 and HL7 and presented our
preliminary results. As ubiquitous systems are growing, u-
healthcare will eventually be used. Thus, patients will wear
sensors that check and measure the patients’ status in real time
and transmit these data to remote sites such as a hospital or an
emergency center. This real time steaming data will develop
with time, eventually HL7 must accept these kinds of data so
that it can interoperate with various online sensor data. To do
this, we must consider two possible choices. One is to develop
a new standard to deal with medical sensors and actuators. The
other is to integrate HL7 with developed or existing standards
such as IEEE 1451. We believe that the latter is more probable

than the former because the latter can save time, man-month,
and money. If this is correct, the best option will be to choose
IEEE 1451. Although integration requires time, we think that
this result has shown that HL7 and IEEE standards can
interoperate with each other.
Acknowledgments This study was supported by a grant of the
Korea
Healthcare Technology R&D Project, Ministry of Health,
Welfare and
Family Affairs, Republic of Korea. (Grant Number: A040032)
Open Access This article is distributed under the terms of the
Creative Commons Attribution Noncommercial License which
per-
mits any noncommercial use, distribution, and reproduction in
any
medium, provided the original author(s) and source are credited.
References
1. National Instruments, Inc., “An overview of IEEE 1451.4
transducer electronic data sheets (TEDS)”, National
Instruments,
Inc.
2. IEEE Std 1451.0™-2007, IEEE standard for a smart
transducer
interface for sensors and actuators—common functions,
communi-
cation protocols, and transducer electronic data sheet (TEDS)
formats.
transducer
interface for sensors and actuators-mixed-mode communication

protocols and transducer electronic data sheet (TEDS) formats.
transducer
interface for sensors and actuators-wireless communication
proto-
cols and transducer electronic data sheet (TEDS) formats.
5. R. Johnson, K. Lee, J. Wiczer, and S. Woods, Smart
Transducer
Interface Standard—IEEE 1451, Oct. 2, 2001 Sensors Expo,
Philadelphia.
6. ISO/IEEE 11073-10201, Health informatics—Point-of-care
medical
device communication—Part 10201: Domain information model
(referred to hereinafter as the “DIM”).
7. ISO/IEEE 11073-20101, Health informatics—Point-of-care
medical
device communication—Part 20101: Application profiles —
Base
standard.
8. Kim, W., Ko, W.J., Cho, H.D., Woo, M.A.: A study on the
seamless transmission of an uplink constant streaming data over
wireless LANs and cellular networks. ICOIN LNCS 3391:874-
883
(2005)
J Med Syst (2010) 34:1033–1041 1041
http://www.tinyos.net
Copyright of Journal of Medical Systems is the property of

Springer Science & Business Media B.V. and its
content may not be copied or emailed to multiple sites or posted
to a listserv without the copyright holder's
express written permission. However, users may print,
download, or email articles for individual use.
RESEARCH Open Access
Semantic validation of the use of SNOMED CT
in HL7 clinical documents
Stijn Heymans*, Matthew McKennirey and Joshua Phillips
* Correspondence: stijn.
[email protected]
SemanticBits, LLC, 13921 Park
Center Road Suite 420, Herndon,
VA 20171, USA
Abstract
Background: The HL7 Clinical Document Architecture (CDA)
constrains the HL7
Reference Information model (RIM) to specify the format of
HL7-compliant clinical
documents, dubbed CDA documents. The use of clinical
terminologies such as
SNOMED CT® further improves interoperability as they
provide a shared
understanding of concepts used in clinical documents. However,
despite the use of
the RIM and of shared terminologies such as SNOMED CT®,

gaps remain as to how
to use both the RIM and SNOMED CT® in HL7 clinical
documents. The HL7
implementation guide on Using SNOMED CT in HL7 Version 3
is an effort to close this
gap. It is, however, a human-readable document that is not
suited for automatic
processing. As such, health care professionals designing clinical
documents need to
ensure validity of documents manually.
Results: We represent the CDA using the Ontology Web
Language OWL and further
use the OWL version of SNOMED CT® to enable the
translation of CDA documents
to so-called OWL ontologies. We formalize a subset of the
constraints in the
implementation guide on Using SNOMED CT in HL7 Version 3
as OWL Integrity
Constraints and show that we can automatically validate CDA
documents using OWL
reasoners such as Pellet. Finally, we evaluate our approach via a
prototype
implementation that plugs in the Open Health Workbench.
Conclusions: We present a methodology to automatically check
the validity of CDA
documents which make reference to SNOMED CT®
terminology. The methodology
relies on semantic technologies such as OWL. As such it
removes the burden from IT
health care professionals of having to manually implement such
guidelines in
systems that use HL7 Version 3 documents.
Background

Introduction
Health Level Seven International (HL7) [1] is a non-profit
organization that develops
standards to increase the interoperability of health care
information technology. One
such standard is the Reference Information Model (RIM) [2]
that functions as the com-
mon information model for all further specified information
models and messages
developed under the auspices of HL7. For example, the HL7
standard for writing clini-
cal documents is provided by the Clinical Document
Architecture (CDA) [3] and is a
constraining of the RIM. It specifies how HL7 clinical
documents should be structured
while using classes and attributes defined in the RIM.
Heymans et al. Journal of Biomedical Semantics 2011, 2:2
http://www.jbiomedsem.com/content/2/1/2 JOURNAL OF
BIOMEDICAL SEMANTICS
© 2011 Heymans et al; licensee BioMed Central Ltd. This is an
Open Access article distributed under the terms of the Creative
Commons Attribution License
(http://creativecommons.org/licenses/by/2.0), which permits
unrestricted use, distribution, and
reproduction in any medium, provided the original work is

properly cited.
mailto:[email protected]
http://creativecommons.org/licenses/by/2.0
The advantage of using such a layered architecture of models
for different purposes
is its provision of syntactic (and to a certain extent semantic)
interoperability through-
out the health care domain. Clinical documents for exchange
between health care pro-
fessionals that satisfy this CDA (CDA documents), are
syntactically understandable by
both ends of the exchange. The CDA caters for some semantic
interoperability. Indeed,
it prescribes what meta-vocabulary to use in the form of
directions such as to use the
class SubstanceAdministration for administering a substance.
However, an extra factor
is needed to understand also the particular data being sent in
such clinical documents.
Clinical terminologies such as SNOMED CT® provide the
means for standardizing
such data. If a health care professional references a CDA
SubstanceAdministration of a

SNOMED CT® concept with ID 433181003, the receiving
professional knows that
Amoxicillin 775 mg extended release tablet is targeted for
SubstanceAdministration.
Note that such clarity (or semantic interoperability) is important
for humans, but
becomes an even more pressing issue if the clinical documents
are to form the basis of
automated decision making: is the substance administration of
Amoxicillin appropriate
given the exhibited symptoms?
Even though a combination of the HL7 RIM and the use of
standardized clinical ter-
minologies goes a long way toward semantic interoperability,
exactly their use together
can lead to interoperability problems. Indeed, there is a certain
overlap between the
semantics of the RIM and the semantics of SNOMED CT®
codes. A SNOMED CT®
code may express a meaning that the RIM expresses using a
combination of classes [4].
To clarify the use of SNOMED CT® in the context of HL7
documents, guidelines are

established in [4]. The guidelines indicate, among others, what
the code of a certain
CDA Observation should be if a SNOMED CT® concept is used
(it should be a sub-
type of the SNOMED CT® concept Observable entity). These
guidelines are written in
natural language and at present no automated means is available
to check whether a
clinical document satisfies them to ensure that both sender and
receiver can interpret
the result the same way.
The goal of this work is to verify how to automatically validate
CDA documents for
satisfaction of the guidelines on the use of SNOMED CT® in
HL7 documents.
We provide a possible solution for this problem by using the
Web Ontology Lan-
guage OWL [5]. OWL is a W3C standard for representing
knowledge on the Web,
and serves in general as a language for expressing ontologies,
where ontologies were
conceived as formalized representations of knowledge that
provide a “shared under-
standing” [6] of certain domains. Moreover, one can reason over

representations in
OWL: one can determine which concepts are equivalent, which
are subsumed, and
whether the knowledge base is inconsistent. As such it is an
excellent candidate for a
lingua franca in the health care domain, and able to inject the
necessary automatiza-
tion for semantic interoperability. We show that by writing the
available knowledge in
the current scenario in OWL and by using OWL reasoners such
as Pellet, we can
exactly tackle the question does my CDA document satisfy the
guidelines on the use of
SNOMED CT®?
This article reports on how to write OWL representations of the
different knowledge
involved in the above problem when dealing with CDA
documents. We define an
ontology for the CDA, use the OWL version of SNOMED CT®,
write a specific subset
of the guidelines (the SNOMED CT® vocabulary domain
constraints [[4], Section 5])
http://www.jbiomedsem.com/content/2/1/2

of 16
as OWL, and show how to transform CDA documents to OWL
ontologies. We then
indicate how to use automated reasoning via ontology reasoners
to validate CDA docu-
ments for conformance to the usage of SNOMED CT®. We
further report on a proto-
type implementation that extends the Open Health Workbench
[7] with a plug-in for
such semantic validation. Finally, we discuss some common
errors that we found in
CDA documents with respect to to the SNOMED CT®
guidelines and we identify
areas of future work.
Methods
Reasoning with OWL Integrity Constraints
One of the corner stone ideas of the envisioned Semantic Web
[8] is to move from
human-readable content on the Web to machine-processable
content that can be auto-
matically reasoned about. Layered on top of basic Web

technologies such as XML,
RDF [9], RDF(S) [10], the OWL Web Ontology Language [5],
and its expressive succes-
sor OWL 2 [11] provide for an expressive logic-based
representation of knowledge on
the Web.
Expressive fragments of OWL, the so-called OWL DL
fragments, correspond directly
to a particular Description Logic [12]. Traditionally,
Description Logics form a set of
logical languages that balance complexity and expressiveness:
they are usually decidable
fragments of undecidable first-order logic with a syntax that has
as basic building
blocks concepts and relationships or roles. In contrast with
first-order logic, they allow
for decidable reasoning and can handle tasks such as verifying
whether one concept is
subsumed by another concept or whether concepts are
satisfiable.
As such, Description Logics are recognized also in the health
care domain as a useful
framework to build clinical terminologies. SNOMED CT® (see
below) is defined as a

particular Description Logic theory, allowing users to, for
example, identify redundancy
by querying for clinical concepts that are equivalent [13].
We use in this article the Manchester OWL syntax [14] as it is
easy for humans to
read and close to the underlying Description Logics syntax. we
refrain from defining
the syntax in detail but will explain its intuition whenever we
use it. Take the following
example:
PCNAllergy SubClassOf
(causativeAgent some Penicillin)
(1)
The basic building blocks are the concepts PCNAllergy and
Penicillin which are used
to classify individuals and their type. The basic relationship or
role used is causativeA-
gent which relates individuals to other individuals, namely its
causative agents. The
concept expression (causativeAgent some Penicillin) is called
an exists restriction as it
captures all individuals that have some causative agent that is a
penicillin. Axiom (1)

then imposes that every individual that is of type PCNAllergy
also needs to have a cau-
sativeAgent relation with some individual that is of type
Penicillin.
We can make this axiom stronger by writing:
PCNAllergy EquivalentTo
Allergy and (causativeAgent some Penicillin)
(2)
Page 3 of 16
Instead of a SubClassOf axiom this is an EquivalentTo axiom
and can be seen as 2
SubClassOf axioms: axiom (1) and
(Allergy and (causativeAgent some Penicillin))
SubClassOf PCNAllergy
(3)
It indicates that individuals of type PCNAllergy are exactly
those allergies that have a
causative agent that is penicillin.

The semantics of such sets of OWL axioms, called ontologies, is
given by first-order
interpretations and thus obeys the open world assumption. This
open world assump-
tion has important consequences on the type of reasoning
possible with OWL. Assume
we have a particular individual i that is of type PCNAllergy.
Denoted in traditional
first-order logic notation, we have PCNAllergy (i). With the
SubClassOf axiom (1), we
deduce that there exists some individual j such that
causativeAgent (i, j) and Penicillin
(j) holds. Given this open world semantics, if such a j does not
exist explicitly, it is
assumed to exist implicitly to satisfy the axiom. In the case of
reasoning with domain
knowledge such as clinical terminologies such standard logical
entailment allows to
answer questions such as “When my patient has an allergy,
should this be associated
with a causative agent?” The usual semantics says “yes, there is
some causative agent.”
In the context of pure conceptual reasoning such an open world
assumption is suita-

ble and desirable (one does not want to include a representative
data set to test equiva-
lence of two concepts). However, when data is present that
needs to conform to an
ontology, one would like the axioms to behave more like
integrity constraints (ICs), i.e.,
one would like to treat OWL as a schema language for the
instance data. In the above
example, a data set containing only PCNAllergy(i) should lead
to a violation of the
PCNAllergy axiom. A data set containing on the other hand
PCNAllergy(i), causativeA-
gent(i, j) and Penicillin(j) is not violating the axiom. Indeed,
whereas logical entailment
is useful for reasoning over the domain knowledge, when
dealing with clinical docu-
ments, one does not just want to know that there is a sole,
possibly unknown, causa-
tive agent. One wants to verify that the clinical document is
explicitly mentioning this
causative agent.
In [15] such an integrity constraint semantics for OWL axioms
is defined, enabling
OWL axioms to be used as constraints that must be satisfied by

particular instance
data, thus effectively implementing a closed world assumption.
An implication for our
treatment of CDA documents is that, whereas the usual
semantics of OWL is inter-
ested in what can be inferred, the integrity constraint semantics
cares about what is or
is not in the document. A prototype integrity constraint
validator, Pellet-ICV [16], is
implemented based on the Pellet OWL reasoner [17].
SNOMED CT
The Systematized Nomenclature of Medicine - Clinical Terms
(SNOMED CT®) [18]
is a reference terminology for clinical data. Such a clinical
reference terminology is
described by [13] as
“[. . .] a set of concepts and relationships that provides a
common reference point
for comparison and aggregation of data about the entire health
care process,
recorded by multiple different individuals, systems, or
institutions. The main pur-
pose of a reference terminology for clinical data is the retrieval

and analysis of data
Page 4 of 16
relating to the causes of disease, the treatment of patients, and
the outcomes of the
overall health care process.”
The work described in this paper uses the SNOMED CT® core
International Release
of January 2010 [18], which consists of 291144 concepts. For
example, the concept
Amoxicillin 775 mg extended release tablet (product) has a
concept identifier
433181003 and is indicated by SNOMED CT® to be a
350162003 |Oral form Amoxicil-
lin (product) where we use the conceptId |Fully Specified Name
format for SNOMED
CT® concepts. Moreover, it has as an active ingredient the
concept 372687004 |Amoxi-
cillin (substance). Note that also relationships between concepts
have an identifier: has
active ingredient has the identifier 127489000. For readability,

we will refrain from
using SNOMED CT® concept identifiers or fully specified
names. Instead, we will use
short human-readable names throughout the paper where
appropriate.
Such stated relationships of SNOMED CT®, i.e., the clinical
statements that are
directly defined by authors or editors, in contrast with inferred
relationships, can be
translated to the ontology language OWL to enable specific
inferencing such as deter-
mining the equivalence of concepts or hierarchical relationships
between concepts.
The SNOMED CT Stated Relationships Guide [19] describes a
script that provides
exactly this translation.
In Table 1, we extend the above example that shows how
SNOMED CT® indicates
that Amoxicillin is a particular Penicillin and that an Allergy to
penicillin has Penicillin
as a causative agent.
The equivalent OWL representation of Table 1 is listed in Table
2. The IsA relations

are directly translated using the SubClassOf construct of OWL,
while other relation-
ships are defined using OWL exists restrictions: the expression
(HasActiveIngre-
dient some Amoxicillin) collects all individuals that have some
active ingredient that
is a Amoxicillin. Axiom (1) in Table 2 then indicates that every
individual that is a
AmoxicillinTablet is also an individual that has some active
ingredient that is a
Amoxicillin.
The only non-trivial axiom is axiom (4) that uses the special
non-SNOMED CT®
role RoleGroup. This role is used to group OWL exists
restrictions together (see [20]
for more details on role groups), and essentially has in this
context the same effect as
the earlier axiom describing the causative agent of a Penicillin
allergy.
Clinical Statements in the CDA
The HL7 Clinical Document Architecture, Release 2 (CDA) [3]
is a standard that pre-
scribes the structure and semantics of document markup for
clinical documents such

as discharge reports and progress reports. The CDA is a
derivation of the HL7 Refer-
ence Information Model (RIM) [2] which enables it to refer to
external code systems
such as SNOMED CT®. CDA documents are particular
instances conforming to this
CDA and can contain text, images, and referrals to particular
codes in HL7-endorsed
Table 1 SNOMED CT® Fragment Amoxicillin
(1) Amoxicillin Tablet Has active ingredient Amoxicillin
(2) Amoxicillin Is a Aminopenicillin
(3) Aminopenicillin Is a Penicillin
(4) PCNAllergy Causative agent Penicillin
Page 5 of 16
code systems such as SNOMED CT®. In this work, we focus on
a particular fragment
of the CDA, the Clinical Statement pattern, which specifies the
structure and seman-

tics of typically used RIM Acts in CDA documents such as
Observation, SubstanceAd-
ministration, Supply, Procedure, Encounter, Organizer, and Act.
Consider the following fragment of a CDA document from [4]:
1 <observation classCode="OBS” moodCode="EVN">
2 <code code="ASSERTION”
codeSystem="2.16.840.1.113883.5.4"/
>
3 <text>Allergy to PCN manifesting as hives </text>
4 <value xsi:type="CD” code="106190000|Allergy|:246075003|
Causative agent|=373270004| Penicillin - class of antibiotic -
(substance)” codeSystem="2.16.840.1.113883.6.96"/>
5 <actRelationship typeCode="MFST “inversionInd="true”
contextConductionInd="true">
7 <code code="ASSERTION” codeSys-
tem="2.16.840.1.113883.5.4"/>
8 <value xsi:type="CD” code="247472004| Hives|”
codeSystem="2.16.840.1.113883.6.96">

9 <displayName value="Hives"/>
10 </value>
11 </observation>
12 </actRelationship>
13 </observation>
Without going into details (see [3] for more on CDA
documents) the fragment con-
sists of an Observation of an allergy to penicillin manifesting as
hives. It has moodCo-
de="EVN” indicating that the observation has occurred and has
a particular code
indicating that the observation is an ASSERTION, where
ASSERTION is in turn a
code from the code system 2.16.840.1.113883.5.4, the HL7
ActCode code
system.
The value of the observation is taken from the code system
SNOMED CT®, identi-
fied by 2.16.840.1.113883.6.96, and is of data type CD, an HL7
defined data
type that allows for the combination of codes from a code
system to define specific

concepts. Indeed, the value uses different codes from SNOMED
CT® to describe the
so-called post-coordinated expression 106190000| Allergy|
:246075003|Cau-
sative agent|=373270004| Penicillin - class of antibiotic - (sub-
stance), an allergy that has penicillin as a causative agent.
The actRelationship on line 5 with typeCode="MFST” relates
this observa-
tion subsequently with the observation on line 6, its
manifestation. This observation is
similarly defined as an ASSERTION with a value code from
SNOMED CT® that repre-
sents hives.
Table 2 OWL Representation SNOMED CT® Fragment
Amoxicillin
(1) AmoxicillinTablet SubClassOf (HasActiveIngredientsome
Amoxicillin)
(2) Amoxicillin SubClassOf Aminopenicillin
(3) Aminopenicillin SubClassOf Penicillin
(4) PCNAllergy SubClassOf (RoleGroupsome
(causativeAgentsome Penicillin))

of 16
Guidelines on Using SNOMED CT® in HL7 CDA Documents
The use of external code systems such as SNOMED CT® in
HL7 specifications is one
aspect of achieving the HL7 goal of semantic interoperability:
not only can different
parties understand clinical information syntactically, they also
agree on the meaning of
this clinical information. By committing to widespread
ontologies such as SNOMED
CT®, each party knows what is meant when using particular
SNOMED CT®
terminology.
However, when representing clinical information conforming to
a reference model
like the HL7 RIM, just using SNOMED CT® codes is not
sufficient to avoid semantic
mismatches. For example, the HL7 CDA Observation class has 2
attributes, Observa-
tion.code and Observation.value: how to use these attributes to
represent clinical find-

ings, i.e., results of a clinical observation, such as has a fracture
of her left femur? One
could use the code attribute to encode this statement via a
SNOMED CT® expression,
but it would be unclear how the value attribute should be
assigned, and vice versa.
The set of guidelines presented in Using SNOMED CT in HL7
Version 3; Implemen-
tation Guide, Release 1.5 [4] addresses issues like the above:
how to use SNOMED
CT® in the context of HL7 clinical statement patterns? Clinical
statement patterns [21]
are constraints on the HL7 RIM and occur in the CDA. In the
example above, the code
for the observation can be an ASSERTION and the value can be
a SNOMED CT®
expression for has a fracture of her left femur which is a
subexpression of the clinical
finding SNOMED CT® concept.
We will focus in this paper on the guidelines around the
SNOMED CT® vocabulary
domain constraints [[4], Section 5] and this in context of the
clinical statement pattern
in the CDA. Note that the approach we present here can be

applied to clinical state-
ment patterns in general.
Consider a constraint from [[4], Section 5] in Table 3. It
indicates that for Observa-
tion classes with class code OBS, and if a SNOMED CT®
expression is used for the
Observation.value (this is not explicitly present in Table 3. It is,
however, a prerequisite
for the constraints to be applicable) and the Observation.code is
ASSERTION, then the
Observation.value should be a subclass of the SNOMED CT®
concept Clinical Finding
Table 3 Constraint on Observation.value when Observation.code
is ASSERTION
Class Name Observation
Class Code OBS
Attribute Name Observation.value
Narrative
description
An act that is intended to result in new information about a
subject. The main difference
between observations and other acts is that it has a value
attribute that is used to state
the result of the assessment action described in Act.code.

Simple
representation
((<<404684003| clinical finding|)OR(<<413350009| finding
with
explicit context|)OR (<<272379006| event|))
Notes Where Observation.code = ASSERTION.
An alternative approach (now deprecated) is for the same value
set to be communicated
in Observation.code where the attribute Observation.value is not
present in the
Observation class instance.
As indicated in section 2.2.2.2 subheading 7, the situation may
arise in which Observation.
value is a SNOMED CT expression from the set specified in the
‘simple representation’
field of this table and Act.code is represented by a code other
than ”ASSERTION”. For
such an approach can only be safely used if interpretation of the
Act.code together with
the Observation.value does not yield a meaning that is
substantially different from the
meaning implied if the Act.code was ”ASSERTION”. Without
exhaustive scrutiny of
SNOMED CT’s content it is not possible to identify that set of
codes that can safely be
used in this way in Act.code.
Page 7 of 16

or of Finding with Explicit Context or of Event. The ‘<<’ in
front of a SNOMED CT®
expression represents all concepts that are subclasses of that
expression or the expres-
sion itself.
Used Method
We show how to verify a given CDA document with respect to
the guidelines for the
use of SNOMED CT®, in other words, we test if the CDA
document satisfies these
guidelines?
As illustrated in Figure 1 our method consists of transforming,
by means of an XSL
transformation, a particular CDA document in XML syntax to a
set of OWL indivi-
duals using a CDA ontology and the SNOMED CT® OWL
representation. We further
write the constraints on the use of SNOMED CT® from [[4],
Section 5] as OWL
axioms and then test the consistency of those OWL axioms with
respect to the set of
OWL individuals that represent the original CDA document.
Constructing the CDA Ontology

In order to write CDA documents as particular OWL
individuals, specifically for test-
ing CDA documents for conformance to the SNOMED CT®
guidelines, we define an
ontology representing the relevant parts of the clinical
statement pattern of the CDA.
Based on the RIM in Figure three of [3], we model, for
example, the CDA Observation
class as in Table 4.
Figure 1 Used Method Verifying Guidelines SNOMED CT®.
The figure describes a top level view of the
used method to validate CDA documents using semantic
technologies.
Page 8 of 16
We note the use of the concepts HL7SupportedCodeSystems and
HL7ValueSets in
axioms (5) and (6). They indicate that CDA Observations have
values and codes that
come either from an HL7 supported code system or from an HL7
value set. An exam-

ple of such an HL7 supported code system is SNOMED CT® or
the HL7 ActClass
code system. Indeed, besides the classes appearing in the CDA
clinical statement pat-
tern, we also add to this ontology the particular HL7 supported
code systems with
their hierarchically organized codes and the HL7 value sets that
are defined using
those codes. For example, Table 5 describes the concept code
OBS as a subclass of the
concept code ACT, a subclass of the code system ActClass that
is in turn a subclass of
the placeholder concept HL7SupportedCodeSystems.
The value sets are defined as hierarchies as well and subclass
the placeholder concept
HL7ValueSets. They are defined using concepts that subclass
from HL7SupportedCode-
Systems as can be seen in a fragment in Table 6. There,
x_ActMoodDocumentObserva-
tion is defined as equivalent to any of the concept codes in HL7
supported code
systems on the right-hand side of axiom (1). It additionally is
indicated to be a subclass
of the placeholder for value sets using the coding system

ActMood which in turn is a
subclass of the placeholder concept HL7ValueSets.
Reconsidering Table 4, one sees that axiom (1,2) and (3,4)
indicate that CDA Obser-
vations should have a class code that is of type OBS and a mood
code that is of type
x_ActMoodDocumentObservation respectively. Axiom (1) in
Table 6 indicates that a
mood code that is of type EVN would thus be allowed as the
mood code for CDA
Observations.
The used CDA ontology can be found as Additional file 1 or at
http://stijnheymans.
net/ontologies/CDA_ClinicalStatement_for_TermInfo.txt.
Transforming the CDA Document to OWL Individuals
Reconsider the earlier XML fragment of the CDA document.
Note the presence of 2
CDA Observations, each with a class code OBS, a mood code
EVN, a code, and a
value. For each of those 2 observations, we introduce 2 OWL
individuals and we use
the previously introduced CDA ontology to define their class
and mood code, as well

as the code and value for those observations. Table 7 lists the
OWL individuals for the
first observation.
Note the definition of the individual obs_pcn_allergy that is of
type Observation (a
concept from the CDA ontology), and is related via the role
classCode (also defined in
Table 4 OWL Representation of the CDA Observation Class
(1) Observation SubClassOf classCode some OBS
(2) Observation SubClassOf classCode only OBS
(3) Observation SubClassOf moodCode some
x_ActMoodDocumentObservation
(4) Observation SubClassOf moodCode only
x_ActMoodDocumentObservation
(5) Observation SubClassOf hasValue only
HL7SupportedCodeSystems or HL7ValueSets
(6) Observation SubClassOf hasCode only
HL7SupportedCodeSystems or HL7ValueSets
Table 5 HL7 Supported Code Systems Fragment
(1) OBS SubClassOf ACT
(2) ACT SubClassOf ActClass

(3) ActClass SubClassOf HL7SupportedCodeSystems
Page 9 of 16
http://stijnheymans.net/ontologies/CDA_ClinicalStatement_for_
TermInfo.txt
http://stijnheymans.net/ontologies/CDA_ClinicalStatement_for_
TermInfo.txt
the CDA ontology) to the individual class_code_obs1 that
represents the class code.
The individuals class_code_obs1, mood_code_obs1, code_obs1,
and value_obs1 are in
turn defined appropriately using the CDA ontology as in Table
8.
Note that the concept ASSERTION is a concept code in the HL7
ActCode code sys-
tem where the latter is an HL7 supported code system and thus
present in our defined
CDA ontology. Further note how the post-coordinated
expression 106190000|
Allergy|:246075003|Causative agent|=373270004| Penicillin -
class of antibiotic - (substance) was rewritten as the OWL
expression

using the RoleGroup role and concepts from the SNOMED CT®
OWL ontology:
Allergy and (RoleGroupsome (causativeAgentsome Penicillin)).
The use of OWL expressions that are constructed using
SNOMED CT® concepts
implies that to write a CDA document as a set of individuals,
we import not only the
CDA ontology but also the SNOMED CT® OWL ontology. We
further correctly con-
nect SNOMED CT® with the CDA ontology by making the top
SNOMED CT® con-
cept 138875005 |SNOMED CT Concept (SNOMED RT+CTV3)
a subclass of the
placeholder concept SNOMEDClinicalTerms (in turn a subclass
of the HL7Supported-
CodeSystems concept) in the CDA Ontology.
The reader can find the used fragment of SNOMED CT® in
Additional file 2 or at
http://stijnheymans.net/ontologies/SNOMED_CT_for_TermInfo.
txt.
Note that we do not model the actRelationship as the SNOMED
CT® guide-
lines are scoped to isolated CDA classes. As such the OWL
translation of a CDA

document is not lossless: we lose the structure of the CDA
documents, which, on the
other hand, causes the OWL individuals ontology to have a
simple at structure.
The Guidelines on Using SNOMED CT® in HL7 CDA
Documents as OWL Integrity
Constraints
We need one more component to be able to verify CDA
documents for conformance
with the guidelines on using SNOMED CT®: the guidelines
written as OWL Integrity
Constraints.
Take, for example, the constraint expressed in Table 3, which
we can phrase as
If an Act has a class code OBS (i.e., it is an Observation), and
the Observation’s
code is ASSERTION, and SNOMED CT® is used to provide a
value for the Obser-
vation, then this possibly post-coordinated expression has to be
either a 404684003
Table 6 HL7 Value Sets Fragment
(1) x_ActMoodDocumentObservation EquivalentTo DEF or
EVN or GOL or INT or PRMS or PRP or RQO

(2) x_ActMoodDocumentObservation SubClassOf
VSUsingActMood
(3) VSUsingActMood SubClassOf HL7ValueSets
Table 7 OWL Individuals for CDA Observations
Individual: Obs_pcn_allergy
Types: Observation
Facts: classCode class_code_obs1
moodCode mood_code_obs1
hasCode code_obs1
hasValue value_obs1
Page 10 of 16
http://stijnheymans.net/ontologies/SNOMED_CT_for_TermInfo.
txt
|clinical finding or a 413350009 |finding with explicit context
or a 272379006 |
event.
We write this constraint as the following OWL integrity
constraint:

(valueOf some (Observation and
(hasCode some ASSERTION))) and
(codeSystem value 2.16.840.1.11388.3.6.96)
SubClassOf
ClinicalFinding or FindingWithContext or Event
(4)
The first component of this integrity constraint, (valueOfsome
(Observation and
(hasCodesome ASSERTION ))), picks up the individuals that
are the value of some
CDA Observation (valueOf is the inverse of hasValue in the
CDA ontology) where
the CDA Observation has a code that is an ASSERTION. These
individuals additionally
have to be related via the codeSystem role to the individual
2.16.840.1.11388.3.6.96
which represents the SNOMED CT® code system. The
SubClassOf then indicates that
such individuals need to be either of type ClinicalFinding,
FindingWithContext, or
Event.

The other constraints in [[4], Section 5] can be written similarly
as OWL integrity
constraints. The reader can find the integrity constraints in
Additional file 3 or at
http://stijnheymans.net/ontologies/TermInfo_ICs.txt.
Verification of the Guidelines
Reconsider the example CDA document in Tables 7 and 8. Is
this document satisfied
by the constraints on the use of SNOMED CT®?
Take, for example, the integrity constraint (4). The individual
value_obs1 is the
valueOf obs_pcn allergy which is of type Observation. Indeed,
valueOf is the
inverse role of hasValue and obs_pcn_allergy hasValue
value_obs1. Moreover, the
individual obs_pcn_allergy has a code code_obs1 that is of type
ASSERTION. Finally,
since value_obs1 is defined using concepts from the SNOMED
CT® ontology it inher-
its the codeSystem value 2.16.840.1.11388.3.6.96 from the
placeholder concept SNO-
MEDClinicalTerms for SNOMED CT® in the CDA ontology.
Note that the ontology

with OWL individuals corresponding to the CDA document
imports both the CDA
ontology and the SNOMED CT® ontology and it appropriately
makes the top
SNOMED CT® concept a subclass of SNOMEDClinicalTerms
in the CDA ontology.
Table 8 OWL Individuals
Individual: class_code_obs1
Types: OBS
Individual: mood_code_obs1
Types: EVN
Individual: Code_obs1
Types: ASSERTION
Individual: value_obs1
Types: Allergy and
(RoleGroupsome (causativeAgentsome Penicillin))
Page 11 of 16
http://stijnheymans.net/ontologies/TermInfo_ICs.txt

The individual value_obs1 thus satisfies the left-hand side of
integrity constraint (4)
– left/right is with respect to the SubClassOf symbol. In order
for the integrity con-
straint to be satisfied the individual value_obs1 is required to
also satisfy the right-
hand side, i.e., it has to be of type ClinicalFinding or
FindingWithContext or Event.
Recall from Table 8 that value_obs1 is of type Allergy and
(RoleGroupsome (cau-
sativeAgentsome Penicillin)).
As the OWL individuals corresponding to the CDA document
import the SNOMED
CT® OWL ontology, we can deduce with standard OWL
reasoning that Allergy and
(RoleGroupsome (causativeAgentsome Penicillin)) is a subclass
of the concept
ClinicalFinding, and thus, that value_obs1 is of type
ClinicalFinding, and finally, also of
ClinicalFinding or FindingWithContext or Event. This satisfies
the integrity constraint
corresponding to the SNOMED CT® guideline.
Note that we intertwine standard OWL reasoning with OWL
Integrity Constraint

reasoning: we use standard reasoning to infer concepts in
SNOMED CT® and use the
Integrity Constraint semantics to test the constraints. To
illustrate this, assume we
replace the integrity constraint (4) with the integrity constraint
(5) where we leave out
the clinical finding concept on the right-hand side:
(valueOf some (Observation and
(hasCode some ASSERTION))) and
(codeSystem value 2.16.840.1.11388.3.6.96)
SubClassOf
FindingWithContext or Event
(5)
Again we have that value_obs1 satisfies the left-hand side of
the integrity constraint.
As before, and using standard OWL semantics, we can infer that
value obs1 is of type
ClinicalFinding. However, to satisfy the integrity constraint, we
would need that it is of
type FindingWithContext or Event. If we would use the standard
OWL semantics we

would infer that value_obs1 is indeed of that type in order to
satisfy the integrity con-
straint. Using the integrity constraint semantics, the constraint
is violated as we cannot
infer via SNOMED CT® (which we treat with standard OWL
semantics) that it is of
the desired type.
Implementation
We implemented the used method to demonstrate the validation
of CDA documents
in terms of guidelines on the use of SNOMED CT®. Our
implementation is based on
the Open Health Workbench [7], an Eclipse-based tool for
editing HL7 clinical docu-
ments. We added our technology to the Open Health Workbench
in the form of an
Eclipse plug-in. Consequently, we can open HL7 CDA
documents and via a newly
added validation option, we can automatically check SNOMED
CT® usage guidelines
for this document. The output of such a violation indicates
which of the HL7 guide-
lines was violated and assists the user in fixing the CDA
document such that it does

conform to the guidelines.
Under the hood, as explained above, we work with OWL as the
lingua franca for our
validation. As SNOMED CT® provides an OWL version and we
designed OWL integ-
rity constraints for the guidelines on using SNOMED CT® in
CDA documents, the
only remaining component for automatic transformation to OWL
is the CDA
Page 12 of 16
document. We accomplish the automatic transformation of CDA
documents by using
an XSL transformation that takes the XML format supported by
the Open Health
Workbench and translates this on the fly to OWL individuals
conforming to the CDA
ontology. The actual validation incorporating the different OWL
ontologies is then
done using Pellet-ICV [16].
A demo demonstrating the technology is available [22].

Results and Discussion
We tested our method on an archive of existing CDA document
examples provided in
[23]. A typical violation of the guidelines of using SNOMED
CT® in CDA documents
can be seen in the below fragment from HITSP C32: HITSP
Summary Documents
Using HL7 CCD at [24]:
2 <templateId root="2.16.840.1.113883.10.20.1.28” assign-
ingAuthorityName="HL7 SDTC CCD"/>
3 <templateId root ="1.3.6.1.4.1.19376.1.5.3.1.4.5” assign-
ingAuthorityName="IHE PCC"/>
4 <id root="0 fdf994f-2839-482d-bb92-f9b9d1a1786f"/>
5 <code code="64572001” displayName="Condition”
codeSystem-
Name="SNOMED CT”
6 codeSystem="2.16.840.1.113883.6.96"/>
7 <text >
8 <reference value="cond001"/>

9 </text >
10 <statusCode code="completed"/>
11 < effectiveTime >
12 <low value="1999"/>
13 <high value="1999"/>
14 </effectiveTime >
15 <value xsi:type="CD” code="37796009” displayName="Mi-
graine” codeSystemName="SNOMED CT”
16 codeSystem="2.16.840.1.113883.6.96"/>
17 </observation>
Indeed, we have in [[4], Section 5.3.1.1] a vocabulary domain
constraint saying that
an Ob-servation.value should be ((<<281296001|result
comments|) OR
(<<260245000|findings values|)) if SNOMED CT® is used to
encode the
value. This constraint is violated as Migraine is neither a
subtype of the result com-
ments concept nor of the findings values concept. Actually, the
Migraine is a subtype
of the used Observation.code Condition.

Additionally, this fragment also violates the constraint saying
that an Observation.
code should be ((<<386053000|evaluation procedure|) OR
(<<363787002|observable entity|)), as Condition is neither an
observable
entity nor an evaluation procedure.
A possible way of resolving this issue is to use ASSERTION for
the Observation.code.
The Observation.value can then be left as is.
Page 13 of 16
As a proof-of-concept, we further analyzed 26 CDA documents
that are available
from [23]. Note that only 14 of those 26 documents use
SNOMED CT® concepts in
their definition, such that they are the only relevant ones for
analysis. We grouped the
8 Integrity Constraints that validate the usage of SNOMED CT®
in the documents in
5 classes pertaining to Observations, Entities, Procedures,

Substance Administrations,
and Organizers. The group of Observation constraints contains 3
axioms while the
other groups contain 1 violation constraint each. Table 9 shows
the 5 groups in the
left-hand column. The second column lists how many statements
in the 14 CDA docu-
ments refer to either Observations, Entities, Procedures,
Substance Administrations,
Supplies, and Organizers by means of SNOMED CT® concepts.
The third column
indicates how many of those statements were violated by the
particular group of Integ-
rity Constraints. The final column shows the percentage of
violations.
We note that even though the sample is not significant, 73% of
the statements that
use Observations using SNOMED CT® are violated. The CDA
documents do not
make extensive use of other definitions than Observations, so
other results are not
indicative. Note that the example is typical for the violated
constraints in this 73%
group around Observations.

A remaining challenge in our approach is the usage of the full
SNOMED CT® ontol-
ogy. Due to its sheer size this is at the moment practically
impossible. In our examples
as well as the prototype, we use a tailored SNOMED CT®
ontology that incorporates
the relevant hierarchies based on the CDA document we want to
validate. The tailored
version defines 358 concepts and is thus significantly smaller
than the full SNOMED
CT® which contains close to 300,000 concepts. It is part of
future research to extract
the relevant SNOMED CT® fragment for which we will
consider modular extraction
techniques [25].
The current prototype supports transformation of CDA
documents to OWL indivi-
duals where the CDA document contains only simple SNOMED
CT® concepts: post-
coordinated expressions are not translated to their proper OWL
equivalents yet. Addi-
tionally, the prototype currently uses Pellet-ICV to validate
OWL Integrity Constraints.

As the latter is closed source software, it is not ideal as a final
solution. We are work-
ing on both issues: the translation of SNOMED CT®
expressions confirming to the
compositional grammar to proper OWL and the usage of
alternatives for Pellet ICV
such as DL-programs [26] as described in [16].
Besides the SNOMED CT® vocabulary domain constraints in
[[4], Section 5], the
implementation guide [4] provides also guidelines on the
overlaps between the RIM
and SNOMED CT® semantics [[4], Section 2]. These overlaps
are in general much
harder, if possible at all, to model in OWL. Guidelines such as
Table 9 Initial Evaluation Results
SNOMED CT® Usages in CDA Violated Statements %
Observation 239 175 73%
Entity 6 0 0%
Procedure 7 0 0%
Substance Administration 2 2 100%
Organizer 4 2 50%

Page 14 of 16
“Act class clones SHALL include the priorityCode attribute if
there is a require-
ment for expressing the urgency of a request, tracking and
auditing services based
on requested prioritization or any other aspects of workflow
management related
to priority.”
are largely dependent on human intervention. Only a human can
decide whether the
goal is to express the urgency of a request. We intend to model
as much as possible of
[[4], Section 2] as integrity constraints, similarly to our
treatment of all constraints in
[[4], Section 5], and thus identifying a subset of the constraints
that are expressible in
OWL. This would provide a sense of focus for CDA document
developers: which
guidelines can be handled automatically, which ones need
special manual care?

Conclusions
We showed a strategy enabling automatic validation of the
implementation guidelines/
rules on using SNOMED CT® in HL7 documents. Using the
available SNOMED CT®
OWL representation and a Clinical Statement OWL
representation, one can use OWL
Integrity Constraints to automatically validate CDA documents
regarding their confor-
mance with the vocabulary domain constraints in [[4], Section
5]. As such it removes
the burden from IT professionals of having to manually
implement such guidelines in
systems that use HL7 Version 3 documents.
Additional material
Additional file 1: CDA Clinical Statement Ontology for
TermInfo Guidelines.
Additional file 2: SNOMED CT®® Fragment Used in Prototype.
Additional file 3: TermInfo Constraints.
Acknowledgements
This material includes SNOMED Clinical Terms® (SNOMED
CT®) which is used by permission of the International
Health Terminology Standards Development Organisation
(IHTSDO). All rights reserved. SNOMED CT®, was originally
created by The College of American Pathologists. “SNOMED”

and “SNOMED CT” are registered trademarks of the
IHTSDO.
Authors’ contributions
SH and JP devised the described used method. SH prepared a
draft of the article and JP did major revisions. MM
implemented the plug-in for the Open Health Workbench,
scripted and built the demo, and contributed to revisions
of the paper. All authors read and approved the final
manuscript.
Competing interests
The authors declare that they have no competing interests.
Received: 14 October 2010 Accepted: 15 July 2011 Published:
15 July 2011
References
1. Health Level Seven International. [http://www.hl7.org/].
2. George Beeler J, Duteau JH, Grieve G, McKenzie L, Nelson
D: HL7 Reference Information Model. 2010 [http://www.hl7.
org/], [Version 0231].
3. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron
PV, Shabo A: HL7 Clinical Document Architecture, Release 2.
Journal of the American Medical Informatics Association 2006,
13:30-39.
4. Cheetham E, Markwell D, Dolin R: Using SNOMED CT in
HL7 Version 3; Implementation Guide, Release 1.5. 2009
[http://www.hl7.org/], [HL7 Version 3 Implementation Guide:
Using SNOMED CT, Release 1 Last Ballot: DSTU Ballot 4].
5. Patel-Schneider PF, Hayes P, Horrocks I: OWL Web
Ontology Language Semantics and Abstract Syntax.

Recommendation 10 February 2004, W3C 2004
[http://www.w3.org/TR/owl-semantics/].
6. Uschold M, Grüninger M: Ontologies: principles, methods,
and applications. Knowledge Engineering Review 1996,
11(2):93-155.
7. Open Health Workbench.
[https://www.projects.openhealthtools.org/sf/projects/openhealt
hworkbench/].
Page 15 of 16
http://www.biomedcentral.com/content/supplementary/2041-
1480-2-2-S1.TXT
1480-2-2-S2.TXT
1480-2-2-S3.TXT
http://www.hl7.org/
http://www.ncbi.nlm.nih.gov/pubmed/16221939?dopt=Abstract
http://www.w3.org/TR/owl-semantics/
https://www.projects.openhealthtools.org/sf/projects/openhealth
workbench/
8. Berners-Lee T, Hendler J, Lassila O: The Semantic Web.
Scientific American 2001, 284(5):34-43.
9. Klyne G, Carroll JJ: Resource Description Framework (RDF):
Concepts and Abstract Syntax. Recommendation 10

February 2004, W3C 2004 [http://www.w3.org/TR/rdf-
concepts/].
10. Brickley D, Guha RV: RDF Vocabulary Description
Language 1.0: RDF Schema. Recommendation 10 February
2004, W3C
2004 [http://www.w3.org/TR/rdf-schema/].
11. Motik B, Patel-Schneider PF, Parsia B: OWL 2 Web
Ontology Language Structural Specification and Functional-
Style
Syntax. Recommendation 27 October 2009, W3C 2009
[http://www.w3.org/TR/owl2-syntax/].
12. Baader F, Calvanese D, McGuinness DL, Nardi D, Patel-
Schneider PF, (Eds): The Description Logic Handbook
Cambridge
University Press; 2003.
13. Spackman K, Campbell K, Côté R: SNOMED RT: A
reference terminology for health care. In AMIA’97- Proceedings
of the
1997 AMIA Annual Fall Symposium. Edited by: Masys D.
Philadelphia: Hanley 1997:640-644.
14. The Manchester OWL Syntax. [http://www.co-
ode.org/resources/reference/manchester_syntax/].
15. Tao J, Sirin E, Bao J, McGuinness D: Integrity Constraints
in OWL. Proceedings of the Twenty-Fourth AAAI Conference
on
Artificial Intelligence (AAAI 2010) AAAI Press; 2010.
16. Pellet Integrity Constraints: Validating RDF with OWL.
[http://clarkparsia.com/pellet/icv/].
17. Pellet: OWL 2 Reasoner for Java.
[http://clarkparsia.com/pellet/].
18. International Health Terminology Standards Development

Organisation - SNOMED CT. [http://www.ihtsdo.org/
snomed-ct/].
19. Spackman K: SNOMED CT Stated Relationships Guide.
International Health Terminology Standards Development
Organisation 2010, [Tabular Format and OWL
Transformations].
20. Spackman KA, Dionne R, Mays E, Weis J: Role Grouping as
an Extension to the Description Logic of Ontylog,
motivated by Concept Modeling in SNOMED. Proc of AMIA
Symp 2002, 712-716.
21. Bishop C, Buitendijk H, Frean I, Loyd P, Smithies R:
Domain: Clinical Statement. 2010 [http://www.hl7.org/], [HL7
Version 3 Standard: Clinical Statement Pattern, Release 1 Last
Ballot: Draft for Comment Ballot 1].
22. Validation of SNOMED CT Terms in HL7 CDA Documents.
[http://demo.semanticbits.com/public/videos/
CDAValidation/CDAValidation.htm].
23. Spronk R: CDA Around the World: Archive of CDA
Instance Examples.[http://www.ringholm.de/download/
CDA_R2_examples.zip], [Accessed July 2010].
24. NIST: CDA Guideline Validation.[http://xreg2.nist.gov/cda-
validation/downloads.html], [Accessed July 2010].
25. Konev B, Lutz C, Walther D, Wolter F: CEX and MEX:
Logical Diff and Logic-based Module Extraction in a Fragment
of OWL. OWL: Experiences and Directions (OWLED) 2008.
26. Eiter T, Ianni G, Lukasiewicz T, Schindlauer R, Tompits H:
Combining Answer Set programming with Description
Logics for the Semantic Web. Artificial Intelligence 2008,

172(12-13):1495-1539.
doi:10.1186/2041-1480-2-2
Cite this article as: Heymans et al.: Semantic validation of the
use of SNOMED CT in HL7 clinical documents.
Journal of Biomedical Semantics 2011 2:2.
Submit your next manuscript to BioMed Central
and take full advantage of:
• Convenient online submission
• Thorough peer review
• No space constraints or color figure charges
• Immediate publication on acceptance
• Inclusion in PubMed, CAS, Scopus and Google Scholar
• Research which is freely available for redistribution
Submit your manuscript at
www.biomedcentral.com/submit
Page 16 of 16
http://www.w3.org/TR/rdf-concepts/
http://www.w3.org/TR/rdf-schema/
http://www.w3.org/TR/owl2-syntax/
http://www.co-ode.org/resources/reference/manchester_syntax/

http://clarkparsia.com/pellet/icv/
http://clarkparsia.com/pellet/
http://www.ihtsdo.org/snomed-ct/
http://www.ihtsdo.org/snomed-ct/
http://demo.semanticbits.com/public/videos/CDAValidation/CD
AValidation.htm
http://demo.semanticbits.com/public/videos/CDAValidation/CD
AValidation.htm
http://www.ringholm.de/download/CDA_R2_examples.zip
http://www.ringholm.de/download/CDA_R2_examples.zip
http://xreg2.nist.gov/cda-validation/downloads.html
BioMed Central publishes under the Creative Commons
Attribution License (CCAL). Under the CCAL, authors
retain copyright to the article but users are allowed to
download, reprint, distribute and /or copy articles in
BioMed Central journals, as long as the original work is
properly cited.
MGMA Connexion • February 2012 • p a g e 3 3 ©2012
MGMA-ACMPE. All rights reserved.
By Debra Bokur, freelance writer,
[email protected]
COACH’S CORNER
From the xxxxxx
To ‘EACH’ its own incentive payment
New CCHIT program rewards groups with EHR systems

F i n a n c i a l M a n a g e m e n t
T
echnology choices for meeting
federal financial incentives have
typically been geared toward large
hospital settings, but a new option from
the Certification Commission for Health
Information Technology (CCHIT) may
narrow the gap for smaller groups.
“CCHIT created the EHR Certification
Alternative for Healthcare Providers
[EACH™] program because we thought
there was a gap that needed to be filled,”
explains Pat Becker, certification director
for CCHIT. “Most hospitals, hospital
systems and some large group practices
are complex and rarely deploy one
vendor’s system exclusively. They have an
interconnected ‘system of systems’ that
is often a mix of commercial and self-
developed software.”
In these cases, Becker says, certified
EHR technology from vendors can fail
when:
• Health information technology is
partly or fully self-developed
• A commercial product version is
too

old to be upgraded
• A hospital is in a multiyear product
upgrade or conversion
• A vendor does not present an
updated EHR for Office of the
National Coordinator-Authorized
Testing and Certification Body
(ATCB) 2011-12 certification
“The EACH program is only for health
providers that went through the effort to
create their own EHR system,” says Derek
Kosiorek, senior consultant with the
MGMA Health Care Consulting Group.
“If a provider created an EHR, it is a vital
step toward achieving meaningful use. A
common misconception is that it is one of
the first steps. A provider can go through
most of the 90-day, first-year reporting
period without having the EHR certified.
As long as it is certified by that last day of
the reporting period, providers are eligible
for meaningful use incentives. Of course,
it’s not advisable to do this since there is
no guarantee that the product will
be certified.
“Either way, by definition, a practice
cannot attest that it is using an EHR
meaningfully if the system has not gone
through the certification process. EACH

is a program that ensures that a custom-
built EHR is in compliance with the
[Health Information Technology
for Economic and Clinical Health]
HITECH Act,” Kosiorek notes.
Personal service
At press time, 15 healthcare systems
had certified complete or modular EHRs
under CCHIT’s EACH™ program. One
of the more attractive components of
this program, according to users, is the
personal service that accompanies it.
“Our biggest risk for certification
was that nobody had certified a data
warehouse before and, therefore, there
was very little information about what to
expect on certification day,” says Garima
Sharma, manager of clinical analytics
and operations for Northwestern Medical
Enterprise Data Warehouse in Chicago.
Sharma found value in the forums on
the EACH website, which “offered valu-
able feedback on the interoperable files to
help prepare us for certification day,” she
adds. “Their willingness to listen and help
us interpret the test scripts was key.”
Harold Boot, senior director of business
intelligence for Tenet Healthsystem in
Dallas, concurs.
DEFINING yOUR

PROFESSION
Principles, expertise and service
that bind us together
see Defining Your Profession, page 34
mgma.com
• mgma.com/ehr
• mgma.com/blog
Connexion12Feb.indd 33 1/24/12 1:14 PM
http://mgma.com
http://mgma.com/ehr
http://mgma.com/blog
p a g e 3 4 • MGMA Connexion • February 2012 ©2012
MGMA-ACMPE. All rights reserved.
DEFINING yOUR
PROFESSION
from page 33
“We needed someone who would be
with us through the whole process,” Boot
says. “We’d read the regulations, but it
was difficult to be certain of getting
the right interpretation of the federal regu-
lations. We looked at six different organiza-
tions… . We wanted an organization that

was respected by the government, but also
someone to hold our hand and take us
through the progress step by step. Though
we have passed our certification, we stay
in touch to make sure we don’t need to
recertify as part of any changes.”
Both Boot and Sharma say the CCHIT
website provides access to feedback and
questions from other users, and weekly
phone calls allowed them to share ques-
tions with peers regarding program
nuances.
“The EACH program allows hospitals
and eligible providers to bring this
technology forward for certification and
fill any gaps in certification they may
have because they do not have a complete
vendor solution or because they have
partially or completely self-developed an
EHR,” Becker says. Alternative certifica-
tion is not needed if a hospital or eligible
provider has adopted an EHR with
complete certification or a combination
of certified EHR modules supporting all
meaningful use objectives, she explains.
As groups implement certified EHR
technology, they will negotiate numerous
obstacles, ranging from financial stress to
decreased productivity during training.
Users say that having access to a team of
experts that helps with the technological
transition can offset some of the drama

associated with change. And, they say, it
allows healthcare providers to focus on
providing patient care.
MGMA 2012 Anesthesia Administration
Assembly Conference
April 15-18, 2012
Westin Kierland Resort Scottsdale
Just a glimpse of what you will experience:
• Dedicated education for anesthesiology and pain
management
practice professionals
• Nonstop networking
• New interactive breakfast session focused on
how to enhance
your practice’s revenue cycle
• 50+ industry leading exhibitors with targeted
solutions for you
• Round-table discussions to spark the
exchange of challenges and
solutions between you and your peers
• The beautiful Westin Kierland Resort
Register now at mgma.com/aaa-connexion.
Connexion12Feb.indd 34 1/24/12 1:14 PM
http://mgma.com/aaa-connexion

Copyright of MGMA Connexion is the property of Medical
Group Management Association and its content
may not be copied or emailed to multiple sites or posted to a
listserv without the copyright holder's express
written permission. However, users may print, download, or
email articles for individual use.

ORIGINAL PAPERIntegration of IEEE 1451 and HL7 Exchanging .docx

More Related Content

Similar to ORIGINAL PAPERIntegration of IEEE 1451 and HL7 Exchanging .docx (20)

More from alfred4lewis58146 (20)

Recently uploaded (20)

ORIGINAL PAPERIntegration of IEEE 1451 and HL7 Exchanging .docx