HIM301: Introduction to Health Informatics WK5-A

profilechantaxrews
HIM30112IntroductiontoHealthInformatics12-Chapter12.docx

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

C:\Users\chanda\AppData\Local\Temp\978-0-323-10095-3_0059.jpg

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

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.

Discussion Questions

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.

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?

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.

Discussion Questions

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

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 computin

g 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

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