Technical Infrastructure

Modern healthcare IT is made possible by the meteoric advancement in complexity and functional capacity of computing systems since the development of the first computers in the 1940s. A common lexicon of terms is required to form an understanding of how healthcare IT infrastructure powers much of what we do today. Yet IT is a new field and terminology, components, and ideas continue to rapidly evolve. Here, we identify common and useful terms that will provide a basic language through which infrastructure can be discussed.

Hardware—the collective physical components of computing systems—has changed dramatically, growing smaller in scale and orders of magnitude more powerful. Hardware components may include processors, controller cards, cabling, cooling systems (e.g., fans or heat sinks), power supplies, cases, and display screens. Other specialized components may be integrated depending on the purpose of the individual computing system (e.g., biometric scanners). Required hardware differs between servers or computers that act as central hubs to process and/or store information and computers that users interact with directly. In addition, the term hardware can be used to describe whole physical units within a larger computing network; these individual units may include such things as workstations (computers that connect to a central hub where data is stored and processed), laptops, tablets, servers, data storage devices, networking equipment, and more.

In clinical settings, there are two primary types of hardware that users directly interact with: workstations and thin clients. Workstations—thick clients—are computers that receive input from users, process and store data, and can function independently of a network. Examples in everyday life include desktop or laptop computers. Thin clients, alternatively, may or may not have traditional workstation capabilities; what sets them apart is that their primary work is not done internally. Rather, thin clients connect to servers that store and process data via a network to request access or make changes to databases. Thin clients are useful in healthcare IT because they enable greater connectivity and real-time access to patient data while providing enhanced data protection. Because no patient information is stored on the local device, physical theft or destruction of a thin client will not result in loss of confidentiality to patients or data loss. Mobile devices other than laptops (e.g., tablets, smartphones, insulin pumps) may use internal or external processing capabilities. These devices often feature stripped-down operating systems and/or applications, and may serve limited functions.

Servers are powerful centralized computing systems. Users must interact with a connected workstation or thin client to access data, and run processes on servers. Servers often require more resources than workstations or thin clients, including orders of magnitude more electricity, environmental cooling capacity, and physical space. Thus, servers are typically housed in secured locations that are remote from the places where users interact with the data and processing capacity. Servers literally “serve up” webpages to browsers or data to applications. In healthcare IT, servers are used for data storage and processing.

Computers may be connected via networks to access remote systems. Networks are collections of computing systems (workstations, thin clients, and servers) that share resources such as data storage or processing power. When a computer connects to the network, it is connecting to a shared space comprised of two or more computing systems (workstations, thin clients, or servers). Networked applications send and request data from servers or other clients.

While hardware forms the physical foundations for computing systems, software is required for computing systems to be functional, and perform the job of storing, processing, retrieving, and displaying information. Software refers to the encoded programs that direct and control how computers function. The major classifications of software include operating systems and applications. Operating systems, such as MacOS, Windows, LINUX, and Android, provide the base for a wide range of computer functions, and act as oversight for applications. All computing systems must have an operating system for baseline functionality, although this may vary widely between workstations. Applications are typically smaller programs that serve individual or integrated functions. One example is a word-processing program that allows text entry, formatting, and printing. In healthcare, one of the primary applications of interest is the software that maintains, stores, processes, and displays patient data.

Unlike much of the computing environment for personal use, healthcare IT is strictly regulated by laws in many countries. In the United States, patient data is considered private and confidential. Healthcare entities (including most healthcare providers, health insurance plans, and healthcare clearinghouses) are legally required to safeguard confidentiality and accuracy of data, regardless of how that data is stored. This poses specific challenges to the implementation and administration of healthcare IT.

Furthermore, federal laws such as the Health Information Portability and Accountability Act (HIPAA) and Genetic Information Discrimination Act (GINA) are two of the many regulations that place specific legal burdens on providers regarding what they may and may not do with data, including the establishment of legal rights of patients to access data themselves, and permit or deny access to others. Under HIPAA, healthcare entities that transmit data are known as “covered entities” and as such are required to meet stringent criteria for data accuracy and security. Similarly, GINA places restrictions on who can access and act on genetic information, a measure put in place to prevent employers and health insurers from discriminating against individuals who have identified genetic risk factors for disease but have not yet manifested symptoms.

Additionally, the 2009 legislation known as the HITECH Act established a requirement that data be shared as electronic health records (EHRs). Reimbursement for services provided to the major US governmental health insurance payer, the Centers for Medicare & Medicaid Services, is tied to healthcare providers and other organizations having, and making meaningful use of electronic systems for recording, storing, processing, utilizing, protecting, and sharing patient data (Centers for Medicare and Medicaid Services, 2010). Such incentives and restrictions necessitate that healthcare IT infrastructure is designed to purpose and strictly controlled.

More recently, the 21st Century Cures Act was passed in 2016 with the goals of accelerating medical product development and enhancing innovations in healthcare. This act goes further than product development and innovation, however. The Office of the National Coordinator (ONC) for Health Information Technology has developed a Cures Act Final Rule to support “seamless and secure access, exchange, and use of electronic health information.” (HealthIT.gov, 2021a)

Federal legislative efforts continue to reshape and guide the direction of healthcare services and healthcare IT infrastructure. In 2021, bipartisan legislators in the House of Representatives unveiled a discussion draft of a bill known as the Cures 2.0 Act (Wagner, 2021). If passed in its current form, this act would improve and continue to modernize healthcare delivery and access, authorize the establishment of an agency within the National Institutes of Health, integrate caregivers (typically family members of an ill person) as members of the patient care team, and increase telehealth and genetic testing access.

One of the primary purposes of HIPAA and GINA, among other regulatory efforts, is the protection of confidential patient data and individually identifiable health information. Thus, another concept that must be explored to understand the effect of these protections is the data life cycle. To be useful to healthcare providers and patients (e.g., individuals, families, and communities who need health services), data must not just exist but be usable. Attention to the data life cycle ensures that data can be retrieved and turned into knowledge that prompts action. The data life cycle refers to the eight steps commonly taken in all data-based projects to turn data into actionable knowledge. The eight steps of the data life cycle for general use are: (1) generation, (2) collection, (3) processing, (4) storage, (5) management, (6) analysis, (7) visualization, and (8) interpretation (Stobrierski, 2021). Additionally, data stored in EHRs requires consideration of a ninth step—sharing (Fig. 6.1).

In modern healthcare IT settings, patient data is collected, stored, used, and protected within two basic types of applications: the electronic health record (EHR) and the electronic medical record (EMR). While these terms are often used interchangeably, there are important differences between the two (HealthIT.gov, 2011).

EMRs consist of all the documentation for a single patient at a single location; they are roughly equivalent to what would have once appeared in a paper “chart” for a patient, and include extensive individually identifiable health records. In addition to the function of paper charts, however, EMRs can be used to automatically track follow-up needs and preventive services delivery windows and trend data, such as blood pressure or weight, across visits, and support clinician decision-making using integrated clinical support tools.

EHRs can accomplish all functions of EMRs and much more. Rather than focusing only on patient data generated by clinicians at one location, EHRs are designed to extend the data through sharing with other providers and even across institutions. Furthermore, EHRs incorporate the entire care team, including the patients themselves and (with appropriate caution regarding privacy and regulatory compliance) their families or caregivers.

The widespread adoption of EMRs and, later, EHRs throughout the healthcare system in the United States has been heavily influenced by legislation creating financial incentives to providers to have “meaningful use” of EHRs within their organizations (Centers for Medicare and Medicaid Services, 2010). Meaningful use is a multi-stage plan for improving quality and safety in healthcare by leveraging IT.

The clinical data repository (CDR) is the storage component for patient clinical records. Data stored in a repository may include lab results, medication orders, vital signs, and clinical documentation as well as demographic data, financial information, patient survey or reported outcomes data, historical data on individual health or family medical events, and more. The data may be stored as free text (i.e., unstructured documents) or coded and structured elements that can be analyzed and visualized using additional application components or software. 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 to find information using criteria that are meaningful to the users. For example, the repository should be able to distinguish data belonging to one patient from that belonging to another based on patient characteristics, such as a patient identifier or an encounter number. Data should also be classified by type, such as lab results, medications, and allergies, to permit easy and quick retrieval of a specific category of data. Data must also be retrievable by the time period in which it was generated, so a picture of current health may be distinguished from historical data. Other important data attributes that help with accessibility include data owners and entry personnel (e.g., ordering physician, charting nurse, and case manager) and location of service or data entry. The access methods for the repository should be robust enough to support current and future users’ access needs.

Data standards must be upheld so that data are able to be processed in a meaningful way. For example, storing blood pressure data in a free-text field eliminates the ability of the application to process and display visualizations, such as trendlines over time. Use of standardized terminology and formatting ensures that data are meaningful and able to be read and processed by machines. The ability to exchange and make meaningful use of data across systems is called interoperability; interoperability is a key requirement of healthcare IT systems. Data standardization serves numerous functions in healthcare IT, including easing the exchange of information across systems and networks. If all data are coded the same way, no conversion processes need to be applied to integrate them. Standardization is accomplished using libraries or languages that set the standards for terminology and encoding schemes for data that are commonly collected within a setting. In healthcare, the common languages for standardization include Logical Observation Identifiers Names and Codes (LOINC) (Werley et al., 1991) and Systematized Nomenclature of Medicine-CT—Clinical Terms (SNOMED-CT) (SNOMED International, 2021) (Table 6.1). These are living languages under continual development and expansion. For example, LOINC has been expanded to include nursing terminology. Furthermore, LOINC features a Nursing Subcommittee whose purpose is the development and maintenance of clinical LOINC codes for standardization of nursing terminology, assessments, and interventions (Matney & Anderson, 2021). In addition, data standardization supports public health surveillance, research, quality improvement and safety initiatives, staff scheduling, patient care, trend analysis, and more (Blair & Hardy, 2019).

Repository reliability refers to the dependability and consistency of access to the repository. In a critical healthcare setting, there is little tolerance for downtime when data and data entry are unavailable. Inconsistent repository performance—for instance, longer wait times for data retrieval during high-usage times of the day—also affects the reliability of the repository. Various architectural and procedural models, including redundancy of storage hardware and access routes, system backup policies, bandwidth availability, and regular performance reviews and maintenance, may be employed to increase the reliability of the repository.

Security is essential to the repository because of both the sensitive nature of the data within and the critical role data play in the healthcare environment. Regulations, such as HIPAA, and sound ethical practices demand that organizations provide a high level of privacy and security for the health information they handle. The repository must incorporate security measures, such as data encryption, secure access paths, user authentication, user- and role-based authorization, and physical security of the repository itself to prevent unauthorized access to data, whether inadvertent or malicious. Some security methods may conflict with accessibility and reliability goals, such as when a measure interferes with needed access to a patient’s data. User behavior must be considered in developing security tools and protocols; emerging threats to healthcare IT systems often leverage user behavior and inconsistencies in application of user policies (see below). EHR implementers must weigh the benefits and costs of each security practice against its impacts on reliability and accessibility. Good system design can mitigate conflicts while supporting the needs of the healthcare setting.

One characteristic that can be used to distinguish repository models is central storage versus distributed storage. In the central storage model, a single repository is used to store all (or most) clinical data, and it 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, 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 it 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. Data may be replicated to other locations for safety and disaster recovery purposes.

The distributed storage model suggests that each data collection application stores its information in its own repository, and data are federated (joined) through a real-time data access methodology. In this case, a results review application may require access to separate repositories for the lab, microbiology, or radiology, for example, 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 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.

Regardless of storage model, one of the key components of any data repository is the ability to determine to whom the records belong. The master person index (MPI), also known as the master patient index or master member index, is the set of information used to 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 that is then sent to the MPI 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 stored as well. (This is often a vestige of paper medical record systems that used facility-specific identifiers for each patient.)

The MPI record is updated as any information is added. 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 is the source for distinguishing a patient from all other patients in the system. The latter point is important because it helps to ensure that clinical and administrative 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 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., 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 the record of a particular patient for use in clinical documentation, review, and patient management applications.

As described above, networking refers to the interconnectivity of computing systems. The internet is the most widely known and used computing network in the world. It relies on servers and peer-to-peer (workstation to workstation) communication to transmit and receive everything from personal banking records and email to high-definition streaming movies. While this open platform provides a cornucopia of opportunities for sharing, learning, and expanding our understanding of our fellow humans around the globe, it also offers malicious actors widespread opportunities to take advantage of security gaps.

In healthcare, providers and users may rely on the internet to locate research and practice guidelines, download or create patient education materials, and access resources that are available through public or private partners. However, most of the work of healthcare happens on intranets. Intranets are smaller, more restricted networks that enable secured transactions between computers within an organization or group; these networks are often administered by local IT resources and professionals. They often have enhanced security protocols, such as two-factor authentication, to ensure that computers and/or individuals connecting to the network are authorized to do so. Traffic on intranets is typically logged to enable IT professionals to conduct optimization of workflows and security protocols.

The protection and preservation of the integrity of data that is transmitted from one healthcare provider or other organization to another must also be considered in healthcare IT infrastructure design and management in accordance with government mandates to share information to enable EHRs. Data sharing networks are networks that exchange health information across regions, organizations, or systems. To facilitate data sharing, information exchange networks are designed using either centralized or distributed data architecture (although hybrids of the two are also sometimes deployed). In the centralized model, network participants aggregate, and push their data to a central storage repository (see central storage above). 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 match patients between organizations correctly. 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 interoperability of the data, the network participants must agree on standards for information exchange. These standards will be discussed in the section titled 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 networks. 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. Another model for linking to the exchange network is to provide a service layer that accepts 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 internet. 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.

Several models of data sharing networks have evolved in recent decades. A regional health information organization (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 a grant or public funding. Meanwhile, health information exchanges (HIEs) have an anchor provider organization and are often started because of financial incentives. The anchor organization frequently provides 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 an HIO is to facilitate data exchange according to nationally recognized standards. This may mean that an HIO only provides guidance to the organizations in an information exchange network or that an HIO assumes the technical responsibility for providing the exchange mechanism.

ONC 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 policies and national standards that allows trusted exchange of health information over secured channels via the internet (The Sequoia Project, 2021a). The effort is now managed by a nonprofit industry coalition called The Sequoia Project. The eHealth Exchange includes organizations from all 50 states and four federal agencies (the Social Security Administration and the Departments of Defense, Veterans Affairs, and Health and Human Services) and allows sending and requesting health information from participating organizations. It was instrumental in coordinating data exchange to the Centers for Disease Control and Prevention and state and local health department data during the COVID-19 pandemic (The Sequoia Project 2021b).

Clinical decision support tools are a promising method to enhance patient outcomes and clinical decision making. Such tools are often integrated into EHRs and designed to (1) enhance provider attention to important but sometimes overlooked data, such as follow-up screening dates or out of range values, (2) reduce or eliminate certain types of medical error, such as double prescribing, (3) provide early recognition of trends associated with poor outcomes, and (4) enhance efficiency, cost-benefit, and patient and provider satisfaction. Examples of clinical decision-support tools include documentation templates; clinical guidelines; alerts and notifications; order-sets; focused, often disease-specific assessment tools; and more (HealthIT.gov, 2018).

Interoperability is defined in US federal law in the 21st Century Cares Act as technology that (1) enhances secure information exchange across technologies without requiring special effort from users and (2) allows “complete access, exchange, and use of all electronically accessible health information for authorized use” under the law while avoiding the blocking of information exchange. Interoperability is a critical component of EHRs because it ensures that data are transferred in a state that users can access and understand. ONC has developed The Roadmap, (HealthIT.gov, 2019) a document that gives further direction for the technical and operational infrastructure that must be developed to advance 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 Interoperability Standards Advisory whose purpose is to “coordinate the identification, assessment, and determination of ‘recognized’ interoperability standards and implementation specifications … [to fulfill] clinical health IT interoperability needs.” (HealthIT.gov, 2021b)

Just as with crumbling roads and bridges that occur when physical infrastructure is allowed to age, outdated IT infrastructure in healthcare can lead to real-world risks and devastating consequences. The reason for this is that such outdated infrastructure creates many cyber security gaps that may be exploited by malicious actors to steal confidential patient data and employee records and/or hold data, systems, and even patient lives hostage.

Yet the picture is more complicated than just outdated infrastructure. During the COVID-19 pandemic, hospitals and other healthcare systems have had to move more quickly, adapting technologies for telehealth and remote work that had not been thoroughly tested in a healthcare environment (Robinson, 2020). The necessary haste with which these technologies were employed created widespread security vulnerabilities that have been exploited to create havoc using several types of attacks.

In addition, securing critical healthcare IT infrastructure is made even more challenging by the recent adoption of a myriad of external, patient-specific applications and devices that must interface or integrate with the EHR/EMR. Such data are frequently then uploaded directly into patient records. Insulin pumps, which are wearable devices that record and store data on blood glucose levels and insulin usage in patients with diabetes, serve as a cautionary tale. In 2019, IBM worked with researchers to identify a security threat to these devices that would enable hackers to reprogram dosing, alter or obscure glucose readings, and more (Slabodkin, 2020). Physicians and individuals might be misled into acting (or failing to act) in ways that harm health if such data changes are made. Most concerningly, these devices can deliver potentially lethal doses of insulin. The US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) issued an advisory about these critical vulnerabilities, and they have since been corrected; however, this case illustrates the importance of overall system design to ensure that data are accurate and protected, regardless of how they enter the EHR environment.

In short, healthcare IT personnel and informaticists must be concerned with the security of data (and devices) for ethical, legal, and regulatory reasons. Robust cyber security practices and teams are essential to ensuring that healthcare IT systems can serve their intended function without compromising patients or the healthcare enterprise.

While specific security practices are ever-evolving and beyond the scope of this chapter, such practices have been described as constituting the top two concerns for any healthcare enterprise, along with patients themselves. Thus, two emerging and escalating types of attacks that have recently been plaguing healthcare will be discussed below, along with best security practices for users of healthcare IT infrastructure.

Ransomware attacks are cyber attacks that exploit security gaps to covertly encrypt data, up to and including the full data repository. Encryption is a method of securing data using a digital key and is critical to protecting the privacy of data from theft and unauthorized access; however, in the case of ransomware, perpetrators of an attack use encryption to lock data they do not own and restrict access by those who are authorized to use it. Imagine if instead of stealing a car, someone put a locking mechanism on the wheel, and demanded payment to remove the lock. Hundreds of hospitals and healthcare systems have been targeted by this type of attack in recent years.

One example from 2020 involves the University of Vermont (UVM) Medical Center (Weiner, 2021). UVM was hit with a ransomware attack that encrypted its EHR, payroll systems, and other vital IT infrastructure, along with a demand from the attackers to pay a ransom. The system was locked down for a month, and while UVM never paid the ransom, the financial cost of the attack was estimated at $50 million. Furthermore, loss of access to critical patient data produced delays in care with real-world consequences to patients in a healthcare system already stressed by an unfolding global pandemic.

Another type of attack has also escalated in recent years. Phishing (pronounced “fishing”) is a type of social hacking. Rather than exploiting technical vulnerabilities within infrastructure systems, phishing attacks seek to exploit the human users of an IT system. These attacks often take the form of an email or other communication and rely on fraud and misdirection to take advantage of individuals’ goodwill to get them to perform an action. Often, this will involve clicking a web link that uploads dangerous software onto devices or networks, or providing confidential information directly, such as phone numbers, personal identifiers, or passwords. Recently, scammers have begun using impersonation of executives, deans, and other organizational leaders to trick people within an organization to perform actions, such as purchase gift cards and send the codes via email. While the schemes themselves may seem unsophisticated, the rate of success (while small) incentivizes unethical scammers to continue.

As is apparent from the phishing attacks, users are one critical component of healthcare IT security. Without adequate training to recognize threats, users may fall victim to schemes and scams designed to gain access to intranets and/or to steal money, resources, or data. Furthermore, users who do not understand the rationale for security processes, such as two-factor authentication (a method of securing data that attempts to prevent access with stolen passwords) or restrictions on software downloads and installation, may attempt to bypass these measures to improve their workflows or enjoyment of the system. Installing a music streaming app, for instance, may seem like a harmless action that will improve work life for individuals working in offices. However, these actions can have dire consequences for IT systems if that music app has ransomware piggybacked to it. Thus, while robust cybersecurity practices and prevention efforts are necessary in any healthcare IT system, it is just as imperative to ensure that individuals who have access to systems and networks are well trained in security practices and policies and accountable for their actions. Basic best security practices are detailed in Fig. 6.2.