Chapter 12 Page 209Discussion Questions 2. How does a d.docx

Chapter 12 Page 209
Discussion Questions
2. How does a data dictionary influence the design and
implementation of an EHR? How does the data dictionary
enhance and restrict the EHR?
3. In what circumstances might a clinical infrastructure based
on either third-party service providers or mobile applications be
desirable? What cautions would we place on these technologies
in the same circumstances?
Chapter 12 Page 209
2. How does a data dictio
nary influence the design and implementation of an EHR? How
does the data
dictionary enhance and restrict the EHR?
on either third
-
party service providers
or mobile applications be desirabl
e? What cautions would we place on these technologies in the
same

circumstances?
Chapter 12 Page 209
implementation of an EHR? How does the data
dictionary enhance and restrict the EHR?
on either third-party service providers
or mobile applications be desirable? What cautions would we
place on these technologies in the same
circumstances?
Chapter 12 Technical Infrastructure to Support Healthcare
Scott P. Narus
No single off-the-shelf system today can support all needs of
the healthcare environment. Therefore it is critical that the
technical architecture be capable of supporting multiple system
connections and data interoperability.
Objectives
At the completion of this chapter the reader will be prepared to:
1.Describe the key technical components of electronic health
records and their interrelationships
2.Define interoperability and its major elements
3.Contrast networking arrangements such as regional health
information organizations (RHIOs), health information
exchanges (HIEs), and health information organizations (HIOs)
4.Provide information about newer technical models such as

cloud computing and application service providers (ASPs)
5.Synthesize current challenges for informatics infrastructure
Key Terms
Application service provider (ASP), 205
Architecture, 197
Clinical data repository (CDR), 198
Cloud computing, 205
Data dictionary, 201
Health information organization (HIO), 204
Infrastructure, 197
Interface engine (IE), 203
Knowledge base, 202
Master person index (MPI), 199
Regional Health Information Organization (RHIO), 204
Service-oriented architecture (SOA), 207
Abstract
This chapter introduces the technical aspects of electronic
health records (EHRs) and the current infrastructure
components. Complementing the functional components
discussed elsewhere, this chapter introduces terms such as
clinical data repository, master person index, interface engine,
and data dictionary and other technical components necessary
for EHRs to function. Recent material about national efforts
related to the infrastructure and electronic data sharing, such as
the Nationwide Health Information Network (NwHIN) and
information exchange networks, is also reviewed.
Introduction
Understanding the information technology (IT) architecture
underlying a healthcare organization's information systems is
foundational to understanding how that system actually
functions. Decisions about the technical infrastructure have
important consequences for the overall system, in terms of both
functional capabilities and support for clinical workflow. Many
aspects of a clinical IT infrastructure are unique to the
healthcare setting or have different properties or priorities.

Understanding the needs of a clinical data repository or health
data interface network as compared to their counterparts in
other industries can mean the difference between successful and
failed implementations.
EHR Component Model
The EHR may be thought of as a collection of several key
components.1 Each of these components contributes to the
overall system functionality. In older EHRs these components
were often bundled, making it difficult if not impossible to
FIG 12-1 The electronic health record component model. CDS,
Clinical decision support; HIE, health information exchange;
MPI, master person index; NwHIN, nationwide health
information network; RHIO, Regional Health Information
Organization.
separate components from each other. In more modern
technologies each of these components is often developed
separately but may follow a common architectural design
philosophy so that the components can be integrated easily.
Each component could also be enhanced independent of the
others as long as the component integration design was
followed. Often the technical responsibility of the informaticist
is to manage the component design and implementation life
cycle, so understanding the component model and integration
strategy is essential (Fig. 12-1). The following sections describe
common EHR components and important considerations for
each component.
Clinical Data Repository
The clinical data repository (CDR) is the storage component for
all instance data of patient clinical records. By instance data we
mean actual pieces of information collected by manual or
automated means for a specific patient at a point in time. Data
stored in a repository may be lab results, medication orders,
vital signs, clinical documentation, etc. The data may be stored
as free text or unstructured documents or as coded and
structured elements (e.g., as columnar data in a relational

database, as elements of a detailed model within an object-
oriented database). The data within the repository are
considered the most essential aspect of the EHR: without these
data the other components of the EHR are meaningless.
Therefore important aspects of the repository include
accessibility, reliability, and security.
Accessibility means the ability to efficiently retrieve data stored
within the repository. The repository must provide access
methods that allow users of the repository (clinical applications,
decision support rules, etc.) to find information using criteria
that are meaningful to the users. For example, the repository
should be able to distinguish data based on patient
characteristics such as a patient identifier or encounter number.
Data should also be classified by type to permit easy and quick
retrieval of lab results versus radiology results. Other important
data attributes that help with accessibility include dates (e.g.,
date recorded, date observed), data owners and entry personnel
(e.g., ordering physician, charting nurse, case manager), and
location. The access methods for the repository should be robust
enough to support current and future users' access needs.
Reliability refers to the dependability and consistency of access
to the repository. In a critical healthcare setting a repository
needs to support its users on a 24/7 basis. There is little
tolerance for downtime. Inconsistent performance of the
repository—for instance, longer wait times for data retrieval
during high usage times of the day—also affects the reliability
of the repository. Because of its importance to the functions of
all EHR components, the reliability of the repository is the
major factor in determining the perceived reliability of the
EHR. Various architectural and procedural models may be
employed to increase the reliability of the repository, including
redundancy of storage hardware and access routes, system
backup policies, and regular performance reviews and
maintenance.
Security is essential to the repository because of both the
sensitive nature of the data within and the critical role it plays

in the healthcare environment. Various regulations, such as the
Health Insurance Portability and Accountability Act (HIPAA),2
as well as sound ethical practices demand that organizations
provide a high level of confidentiality and privacy for the health
information they handle. The repository must incorporate
security measures in order to prevent, to the extent possible,
inadvertent and intentionally inappropriate access to data. Data
encryption, secure access paths, user authentication, user and
role-based authorization, and physical security of the repository
itself are typical methods employed. Some security methods
may conflict with accessibility and reliability goals, and EHR
implementers must weigh the benefits and costs of each, but
good system design can mitigate conflicts while supporting the
needs of the healthcare setting.
Repositories are distinguished along two axes that describe
storage characteristics of the data: central versus distributed
storage and encounter-based versus longitudinal-based storage.
Central versus Distributed Storage
In the central storage model, a single repository is used to store
all (or most) clinical data and is used as the primary source for
reviewing data. There may still be departmental or function-
specific clinical information systems, as well as automated data
collection devices, that are used to gather data. Some of these
systems may even store copies of their information in their own
repositories but these data are also forwarded to the central
repository and stored there. In the case of a healthcare
enterprise with multiple facilities, potentially consisting of
inpatient and outpatient areas, the central model could store
information from each of these facilities in one repository. This
model improves the ability of a single application to display
data from multiple original sources and locations and provides
the capability to perform clinical decision support (CDS) more
efficiently across multiple data types (e.g., combining lab
results with medication administration and nutrition data to
provide input for medication ordering). Central storage usually
requires that data collected from secondary systems be

transformed (mapped) to a common storage model and
terminology before being stored in the repository. This model
does not imply that data cannot be replicated to other locations
for safety and disaster recovery purposes.
In the distributed storage model, each data collection
application stores its information in its own repository and data
are federated through a real-time data access methodology. In
this case, a results review application may have to access
separate repositories for lab, microbiology, radiology, etc., in
order to provide a composite view of information. In the
previous example of an enterprise with multiple facilities, each
facility might store its own data in a facility-based repository.
The distributed model provides some reliability to the EHR
because, for example, if one repository goes down, the user may
still be able to access information from the other repositories. It
also allows the most efficient storage and access for particular
data types and lessens the complexity of having to map data
from one system to another. However, the distributed model
produces many single points of failure for each repository,
limits performance because of the multiple data access paths
that may be required, and makes integrated tasks such as CDS
much more difficult.
Encounter-Based versus Longitudinal-Based Storage
Encounter-based (or episodic) storage was typically used in
older, hospital-based EHRs. In this model, data are collected
according to the current patient encounter and then are usually
purged or archived from the repository when the patient is
discharged. If the patient has a future encounter with the
facility, data may need to be collected completely anew,
including patient history, allergies, and previous medications.
Encounter-based storage is very efficient in terms of system
performance for supporting the current encounter because the
data in the repository are always the most current and reflect
only what has been collected as relevant to the present
circumstances. In this case, the repository's storage space can
be quite small. However, since data are purged, some

duplication of effort is inherent in this model since data
collected during a previous visit may still be relevant and will
need to be collected again. There is also a chance that pertinent
information from a previous encounter may be lost if a clinician
omits collecting it in a subsequent visit.
A longitudinal-based repository, on the other hand, stores data
across all encounters. It is often referred to as a “cradle to
grave” or “womb to tomb” repository because data may extend
over the entire lifespan of an individual. The obvious
advantages are that clinicians have access to all data collected
on a patient from all clinical interventions and data that do not
change and are relevant across all encounters, such as allergies,
family medical history, and past procedures, do not need to be
reentered at each visit. As with the central (versus distributed)
storage model, the longitudinal record may contain data from
multiple facilities and health enterprises as well. Access to
historical data may be helpful in automated CDS. The
disadvantage is that a patient's record (and therefore the entire
repository) can grow tremendously large with data that become
less relevant over time.
Master Person Index
The master person index (MPI) (also known as the master
patient index or master member index) is the repository for the
information used to uniquely identify each person, patient, or
customer of a healthcare enterprise. One or more registration
systems may be used at each visit to collect identifying
information about the patient, which is then sent to the MPI in
order to match against existing person records and resolve any
conflicting information. The MPI stores demographic
information about the patient, such as names, addresses, phone
numbers, date of birth, and sex. Other organizational identifiers,
such as social security number, driver's license number, and
insurance identification, also may be stored. Identifiers from
within the healthcare enterprise, such as individual facility
medical record numbers, are also stored. (This is often a vestige
of paper medical record systems that used facility-specific

identifiers for each patient.)
As any of this information is updated or added to, the MPI
record is updated. The MPI then serves as both the master of all
information collected, forming what is often referred to as the
“golden record” for a person, and the source for distinguishing a
patient from all other patients in the system. The latter point is
important because it helps to ensure that data are attributed to
the correct patient during healthcare encounters. Each MPI
record will have a unique patient identifier or number that is
used in the repository to associate a clinical record with the
appropriate patient and also is used by applications to properly
retrieve and store information for the right patient. The MPI
will typically support standard access methods for storing and
retrieving data (e.g., Health Level Seven [HL7]
Admit/Discharge/Transfer messages) so that systems that need
to use the MPI can rely on a common interface mechanism. A
user-facing patient selection application connected to the MPI is
typically provided in the EHR so that EHR users can search for
and find a particular patient for use in clinical documentation,
review, and patient management applications.
Clinical Applications
Clinical applications provide the user-facing views of the EHR
to clinicians. When clinicians think and talk about the EHR,
they usually are referring to these applications. Applications are
provided in a variety of technologies and user interface
paradigms, including web-based applications, rich clients
installed on a user's desktop, and mobile apps. A rich client
(also called a fat, heavy, or thick client) is a client–server
architecture or network that provides rich functionality
independent of the central server. In contrast, a thin client
refers to a client–server architecture that is heavily dependent
on a server's applications.
When supplied by a single vendor, applications are typically
“wrapped” inside a single desktop framework that provides
global EHR functions such as user authentication and patient
selection and then launches the individual applications as part

of a clinical workflow. When supplied by different vendors,
applications can still share user and patient context by using
technologies such as Clinical Context Object Workgroup
(CCOW), provided the vendor supports such functionality.3,4
CCOW is an HL7 standard protocol designed to enable different
applications to work together in real time at the user interface
level. The CCOW standard exists to facilitate interoperability
across disparate applications.
Clinical applications can be divided into four broad areas of
functionality: review and reporting, data collection, patient
management, and clinician productivity. For more information
on individual applications in the patient care setting, refer to
Chapter 6.
Review and Reporting
One of the most widely used functions of an EHR is review and
reporting of clinical data in the repository. In general, a review
application is typically focused on one area of clinical data
(e.g., a lab results review application, a vital signs review
module). On the other hand, a reporting application often has a
broad range of clinical data that displays to the user (e.g., a 24-
hour rounds report that combines lab, vitals, medications, intake
and output (I/O), invasive line status, assessments, and plan in
one view). A reporting application also typically allows much
more user customization for selecting content and layout. A
review and reporting application is optimized for display of data
and does not necessarily allow direct data entry. However, to
improve clinical workflow the application may provide a
simple, one-click shortcut to a data collection application in
order to edit or enter new data. A “smart” review and reporting
application may also provide links from displayed data to more
detailed information about that data, such as might be found
with an Infobutton.5–9 In more complex graphical user
interface environments, the review and reporting application
might provide functionality for graphing results, creating
timeline associations between data points, and incorporating
baseline, average, and goal parameters. The ability of the

review and reporting application to support more advanced data
display functions will depend significantly on the granularity of
data stored in the repository; primarily text-based storage will
limit the amount of functionality while highly coded and
structured data will allow increased possibilities. The
performance and overall display capabilities of the applications
are also affected by the repository's central versus distributed
and encounter-based versus longitudinal-based storage
characteristics.
Data Collection
The ability of clinical applications to collect data in the
healthcare environment has improved dramatically as new
technologies have become available. Older clinical information
systems were typically text-based screens that required heavy
use of a computer keyboard or 10-key pad for navigation and
data entry. More modern graphical user interfaces allow a
variety of input and screen navigation possibilities. Some
systems may even allow direct collection of information from
devices such as blood pressure monitors and weight scales. Data
are usually collected one patient at a time and stored in the
repository. Data may be collected in narrative form as
unstructured notes or in a much more granular form as coded
and structured data. For example, a vital signs assessment is
typically collected in a structured format so that it may be used
in a variety of reporting and CDS applications.
Data collection applications often are linked to review functions
so that the clinician can see the current status of the patient and
then add new or updated information. More advanced clinical
workflows such as activity documentation (e.g., medication
administration) may involve computerized decision support and
computerized documentation flow processes to improve data
collection. As with review and reporting applications, links to
detailed information about the data to be collected (Infobuttons)
may be provided to assist the clinician with evidence-based and
regulatory and accreditation requirements for documentation.
For example, in a medication administration application, an

Infobutton linked to a particular drug might provide information
on potential side effects, adverse effects, and therapeutic effects
to assess for a particular patient.
Patient Management
Some clinical applications fit within a category that deals with
clinician cognitive tasks, particularly around therapeutic and
care delivery responsibilities. Ordering and care planning are
examples of patient management responsibilities that are
increasingly being supported by health information technology
(health IT) applications. Each of these responsibilities requires
an elevated cognitive load in order to process the amount of
available patient information as well as the number of potential
decisions a clinician can make. Successful EHRs will provide
appropriate capabilities within patient management applications
so as to support clinicians' ability to appropriately adopt these
applications and support their cognitive tasks.10 Quite often
patient management applications will provide in-line access to
review and reporting applications to improve the ordering and
care planning process. The use of standard terminologies from a
central data dictionary (discussed below) within these
applications ensures that appropriate items are used by
clinicians and communicated to other members of the care team.
CDS systems and access to knowledge resources (discussed
below) may also be employed to enhance decision making.
Clinician Productivity
EHRs often provide clinicians with functionality to assist with
care process tasks that cut across many patients and address
clinical workflow. Examples include care coordination and
physician signature applications as well as interclinician
messaging and notification functions. Point-of-care analytic
applications that address quality issues are also becoming
popular, particularly because of national health IT initiatives
such as Meaningful Use.11,12 These applications provide
information on a clinician's patient population in order to
monitor care and outcomes according to desired goals and can
compare progress over time or against either standard criteria or

other similar clinicians. For example, this type of application
might report that one physician's patients with a specific
diagnosis average an extra day in the hospital but also show a
lower average readmission rate than other patients with the
same diagnosis.
Data Dictionary
A key component of many modern EHRs is a data dictionary
that contains the medical vocabulary terms used to store data
within the repository. These same terms are used by the EHR
applications to collect and display clinical data. In its simplest
form the data dictionary can be viewed as a list of the health
terms and their definitions needed by the EHR, usually stored in
one or more database tables. The dictionary might contain terms
for diagnoses, medications, lab tests, clinical exam measures,
etc. Each of the terms may be assigned a specific code that is
independent of how the term is represented to a user. For
example, a diagnosis of dyspnea might be assigned a code of
1234. The actual representation for the term dyspnea (medical
concept) could be “dyspnea” (English medical text
representation), “shortness of breath” (English common text
name), or “SOB” (English abbreviation of shortness of breath).
In this case all of the representations would have the same
definition and dictionary code because they are equivalent.
Medical concepts from standard terminologies such as
International Classification of Diseases (ICD)-9, ICD-10, or
Systematized Nomenclature of Medicine (SNOMED) are also
added to the data dictionary so that these terms can be used in
applications and in the repository.
The data dictionary is particularly useful in the EHR because it
is the central source for defining all terms and their
corresponding codes used by the EHR. Instead of hard-coding
these terms and codes within applications, the data dictionary
allows more flexibility at application runtime to access new and
updated terms as they become available over the lifetime of the
EHR. For example, as new medications and diagnoses are
created they can be added easily to the data dictionary and made

accessible to all applications within the EHR. If these terms
were hard-coded within an application instead, the programs
would have to be updated and recompiled to make the terms
available. In addition, all instances where the terms are used
would potentially have to be updated (e.g., if two or more
applications were exposing medication information). This leads
to a greater maintenance burden for the EHR and can potentially
lead to errors if term sources are not kept synchronized.
The data dictionary also provides the ability to create term
relations. These relations take the form of hierarchical or
associative relations. Hierarchical relations are the most
common and can be used to describe domains and subdomains
for terms. For example, a domain term for “diagnosis” can be
created and then subdomains of “cardiovascular diagnosis,”
“respiratory diagnosis,” and “endocrine diagnosis” could be
defined. Within each of these subdomains, additional
subdomains may be defined for more granular categorization but
eventually the domains would list individual diagnosis terms,
such as “hypertension” or “pneumonia.” The domain
relationships are useful in applications and decision support
logic when, for example, a user wants to narrow a disease
search in a problem list application to just cardiovascular
diseases or when a decision support rule broadly defines an
inclusion statement such as “IF Ordered_Drug Is_A
Cardiovascular_Drug THEN…,” where “Ordered_Drug” is an
instance of a drug ordered for a patient, “Cardiovascular_Drug”
is defined as the domain for all cardiovascular drugs, and
“Is_A” is the relationship used by the data dictionary to define
hierarchical domain relationships between parent and child
terms.
Associative relations can be used to define other useful,
nonhierarchical relationships between terms. For example, we
could associate the diagnosis term hypertension with the drug
domain term beta blocker by creating a relationship called “can
be treated by.” In this case, since “beta blocker” is a domain,
we can assume that all terms within this domain would inherit

the “can be treated by” relationship with hypertension. Another
example of an associative relationship is a link created between
two different coding systems that might describe similar terms.
For example, a local laboratory information system (LIS) might
contain its own coding for all lab tests it performs. However,
the EHR and other external systems might use a standard lab
terminology such as Logical Observation Identifiers Names and
Codes (LOINC).13–15 In this case the dictionary could define a
mapping relationship between the terms in each of the systems
so that information could be shared between the systems and
maintain the semantic meaning of the terms.
One final note about data dictionaries concerns the desire or
need to provide a unique code for each term in the dictionary.
The unique code is necessary because the same term
representation might be used to describe different concepts. For
example, the word temperature might be used by a patient to
describe having a “high temperature” (chief complaint) while a
nurse might use this word to chart a physical measurement of
“body temperature” (observation). These are different concepts
and the concept codes ensure that they remain distinct. Other
reasons to use unique codes are because term representations
may change over time or multiple representations for the same
term may be allowed depending on the user or display context.
In these cases the code would remain the same. Lastly, it is
usually much faster to search for codes rather than
representations within a repository when they follow a strict
numeric or alphanumeric syntax. This makes the repository and
thus applications more responsive to user access, although the
overhead of translating stored codes to user-readable term
representations must be considered.
Knowledge Base
A knowledge base (or knowledge repository) is a component
within the EHR that stores and organizes a healthcare
enterprise's information and knowledge used by the enterprise
for clinical operations. This information might range from
simple material such as lists of orderable items, available

services, or policy documents, to richer content such as order
sets and searchable medical subject matter, to highly complex
knowledge such as clinical guidelines and decision support rule
sets.
The content in the knowledge base is usually organized by
attaching metadata (information describing the content) to
content items, allowing categorization of the knowledge content
based on contextual need. The content itself usually follows a
defined metadata model (detailed data format description) so
that it can be consumed easily by applications. In some cases
the content may be human readable, such as content consisting
of medical journal articles that are indexed by subject matter. In
other cases the content may be machine consumable; that is, the
content may be read by a computer program and used to
automatically produce an output, such as a logic statement that
might be executed by a decision support engine in order to
produce a suggestion or alert from a clinical guideline. Often
the data dictionary is used to supply coded content and index
information within the knowledge base. This ensures that the
knowledge base remains synchronized with the patient data
repository and clinical applications.
The knowledge base's content (often known as knowledge
“artifacts”) allows an EHR to become a “content-driven” system
as opposed to a system whose knowledge is hard-coded in
software programs. When knowledge such as treatment
protocols, drug–drug interaction rules and descriptive content is
hard-coded in clinical applications it is much more difficult and
costly to update those applications. By separating the
knowledge artifacts from the software and providing access
through linkage services, clinical programs can keep pace with
the rapidly changing and expanding medical environment, as
represented by approaches such as evidence-based practice.
One example of a knowledge-based environment is use of the
Infobutton standard: the Infobutton allows clinical applications
to link dynamically to contextually relevant content located
either within or outside a provider system.5 The content

provider may update this content as newer information is
discovered or produced but the applications that link to the
content through the Infobutton do not need to be changed
because the interface (link) remains the same, providing a more
robust EHR. Content-driven systems can also use local
knowledge about a healthcare enterprise's operations in order to
optimize workflows and enhance clinician interactions with the
EHR.
As the content within a knowledge base grows, knowledge
management tools become necessary in order to maintain the
information.16 Authoring tools that allow knowledge content to
be created and updated and then facilitate the review process
are particularly useful.17,18 In addition, governance policies
and procedures must be instituted to ensure the integrity of and
promote and coordinate the use of the knowledge within the
repository.
Clinical Decision Support System
A CDS system provides the technical means to combine general
medical and health knowledge with specific data about a patient
and current clinical context in order to assist a clinician in
making appropriate treatment choices and to alert healthcare
providers about relevant information and important events. For
example, during the ordering process a clinician might be
alerted about a potential drug–drug interaction that was found
by the CDS system when a newly submitted prescription was
compared with the patient's current medications. The CDS
system also might be used to advise a clinician on the preferred
treatment actions for a diabetic patient, based on the
institution's best practice guidelines and the patient's current
medical state. In addition, a hospital staff member might be
alerted about a critically abnormal lab result that could affect
medical care.
The CDS system typically consists of an inference engine that
runs rules or logic (programs), methods for receiving or pulling
data from clinical sources, and a communication system for
notifying users or other systems about decision support results.

The CDS system may be tied to a knowledge base in order to
receive its rules, in which case the rules can be updated as
needed without having to change or recompile CDS code. The
CDS system also may contain hard-coded rules that must be
changed by recompiling code, or the logic may be based on
machine-learning algorithms that dynamically update as new
information is processed by the system.
Data services may be used by the CDS system to access clinical
data in the repository. Sometimes these data are automatically
sent to the CDS system by a “data drive” mechanism that
automatically triggers a feed to the CDS system whenever data
are stored in the repository. Clinical applications also may
supply data directly to the CDS system for real-time decision
support, for instance when a clinician is in the process of
performing an action and needs assistance from the CDS system
before making a final judgment. Quite often, even if data are
automatically sent to the CDS system through a data drive
mechanism or directly from an application, the rules to process
the data require additional information from the repository. In
this case the CDS system may use data access services to
retrieve the needed repository data.
The CDS system may need a queuing mechanism in order to
support rules that will be triggered at a later time. For example,
a rule processed on a lab result might trigger an output that says
to wait for a new lab value in 24 hours before making a final
recommendation to the clinician. If another lab result is not
found within 24 hours, the rule will provide a different output
recommendation, such as “order a new lab X.” Another use for
the queue is to support “stateful” clinical protocols, that is,
protocols that remember the state of the patient from a previous
point in time and use this information to make recommendations
at a later time.
Once a rule is run the output result must be communicated to
the appropriate recipients. The CDS system might store a
decision support result in the data repository if the rule was
triggered without direct user input so that a clinician can see the

result at a later time. There might also be a mechanism for
notifying a specific user of a result through email, pager, or
other communication device. When accessing the CDS system
directly from a clinical application, the CDS system must have a
method for communicating its results back to the application,
usually through a service or application programming interface
(API). CDS systems are explained in additional detail in
Chapter 10.
System Integration and Interoperability
The EHR is often only one piece of a larger health information
system environment within a healthcare enterprise. In fact, it is
common for larger institutions to run two or more EHRs.
Because no single EHR today can provide all of the
functionality needed in most healthcare facilities, the ability to
share information between systems is necessary. Departmental
and ancillary systems for lab, pharmacy, radiology, registration,
billing, etc., must be able to pass information to and receive
information from the EHR. Integrating these systems is
typically the responsibility of an interface engine (see following
section). The different methods for storing and communicating
data used by health information systems today necessitate
interoperability standards to ensure proper communication.
Interface Engine
Older intersystem communication methodologies used point-to-
point connections to allow different systems to share data and
information; that is, a specialized interface was created between
one system (A) and another system (B). The interface between
systems A and B only knew how to translate between these two
systems and could not be used to talk to another system. This
method is fine if there are few systems in the network.
However, as the number of systems grows, the number of
connections multiplies rapidly. For a network with N systems
where all of the systems are interconnected, there are N × (N –
1)/2 connections; for example, a network with six systems
would have 6 × (6 – 1)/2 = 15 connections. Each system in the
network must individually expose N – 1 interfaces in order to be

fully interconnected with all other systems in the network. In
practice this means that for a network with 6 systems and 15
connections a total of 30 interfaces must be maintained. If a
system in the network is replaced, all of its N – 1 interfaces
must be replaced, too.
Because of the cost and complexity of point-to-point interfaces,
modern information systems often employ an interface engine
(IE). An IE allows each network data source to have one
outbound interface that can then be connected to any receiving
system on the network. The IE is able to queue the messages
from a data source, transform the messages to the proper format
for the receiving systems, and then transmit the messages to
appropriate systems. Acknowledgment and return messages also
can be routed appropriately by the IE.
IEs use proprietary software or standard programming
languages such as Java to write routines for translating one
system's data message model into another system's model. Most
of today's IEs support standard messaging interfaces like HL7
and X12. The IE must also translate terminology between
systems because quite often systems will use different
vocabularies or coding methods to represent comparable
concepts. Sophisticated interface engines will use external
sources such as a standard data dictionary to provide the
necessary terminology translation services. This allows the IE
to remain up to date on the latest coding conventions and
translations for the systems on the network.
The following scenario explains how an IE could be used to
integrate an EHR with various ancillary systems. At the
beginning of a clinical encounter the patient is registered in the
facility's registration system. The collected demographic
information and encounter identifiers are transmitted by the
registration system to the IE, which then transforms and
forwards this information to the EHR and the LIS. During the
patient's visit the physician uses the EHR to order a laboratory
test. The lab order message is appended with the correct patient
identifiers and routed through the IE to the LIS. The EHR uses a

proprietary coding system for lab tests that the physician
orders; these are mapped to LOINC codes that the LIS uses.
When the lab completes processing of the test, the lab results
are returned by the LIS to the EHR via the IE. The IE also
branches LIS administrative information for the test to the
facility's billing system for reimbursement purposes.
This scenario describes a somewhat simple network of five
interfaces. In reality, the registration system may be tied to
many more systems that need demographic and patient identifier
information. The EHR will provide order messages not only to
an LIS, but also to departmental systems for radiology,
pharmacy, nutrition, etc. Each department system's results may
need to be routed to several receiving systems for storage,
processing, and reporting; the EHR will typically need an
inbound interface from each of these diagnostic systems. The
impact when one or more of the systems on the network is
replaced must be considered. An IE greatly improves the ability
to address this complicated network environment in an efficient
and usually less costly manner.
Interoperability Standards
System and data sharing or interoperability has long been a
problem for EHRs. Most EHRs and departmental and ancillary
systems have been written using proprietary programming and
data storage schema. This has made it difficult to share data
between systems. When trying to connect two systems,
integrators must first agree on a common exchange mechanism
and message format (called syntactic interoperability). Then, to
ensure that the data passed between the two systems are
understandable by the receiving system, the content of the
message must be mapped to a comparable and comprehensible
model and terminology in the receiving system (called semantic
interoperability).
Some of the most widely used clinical messaging standards are
produced by the HL7 organization.19 The HL7 version 2.x
message standard is supported by virtually all major clinical
information systems in the U.S., providing a common method

for connecting EHRs and departmental and ancillary systems.
The version 2.x standard specifies the format for messages but
does not specify a standard for the content. The HL7 version 3
standard uses a much more formal specification to define
messages and is based on the Reference Information Model
(RIM). RIM and the Clinical Document Architecture (CDA) can
be used to ensure better semantic interoperability between
systems. Version 3, initially published in 2005, is not as widely
implemented in clinical information systems in the U.S. as
version 2.x because of its added complexity and significant
implementation costs. Most clinical interface engines support
the HL7 standards.
Many national and international terminology standards have
been developed to support the exchange of clinical data and
promote semantic interoperability of systems. Most of these
standards were started around a specific clinical domain but
may have been expanded to cover additional domains as the
terminology was adopted. For example, LOINC was originally
developed to describe clinical laboratory data but has been
expanded to cover other clinical observations such as vital
signs. SNOMED CT was originally developed as a nomenclature
for pathology. It has been extended to become a highly
comprehensive terminology for use in a wide variety of
applications, including EHRs. Other terminology standards
include ICD-9 and ICD-10, Current Procedural Terminology
(CPT), RxNorm, and nursing terminologies such as Nursing
Interventions Classification (NIC), Nursing Outcomes
Classification (NOC), and North American Nursing Diagnosis
Association (NANDA). For additional information on
terminology standards, refer to Chapter 22. Information on the
Omaha System is included in Chapter 9, which deals with home
and community-based health systems.
Networking Systems
In the previous section we discussed system interoperability
within the walls of a single institution. However, there is a
growing desire and need to share patient information between

institutions for quality, financial, and regulatory purposes.
Sections of the Meaningful Use criteria in the 2009 Health
Information Technology for Economic and Clinical Health
(HITECH) Act specifically call for sharing of clinical data
between healthcare providers and with public health.11 Various
organizational models for sharing data have been developed at
the local, regional, and national level.
RHIOs, HIEs, and HIOs
One of the earliest models for a data sharing network was the
Regional Health Information Organization (RHIO). A RHIO is
typically characterized as a quasi-public, nonprofit organization
whose goal is to share data within a region. RHIOs were quite
often started with grant or public funding. Health information
exchanges (HIEs) followed RHIOs and are differentiated from
them by having an anchor provider organization and usually
being started for financial incentives. The anchor organization
often provides a data sharing mechanism with affiliated
providers. In practice the operating characteristics of RHIOs
and HIEs may be quite similar and the distinctions are only in
the terminology used.
Health information organizations (HIOs) are the latest models
and support the 2009 HITECH Act mandate for health
information sharing between EHRs. The role of the HIO is to
facilitate data exchange according to nationally recognized
standards. This may mean that the HIO only provides guidance
to the organizations in an information exchange network or that
the HIO assumes the technical responsibility for providing the
exchange mechanism.
To facilitate data sharing, the information exchange network is
designed as either a centralized or a distributed data
architecture (although hybrids of the two are also sometimes
deployed). In the centralized model the participants on the
networks push their data to a central repository housed in one
location. Organizations then retrieve data from the repository as
needed. In a distributed model the network participants keep
their data and provide a mechanism to answer requests for

specific data. In either model the network must provide the
ability to correctly match patients between organizations.
Without this matching functionality, the network participants
are unable to share information accurately. The network may
use a global MPI that can map patient identifiers between
organizations. In addition, to provide syntactic and semantic
interoperability of the data, the network participants must agree
on standards for information exchange. These standards may be
similar to those discussed in the previous section on
interoperability standards. Lastly, the exchange network must
provide appropriate security mechanisms to authenticate and
authorize appropriate use, prevent unwanted access, and
accommodate necessary auditing and logging policies.
To connect to the information exchange network, participants
may simply treat the network as another interface on their local
interface engines. This allows participants to use existing
methods for sharing data, particularly if a centralized model is
used and data are pushed to the central repository. In the case
where a distributed model is used and participants must accept
ad hoc, asynchronous data requests, some additional effort may
be required to effect data sharing. Another model for linking to
the exchange network is to provide a service layer that accepts
ad hoc requests for data. The data request services are
accessible by network participants, often in the same way that
web pages are made available as URLs on the World Wide Web.
This method is becoming more popular and is particularly
advantageous in the distributed exchange model because it
better supports pulling data from an organization as it is
needed.
Nationwide Health Information Network (NwHIN)
The Office of the National Coordinator for Health Information
Technology (ONC) is facilitating the development of a national
“network of networks” that will enable health care provider
organizations and consumers to share information across local
information exchange networks. The Nationwide Health
Information Network (NwHIN) is a set of policies and national

standards that will allow trusted exchange of health information
over the Internet.20 An initial implementation of the NwHIN
architecture called CONNECT was demonstrated in 2008, with
participation by various public and private entities,21 and
includes components for core services (locating patients,
requesting documents, authentication, etc.), enterprise services
(MPI, consumer preferences management, audit log, etc.), and a
client framework (application components for building test and
user interfaces to CONNECT). A simplified implementation of
the NwHIN architecture called Direct allows two organizations
to share medical information through common methods, such as
email-like protocols.22 These methods require a provider
directory to ensure secure, point-to-point routing of messages.
Other Infrastructure Models
The previous sections on the EHR component model and system
integration focused on technical infrastructure that may be
deployed locally within an organization. Other models exist that
can also supply this infrastructure, but from sources outside an
organization's walls.
Application Service Provider
Rather than purchasing and installing an EHR, some institutions
opt to partner with an application service provider (ASP) for
their clinical application needs. An ASP is a company that hosts
an EHR or departmental system solution for a healthcare
enterprise and provides access to the application via a secure
network. Users of the application are usually unaware that they
are connecting to a vendor's offsite computing facilities. An
ASP model relieves the healthcare enterprise from having to
host and support the technical components of the EHR, which
may lead to lower capital infrastructure costs. This obviously
helps smaller facilities that lack funding for a complete IT shop
but it may be financially beneficial for larger facilities as well
because of the economies of scale that an ASP vendor can
provide over many customers.
On the other hand, the ASP model implies some loss of control
of the EHR. ASP customers must be content with their data

being stored at the vendor's off-site location. They must also
accept that versions of application software, functionality,
configurations, and levels of support typically will be what the
majority of the other ASP customers are using. Lastly, it may be
more difficult to integrate with other IT systems at the local site
since the ASP vendor may not support interfaces for a
healthcare enterprise's entire portfolio of departmental and
ancillary systems. Interfaces may be more difficult to develop
and maintain since the ASP vendor controls its half of each
interface and may not prioritize projects in sync with the
facility's needs.
Cloud Computing
One of the growing trends in IT is the concept of cloud
computing. Although the term cloud computing is somewhat
new, the basic idea behind it goes back decades. It can be traced
to early suggestions that computing would some day be like
other public utilities and that IT consumers would plug in to
networks of applications and physical resources in the same way
that electricity and phone lines are accessed. Computing
resources would be supplied by either public organizations or a
few private enterprises and shared by the consumer community.
The term cloud was attached to this concept because early
networking diagrams enclosed these “public” computing
resources within a cloud figure in order to represent resources
outside of an organization's physical walls and the ability for
these resources to change location without affecting the
consumer's ability to access them. While we often still consider
clouds as being available in a public space (i.e., accessible by
many consuming individuals and organizations), a cloud may
also be private (i.e., deployed within the walls of single
organization for use by that organization's various entities).
Cloud computing can be separated into three models: software
as a service (SaaS), infrastructure as a service (IaaS), and
platform as a service (PaaS).23
In the SaaS model, service providers run applications (services)
at one or more locations and make these available to consumers.

Consumers connect to the services through a cloud client, often
something as simple as a web browser. This eliminates the need
for consumers to host and support the applications themselves.
The SaaS provider can also use economies of scale to provide
multiple servers and sites that host applications, potentially
increasing the efficiency, performance, and reliability of the
applications. SaaS applications may be as simple as a service
that provides a single function, such as Google Maps, or an
application that covers an entire set of workflow requirements.
The ASP model described in the previous section may be
considered a type of SaaS. In clinical computing SaaS might be
used to provide an entire EHR or EHR function (e.g.,
scheduling, lab results review from a lab services provider) or
more focused functions within an EHR application such as
drug–drug interaction checking during the ordering process,
information retrieval for clinical descriptions of diagnoses and
abnormal lab results, or terminology mapping between coding
systems.24
The most utility-like example of cloud computing is IaaS. In
this model, the cloud provider makes computing machinery
available to consumers from large pools of resources. The IaaS
provider can scale the computing resources to the needs of the
consumer. This practice has become simpler with the growing
use of virtual machines, which can be installed as multiple
instances on physical hardware and simulate most of the
characteristics of an operating system and its environment. The
consumer is responsible for deploying the operating system,
applications, databases, tools, etc., and then supporting those
installed assets. Users may connect to the assets deployed on
the IaaS resources through the Internet or via a virtual private
network. The IaaS provider can help organizations to lessen the
cost of ownership of physical resources and offload the need to
employ local technical personnel to maintain equipment.
The PaaS model is a simplification of the IaaS model in which
the cloud provider deploys an entire platform for running the
customer's computing needs. This may include the operating

system, application server, web server, database, etc. The
consumer then installs or develops software on the resources
provided. The PaaS provider supports the computing resources
supplied by its cloud while the cloud user supports the assets
built on top of it.
Current Challenges
Even though most of the technologies discussed so far have
existed for decades, many technical challenges and barriers
remain for implementation in the clinical environment. For the
EHR repository, primary challenges remain around the
robustness of storage architectures. With transitions to patient-
centered longitudinal records, the size and content scope of the
repository has grown considerably. Additionally, as new data
types are added to the EHR in order to capture more detailed
information about clinical encounters and patient health
(particularly to meet the expanding requirements of Meaningful
Use), the repository must be able to handle new information that
was not anticipated in its original design. These facts demand
that the database and storage mechanisms be flexible.
Databases must be able to scale in size to accommodate large
amounts of online data. As they grow in size, they must retain
performance characteristics that do not slow down the workflow
of the clinical environment. Some database architectures and
their storage services require new designs and recompilations as
new data types are added. Some are not designed for the
volumes of information that may be stored, especially in the
future. Careful consideration of repository architecture must be
performed before system selection to ensure that the system will
meet the ongoing needs of the healthcare organization. Consider
that patient data will have a lifetime measured in decades,
whereas the technology will be enhanced or replaced on a 5- to
10-year, or less, lifespan. There must be a graceful way to
transition the data in the repository to new technology without
loss of information.
Data integration and interoperability remain the most difficult
challenges in health information systems. The lack of standards,

or the lack of implementation of standards, is a significant
barrier. Expanding federal requirements around data exchange
are forcing EHR vendors to abandon proprietary data
architectures and adopt accepted standards for many types of
data, but considerable work still needs to be accomplished to
ensure semantic interoperability of data. This issue, coupled
with older, outdated repository architectures, may leave some
health IT vendors, and therefore their customers, without a path
forward for their systems.
Some underlying system architectures make the EHR component
model described earlier in the chapter difficult, impractical, or
impossible to implement. Component APIs and services may be
inflexible and require considerable effort in order to add new
components, particularly if a different development group or
vendor supplies those components. This issue reflects a lack of
system integration standards (to accompany the lack of data
integration standards discussed previously). Because of this,
quite often a health IT vendor must supply all pieces of the
component model, locking customers into a single solution that
may lack needed robustness in one or more of the components.
Lastly, one of the most vexing challenges for health IT has been
the ability for clinical applications to integrate well with
clinical workflow. Informatics professionals address these
workflow issues during system analysis and usability activities
to improve application adoption by clinicians. Additional
information for understanding usability activities is included in
Chapter 21. Still, a thorough analysis and usability assessment
may not ensure acceptance in all environments. Some amount of
application adaptability is often necessary to tailor the system
to specific settings and for specific individuals. On the other
hand, allowing for application customization at the facility,
department, and user level may be quite difficult to accomplish
and support (depending on the system architecture and technical
abilities of the application support staff) and can lead to
nonstandard implementations that may prove costly. Upgrades
to nonstandard and highly tailored applications can also be

extremely challenging. How well application providers support
customization is an important consideration in system selection.
It can have significant consequences on overall clinical IT
systems infrastructure. Too little customization may mean that
multiple applications must be added to the infrastructure to
address the specific needs of each department or unit. More
liberal customization, besides adding user complexity, may
force larger manual and automated governance structures on the
organization to ensure that individual solutions still support
organizational policies and goals. In either case the underlying
technology of the clinical applications has a profound effect on
the ability of users to do customization. In some cases a
programmer must change or add source code in order to make
local adaptations. In other cases tools supplied with the
application allow configuration changes that can be
incorporated more easily and quickly in the application, but
obviously with limits to the scope of customization.
Conclusion and Future Directions
The technical infrastructure of a health information system
includes several key components that are unique to the
healthcare environment. A sound understanding of the attributes
of these components and how they interact is essential for a
successful system implementation that supports the needs of the
clinician users. No single off-the-shelf system today can support
all needs of the healthcare environment. Therefore it is critical
that the technical architecture be capable of supporting multiple
system connections and data interoperability. More
functionality will also become available from third-party
vendors and infrastructures should be designed to support
linking these capabilities directly to the clinical workflow. It
should also be expected that the desire, and requirement, to
share data outside an institution's walls will expand. The
informatics role will continue to grow as the need to understand
new technologies and how they can be combined with existing
systems and exploited in the healthcare environment gains
heightened importance.

Many new technologies are being explored or contemplated for
health IT infrastructure. Most of these technologies are not new
to other industries; healthcare has been much slower to adopt IT
in general. In some cases these technologies have been
implemented in organizations that possess strong informatics
experience but they have not been employed more widely.
Certainly the increasingly technology-savvy clinicians
practicing at healthcare institutions are demanding functionality
that looks more like what they use daily in web-based
applications, smartphones, and tablet computers.
Mobile Apps
The growing use of mobile electronic devices has resulted in an
explosion of smarter technologies for operating systems, user
interfaces, and applications. Apple advertised more than
500,000 apps available for its iPhone and iPad as of June 2012.
Google advertises hundreds of thousands of apps for its Android
operating system, which is used in smartphones and tablets.
Several hundred of the mobile apps available can be categorized
as medical or health related, and that number is growing. The
apps range from medical reference materials, to radiology image
and diagnostic results viewers, to fairly robust clinical
documentation tools.
A valuable aspect of these apps is that they are easily installed
on a user's device. They are typically much cheaper than
applications that run on laptop and desktop computers. The
ability to “carry” the app anywhere the user goes and remain
connected to an institution's network (through a cellular or
wireless network) is appealing to clinicians who roam to several
locations throughout their workday. The volume, ease of
installation, and inexpensiveness of apps can provide a much
more “democratic” user voice in the selection of apps that are
most useful or appealing to the user. The lightweight nature of
mobile apps and the use of common user interface and
application programming interface standards may make it easier
for healthcare institutions to develop their own apps,
customized to local needs.

There are challenges, however, to the use of mobile apps in the
healthcare setting. First, the small screen factor of mobile
devices limits the amount of information that may be displayed
or collected. This can mean scrolling or paging through many
screens to eventually get to the information needed by the
clinician. It also may be easier to miss important information on
the screen because of the smaller font and image sizes. Wireless
networking may be another challenge for healthcare institutions.
The increasing number of mobile devices in a healthcare
facility, coupled with the “chatty” nature of many mobile apps,
may overwhelm a hospital or clinic network. Organizations may
need to develop support for virtual private networks in order to
accommodate users who wish to use their mobile devices and
apps outside the institution's walls. IT departments also must be
able to handle devices brought into a facility by clinicians who
are not employed by the organization, leading to potentially
significant support and security issues. Finally, while the
“democratization” of apps referred to earlier may seem at first
blush to be a positive trait, a healthcare institution must be
concerned with the support, data, and process standardization
issues that may ensue. If clinicians are free to choose any app
(e.g., for charting vital signs or ordering), will those apps be
able to access and store data in the institution's required format,
run decision support rules required for patient safety and
quality reporting, and share information with co-workers and
referral partners?
Service-Oriented Architecture
There has been much hype for years in the IT industry in
general about service-oriented architecture (SOA), and
healthcare has certainly been an active topic area in the
discussion. SOA can be described as an architecture design
pattern in which services are business oriented, loosely coupled
from other services and system components, vendor and
platform independent, message based, and encapsulated with
internal architecture and program flow that are hidden from the
service user. SOA services are most evident today as web-based

(URL) services that are accessed through Hypertext Transfer
Protocol (HTTP). Extensible Markup Language (XML) is
commonly used as the message format. The interface to a web
service, including its allowed input parameters and return data,
is often described using the Web Services Description Language
(WSDL).25 SOA fits in the SaaS category of cloud computing
but it has much more highly defined design and implementation
patterns.
What this means to IT is potentially a more decentralized
approach to system design in which solution providers
concentrate on specific aspects of a business need. System
architects can pull together many business services to meet the
larger application needs of the organization without having to
worry about the complexity inside the service code. Reuse is a
key benefit of SOA because services may be used by different
consumers for a variety of applications. Because the services
are loosely coupled from each other and from other aspects of
the service user's system, service code may be changed and
enhanced without necessarily having to change other aspects of
the overall consuming system. Changes can easily be
communicated to service users through updates in a service's
WSDL.
The SOA design philosophy has been researched in healthcare
for a number of years. A joint effort by HL7 and the Object
Management Group (OMG) to develop standards for healthcare
services has resulted in the Healthcare Services Specification
Project (HSSP).26,27 HSSP has been investigating several
health IT functional areas that could become the building blocks
for EHR services. One example is CDS.28 By exposing CDS
services over the web, users would be able to access CDS
content from a variety of sources without having to maintain the
content locally. Other areas being pursued by HSSP include
services for terminology mediation and clinical data access and
update.
Because no single vendor product can meet all needs of a
healthcare enterprise, vendors and market segments (e.g.,

pharmacy fulfillment, HIE) are also incorporating SOA
principles in their architectures in order to more easily and
quickly provide functionality to users. Whether a major EHR
product will ever be entirely composed of SOA services
supplied by third-party providers is an open question, but it is
likely that health IT infrastructures will provide increased
support for services as standards continue to emerge and service
providers become more numerous and relevant to the healthcare
community.
Open Source Software
Open source software (OSS) can be defined as software whose
source code is made available to users, who then may be able to
examine, change, and even redistribute the code according to
the software's open source license. OSS is often developed in a
public forum in which many programmers from different
organizations, or acting as independent agents, contribute to the
code base. There is typically a central code repository where all
contributors place their updates and where users can download
latest versions of code or compiled objects. Users may also keep
a list of bug reports and feature requests. Open source advocates
believe that OSS may be more secure, bug-free, interoperable,
and relevant to specific user needs than proprietary (vendor)
software because a more heterogeneous group of individuals
with varying uses for the software has direct access to the
source code. Some noted examples of OSS are the Apache
HTTP web server, the Linux and Android operating systems, the
Eclipse software development platform, the Mozilla Firefox web
browser, and the OpenOffice software suite.
Several examples of OSS exist in the healthcare arena. EHR
applications include OpenMRS, a multiinstitution project led by
the Regenstrief Institute and Partners In Health, a Boston-based
philanthropic organization,29 and OpenEHR, an ONC-certified
ambulatory EHR.30 The U.S. Department of Veterans Affairs is
seeking to develop an open source version of its VistA EHR.31
The openEHR Foundation is developing open clinical
archetypes (standard data models) to promote sharable and

computable information.32 Open source, standards-based CDS
tools and resources are being developed as part of
OpenCDS.33,34 Mirth Connect is an OSS interface engine that
is built for HL7 integration.35 Apelon provides its terminology
engine, Distributed Terminology System (DTS), as an open
source platform36; 3M Health Information Systems has
announced that it will make its health data dictionary available
through open source.37,38 These examples, and the many more
in development or production, point to a future health IT
infrastructure environment with wider clinician collaboration
and less expensive software licensing costs. Organizations need
to be aware that “open source” does not mean “free”; they must
budget for local customization, implementation, training,
support, and hardware costs.
SMART
Through its Strategic Health IT Advanced Research Projects
(SHARP), the ONC has funded the Harvard-based Substitutable
Medical Applications, Reusable Technologies (SMART)
Platforms project.39 The goal of SMART is to provide a health
IT platform based on core services that allows apps to be
substituted easily. Inspired by the boom in mobile apps for
cellphones and tablets, researchers have developed an
application ecosystem in which data can be accessed easily and
presented to apps constructed for specific purposes. The apps
can be bundled to provide an entire health IT solution.
Institutions can decide which apps their “containers” will
deploy for their clinicians based on local needs and specific app
aspects such as security capabilities. The API is open source,
allowing anyone to develop new applications, which can then be
provided to the user community as open or closed source code.
A government-funded effort initially, it will be interesting to
see whether the SMART platform will be adopted widely by the
healthcare provider and vendor community or a similar effort
may compete with SMART.
References
1.

Clayton, PD, Narus, SP, Huff, SM, et al.: Building a
comprehensive clinical information system from components:
the approach at Intermountain Health Care. Methods Inf Med.
42(1), 2003, 1–7.
2.
Gostin, L: Health care information and the protection of
personal privacy: ethical and legal considerations. Ann Intern
Med. 127(8 Pt 2), 1997, 683–690.
3.
Marietti, C: The eyes have it: CCOW (Clinical Context Object
Workgroup) brings both cooperation and competition together
to tackle visual integration. Healthc Inform. 15(6), 1998, 39.
4.
Berger, RG, Baba, J: The realities of implementation of Clinical
Context Object Workgroup (CCOW) standards for integration of
vendor disparate clinical software in a large medical center. Int
J Med Inform. 78(6), 2009, 386–390.
5.
Cimino, JJ, Li, J, Bakken, S, Patel, VL: Theoretical, empirical
and practical approaches to resolving the unmet information
needs of clinical information system users. Proc AMIA Symp.
2002, 170–174.
6.
Reichert, JC, Glasgow, M, Narus, SP, Clayton, PD: Using
LOINC to link an EMR to the pertinent paragraph in a
structured reference knowledge base. Proc AMIA Symp. 2002,
652–656.
7.
Cimino, JJ, Li, J: Sharing Infobuttons to resolve clinicians’
information needs. AMIA Annu Symp Proc. 2003, 815.
8.
Collins, S, Bakken, S, Cimino, JJ, Currie, L: A methodology for
meeting context-specific information needs related to nursing
orders. AMIA Annu Symp Proc. 2007, 155–159.
9.
Del Fiol, G, Huser, V, Strasberg, HR, Maviglia, SM, Curtis, C,

Cimino, JJ: Implementations of the HL7 Context-Aware
Knowledge Retrieval (“Infobutton”) Standard: challenges,
strengths, limitations, and uptake. J Biomed Inform. 45(4),
2012, 726–735.
10.
Weir, CR, Nebeker, JJ, Hicken, BL, Campo, R, Drews, F, Lebar,
B: A cognitive task analysis of information management
strategies in a computerized provider order entry environment. J
Am Med Inform Assoc. 14(1), 2007, 65–75.
11.
Centers for Medicare & Medicaid Services (CMS): Meaningful
Use. 2012, CMS, Accessed September 17, 2012
http://www.cms.gov/Regulations-and-
Guidance/Legislation/EHRIncentivePrograms/Meaningful_Use.h
tml.
12.
Anderson, C, Sensmeier, J: Alliance for nursing informatics
provides key elements for “Meaningful Use” dialogue. Comput
Inform Nurs. 27(4), 2009, 266–267.
13.
Forrey, AW, McDonald, CJ, DeMoor, G, et al.: Logical
Observation Identifier Names and Codes (LOINC) database: a
public use set of codes and names for electronic reporting of
clinical laboratory test results. Clin Chem. 42(1), 1996, 81–90.
14.
Huff, SM, Rocha, RA, McDonald, CJ, et al.: Development of
the Logical Observation Identifier Names and Codes (LOINC)
vocabulary. J Am Med Inform Assoc. 5(3), 1998, 276–292.
15.
Logical Observation Identifier Names and Codes (LOINC):
Regenstrief Institute http://loinc.org, 2012, Accessed September
17, 2012.
16.
Sittig, DF, Wright, A, Simonaitis, L, et al.: The state of the art
in clinical knowledge management: an inventory of tools and
techniques. Int J Med Inform. 79(1), 2010, 44–57.

17.
Hulse, NC, Rocha, RA, Del Fiol, G, Bradshaw, RL, Hanna, TP,
Roemer, LK: KAT: a flexible XML-based knowledge authoring
environment. J Am Med Inform Assoc. 12(4), 2005, 418–430.
18.
Rocha, RA, Bradshaw, RL, Bigelow, SM, et al.: Towards
ubiquitous peer review strategies to sustain and enhance a
clinical knowledge management framework. AMIA Annu Symp
Proc. 2006, 654–658.
19.
Health Level Seven International (HL7): http://www.hl7.org,
2012, Accessed September 17, 2012.
20.
The Office of the National Coordinator for Health Information
Technology (ONC): Nationwide Health Information Network:
overview. 2011, ONC, Accessed September 17, 2012
http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_
gov__nationwide_health_information_network/1142.
21.
CONNECT Community Portal:
http://www.connectopensource.org/, 2012, Accessed September
17, 2012.
22.
The Direct Project: http://wiki.directproject.org, 2012, Accessed
September 18, 2012.
23.
Glaser, J: Cloud computing can simplify HIT infrastructure
management. Healthc Financ Manage. 65(8), 2011, 52–55.
24.
Paterno, MD, Maviglia, SM, Ramelson, HZ, et al.: Creating
shareable decision support services: an interdisciplinary
challenge. AMIA Annu Symp Proc. 2010, 602–606.
25.
Web Services Description Language (WSDL) 1.1. W3C
http://www.w3.org/TR/wsdl, 2001, Accessed September 17,
2012.

26.
Kawamoto, K, Honey, A, Rubin, K: The HL7-OMG Healthcare
Services Specification Project: motivation, methodology, and
deliverables for enabling a semantically interoperable service-
oriented architecture for healthcare. J Am Med Inform Assoc.
16(6), 2009, 874–881.
27.
Healthcare Services Specification Program:
http://hssp.wikispaces.org, 2012, Accessed September 17, 2012.
28.
Kawamoto, K, Lobach, DF: Proposal for fulfilling strategic
objectives of the U.S. roadmap for national action on clinical
decision support through a service-oriented architecture
leveraging HL7 services. J Am Med Inform Assoc. 14(2), 2007,
146–155.
29.
Mamlin, BW, Biondich, PG, Wolfe, BA, et al.: Cooking up an
open source EMR for developing countries: OpenMRS—A
recipe for successful collaboration. AMIA Annu Symp Proc.
2006, 529–533.
30.
Kalra, D, Beale, T, Heard, S: The openEHR Foundation. Stud
Health Technol Inform. 115, 2005, 153–173.
31.
Mosquera, M: VA's VistA open source agent to launch in
August. Government Health IT [serial online]. 2011, Accessed
September 18, 2012 http://www.govhealthit.com/news/vas-
vista-open-source-agent-launch-august.
32.
Garde, S, Hovenga, E, Buck, J, Knaup, P: Expressing clinical
data sets with openEHR archetypes: a solid basis for ubiquitous
computing. Int J Med Inform. 76(suppl 3), 2007, S334–S341.
33.
Kawamoto, K: OpenCDS. 2012, Accessed September 17, 2012
http://www.opencds.org/.
34.

Kawamoto, K, Del Fiol, G, Strasberg, HR, et al.: Multi-national,
multi-institutional analysis of clinical decision support data
needs to inform development of the HL7 virtual medical record
standard. AMIA Annu Symp Proc. 2010, 377–381.
35.
Mirth Corporation: Mirth Connect. 2012, Mirth Corporation,
Accessed September 17, 2012
http://www.mirthcorp.com/products/mirth-connect.
36.
Apelon: DTS—Distributed Terminology System Apelon
http://www.apelon.com/Products/DTS/tabid/97/Default.aspx,
Accessed September 17, 2012.
37.
3M Terminology Consulting Services: http://www.3mtcs.com,
Accessed September 17, 2012.
38.
Goedert, J: 3M health data dictionary going open source.
HealthData Management [serial online]. 2012, Accessed
September 17, 2012
http://www.healthdatamanagement.com/news/3M-data-
dictionary-open-source-interoperability-coding-44468-1.html.
39.
Mandl, KD, Mandel, JC, Murphy, SN, et al.: The SMART
Platform: early experience enabling substitutable applications
for electronic health records. J Am Med Inform Assoc. 19(4),
2012, 597–603.
1. Describe the role of the informaticist in designing and
implementing the EHR technical infrastructure as outlined by
the component model discussed in the chapter.
implementation of an EHR? How does the data dictionary
enhance and restrict the EHR?
on either third-party service providers or mobile applications be

desirable? What cautions would we place on these technologies
in the same circumstances?
4. How will incentive programs such as Meaningful Use
affect, both positively and negatively, technical infrastructures
in healthcare settings?
5. Assume that you are leading a group developing a CDS
system for your organization. Choose a particular clinical
environment and set of clinical problems you want to address
and describe the types of interfaces you would need with other
components in the clinical infrastructure in order to be
successful.
6. What would be potential areas of concern for an EHR that
heavily used third-party services to supply critical clinical
functionality, such as decision support or medical reference
links?
7. Meaningful Use criteria mandate that healthcare
organizations be able to share data with other healthcare
providers and public health organizations. These mandates will
likely continue to expand over time. Describe how you would
design the technical infrastructure to support this expansion so
that new data sharing criteria are easily incorporated into the
system.
8. Vendors often design “closed” infrastructures in order to
lock customers into their products. What would be positive and
negative aspects, from the healthcare organization's viewpoint,
of having such an infrastructure?
9. As opposed to the closed infrastructure of most vendor
systems, open source systems may allow multiple sources to
contribute to the underlying system code and architecture.
Describe the positive and negative aspects of this approach for
the healthcare organization.
10. The Infobutton standard for access to knowledge
resources is receiving growing interest from health IT vendors
and users. If more medical knowledge resources are made
available through this standard, how might this change the
nature of EHR applications, CDS systems, and local knowledge

development and storage?
Case Study
An integrated delivery network (IDN) serving a large urban and
rural demographic area is using separate EHR systems in its
inpatient and outpatient settings. Some of the specialty
departments have also purchased their own systems for
documentation. Unfortunately this means that information
collected in the inpatient setting is not available when patients
are seen in the IDN's outpatient clinics (and vice versa). The
clinicians need this information to be better informed about
their patients and to provide optimal care. In addition, new
Meaningful Use requirements for problems, medications, and
allergies as well as new chronic disease care initiatives that the
IDN is implementing for its patient population are being
hindered by the separate systems. The clinicians have been
given accounts on both EHRs but this is cumbersome for the
users because they must be trained on multiple systems, they
use valuable time logging into different systems and navigating
for information, and there is a potential safety issue if the user
selects different patients on the two EHRs. A coordinated
decision support environment has also been difficult to
implement because the two EHRs use different coding systems
and do not share most of their information. This means, for
example, that admission rules for congestive heart failure
patients are unable to use the ambulatory medication list and
recent vital signs measurements in order to run the IDN's
standard care process models.
The IDN realizes that it will not be able to replace either EHR
in the near future and, even if it could, there will still be issues
with integrating information from the specialty care systems. It
decides on a strategic plan to create a clinical data repository
(CDR) that is fed with high-value data from each of the clinical
systems. The outpatient EHR's master person index already was
being used as the master unique identifier for most of the IDN's
systems, so it can be incorporated with the new CDR. A robust

interface engine is implemented to supply data from the clinical
systems to the CDR. To normalize the different terminologies
used on their various systems, the IDN engages a terminology
services vendor to provide a central data dictionary for the CDR
and map the concepts from the current systems to the central
standard terminology. The interface engine uses the terminology
services to normalize inbound data to the CDR from the other
systems.
The second phase of the strategic plan is to build a CDS system
on top of the CDR in order to develop and maintain enterprise
patient care rules. As rules are fired, their results will be both
sent through the interface engine to the existing EHRs and
stored in the CDR; storing the decision support results in the
CDR provides a link to supporting data from all clinical
systems, which can help with rule triage and maintenance.
Another effort in this phase is to provide clinician views into
the CDR. The IDN plans to build data services that can be
called by third-party EHRs in order to display longitudinal,
enterprise-wide patient data from within the EHRs. Several
simple web- and mobile-based viewing applications using the
data services will also be developed and will be available in a
stand-alone mode or as callable modules within the current
EHRs. The IDN will use CCOW to provide the user and patient
context from the EHR to these viewing apps so that the
clinicians will not have to log in twice and find the patient.
1. Describe the advantages and disadvantages of the situation
in the case study.
2. You are the chief medical informatics officer for the
organization. You are asked to comment about how the
technical plans will impact clinicians. Based upon the case
study, how do you respond?
3. The organization receives a $3 million gift from an
informatics benefactor. You are an informaticist in the
organization. What would your technical priorities be to remedy

the issues in the case study?
Pageburst Integrated Resources
As part of your Pageburst Digital Book, you can access the
following Integrated Resources:
Chapter 12 Technical Infrastructure to Supp
ort Healthcare
Scott P. Narus
No single off
-
the
-
shelf system today can support all needs of the healthcare
environment. Therefore it
is critical that the technical architecture be capable of
supporting multiple system connections and data
interoperabi
lity.
Objectives

information organizations (RHIOs),
health information exchanges (HIEs), and health information
organizations (HIOs)
cloud computin
g and application service
providers (ASPs)
Key Terms
Architecture, 197
Infrastructure, 197
Knowledge base, 202

Chapter 12 Technical Infrastructure to Support Healthcare
Scott P. Narus
No single off-the-shelf system today can support all needs of
the healthcare environment. Therefore it
is critical that the technical architecture be capable of
supporting multiple system connections and data
interoperability.
Objectives
information organizations (RHIOs),
health information exchanges (HIEs), and health information
organizations (HIOs)
cloud computing and application service
providers (ASPs)
Key Terms
Architecture, 197

Infrastructure, 197
Knowledge base, 202

Chapter 12 Page 209Discussion Questions 2. How does a d.docx

More Related Content

Similar to Chapter 12 Page 209Discussion Questions 2. How does a d.docx (20)

More from cravennichole326 (20)

Recently uploaded (20)

Chapter 12 Page 209Discussion Questions 2. How does a d.docx