rules that must be changed by recompiling code, or the logic may be based on machine-learning algorithms that dynami- cally 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 auto- matically 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 deci- sion support; for instance, when a clinician is in the process of performing an action and needs assistance from the CDS sys- tem 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 pro- cess the data require additional information from the repos- itory. 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 to support rulesthatwillbetriggeredlater.Forexample,aruleprocessedon a lab result might trigger anoutputthat says to waitfor 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 ofthe patient from a previous point intimeand use this information to make recommendations later.

Once a rule is run, the output result must be communi- cated 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 later. There might also be a mechanism for noti- fying a specific user of a result through e-mail, text message, or other communication pathway. 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, larger institutions may 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 the lab, pharmacy, radiology, registration, and billing, for example, must be able to pass information to and receive information from the EHR. Integrating these sys- tems is typically the responsibility of an interface engine (IE) (see the “Interface Engine” section). The different methods for storing and communicating data used by health informa- tion systems now 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 inter- face 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 inter- faces 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, 30 interfaces must be main- tained. 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 inter- faces, modern information systems often employ an interface engine(IE).An IEallows each network data sourcetohave 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 for- mat for the receiving systems, and then transmit the messages toappropriate systems.Acknowledgment andreturn messages also can be routed as appropriate 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 such as HL7 and X12. The IE must also translate terminology between systems because, quite often, systems will use differ- ent vocabularies or coding methods to represent comparable concepts. Sophisticated IEs 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 begin- ning 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.

81CHAPTER 5 Technical Infrastructure to Support Healthcare

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

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 iden- tifier information. The EHR will provide order messages not only to an LIS but also to departmental systems for radiology, pharmacy, and nutrition, for example. 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 diag- nostic systems. The effect 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 ancil- lary systems have been written using proprietary program- ming 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 interopera- bility). 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 Virtually all major clinical information systems in the United States support at least part of the HL7 version 2.x message standard, 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 stan- dard for the content. The HL7 version 3 standard uses a much more formal specification to define messages, and it is based on the Reference Information Model (RIM). The 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 United States as is version 2.x because of its added complexity and significant implemen- tation 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 the 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 orig- inally developed to describe clinical laboratory data, but it 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 stan- dards 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.

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. In fact, 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 organiza- tions.11 Various organizational models for sharing data have been developed at the local, regional, and national level.

Regional Health Information Organization, Health Information Exchanges, and Health Information Organizations One of the earliest models for a data sharing network was the regional health information organization (RHIO).An 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 they are differentiated from them by having an anchor provider organization and, usually, by being started because of financial incentives. The anchor organization often pro- vides a data-sharing mechanism to 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 they 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 pro- vides 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 net- work 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 repos- itory as needed. In a distributed model, the network partici- pants keep their data and provide a mechanism to answer requests for specific data. In either model, the network must provide the ability to match patients between organizations correctly. Without this matching functionality, the network participants are unable to share information accurately.

82 UNIT 1 Foundational Information in Health Informatics

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

The network may use a global MPI that can map patient identifiers between organizations. In addition, to provide syn- tactic 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. Last, the exchange network must provide appropriate security mecha- nisms to authenticate and authorize appropriate use, prevent unwanted access, and accommodate necessary auditing and logging policies.

To connect to the information exchange network, partic- ipants may simply treat the network as another interface on their local IEs. 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 popu- lar and is particularly advantageous in the distributed exchange model because it better supports pulling data from an organization as it is needed.

eHealth Exchange The Office of the National Coordinator (ONC) for Health Information Technology facilitated the development of a national “network of networks” whose purpose was to enable healthcare provider organizations and consumers to share information across local information exchange networks. The eHealth Exchange (formerly known as the Nationwide Health Information Network [NwHIN]) created a set of pol- icies and national standards that allows trusted exchange of health information over the internet.20 The effort is now man- aged by a nonprofit industry coalition called The Sequoia Project (formerly HealtheWay). The Exchange includes orga- nizations from all 50 states and four federal agencies (Depart- ment of Defense [DoD], Veterans Health Affairs [VHA], Health and Human Services [HHS], and Social Security Administration [SSA]) and allows sending and requesting health information from participating organizations. An ini- tial implementation of the information exchange architecture called CONNECT was demonstrated in 2008, with participa- tion by various public and private entities,21 and it includes components for core services (e.g., locating patients, request- ing documents, and authentication), enterprise services (e.g., MPI, consumer preferences management, and audit log), and a client framework (application components for building test and user interfaces to CONNECT). A simplified implementa- tion of the exchange architecture called Direct allows two organizations to share medical information through common methods, such as e-mail-like protocols.22 These methods require a provider directory to ensure secure, point-to-point routing of messages.

ONC has developed a Shared Nationwide Interoperability Roadmap23 that gives further direction for the technical andoperationalinfrastructure thatmustbedevelopedtoadvance true system-wide interoperability. This Roadmap addresses not only data syntax and semantic standards but also identity resolution, data security, access authorization, directories, and resource locators. Most recently, ONC released an Interop- erability Standards Advisory, whose purpose is to “coordinate the identification, assessment, and determination of the ‘best available’ interoperability standards and implementation specifications…[to meet] clinical health IT interoperability needs.”24 Readers may view the entire document at: www. healthit.gov/sites/default/files/2016-interoperability-standards- advisory-final-508.pdf. New material from the ONC’s Standard Advisory panel may be viewed at: www.healthit.gov/providers- professionals/standards-interoperability or by browsing for “interoperability standards,” inputting the current year and “ONC.”

OTHER INFRASTRUCTURE MODELS The previous sections on the EHR component model and sys- tem 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 institu- tions opt to partner with an application service provider (ASP) for their clinical application needs. An ASP is a com- pany 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 also may be financially beneficial for larger facilities because of the economies of scale that an ASP vendor can provide over many customers.

On the contrary, 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 offsite location. They must also accept that versions of application soft- ware, functionality, configurations, and levels of support typically will be what the majority of the other ASP cus- tomers are using. Last, it may be more difficult to integrate with other IT systems at the local site because the ASP vendor may not support interfaces for a healthcare enter- prise’s entire portfolio of departmental and ancillary sys- tems. Interfaces may be more difficult to develop and maintain because the ASP vendor controls its half of each

83CHAPTER 5 Technical Infrastructure to Support Healthcare

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

interface and may not prioritize projects in sync with the customer’s needs.

Cloud Computing A growing trend 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 someday be like other pub- lic utilities, and IT consumers would plug into networks of applications and physical resources in the same way that elec- tricity and phone lines are accessed. Computing resources would be supplied by either public organizations or a few pri- vate 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 figure of a cloud to represent resources out- side of an organization’s physical walls and because of the ability for these resources to change location without affecting the consumer’s ability to access them. Although we often still consider clouds as being available in a public space (i.e., acces- sible 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 enti- ties). Cloud computing can be separated into three models: software as a service (SaaS), infrastructure as a service (IaaS), and platform as a service (PaaS).25

In the SaaS model, service providers run applications (ser- vices) at one or more locations and make these applications 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, per- formance, 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 clin- ical computing, SaaS might be used to provide an entire EHR or EHR function (e.g., scheduling and 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 descrip- tions of diagnoses and abnormal lab results, or terminology mapping between coding systems.26

The most utility-like example of cloud computing is IaaS. In this model, the cloud provider makes computing machin- ery 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 environ- ment. The consumer is responsible for deploying the operat- ing system, applications, databases, and tools, for example, and then supporting those installed assets. Users may connect

to the assets deployed on the IaaS resources through the inter- net 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 run- ning the customer’s computing needs. This may include the operating system, application server, web server, and data- base, for example. The consumer then installs or develops software on the resources provided. The PaaS provider sup- ports 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 to capture information aboutclinicalencountersandpatienthealththatismoredetailed (particularlytomeettheexpandingrequirementsofMeaningful Use),therepositorymustbeabletohandlenewinformationthat 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 archi- tectures 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. Careful consideration of repository architecture must be per- formed 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, life span. 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 dif- ficult challenges in health information systems. The lack of standards, or the lack of implementation of standards, is a sig- nificant 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 accom- plished 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 com- ponent model described earlier in the chapter difficult,

84 UNIT 1 Foundational Information in Health Informatics

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

impractical, or impossible to implement. Component APIs and services may be inflexible and require considerable effort to add new components, particularly if a different develop- ment 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 the needed robustness in one or more of the components.

Finally, 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 assess- ment 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 contrary, allowing for application customization at the facility, department, and user level may be quite difficult to accomplish and support (depending on the system architec- ture and technical abilities of the application support staff), and it can lead to nonstandard implementations that may prove costly to operate and maintain. Upgrades to nonstan- dard and highly tailored applications can also be extremely challenging. How well application providers support custom- ization is an important consideration in system selection. It can have significant consequences on overall clinical IT sys- tems 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 pro- found effect on the ability of users to do customization. In some cases, a programmer must change or add source code to make local adaptations. In other cases, tools supplied with the application allow configuration changes that can be incor- porated more easily and quickly in the application, but obvi- ously 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 attri- butes of these components, as well as how they interact, is essential for a successful system implementation that sup- ports the needs of the clinician users. No single off-the-shelf system today can support all needs of the healthcare environ- ment. 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 would expand. The informatics role will continue to grow as the need to understand new technologies, as well as how they can be combined with existing systems and exploited in the healthcare environment, gains heightened importance.

Many new technologies are being explored or contem- plated 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 technolo- gies have been implemented in organizations that possess strong informatics experience and/or financial resources, 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 1.5 million apps available for its iPhone and iPad as of July 2015. Google advertises 1.6 million apps for its Android operating system, which is used in smartphones and tablets. Over 165,000 of the available mobile apps can be categorized as mobile health (mHealth) applications, and that number is growing (see Chapter 15 for detailed information). The apps range from personal health and fitness, to medical reference materials, to radiology image and diagnostic results viewers, to 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 low cost 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 dis- played 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 impor- tant 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”

85CHAPTER 5 Technical Infrastructure to Support Healthcare

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

nature of many mobile apps, may overwhelm a hospital or clinic network. Organizations may need to develop support for virtual private networks 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, although 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 sup- port, data, process standardization, and security 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 gen- eral about service-oriented architecture (SOA), and health- care 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 with 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) and JavaScript Object Notation (JSON) are commonly used as the message formats. The interface to a web service, including its allowed input parameters and return data, is often described using the Web Services Description Language (WSDL).27 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 con- centrate on specific aspects of a business need. System archi- tects 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 dif- ferent consumers for a variety of applications. Because the services are loosely coupled with each other and with other aspects of the service user’s system, service code may be chan- ged 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 health- care for a number of years. A joint effort by HL7 and the Object Management Group (OMG) to develop standards for health- care services has resulted in the Healthcare Services Specifica- tion Project (HSSP).28,29 HSSP has been investigating several health IT functional areas that could become the building blocks for EHR services. One example is CDS.30 By exposing

CDS services over the web, users would be able to access CDS content from a variety of sources without having to main- tain 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 and 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 ser- vice providers become more numerous and relevant to the healthcare community.

One emerging technology that is capturing the attention of the provider, vendor, and standards communities is Fast Healthcare Interoperability Resources (FHIR).31 Currently a draft HL7 standard, FHIR combines features from HL7 v2, v3, and CDA with a foundation in existing web messaging standards such as HTTP, XML, JSON, and REST (represen- tational state transfer). As its name implies, it is designed to provide a faster path to system interoperability. The common building blocks of FHIR are called “Resources.” Resources describe a specific type of exchange, which includes the type of information being exchanged (e.g., patient demographics, conditions, and medications) and the type of interaction (e.g., search, read, and update). The ease of use of the standard has encouraged several major electronic medical record (EMR) vendors to begin building FHIR interfaces to their systems, demonstrating a long-sought desire for open, nonproprietary services that others may use to access data and build third- party applications.

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 the 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 is because a more hetero- geneous group of individuals with varying uses for the soft- ware 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 develop- ment 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 multi-institution project

86 UNIT 1 Foundational Information in Health Informatics

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

led by the Regenstrief Institute and Partners In Health, a Boston-based philanthropic organization,32 and OpenEHR, an ONC-certified ambulatory EHR.33 The U.S. Department of Veterans Affairs is seeking to develop an open source ver- sion of its VistA EHR.34 The openEHR Foundation is devel- oping open clinical archetypes (standard data models) to promote sharable and computable information.35 Open source, standards-based CDS tools and resources are being developed as part of OpenCDS.36,37 Mirth Connect is an OSS IE that is built for HL7 integration.38 Apelon provides its terminology engine, Distributed Terminology System (DTS), as an open source platform39; 3 M Health Information Systems has announced that it has made its health data dic- tionary available through open source.40,41 FHIR (described above) is another example of OSS. These examples, and the many more in development or production, point to a future health IT infrastructure environment with wider clinician col- laboration and less expensive software licensing costs. How- ever, 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 funded the Harvard-based Substitutable Medical Applications, Reusable Technologies (SMART) Plat- forms project.42 The goal of SMART is to provide a health IT platformbasedoncoreservicesthatallowsappstobesubstituted easily. Inspired by the boom in mobile apps for cell phones and tablets, researchers have developed an application ecosystem in which data can be accessed easily and presented to apps con- structed for specific purposes. The apps can be bundled to pro- vide 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 appli- cations, which can then be provided to the user community as open or closed source code. A government-funded effort ini- tially, it will be interesting to see whether the SMART platform will be adopted widely by the healthcare provider and vendor community or if a similar effort may compete with SMART. A recent initiative with FHIR, SMART on FHIR43,hascom- bined the open application technology of SMART with the open-exchange standard in FHIR, to provide interesting new possibilities for health application development.

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. 2003;42(1):1–7.

2. Gostin L. Health care information and the protection of personal privacy: ethical and legal considerations. Ann Intern Med. 1997;127(8 Pt 2):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. 1998;15(6):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. 2009;78(6):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. 2012;45 (4):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. 2007;14(1):65–75.

11. Centers for Medicare & Medicaid Services (CMS). Electronic Health Records (EHR) Incentive Programs; 2015. https://www. cms.gov/Regulations-and-Guidance/Legislation/ EHRIncentivePrograms/index.html?redirect¼ / ehrincentiveprograms.

12. Anderson C, Sensmeier J. Alliance for nursing informatics provides key elements for “Meaningful Use” dialogue. Comput Inform Nurs. 2009;27(4):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. 1996;42(1):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. 1998;5(3):276–292.

15. Logical Observation Identifier Names and Codes (LOINC). Regenstrief Institute; 2015. http://loinc.org.

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. 2010;79(1):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. 2005;12(4):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; 2015.

20. eHealth Exchange. The Sequoia Project; 2015. http:// sequoiaproject.org/ehealth-exchange/.

21. CONNECT Community Portal. http://www.connectopensource. org/; 2015.

22. The Direct Project. http://wiki.directproject.org; 2015. 23. Office of the National Coordinator for Health Information

Technology. Connecting Health and Care for the Nation:

87CHAPTER 5 Technical Infrastructure to Support Healthcare

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu

Persona l use on

ly, do no t reprodu

ce.

2020-09 -04

shayna. rocourt@

student. ashford.

edu