Healthcare information technology (HIT) includes all the computer, digital, and electronic hardware and software used in a healthcare organization to collect, use, transfer, and store information. This technology can differ distinctly from other forms of IT used in business, industrial control, financial, or telecommunications, for example, though many of the IT components are the same across these industries. You would recognize operating systems, databases, hardware, and mobile platforms in all of them, for example. The difference with HIT that you, as a healthcare information security and privacy professional, need to be aware of is in the function and purpose of HIT compared to the other forms of IT. HIT can be directly central to human life and safety issues as well as being critical to very complex medical procedures, where precision is required. The security implications for HIT used in medical devices and electronic health records, for example, are equally critical.

This chapter focuses on special-purpose computing resources used to conduct healthcare operations or support patient care. When we cover privacy and security in healthcare more in depth in Chapter 5, you will gain more insight into the frameworks, regulations, and responsibilities that come with health information privacy and security obligations. As you understand how these technologies are used in the healthcare environment, you will realize that the implementation of privacy and security controls must be tailored to each situation. In many cases, the best security practices used in other industries and IT protection specifications may not operate efficiently or effectively in a patient care environment. In fact, these privacy and security controls can actually introduce unintended consequences leading to patient safety and quality of care issues.

Fostering Privacy and Security with HIT

To review, the term “privacy” in a healthcare context refers to processes and safeguards put in place to protect the confidentiality of certain personal health information. The definition of “security” is the means and methods used to control access, collection, use, storage, transfer, and disposal of an individual’s sensitive information. By implementing privacy and security correctly, we foster patient trust in our organizations. The advent of HIT has had a positive impact on patient care. State-of-the-art imaging systems, monitoring devices, and robotic surgical tools are all examples of HIT that have improved provider practices and saved lives. Throughout this chapter, we will examine areas where HIT has impacted privacy and security in ways that require us as information protection professionals to design and implement controls to safeguard digital healthcare information.

Before we begin that discussion, it would be worthwhile to mention how HIT has actually improved healthcare information privacy and security concerns. For example, the implementation of electronic health records has improved the secure availability of medical information. Traditionally, medical records were kept in paper documents that were immediately available only in one office or organization. Information sharing for continuity of care or public health surveillance, while protecting the privacy and security of such information, could be very difficult. Transferring a digital patient record across a network to authorized providers and public health officials, on the other hand, can be a more confidential process that enables the right information to be available at the right place when needed. Remember that availability is one of the components of the information security triad of confidentiality, integrity, and availability.

Another example of a positive impact from HIT is that data integrity is vastly improved. The complex algorithms and data analytics that are sometimes inherent to a medical device make possible important data integrity capabilities. Medical errors such as drug-to-drug interactions or dosage mistakes have plagued healthcare. Using an advanced medical device in patient care may enable providers to collect and analyze information, and these devices may alert providers to various potential problems. Imagine, for example, a provider authorizing a dosage of Warfarin through an infusion pump. The device may alert the physician to the patient’s earlier doses of Warfarin or other drugs, and this could help avoid overdoses or negative interactions. The implementation of HIT in such cases not only improves data privacy and security, but also improves patient care and safety.

Increased Exposure Affecting the Threat Landscape

Confidentiality, integrity, and availability—the CIA triad—must be addressed in every healthcare environment. The privacy and security controls we implement and monitor are intended to protect one or more facets of the CIA triad.

•   Confidentiality  Protects information from disclosure to unauthorized parties

•   Integrity  Safeguards information from unauthorized alteration or modification

•   Availability  Ensures that authorized parties have access to the right information when needed

The introduction of HIT has increased exposure to information security and information privacy threats. You must constantly assess these threats and the impact on the CIA triad relative to HIT systems while managing and using sensitive information. When security or privacy risks are realized, they can cause adverse effects or problems for patients. To avoid these problems, HIT engineers are responsible for working with security professionals to design, build, and implement systems that integrate information protection and risk management. This results in more trustworthy systems that include privacy and security as integral attributes. In selecting and securing HIT, you should use the following three design attributes with regard to protection of sensitive information:

•   Knowledge of what data is collected and used

•   Support for restricted access by enabling granular controls

•   Ability to limit authorization based on operational requirements

Lines between information security and information privacy can be blurred. The context of these information protection concerns offers an opportunity for you to recognize the boundaries and overlaps. You must determine when existing security risk models and security-focused guidance can be applied to address privacy concerns in HIT. Where there are gaps, security engineering must be added to achieve an approach to privacy.

Figure 3-1 depicts the entwined relationship between privacy and security. A key point to remember as we explore HIT is the relationship between these disciplines that is best served by managing the material distinctions and leveraging the overlaps. Security risks arise when sensitive information is not handled appropriately. Privacy risks, however, arise when sensitive information is disclosed in an unauthorized manner and exposes the data (confidentiality failure) to potential problematic actions.

Figure 3-1  The overlapping relationship between information security and information privacy

Internal Threats to HIT Privacy and Security

To begin the examination of how HIT increases exposure to threats, we need to start with how internal actions are part of the risk profile. Remember that HIT systems that are designed to make our patient care processes safer, more efficient, and more effective can also pose privacy and security risks. Because HIT operations usually depend on human interaction with the technology, errors can result with unintended consequences, such as unauthorized disclosures or exploited vulnerabilities, leading to privacy or security issues. In fact, in some cases, an internal error or mistake could result in a patient safety issue.

The Emergency Care Research Institute (ECRI) highlights the privacy and security threats introduced by HIT. This industry group focuses on helping healthcare organizations use healthcare technology that is effective and safe for use with patient care. Each year, the ECRI assembles a top 10 list of healthcare technology hazards that cause the most incidents that impact patient safety. Relevant to internal incidents, in 2019, ECRI listed mistakes such as entering the intended flow rate into an infusion pump’s dose rate field as a leading privacy and security problems that can result in dangerous medication administration errors.¹ This is an example of wrong-field programming, and even sophisticated medical devices can be misconfigured and operated in an insecure or unsafe manner. The problem is that these errors often go unnoticed by the clinician because of their assumption that the HIT is working correctly.

External Threats to HIT Privacy and Security

Addressing the threats from another perspective, the growing numbers of IP-enabled HIT systems are imperative to clinical operations and patient care. Initially, manufacturers paid little attention to protecting their equipment from external attackers possibly targeting their HIT systems. However, with embedded software in many products, ranging from health-tracking wristbands to cardiac-monitoring undergarments, regulators and manufacturers are becoming increasingly concerned about the potential threat to poorly secured devices.

Threats to Medical Devices

This concern is not new, yet it is very real—witness the issue in 2013 with former Vice President Dick Cheney and his defibrillator, or a recently sanctioned medical device–hacking challenge at an industry security conference in 2019.^2,3,4 Internet-enabled medical devices and electronic databases for clinical and administrative operations are networked technology that provide greater connectivity, but they increase HIT exposure to cybersecurity threats. HIT device manufacturers, hospitals, and other healthcare providers must evaluate and manage a new set of risks. Connected medical devices—like other computer systems—can be vulnerable to security breaches and have a potential major impact on the safety and effectiveness of these devices. Specifically, in a healthcare environment, this vulnerability increases as medical devices and medical equipment are becoming more connected through the Internet to other medical devices, patients, and/or to hospital networks (also referred to as the Internet of Medical Things, IoMT).

In 2017, the FDA issued a safety communication, noting that cybersecurity vulnerabilities in St. Jude’s Medical implantable cardiac device, the Merlin@home Transmitter, which sends and receives radiofrequency signals wirelessly to the pacemaker, could pose a serious problem. The FDA determined that this transmitter was vulnerable to attack and noted this in its 2017 press release:

The FDA has reviewed the information concerning potential cybersecurity vulnerabilities associated with this transmitter and has confirmed that these vulnerabilities, if exploited, could allow an unauthorized user, i.e., someone other than the patient’s physician, to remotely access a patient’s RF-enabled implanted cardiac device by altering the transmitter. The altered transmitter could then be used to modify programming commands to the implanted device, which could result in rapid battery depletion and/or administration of inappropriate pacing or shocks.⁵

Fortunately, according to the FDA, no adverse events, including death, have resulted from the vulnerability. The FDA later noted that St. Jude Medical issued a patch that fixed the vulnerability and was quick to issue a statement taking the appropriate remediation actions by patching its systems against cyber risks.

This was not the first FDA comment on cybersecurity issues, however. In December 2016, the FDA issued a recommendation that both hospitals and medical device manufacturers implement a proactive, comprehensive risk management program that includes the following:

•   Implementing the National Institute of Standards and Technology (NIST) Framework for Improving Critical Infrastructure Cybersecurity

•   Establishing and communicating processes for vulnerability intake and handling

•   Adopting a coordinated disclosure policy and practice

•   Deploying mitigations that address cybersecurity risk early and prior to exploitation

•   Engaging in collaborative information sharing for cyber vulnerabilities and threats

Hospitals must make medical device security a central component in their entire risk management and business resiliency programs. The FDA also called for manufacturers to increase their attention to medical device security and connected cybersecurity with regard to current safeguards to ensure device quality and patient safety.

Threats Related to Cloud Computing

Cloud computing has introduced new threats to healthcare information security. The increase in protected health information (PHI) and personally identifiable information (PII) in cloud environments brings new concerns. Cloud computing is being increasingly adopted by healthcare because it offers benefits such as improved access to data and cost efficiency. There are, of course, risks as well. Processes and techniques used to protect data within the cloud can be different from those required for data located in a data center under the direction of the healthcare organization. In the cloud, data loss prevention monitoring and vulnerability management scanning may be the responsibility of the cloud service provider alone. The configuration of security technology in the cloud may also be a risk undertaken by a third party, rather than by the healthcare organization.

To illustrate, consider the 2019 Capital One data breach incident that potentially exposed the data of 100 million of the bank’s customers. Capital One, like many users of cloud technology, relied on internal employees as well as third-party contractors to protect its cloud-stored data. Potential vulnerabilities the criminal attacker exploited may have included misconfiguration of assets in the cloud and disregarded authentication protocols.⁶ Who was at fault is not important to this discussion; what is important is that the use of the cloud, as is clear in the Capital One report, introduces the organization to new sources and types of threats to its data. While Capital One is not a healthcare organization, the example is relevant because cloud use of and reliance on third-party contracted support are a shared reality among all industries using the cloud.

What is also shared are the risks to information privacy and security of which this scenario illustrates but one example. Depending on the type of service model you have with a cloud service provider, you will have different responsibilities. With a Software as a Service (SaaS) cloud agreement, you will likely have responsibilities for access and authentication. The cloud service provider is responsible for maintaining the hardware and software; particularly vulnerability management and security monitoring. In comparison, an Infrastructure as a Service (IaaS) cloud service vendor would likely be responsible for overall security of the facilities and possibly disaster recovery capabilities, but your organization would remain responsible for maintenance of the hardware and software resources you are leasing for use within the cloud service provider’s environment. We will explore the shared security concerns and the variety of cloud service provider models in greater depth in Chapter 7.

Figure 3-2 illustrates some categories of information privacy and security threats that are relevant to using cloud computing models.

Figure 3-2  Major categories of information privacy and security threats to cloud computing environments

Software-Initiated Threats (Malware)

Additional cybersecurity threats for connected HIT, including computer viruses and malware, also have the potential to jeopardize a patient’s treatment and privacy. It is important to recognize the threats to HIT that can come from simply being connected to a network.

A case in point is Bayer, a medical device manufacturer, which confirmed in 2017 that the company had received reports from customers in the United States that their computers had been targeted by the WannaCry ransomware attack.⁷ This compromise happened because some medical devices were connected to a network and used a commercial software operating system (Microsoft Windows).

To prevent such attacks, our roles and responsibilities as healthcare information security and privacy professionals is to have a thorough and well thought out cybersecurity management policy that incorporates software threats to HIT, including medical devices. This is critical today for both healthcare organizations and medical device manufacturers.

E-iatrogenesis

The internal and external threats that have emerged from increased use and reliance on HIT has concurrently introduced a new concept into the healthcare information security lexicon: e-iatrogenesis refers to any patient harm caused by the application of HIT (and, by extension, healthcare information security efforts).⁸ The term evolves from iatrogenesis, which is an inadvertent adverse effect or complication resulting from medical treatment or advice from a healthcare provider.

For example, suppose a doctor writes a prescription for a patient but does not cross-referenced this medication with the patient’s current medication list; an adverse reaction happens when the new drug negatively reacts with the medications the patient currently takes. Table 3-1 highlights some real-life examples of episodes of e-iatrogenesis that have occurred at various engineering stages of HIT, specifically relating to medical devices.

Table 3-1   Some Adverse Events Resulting from Medical Device Software Issues

Even if an incident does not actually harm the patient, the healthcare organization may face consequences. The Joint Commission, a nongovernment organization in the United States that inspects, accredits, and certifies hospitals, requires reporting of a sentinel event, in which death or serious physical or psychological injury, or the risk of either, was the result of prescription drug administration.⁹ A drug reaction scenario would be considered such an event. Another example, having a medical device reboot in the middle of a patient procedure, can certainly be considered a near-miss event. It is also easy to imagine how the process or procedure could go wrong and cause a serious adverse outcome for the patient. In sum, the best information security practices, as applied to the healthcare industry, must include a risk-reward consideration with the number one rule of healthcare at the core: first, do no harm.

Oversight and Regulatory Challenges

The healthcare environment has evolved into a highly interconnected system of systems that depends on the exchange of digital information. Increasingly, many agencies and entities have varying degrees of authority to improve healthcare quality, safety, and efficiency through the promotion of health IT, including electronic health records and private and secure electronic health information exchange. They may be government organizations or private governing bodies made up of volunteers. The work that they do results in guidance, standards, or even laws that impact the usability of HIT, for the benefit of information security and privacy. These oversight and regulatory activities should encourage secure and authorized interoperability and information sharing using HIT is an imperative to quality patient care.

HIPAA and HIT

The US Health Insurance Portability and Accountability Act (HIPAA) has a material impact on HIT. HIPAA is a collection of multiple rules and amended guidance consisting of the following:

•   HIPAA  The original intent of HIPAA included significantly more regulatory intent than just protection of patient information. The first iteration in 1996 was aimed at clarifying the portability of health insurance so that people were able to change health insurers without disruption. The law also contained administrative simplification to begin to address issues that result in waste, fraud, and abuse in the healthcare system. That effort continues today.

•   Privacy Rule  This major addition was enacted in 2002 and addressed the specific requirements to protect the confidentiality of patient information. To that end, the law described safeguards such as restrictions for authorized use and limits on the disclosure of protected information. Informed patient consent for information use was included in this law. It also outlined patients’ rights with regard to reviewing records and requesting corrections to their records.

•   Security Rule  This 2004 law addressed the evolution of healthcare information to more electronic formats, as HIT increased in healthcare organizations. This law required that healthcare organizations safeguard electronic healthcare information that they collected, and use reasonable and appropriate administrative, physical, and technical controls.

•   HITECH  This act, formerly known as the Health Information Technology for Economic and Clinical Health Act, was passed in 2009 and focused on the implementation of electronic health records (EHRs) in healthcare organizations. HITECH was part of the American Recovery and Reinvestment Act of 2009 (ARRA), and together they offered financial incentives for EHR adoption in an initial phase. The act had to also address some security requirements, including evidence of an enterprise risk assessment completed by healthcare providers. After an initial adoption phase, the ARRA and HITECH removed the incentives and introduced penalties for not meeting EHR implementation targets. HITECH included harsher penalties for healthcare organizations that failed to protect information, such as those that experienced data breaches or had findings resulting from federal audits.

•   Omnibus Rule  This rule organized and combined some interim final rules that were in various phases of authority and effect. In 2013, a major component of the rule was the clear definition of who was subject to HIPAA by defining the conditions for being a business associate.

We’ll examine HIPAA in more depth in Chapter 4, with additional regulatory sources that impact healthcare. The introduction of regulatory sources is meant to highlight how laws are designed to motivate healthcare organizations to improve the healthcare system by implementing HIT that can reduce costs, enhance quality, and improve the delivery of care. For example, HITECH helped in this regard by making Medicare and Medicaid incentive payments available to healthcare organizations that adopted HIT. Those organizations that could demonstrate they were meeting established workload targets and transactions with electronic health records earned reimbursement from the US government. HIPAA has affected HIT in the following ways:¹⁰

•   Encryption services  These have advanced because of requirements for PHI to be made unreadable, unusable, or indecipherable to unauthorized persons.

•   Employee training  This emphasizes that awareness and training of personnel are central to the regulations.

•   Risk management  This mandates assessment, evaluation, and reduction of risk across the organization as well as per HIT system or application.

•   Cloud service providers  Specifically, the Omnibus Final Rule helps clear the way for healthcare organizations to enter into contractual agreements with cloud providers.

•   Electronic health records  HITECH provided reimbursement, which catapulted implementation rates for digitized record use.

•   Access and authorization  The ability to limit and monitor access to information is improved by HIT because logging and auditing enables the accounting of disclosures and data forensics.

The use of HIT regulated by HIPAA can be exceptionally beneficial to a healthcare organization. The implications of information privacy and security are important for you to understand and leverage on behalf of patient care and patient safety.

Office of the National Coordinator for Health Information Technology

An influential source of HIT guidance is the Office of the National Coordinator for Health Information Technology (ONC) located in the US Department of Health and Human Services (HHS). Established by HITECH, the ONC aims to provide information to clinicians to help them connect using HIT. Its goals include making healthcare more individualized, which will also improve outcomes for the community. Success with the ONC relies on input and assistance from many private-sector experts or practitioners to develop communication standards, software, hardware, and training for those who use HIT. ONC provides recommendations for strategies that will result in a US HIT infrastructure based on standards and policies that support the exchange of health information. To recommend standards, the HIT Standards Committee provides implementation specifications and HIT certification criteria. It also tests and ensures consistency with privacy and security guidance.

GDPR and HIT

The EU General Data Protection Regulation (GDPR) was created and adopted in April 2016 and has been enforced since May 2018. The law explains and increases privacy rights in light of the growing use of the Internet for commerce in the EU and globally. The GDPR is a single set of rules on data protection. A single market is established to reduce administrative complexity, costs, and burden to member states. However, each EU nation has an autonomous national protection authority.

The following GDPR items highlight HIT:¹¹

•   The regulation strengthens individuals’ rights so that the collection and use of personal data is limited to the minimum necessary.

•   The GDPR defines rights to data portability to ease the transfer of personal data from one service provider to another.

•   The “right to be forgotten” is explicitly recognized. The previous privacy law limited the processing of data unless specific criteria were met; the GDPR expanded that to include individual rights, to enable a patient to demand removal of his or her information.

•   GDPR rules have clarified and strengthened data breach notification requirements.

The GDPR has more of an impact on health data than HIT. This does not minimize the law’s regulatory impact, but clarifies and focuses its attention. For example, the GDPR continues the previous privacy law’s approach to treating health data as sensitive personal data. The GDPR, however, has added emphasis and requirements for genetic data and biometric data as sensitive personal data that should be classified more restrictively. Member states are permitted to introduce stricter conditions beyond the GDPR with regard to the processing of biometric, genetic, or health data.

Interoperability

Interoperability refers to the availability of data with regard to its ability to be transferred between connected systems and applications. Several conditions establish interoperability:

•   The HIT must be able to share information securely with other HIT systems without the need to create custom configurations or require manual interventions.

•   The interchange of information needs to be comprehensive and must support authorized access and use.

•   Systems should not introduce information blocking, a problem characterized by proprietary HIT systems purposely not supporting interoperability with systems from other manufacturers.

Interoperability in HIT is important, because data sharing in healthcare is an essential component of patient care, research, and quality initiatives. Within the organization, providers consider data sharing an imperative that enables them to access things easily, such as medication lists and laboratory results, precisely when they need it. Even after care is provided, sharing information is important in settings such as peer record review, where procedures are reviewed and measured against organizational and clinical standards. The intent there is to discuss best practices, share common experiences, and, in the end, maximize scarce resources by reducing duplication and ineffective processes. When HIT systems and applications cannot send and receive information, you can imagine the resulting delays and frustrations.

Given the imperative for data sharing, enabling one healthcare organization to communicate with another is a challenge. We covered data interoperability and exchange in Chapter 1 and introduced the primary data standards. You’ll remember that the use of common standards and taxonomies makes interoperability possible. Impediments can exist even though the language of healthcare is based on recognized clinical terminology, many standardized code sets, and a mission of diagnosis and treatment. You may find challenges in your organization’s ability to interconnect with suppliers, payers, and other stakeholders (including government agencies) that result in administrative and management problems.

Such communication breakdowns are not always technology-based impasses. Sometimes overcoming political and personal hurdles resolves disconnects. For instance, each healthcare organization that uses an information system to automate workflow, an EHR, or a patient administration system probably purchases that system from a commercial manufacturer. In the case of some government healthcare organizations (the military or Veterans Administration), the information systems may be government developed. In any case, based on the agency that develops the system, interoperability may be limited. As you investigate the reasons why systems are difficult to connect, you may discover proprietary interconnection requirements or a lack of standards-based interfaces. The outcome is valuable data locked in seemingly impenetrable silos. We know this is counter to interoperability, because it creates information blocking. We also know this can be a huge problem as patients typically move from one healthcare organization to another based on referrals for advanced care, for example. Or, as healthcare organizations desire to submit bills to payers, the organizations must be able to send and receive data independent of what proprietary system they (or their counterparts) use.

Figure 3-3 shows a high-level view of the entities that are present and dependent on system interoperability.

Figure 3-3  Interoperability of healthcare systems between interdependent entities

Software and System Development

Software and system development, in a generic sense, are important with respect to HIT and interoperability safeguards in that too often information security is “bolted on” at the end of development and during implementation. Referencing the concept of “security by design,” a focus on integrating secure interoperation is needed for the identified phases of HIT development. Software and system development lifecycle management is akin to the configuration management process, but the former is more focused on systems or software as it is being engineered before implementation. Generally speaking, development lifecycles have four development phases, which are listed next. To build-in information security and privacy properly, all phases have relevant inflection points for your involvement.¹² The relative milestones for information security and privacy are listed in italics corresponding to the appropriate development phase:

•   What  Specification of WHAT the product is to do

Initiation: An initial threat and risk assessment to provide input for IT security requirements

•   How  Specification of HOW the product does it

Initiation: Assessment for awareness of potential engineering challenges of implementing security controls and interoperability requirements to include identification of secure integration and reuse of proven strategies and tools

•   Build  Development or BUILD of the code or components that implement HOW

Design and development: An appropriate balance of technical, managerial, operational, physical, and personnel security safeguards that will help to meet the requirements

•   Use  Operational deployment or USE of software or system that performs WHAT

Implementation: Design documentation, acceptance tests, and certification and accreditation to be performed

Operation: System security monitoring and maintenance to aid in the evaluation of modifications for interoperability that could affect security

Levels of Interoperability

According to the Healthcare Information and Management Systems Society (HIMSS), interoperability is the technology antidote for the lack of communication among disparate systems. Three levels of interoperability should be addressed.

•   Foundational interoperability  An HIT system is able to send information to another. This level does not include concern for the receipt of that transmission.

•   Structural interoperability  Data must be structured and constructed in standard, meaningful ways and formats to be useful by other systems.

•   Semantic interoperability  At this level, the initial system successfully sends the message, the message is structured appropriately, and the receiving system is able to receive and understand the information.

Within many organizations and between HIT systems, you may find that interoperability is more an issue about bridging cultural, social, policy, or economic concerns. The technical obstacles may be relatively straightforward to address. There are valid reasons for not making systems interoperable, such as when the receiving entity has a suspected or known information security problem that makes data transfer a high risk. You will have to determine through risk assessment when those situations exist. In general, however, health information blocking is an impediment to achieving interoperability, and we should do our best to establish and support secure, meaningful information exchange between systems to maximize benefit from the HIT.

Medicare Access and CHIP Reauthorization Act of 2015

As a part of this comprehensive act, MACRA, nicknamed the Permanent Doc Fix, is legislation intended to incentivize healthcare that demonstrates value and achieves outcomes. It established an important reimbursement program, called the Quality Payment Program (QPP). Healthcare providers could participate in QPP through the Merit-based Incentive Payment System (MIPS) and Advanced Alternative Payment Models (Advanced APMs). Relevant to our discussion on interoperability, QPP promoted the increased use of certified HIT that supports interoperability and advances the criteria that came from meaningful use (which were introduced as part of ARRA earlier in this chapter). QPP, in fact, took the place of meaningful use as healthcare providers were now measured against a “promoting interoperability” framework of standards and measures. Meaningful use encouraged digitizing healthcare information, and QPP advances the concept to include meaningful exchange and use of health information across multiple systems to provide complete and high-quality healthcare. Providers have to provide evidence that they satisfy QPP guidelines, which could include demonstration of electronic exchange of health records, test results, or physician consults from one organization to another in providing patient care.

Information Technologies

The healthcare and medical industries have witnessed an increasing amount and reliance on HIT. HIT supports health information management across computerized systems and the secure exchange of health information between consumers, providers, payers, and quality monitors. The systems also integrate with many traditional business and office automation systems, such as human resources or financial platforms. When used appropriately, HIT is helpful in improving the overall quality, safety, and efficiency of patient care and clinical operations. The electronic interchange of information has also shown reductions in medical errors and better accuracy in procedures. This section highlights some specific examples of information technologies unique to healthcare providers and payers.

Electronic Health Records

An EHR is basically one or more electronic files that has replaced the traditional paper medical chart. That may not be the best description, but it does acknowledge that the information that was once collected on paper is now digitized in EHRs. This information includes hand-written physician notes, images, audio, and prescription orders. The EHR has made gathering and organizing diverse types and formats of information easier, and, if properly secured, the information can be safely stored and made available without delay.

A better description is that EHRs are a system of HIT systems that house a comprehensive amount of patient and business data to help healthcare organizations deliver patient care. You will find them as central HIT systems in doctors’ offices, hospitals, and healthcare payer organizations. Here are some of the common components of EHRs:¹³

•   Medical histories, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results

•   Connections to diagnosis and treatment applications and tools to support evidence-based decisions by providers for patient care plans

•   Automated and streamlined provider and information workflows

EHRs have ushered in an era of expanded connectivity and interoperability between healthcare systems and providers. EHRs provide immediate access to extremely important patient information, without the physical separation that existed in the predigital world, when data was stored on paper in file cabinets. EHRs are the core of quality patient care and bring together valuable clinical information from internal and external caregivers. The ability to share information securely and quickly between organizations is illustrative of the transformative power of EHRs. Figure 3-4 shows how EHRs store and distribute healthcare data, including imaging, scanning, analysis, pathology, observations, and more. EHR implementation has transformed not only healthcare data storage, but its use has resulted in a reduced risk for medical errors.

Figure 3-4  EHR is a system of HIT systems

Although the EHR has created efficiencies and gains for healthcare organizations, it has also experienced some unintended consequences, including the threat to patient privacy and the increased potential for data misuse. Your role as an information security professional is important because healthcare organizations have obligations, both legal and ethical, to establish security measures and safeguard sensitive information entrusted to them. Ensuring the privacy and security of health information, including EHR, is the key component to building the trust required to realize the potential benefits of electronic health information exchange. If individuals and other participants in a network lack trust in the electronic exchange of information because of perceived or actual risks or the accuracy and completeness of such information, it may affect their willingness to disclose necessary health information and could have life-threatening consequences.¹⁴

A subcategory of EHR you need to be familiar with is the legal medical record, a set of particular patient data that is part of the entire patient record. Although there are no regulations specific to a defined legal medical record, federal and state governments have offered guidelines regarding legality. Simply put, a legal medical record is an official patient record recorded and stored by the healthcare organization that can be used as evidence in a court of law. A legal medical record is connected to revenue, because it supports reimbursement payments to the relevant third parties. The organization must meet baseline requirements for content and disclosure to authorized recipients in support of legal proceedings or in response to patient requests for release. Above these baseline requirements, each organization can make an assessment regarding what is and is not appropriate to reveal. Keep in mind that the components of the legal medical record may be located in multiple HIT systems, and the organization must be able to find and assemble the record when needed.

Another subset of medical records is the designated record set (DRS). HIPAA distinguishes the DRS as a set of records that include PHI and that is maintained, collected, used, or disseminated by or for covered entities for each individual who received care from a healthcare organization. The DRS normally contains more information than the legal health record. It may include patient medical and billing records; the enrollment, payment, claims, adjudication, and cases or medical management record systems maintained by or for a health plan; or information used to make care-related decisions.¹⁵ Individuals have the right to obtain a copy of their DRS, request amendments, and set restrictions and accountings of any information used to make decisions about their care. The DRS can comprise paper records, film images, electronic data, and any other medium used to store a patient’s healthcare data. You can think of the difference between a legal health record and the designated record set like this: direct patient care is recorded in the legal medical record; the designated record set includes that information, plus all the business information unrelated (but important) to patient care.

Another form of EHR is the personal health record (PHR), an electronic application through which patients can maintain and manage their health information (and that of others for whom they are authorized) in a private, secure, and confidential environment.¹⁶ Sometimes called a patient portal, a PHR is a lot like an EHR, except that patients themselves can control what kind of information goes into it. Patients can use a PHR to keep track of doctor visits, but it can also reflect a patient’s life outside the doctor’s office and can include health priorities, such as tracking eating and exercise habits and blood pressure. A PHR may be linked to the doctor’s EHR. When used effectively, PHRs can help patients focus on managing their health information and controlling, to varying extents, who can access that health information.

An EHR uses a mix of security controls to keep patient health information confidential, to provide data integrity, and to assure availability. Technology also brings new responsibilities for safeguarding patients’ health information. Widespread adoption of EHRs in healthcare occurred only after the US government provided reimbursement for their adoption as a result of the American Recovery and Reinvestment Act (ARRA) of 2009. Although, prior to that date, some healthcare data was being collected in digital format, electronic order entry and digitization of most of the patient record was still the exception, not the rule. Post-ARRA, in the United States, the EHR is very common.

Next, we will examine a few privacy and security concerns that EHR implementation introduces in access management and data management categories.

Access Management Concerns

Identity, access, authentication, and authorization within the context of information security controls are important in any information technology that handles sensitive information. This is especially true for EHRs, which must be protected by appropriate administrative, physical, and technical controls. For EHRs, patient rights concerning viewing, writing, and otherwise editing access permissions must be protected. In a healthcare environment with physicians, nurses, and clinicians filling multiple roles, often based on temporary responsibilities, we can expect a highly dynamic access management environment around the EHR. Consider the example of a cardiologist who wants access to a pediatric record. If the cardiologist is not currently treating that patient, she should be denied access to the patient’s records. If, however, the cardiologist was serving on a peer review panel or as the CMO in the hospital, access to the record may be authorized for purposes of fulfilling those responsibilities. Just because the EHR is a medically unique application or system, it is not unreasonable or even unusual to implement certain specific access control management methods.

To begin with, access can be controlled by physical safeguards. Never overlook or underestimate the use of locked doors, surveillance cameras, or even security guards to augment other controls. Ensuring that resources are not physically available to those who are not authorized to access the systems is imperative. With the proper credentials, unauthorized users may be able to access digital and physical information and network resources unless they are physically prevented from doing so.

In addition to physical barriers, security must include active and continuous monitoring processes to help control access. The process may start with coworkers who are vigilant in monitoring who is accessing systems in their view or work area. Questioning people who are not known or do not behave normally (for example, someone who seems nervous and rushed) is the first line of defense. Next, EHR administrators should maintain an up-to-date access list with designated roles or levels of access specified. The individuals who are on the list should be supplied with unique IDs and mandated to create strong passwords or personal identification numbers (PINs) unless another form of multifactor authentication is available.

An often-overlooked control that can help prevent unauthorized access is an automatic shutdown routine. When an authorized user is done working or simply walks away from his or her access point (for example, a desktop, laptop, smartphone, or medical device), the device should log off or shut down after a short, but reasonable, amount of time. This forced termination of access can reduce the likelihood that someone who is not authorized could piggyback or continue the session under the authorized user’s credentials. In fact, even if the second person is authorized, conducting business on the network under another person’s credentials is not acceptable, because it violates the information security principles of authentication, authorization, and nonrepudiation.

A final consideration for healthcare organizations relative to access management is to audit access and user activity logs periodically. Having an active monitoring process that is reviewed and analyzed can help prevent and detect security incidents. Additionally, when it comes to providing data subjects or patients an accurate history of who has accessed their data or what actions were taken, the access management process can support that disclosure, which is required by privacy and security frameworks. In the United States, this disclosure supports a healthcare organization’s obligation to provide, upon request, a full accounting of the use of a patient’s PHI upon request.

Data Management Concerns

EHR data management is the process of storing, protecting, and analyzing data pulled from the multiple HIT systems that support patient care. Managing the wealth of available healthcare data helps healthcare organizations develop processes and approaches to improve care for their patients and their health status. Effective data management in a digitized healthcare organization can be a daunting task, and protecting that data is the purview of the HCISPP. A key consideration involves identifying and knowing use and demand requirements for authorized EHR users.

As an HCISPP, you will design and implement security and privacy solutions for specific components of EHR data management, including the following:

•   Data sharing  Providers cite data security and privacy concerns as reasons for not sharing data, but regulations generally support interoperability. HIPAA, for example, permits the use or disclosure of health information for treatment, payment, and healthcare operations, which includes disclosure to another healthcare organization for the continuum of treatment, payment, and operations for the recipient organization.

•   Data at rest  Healthcare organizations must protect health information confidentiality. Regulations require that organizations safeguard information, through means such as encryption of data at rest, to protect against threats or hazards to the security, unauthorized use, or disclosure of the information. Proper encryption procedures render sensitive health information unreadable and unusable against unauthorized access.

•   Data mining and analysis  Healthcare organizations must protect sensitive patient data from unauthorized use or use without patient consent. One way to accomplish data mining and analysis that falls outside of acceptable treatment, payment, and operations, such as selling data to a company to conduct risk of illness analysis on a patient population, is to offer patients options to opt-in or opt-out of such information sharing during treatment. Another tactic is to apply de-identification or data masking processes to databases to remove identifying information but keep relevant health information unaffected.

•   Retention and recovery  Central to EHR data management is the ability of the organization to enable full restoration of data from frequent backups that is stored in a separate location. The same safeguards that are appropriate during normal operations are required during recovery mode. Data retention must be governed and limits must be established and followed based on regulatory guidance to minimize risk of exposure to unauthorized disclosure.

•   Privacy  Healthcare organizations must realize that patient privacy regulations generally give patients the right to view their medical records on demand within a reasonable period of time, such as 30 days. Patients must be informed through notice of privacy practices and offered consent documentation that informs them of relevant health data management practices, particularly in the organization’s use of the EHR. Management of the data outside of these stated uses requires additional permission from the patient.

•   Availability  If patient care is disrupted when data is not available, because of a successful malware attack or denial of service, the healthcare organization may face fines and penalties. This is in addition to the operational, clinical, and financial risk present when patients cannot receive the standard of care that is expected when there is access to data.

In summary, healthcare organizations must administer proper health data management security and privacy procedures when collecting, using, storing, and transferring patient data. Marketing and other business departments must adhere to patient privacy and security considerations as well when using health data that may be outside of treatment, payment, and operations beyond which the patient consented. As an HCISPP, you will play a lead role in ensuring that the organization satisfies all requirements, but many stakeholders in the organization will have a responsibility in proper health data management.

Internet of Medical Things

Modern healthcare systems now rely on advanced computing methods and technologies, such as Internet of Things (IoT) specific to healthcare devices, or the Internet of Medical Things (IoMT). IoMT is a category of medical devices and applications that are HIT systems or that connect to HIT systems through Wi-Fi, online computer networks, and cloud platforms. IoMT leverages machine-to-machine communication to collect, store, analyze, and transfer personal health data at an unprecedented scale and depth. Patients, healthcare providers, and researchers use information derived from such data sources to monitor patients remotely, diagnose diseases earlier, and find personalized treatments and medications. Without appropriate privacy protection, however, IoMT introduces potential security and privacy nightmares:¹⁷

•   Volumes of data  IoMT devices significantly increase the volume of data, and you must know where your sensitive data is located. Inventory and protection around new sources, locations, and computing infrastructures may not be thoroughly vetted. Another issue is the scalability of current encryption capabilities at large data volumes.

•   Quality of data  With IoMT, the devices that collect, store, and transfer sensitive information may be used for personal reasons, such as a fitness watch or a voice-activated digital assistant. These are vulnerable to security breaches that could lead to data quality issues based on how the information is gathered and transferred. Such issues could result from a cyber attack or something related to device misuse. For example, a patient may give the device to a friend, and you may not have the ability to regulate the friend’s data input. As a result, analysis and outputs may be flawed. Without proper security safeguards, such personal use could jeopardize the quality, security, and confidentiality of sensitive data.

•   Sharing of data  Many privacy and security professionals identify the potential for information leaks that IoMT can introduce. For example, cloud providers that manage digital personal assistants may have access to PHI that should be protected. The ability of devices such as Alexa and Google Home to process and understand human voice can also lead to collection and transfer of data. When devices are used for healthcare monitoring or consultation, the sharing of data over the devices requires information protections.

•   Data accuracy  Data analytics are often performed on samples, not full volumes, of data. As IoMT devices collect large volumes of data, the accuracy of data is a consideration. In many cases, the data is gathered using input from devices outside of the organization’s control. Controls that help assure data integrity, such as sensors and telemetry, help to minimize manual input to IoMT.

Medical Devices

Medical devices are central to our concern with ensuring information security and privacy in a healthcare environment. Medical devices can range from a thermometer to a digital X-ray machine. Networked medical devices are special-purpose computing systems and instruments, apparatuses, and implants that are intended for use in the diagnosis of disease or other conditions; in the cure, mitigation, treatment, or prevention of disease; or to affect the structure or any function of the body.¹⁸ Increasingly, medical devices are networked (to each other or to larger networks), and they are continuously communicating, which presents a unique challenge to securing them within a healthcare environment. An increasing number of devices are connected to the hospital network or use network resources to operate.

It will be helpful for you to identify and learn about the various medical devices that are used in your organization. In some cases, the number of medical devices connected to the organization’s network may equal or outnumber business systems. There are several basic types of medical devices:

•   Diagnostic equipment  Medical imaging machines such as ultrasound and MRI machines, PET and CT scanners, and X-ray machines

•   Treatment equipment  Medical treatment devices, including infusion pumps, medical lasers, and LASIK surgical machines

•   Life support equipment  Medical devices used to maintain a patient’s bodily function, such as medical ventilators, incubators, anesthetic machines, heart-lung machines, extracorporeal membrane oxygenation (ECMO), and dialysis machines

•   Therapeutic devices  Physical therapy machines such as continuous passive range of motion (CPM) machines

•   Medical monitors  Monitoring devices used to view and assess a patient’s medical state or vital signs, including electrocardiogram (ECG), electroencephalogram (EEG), and blood pressure monitors

•   Medical laboratory equipment  Analytic devices that automate or help analyze blood, urine, genes, and dissolved gases in the blood

•   Home health devices  Diagnostic and treatment equipment used outside the healthcare environment for certain purposes, such as the control of diabetes mellitus or congestive heart failure

Although these devices are typically built upon standard IT operating systems and run well-known applications, their special-purpose natures mean that the normal operational safeguards that would be appropriate in office automation IT could cause patient harm when indiscriminately applied to medical devices. In the future, more types of medical devices will be developed to wear on the body, with some devices implanted or ingested; many already exist and are providing patient care today.

Medical devices entered the medical marketplace under the purview of the US Food and Drug Administration (FDA). Figure 3-5 depicts some important events in the history of medical device privacy and security.

Figure 3-5  A brief history of medical device law and associated privacy and security guidance provided by the FDA

For several years, the FDA has provided urgent warnings and updates to the field concerning medical device cybersecurity vulnerabilities. This forward-thinking approach recognizes the growing reality that medical devices are targets for attackers. The FDA has assured healthcare organizations that these vulnerabilities have not resulted in known patient harm. However, the FDA is taking a proactive stance against vulnerabilities that could allow unauthorized users to remotely access, control, and issue commands to compromised devices. Healthcare facilities are forewarned and can take action to reduce the risks based on the FDA recommendations included in Table 3-2.¹⁹

Table 3-2   FDA Cybersecurity Safety Communications

In the pursuit of implementing good privacy and security practices, unintended consequences can occur with networked medical devices. These devices are essential to direct patient care and are highly regulated by the FDA. If a device fails to perform or performs in an unsafe manner, it can mean patient injury or death. If privacy and information security practices exclude medical devices, vulnerabilities can evolve, and this can introduce patient safety risks. The proper way to address the privacy and security of medical devices is to implement, whenever possible, practices that understand and account for special considerations relative to each device. These devices may have IP addresses, operating systems, and relational databases, but they are not identical to office automation endpoints or servers performing office automation tasks or business functions. If a prescribed information security control may cause unintended issues, security professionals must seek out alternative controls and tailored safeguards. For instance, a medical device may use an operating system that is no longer supported by the software manufacturer, yet the device manufacturer can’t upgrade the software unless it upgrades the device to the next model. Because a new model may be too expensive for an organization, the current model may work sufficiently for its intended clinical purpose.

Upgrading to a newer model simply because the operating system cannot be updated with future vulnerability patches likely is not justified from a cost–benefit perspective. A better control is to segment the device into a separate enclave that is firewalled (quarantined) from the rest of the network but still able to access the network. In these types of cases, the required skill for an HCISPP is having the savvy to know when to implement the prescribed control (for example, upgrading to new operating system) and when to seek a compensating or alternative control (for example, quarantining the device).

Here is another scenario to help illustrate the concept: Imagine your job is to configure and perform periodic software vulnerability updates to your local area network (LAN). Typically, once a prescribed update is tested against your standard computing configuration for endpoints (desktops, laptops, and so on), you are authorized to perform the update through automated routines across the network. The efficiency and effectiveness of this pushbutton approach are clear industry best practices. Now imagine that some of those endpoints are in a cardiac catheterization lab. Sure, they look like desktop computers running standard operating systems, and they have a network IP address assigned to them. However, these special-purpose computers also run medical applications that serve up diagnostic-quality (high-resolution) video and imaging that enable physicians to perform complex cardiac procedures. If, in the middle of such procedures, your automatic push of a software vulnerability patch causes the system to reboot involuntarily (as patches often do), that unanticipated downtime may cause a patient safety issue.

Following are the main concerns about integrating networked medical devices into an overall information security program without much regard for their unique characteristics:

•   Medical devices are used in direct patient care scenarios. Medical devices that malfunction can put patients at risk and impede diagnosis or treatment by clinicians.

•   Medical devices depend on special applications with unique protocols and standards. Although most devices run on known operating systems and use common database technologies, they also depend on or use special-purpose applications and use distinctive protocols. The use of Health Level Seven International (HL7) data transfer protocols and Digital Imaging and Communications in Medicine (DICOM) as an imaging standard are just two examples.

•   Medical device manufacturers play a major role in ensuring safety. Unlike other computing device manufacturers, medical device manufacturers retain a great deal of responsibility for their devices even after they are sold to a healthcare organization. The reason for this has to do with safety rather than cybersecurity, and this responsibility can actually introduce security risks. Because medical devices are FDA-regulated and patient safety is a concern, medical device manufacturers must test and approve all third-party software before a healthcare organization can update a medical device. This process can, at best, delay the software vulnerability patch management process; at worst, it can cause medical devices to remain unpatched and vulnerable to exploit on the hospital LAN.

•   Medical devices often exist on legacy operating systems and sunsetted applications (those no longer supported by their developers). The cost of upgrading a medical device to a newer model simply because the operating system or database application is no longer supported, for example, is sometimes cost prohibitive.

The point of discussing medical devices and their privacy and security implications is not to say that medical devices cannot or should not be fully integrated into the overall information security program. In fact, the opposite is true. If medical devices are not part of the enterprise information security program, it is certain that the LAN will be extremely susceptible to attack. In 2015, the FBI published a public service announcement regarding its investigations of healthcare organizations in the United States. The FBI identified some profoundly disturbing levels of vulnerability related to poorly managed medical devices.²⁰

Medical devices offer information security and privacy professionals an opportunity to protect information by developing appropriate compensating or tailored controls. Here are some of the approaches you should consider:

•   Include the medical devices in the information security program. Medical devices are often managed by biomedical technicians, and sometimes the department is completely outsourced to a third-party management team. Proper communication and coordination must include these devices in the overall asset inventory and vulnerability management process. According to the 2015 FBI report, simply knowing which devices have up-to-date software configurations and which do not is a big first step toward solving security problems.

•   Segment the LAN. Quarantining medical devices or segregating them in a defense-in-depth architecture in a firewalled enclave, for example, is helpful. Because software vulnerability patch management can be on a compliance schedule that differs from one that the medical devices can support, segmentation not only provides a series of subnets and an additional line of defense from external infiltration, but it also protects the rest of the organization’s network from these vulnerable devices while the testing and approval steps are taken and the manual patching process is completed.

•   Ensure that medical devices are included in the organization’s data incident response policy. When a medical device malfunctions or its performance degrades, it may not be obvious that the cause is related to malware or security. As repair actions are taken, a data security incident must be considered as a potential source of the problem. Additionally, the data incident policy must allow for biomedical technicians to report potential and actual issues. This also means that the healthcare organization will notify the medical device manufacturer and the FDA as part of normal data incident processes. Make sure that you use the FDA reporting channels.

Classification of Medical Devices

FDA classification is an important privacy and security component of medical devices. The FDA uses classifications categories for approximately 1700 different generic types of devices and groups them into 16 medical specialties, or panels. Each device is typed into one of the following three regulatory classes based on the level of control necessary to assure its safety and effectiveness:

•   Class I  General Controls (defined in the Note that follows) must be applied. Almost half of all medical devices are in this category, which includes enema kits, elastic bandages, manual stethoscopes, and bedpans. Almost none of these devices undergoes a premarket regulatory process or evaluation by the FDA, but the devices still must register with the FDA before being marketed in the United States. Class I devices present low to moderate risk to the patient or user.

•   Class II  General Controls and Special Controls (defined in the Note that follows) are implemented for this classification. About 43 percent of medical devices are Class II devices. The risk level to the patient or user is considered to be moderate to high. Examples include powered wheelchairs, biological indicators, X-ray systems, gas analyzers, pumps, and surgical drapes.

•   Class III  General Controls apply and the devices must go through a process of scientific and regulatory review to evaluate the safety and effectiveness called FDA Premarket Approval. These devices usually sustain or support life, are implanted, or present a high risk of illness or injury. Heart valves, implantable pacemakers, silicon-based breast implants, and cerebellar stimulators are a few examples of Class III medical devices. These devices make up about 10 percent of the medical devices in use and present the highest level of risk to the patient or user.

Device classification depends on the intended use of the device and upon indications for use. For example, a scalpel’s intended use is to cut tissue. A subset of its intended use could be a more specialized indication included in the device’s labeling, such as, “for making incisions in the cornea.”²² The most relevant impact of device classification to an HCISPP is the other reason devices are classified: classification is based on risk. The level of risk the device poses to a patient or the device user determines its classification. Class I includes devices with the lowest risk and Class III includes those with the greatest risk. As you implement privacy and security controls that may impact medical devices, the classification will influence how you evaluate information risk reduction against patient care and patient safety concerns.

Cloud Computing

In an effort to increase efficiency, reduce costs, and garner expert HIT support, healthcare organizations are rapidly moving toward the cloud. In cloud computing, resources, software, processing power, and storage are shared and accessible via the Internet. In short, in cloud computing, HIT services are delivered much like utilities such as electricity are delivered. As with many other industries, healthcare organizations are moving to these virtual computing environments and away from the traditional on-premises IT environment, which suffers from single-purpose server and storage resources. In traditional HIT environments, IT costs can be prohibitive, and this can often result in low device utilization, gross inefficiency, and inflexibility in responding to changing organizational initiatives. By contrast, the return on investment with cloud-based, HIT-as-a-service arrangements are promising. Because future HIT costs seem to be boundless, potential savings and efficiencies gained from initiatives such as cloud computing are very attractive to the healthcare industry.

According to leading sources such as the NIST Cloud Computing Program (NCCP) and the Cloud Security Alliance (CSA), the benefits offered by cloud computing in healthcare organizations include the following:

•   EHR technologies

•   Improved data exchange or sharing

•   Availability of large amounts of data for analytics (big data)

•   Patient enrollment

•   Home health, telehealth, and picture archiving and communication system (PACS) technology

Moving healthcare data to the cloud introduces concerns relative to privacy and security, however. Some of these concerns involve general privacy laws, and others are unique to healthcare. All organizations, including healthcare organizations, face many concerns with regard to cloud computing. Among the most prevalent concerns that impact healthcare are multiple tenants, trans-border concerns, and third-party risks. Figure 3-6 provides a visual representation of the cautionary tale for those that ignore guidance such as that found in NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing. Leading cloud security sources caution that including proper privacy and security safeguards is necessary to prevent adversaries from gaining access, because adversaries also see the cloud as a terrific business opportunity—for a very different and untoward purpose.²³

Figure 3-6  Plan for privacy and security before you implement cloud computing solutions.

EHRs in Multitenant Cloud Environments

By definition, in a cloud computing environment, many different customers intermingle within the same cloud service provider’s architecture. These customers can come from banking, retail, and academic organizations, as well as healthcare. Each industry may have varying mandatory information security requirements—for example, the US healthcare industry must abide by HIPAA data storage regulations, while a retail organization may be affected by the Fair and Accurate Credit Transaction Act (FACTA) and the Red Flags Rule. For instance, under HIPAA, disclosure of healthcare information is prohibited outside of treatment, payment, and operations. HIPAA prohibits health data from being accessible by other cloud tenants, because that would be unauthorized disclosure. Cloud service providers, therefore, must provide extra technologies to segregate health data properly within shared virtual machines (VMs) and physical servers with multiple clients.

Under HIPAA, healthcare data in the cloud must be secured in the same way it would be secured in an in-house data center. Some cloud providers may not have the ability to meet stringent HIPAA requirements, and some providers may not be able to accommodate security policies and procedures required by a healthcare organization. Healthcare organizations should therefore use only cloud providers that are equipped to handle healthcare data specifically.

With regard to identity and access management, the healthcare organization must be able to restore or delete its cloud-stored data on demand. Cloud providers that want to support healthcare organizations must also be able to provide networks that are logically partitioned enclaves with segmented database and storage layers. If the data is not properly segmented, restoration or data disposal will be difficult or impossible.

Mobile Device Management

Bring your own device (BYOD) is a popular strategy that end users are embracing and organizations are trying to adopt. The positive aspects of BYOD, including reducing inventory costs and maintenance for the organization’s IT department, are evident. End users like the flexibility of using a device that they can personalize and customize (for improved productivity). These BYOD environments typically include laptops, tablets, and smartphones that run operating systems and mobile applications the organization cannot provide resources to support.

Because of the information privacy and security implications with BYOD, a mobile device management (MDM) process must be in place. The MDM policy will include access management, user rights and responsibilities, as well as what actions the organization can take with respect to BYODs. A growing number of healthcare providers are realizing improved productivity by accessing the organization’s EHR and ordering tests and medication by using computerized provider order entry (CPOE) via their own personal mobile devices. Because healthcare organizations are required to protect PHI and PII, they will need to address mobile device management to protect their patient’s data.

BYOD presents unique challenges in healthcare, in that any PHI or PII located on a BYOD is beyond the information-protection reach of the organization. An organization has little control over third-party software, including malware, that is loaded on a personal device. Further, mobile devices can be easily lost or stolen. If a device is not encrypted and contains PHI or PII, the data loss may require patient notifications as well as government intervention. In addition, the economic costs of data loss from personal devices can be significant. According to research conducted by the Ponemon Institute, “Just one mobile device infected with malware can cost an organization an average of $9485.”²⁴

Healthcare organizations can implement network access control (NAC) to identify an end user’s device when it’s being used to access the healthcare organization’s network. Prior to allowing the device any level of access, the device can be scanned for compliance with the latest antivirus version and up-to-date vulnerability patches. NAC technologies can support all brands of mobile devices, including medical devices.

Another architecture solution that is facilitating mobile device management is the implementation of the virtual desktop interface (VDI). This configuration, relying on VM equipment and software, basically enables an authenticated user access to network resources without delivering and storing those resources on the end device. In the past, “dumb terminals” were used to access mainframes in a mainframe computing environment, which bears some similarity to how mobile devices now access VDIs.

Health Information Exchange

We are in an age in which the digitization of patient information has made sharing the information much easier. This makes security constraints with regard to using sensitive health information more important than ever. Hospital A cannot freely share patient information with Hospital B unless the use is for treatment, payment, operations, or if the patient gives informed consent for the sharing. However, advantages exist for sharing health information beyond treatment, payment, and operations; these are the basis of health information exchange (HIE). Healthcare organizations see value in HIE in that it can improve access to clinical data by providing safer, timelier, and more equitable care, with better outcomes. Sometimes HIE is part of treatment, payment, and operations; other times, it can occur for research, public health, or another valid clinical reason. HIE introduces its own privacy and security concerns—namely, the creation of multiple copies of data. Decentralized database locations with overall system awareness can help keep control localized and safeguarded.

Before we go further, rest assured that HIE is not just a US-centric phenomenon. Although US healthcare organizations are implementing HIEs, their global use is increasing annually by 10 percent. An estimated $2.21 billion will be spent on HIEs by 2024.²⁵ The global demand for HIEs is based on motivating factors similar to those in the United States: cloud computing, mobile devices (BYOD), and emerging global economies. With rising economic levels, EHR implementation is spreading; thus, so is information sharing through HIEs.

For the most part, HIEs provide healthcare providers across the same or multiple organizations almost real-time access to clinical information, reducing the delay in information transfer that occurred with traditional, paper-based record systems. Built into the HIE is the ability to ensure information integrity if operational safeguards are integrated. Because of the availability of PHI, HIEs may also provide a way for healthcare organizations to accomplish public health reporting, measure clinical quality, conduct biomedical surveillance, and perform advanced population health research. But this is true only if the element of trust is present and the PHI is deemed reliable from each perspective: the patient, the provider, and the HIE activity.

HIEs are also subject to HIPAA rules. Patients have specific rights regarding how their health information is used and disclosed. HIEs are required to publish their practices and inform participating patients of their individual rights. The only way to build trust is to communicate these terms and conditions clearly. The ONC has outlined a privacy and security framework that, when used, constitutes good data stewardship and forms a foundation of public trust in the collection, access, use, and disclosure of PHI by HIEs.²⁶ Along with the ONC framework, the US Department of Education’s Office for Civil Rights (OCR) has provided an expectation for HIEs using principles from leading privacy frameworks to increase individual control over the collection and use of PHI while limiting and securing the sharing between healthcare organizations to specific scenarios.

If HIEs are implemented correctly, with protection of properly collected PHI or PII, their international evolution will give healthcare organizations unprecedented access to public health reporting, outcome measures, biomedical surveillance capability, and research. However, patients and regulatory authorities will be the judges when it comes to determining whether or not the HIEs can share information safely and securely.

Data Lifecycle Management

Secure data lifecycle management must be a priority as healthcare organizations make the shift from paper to digital records, as data is shared more easily, and as methods for data storage change. Healthcare organizations must establish governing principles for the useful life of healthcare and business data.

Chapter 1 introduced and differentiated DLM from information lifecycle management (ILM) and information flow within a healthcare organization. You’ll remember that although DLM is similar to ILM, DLM is concerned with information at the file level, which is more abstract in nature and less concerned with the use of the data within the file. ILM deals with specific information within that file (patient height, weight, and so on). This section provides an overview of the specific components of the data lifecycle and how to manage its privacy and security impacts.

The data lifecycle begins with a creation (create) phase and ends with the secure disposal (destroy) of data that is no longer needed. This section discusses the major components of a data lifecycle as shown in Figure 3-7.

Figure 3-7  Data lifecycle components

Phase 1: Create

Healthcare organizations create, or collect, a tremendous amount of data. An incredible amount of patient healthcare data is required for treatment, payment, research, and quality improvements. Storage manufacturers (such as DellEMC)²⁷ have estimated that we will have about 2314 exabytes of stored healthcare data globally by this year (2020). In fact, the healthcare industry has the highest compound annual growth rate (CAGR) of any industry at 36 percent through 2025.²⁸ The explosion of data sources is the result of multiple innovations and advanced HIT as the healthcare industry has evolved from paper-based data storage to digital storage. The proliferation of data collection and storage has come in part from the incredible abilities of medical devices that connect directly to the patient or are ingested. This data can inform providers of more information in an instant about the patient than was ever possible before.

Massive amounts of collected and stored data have ushered in the era of “big data.”²⁹ The promise of big data is that healthcare providers, payers, and researchers will have ready access to relevant information to use and share. The goals are to improve healthcare practices, enhance the quality of patient care, and reduce healthcare costs over the long run. While big data may provide deep statistical and analytical insights that benefit patient care, safety, and reimbursements, significant concerns for privacy and security are a constant. Because the sensitivity and criticality of the data created or collected is important, the regulatory environment is constantly working to keep up with the pace of progress. Updates to HIPAA, state laws, the EU GDPR, and other laws and standards have published substantive new and adaptive changes that acknowledge the amount of data collected and stored and how much control individuals have in determining the information’s use by the healthcare organization. A proven practice during the creation phase is to ensure that data classification is applied here to identify data as public, internal, sensitive, or restricted.

Phase 2: Store

As data is collected, it has to be processed and stored. At first, the organization does not yet gain any value from the data, because it is simply moved into the environment to be entered into the data repositories and applications. At that point, the data begins to be manipulated to start becoming valuable.

In this phase, the data is copied from one or more sources into a destination system, known as the extract-transform-load (ETL) processes. Data governance policies and procedures, which you will help support and enforce, will have primary focus in this phase. Roles and responsibilities for moving data to authorized users are also relevant. The aim is to prevent problems such as sprawl of data to unauthorized locations or reduction of numerous copies of databases that diminish the data source.

Data storage across the lifecycle employs a hierarchical approach to support secure lifecycle management. In hierarchal storage, data is stored based on operational considerations, such as how frequently the data is used. The same volumes of data may move between high-cost and low-cost storage media. Speed and access come with higher costs: high-speed storage devices such as solid state drive arrays cost more than the slower storage options, such as hard disk drives, optical discs, and magnetic tape drives. Use of high-speed storage is appropriate for data that is frequently retrieved and provides low latency. Secure movement of records to slower storage media according to the organization’s record management schedule supports the progression of data to future steps of the data management lifecycle.

Phase 3: Use

At the point of data use, meaningful information is generated from the data. At this phase, the collected data is used in support of the healthcare organization to conduct analysis or support decision-making.

As an HCISPP, one of your concerns is defining and administering permitted use of data guidelines and controls. The permitted use of data is a crucial concept that refers to how a company manages and uses individuals’ data. The concept is defined in many international privacy laws. Under the GDPR, organizations are required to be open and transparent about their data collection and use policies. Consumers have to provide consent to those collection and use policies before the organization can use the data for those stated purposes.

Along with rules for obtaining consent and openness and transparency for how the data is going to be used, organizations must create and abide by a strict process for sharing sensitive data along with access and authorization rules. By committing to proper data use policies and procedures, a healthcare organization will not only adhere to regulatory guidelines but will also maintain the trust of its patients.

Phase 4: Archive

Data may have a long life span in an organization and may be used for a variety of purposes. When data is no longer useful, it is retired or moved to an archival location. Data archival becomes relevant as the need for routine or quick access begins to decline, as the data is less likely to be used or shared. However, because of retention requirements such as legal discovery or regulatory guidelines, a healthcare organization may need to archive patient data for a specific amount of time.

The key point at this phase is that although the data is no longer available routinely within the active production environments, it can be accessed if necessary. While the data is in archival status, it is no longer accessed for day-to-day use, and additional processing in the data’s storage phase is halted.

Traditionally, paper documents and physical media required sufficient storage space. Because securing rooms in buildings can be an expensive endeavor, organizations were motivated to save costs by archiving data for only as long as it was needed. Of course, data archival had to adhere to regulatory guidelines for minimum retention periods.

The transformation of data from paper documents and physical forms of media to digital formats has not removed the need to retain data safely during its lifetime. The fact that digital archival costs and space requirements are far less than traditional paper-based technology and methods does not lessen the need to employ proactive and mandatory archival policies for electronic data. Because digital archival requires so little space, many organizations have not set boundaries on how and when data will be moved from normal storage to archival. To underscore this point, imagine the amount of space required to store 5000 medical records comprising paper-based images, charts, notes, and printouts. The ability to provide access to data and long-term archive requirements could easily command multiple rooms filled with medical files. With EHR today, thousands of records can fit on an inexpensive USB thumb drive.

Some organizations are opting to archive their on-premises data in cloud computing solutions, even where the source data is not stored and used on a day-to-day basis. The benefits of cloud storage include a high-availability environment that is kept current with security patches and technical support. Compared with the costs incurred by an organization trying to archive within their own data center, the cloud solution helps defray infrastructure and time expenses.

Phase 5: Destroy

Simply put, when a healthcare organization has no business, clinical, legal reason or obligation to maintain data, it needs to securely dispose of it. The destruction of data must be guided by organizational policy and relevant regulations, both local and national. In the United States, data retention is not prescribed by HIPAA, but some state laws provide governance. The governance is important to establish a minimum amount of time that data elements must be maintained. A maximum limit should also be established, with a caveat that allows longer limits if the information is determined to be valuable to business processes or clinical treatment. There are international standards, too. The Canadian Privacy Act is not prescriptive in that it does not mandate how long the government must store personal information; however, if the act charges government data collectors with retaining the information for a minimum time period, set by additional regulation. This time period must be sufficient for the data subject to have access to the information. Because healthcare is funded by the Canadian government, this provision can mandate longer retention periods. In the European Union, the GDPR also has a provision that describes maximum limits for how long the information should be retained, so that it is kept no longer than necessary. At the same time, GDPR allows member states to establish longer retention periods if they have historical, statistical, or scientific uses for the information that are valid and otherwise permitted by the GDPR.

Data destruction is important for you to master. One major reason is because data users often relax controls for protecting sensitive data when it is no longer needed. When computing equipment is decommissioned from production, a common reuse is to donate it to charity organizations. But if hard drives are not sanitized, the goodwill of a donation can be ruined by a data breach.

With the advent of data collection and storage of petabytes of data, the impact of losing data is significant enough. But when the story also includes acknowledgment that the breached data was no longer needed by the organization, but kept anyway, the impact is magnified. Consider the case of US company InfoTrax that found hackers had compromised its servers, and that customer data, including sensitive information, had been accessed by the attackers. Over one million accounts with Social Security numbers, payment card information, bank account information, and usernames and passwords in clear text were potentially leaked—information that, by the company’s own admission, was kept longer than it needed to be.³¹ Maintaining privacy and security vigilance throughout the entire data lifecycle, especially at the data destruction phase, will help you keep your organization and patients safe.

You will need to know and use appropriate methods for securely disposing of data. Again, in this stage, the information remains sensitive, whether it is payment related or contains health data for an individual. Proper disposal and destruction methods, collectively called “sanitization methods,” are needed to prevent unauthorized disclosure. There are two general approaches to data destruction. The first approach is to render the actual device containing the media useless. Physical destruction of the media, electromagnetic degaussing, and incineration are common tactics. If the organization intends to repurpose the device after destroying the sensitive data, these approaches would not be appropriate. If the media is not rewritable, physical destruction is the best method to ensure the information is destroyed.

The second type of data disposal is by cleansing or sanitizing the media/drive. The physical media can therefore be reused, but there is no trace of data on the media after the data-wiping action, which can occur when data destruction efforts are insufficient to prevent data reconstruction. There are numerous validated processes for this objective. The techniques outlined in Chapter 1 for information sanitization would also apply here. Keep in mind that data sanitization is usually considered a minimum standard because of the risk of data remanence.

The best methods use both approaches as needed based on the level of sensitivity of the information and the possibility of reusing the media. The goal of sanitization as an information security control is to render the data so that it is impossible or impractical for someone ever to retrieve it.

Physical Media Destruction

Somewhat analogous to physical destruction of paper-based records, media that contains sensitive data can be destroyed completely as opposed to removing the data securely while leaving the physical media asset (backup tape, hard drive, and so on) intact. The processes for physically destroying the media are not very technical or elegant, but they are highly effective. For instance, drilling holes into a hard drive through the spinning disk is effective. This method may not actually destroy the data, but the data will become unreadable or unrecoverable. Large shredders can also be used to shred the physical assets into small pieces. Some other methods that can be used are disintegration, incineration, pulverization, melting, sanding, and treatment with chemicals.

Secure Overwriting  Secure overwriting renders data unusable by destroying just the data. Other methods render the drive completely unusable, even those that do not destroy the physical asset. If an organization wants to reuse storage assets, such as expensive storage area network components, it can overwrite the data. The secure overwriting process consists of writing meaningless data over and over onto each of the sectors on an asset’s hard drive. The meaningless pattern typically consists of combinations of 1’s and 0’s. The number of times this process must happen to be effective varies across a number of standards. Probably the most often referenced standard is the NIST SP 800-88, Guidelines for Media Sanitization, which calls for multiple overwriting passes to overwrite the data completely.

Degaussing  Degaussing is a process used to erase all data on magnetic field types of media, such as backup tapes or hard drives. The device used to degauss the media generates a magnetic field that completely randomizes the 1’s and 0’s on the media with no preference to orientation, thereby rendering previous data unrecoverable. This process is useful in sanitizing large amounts of data quickly. It is also very effective to use when the media is damaged and is inoperable. Many argue it is impossible to remove the magnetic field completely and thereby fully randomize all the 1’s and 0’s. A remnant can remain, making it theoretically possible for some of the data to be recovered. For this reason, much like secure overwriting, information security best practices require multiple degaussing for each piece of media. NIST recommends multiple degaussing passes. Degaussed media cannot be reused.

Third-Party Connectivity

Because many healthcare organizations have implemented EHRs, the work required to connect any existing data systems, engineer the local area network, and prepare physical environments to house the equipment may require additional support from external organizations. Other types of third-party entities may require access to your organization’s data to accomplish the duties they are contracted to do. If the third party works at a location away from that of the healthcare organization, they made need to make remote external connections into your computing environment.

The operations of healthcare organizations extend well beyond the clinical care settings to include a new type of supply chain between the healthcare organization and vendor suppliers. This supply chain must be managed as a valuable asset to be protected and shared securely according to organizational, regulatory, and legal requirements. In international terms, data controllers rely on partners who are data processors and, in many cases, have other data processors that must be approved to handle the sensitive information. In the United States, this relationship is called the business associate and can include all of the downstream business associates as well (that is, the business associates of the business associates). The traditional vendor relationship has moved from contractual relationships to include various, complicated interconnection agreements. As you would expect, there are several considerations for privacy and security of information related to third-party connectivity.

There must be a chain of trust between the healthcare organization and its third-party vendors. Imagine the complex relationship between third-party organizations that manage an HIE process for exchanging relevant healthcare information between (often competing) healthcare organizations that have patients in common. This may involve a data center or cloud provider contracted as a third-party vendor to host the data from the healthcare organizations. This third party would have access to healthcare information, with statutory and contractual responsibilities to protect that information.

One reality is constant across the globe: no matter who is the third party for the healthcare organization, data controller, or covered entity (synonymous depending on country of origin), accountability for the loss of sensitive data is always the healthcare organization’s responsibility. Although the regulatory or legal liability can fall to the third party, this is of little benefit. The patient may not understand the complexity of the third-party relationship and will lose trust in the healthcare organization. After all, the healthcare organization collected the information and made promises to the patient to protect personal information (and use only as much of it as needed for intended purposes).

Although contractual agreements and business relationships do not change this, the healthcare organization must implement controls to outline expectations, define procedures, and identify matters of redress relevant to any third party’s use of protected information. Failing to take these interconnection actions represents a lack of accountability to regulators. The absence of such may result in the healthcare organization facing additional civil and even criminal penalties. Keep in mind that even if an organization is found to have done everything reasonable and appropriate to prevent data loss (due diligence), civil and criminal penalties are a possibility—including fines and penalties incurred by not properly attending to third-party relationships.

Trust Models for Third-Party Interconnections

Starting with an understanding of regulations and laws for data use outside of the healthcare organization, you will have a role in establishing third-party interconnections. You should expect to design, implement, and enforce technical solutions as well as administrative controls such as contracts and data-sharing agreements to support external connections. As you work within that role, you will be required to define privacy and security parameters, such as minimum data sets and least privilege levels for access. You will outline third-party on-boarding, credentialing, and termination processes to make sure these parties are properly cleared to use the healthcare organization’s network and applications. Another responsibility you will have in this area will be in securing data transfer capabilities, such as encryption, for safeguarding information. Communication of these processes and many others must be done within the healthcare organization and to third parties before contracts are signed and work begins.

After considering the complexity, magnitude, and nature of the arrangement and associated risks with the third-party connection, the healthcare organization should decide how to manage interconnections and data sharing. A trust model, or a selection of connection controls, is important. A quick look at some technical controls of the third-party trust model is helpful. Such models and tools are important to help formalize a level of trust with third-party organizations that provide a service. To formalize the chain of trust and to gain the satisfactory assurances required, you can expect to see these technical trust models in practice. By no means comprehensive, here are some leading examples:

•   PKI certificates  Public-key infrastructure (PKI) certificates are used to support the encrypted transfer of healthcare information. PKI is a collection of hardware, software, organizations, policies, and procedures that work together to facilitate the appropriate use of digital certificates, which make encrypting information possible. Within PKI, each user has a unique identity validated by a trusted authority. The transfer of information between two individuals with an established trust relationship under PKI is secure, and the sender and recipient have assurance that each is who they say they are (nonrepudiation).

•   Transport Layer Security (TLS)  and Secure Sockets Layer (SSL)  TLS and its predecessor, SSL, are security protocols that enable the secure transport of information across protected network tunnels on the Internet. The X.509 class of certificates are used (PKI, for example). Like PKI, the use of certificates allows nonrepudiation and the data is encrypted. Several versions of these protocols make possible secure applications in web browsing, e-mail, Internet faxing, instant messaging, and Voice over IP (VoIP).

•   Virtual private networking  (VPN)  Through a user-created connection, remote access is made possible by a combination of passwords, biometrics, two-factor authentication, or other cryptographic methods. The remote user establishes a secure connection that extends a private network across the Internet. Data is shared just as it is all within the organizational domain or private intranet. Logically, the connection is a virtual point-to-point connection using dedicated connections, encryption, or a combination.

•   Virtual desktop interface (VDI)  Because external vendors may need access via mobile endpoints, a VDI may be a preferred, secure solution. VDI is remote access to a virtual desktop and is enabled through client software on the remote endpoint. The client system presents the remote computer desktop image to the remote user on his or her mobile device. The remote user can manipulate and access the client’s system. VDI adds data security because it can be configured to make it impossible for data to leave the organization’s network.

Not only should interconnection terms be spelled out in contracts and agreements, but it is also incumbent upon the primary entity to ensure that termination actions are carried out. Appropriate activities must all be taken into consideration, such as removing access to the data; appropriately destroying, disposing, and/or returning the data; terminating network connections; and ensuring that files are no longer exchanged.

Technical Standards: Physical, Logical, Network Connectivity

The process of interconnecting third parties to the healthcare organization network could open the organization to various information risks. It is imperative that entities take appropriate steps to implement effective security controls. This will start with ensuring that current controls are configured correctly and any gaps are addressed using new controls. Technical security controls will be a combination of firewalls, identification and authentication mechanisms, logical access controls, encryption devices, intrusion detection systems, and network behavior monitoring systems. Technical standards will include physical, logical, and network connectivity components, as shown in the following list. Objective standards can easily be found in leading information security guidance and risk management frameworks such as the NIST Cybersecurity Framework, ISO 27001, and the HITRUST Common Security Framework.

Physical Controls

Physical control considerations include the physical environment in which the vendor’s computing network resides as well as the physical architecture of the computing environment itself. You need to collect information about the data center or facility that houses equipment that collects, stores, or transfers your organization’s sensitive data. Such external assessments are considered necessary. An example of such an assessment is SOC 2, an auditing procedure developed by the American Institute of CPAs (AICPA) that can be used to evaluate the management of customer data based on five “trust service principles”: security, availability, processing integrity, confidentiality, and privacy. SOC 2 assesses the effectiveness of physical controls in place.

The physical technical standards relate to the hardware, software, and pathways that must support and conform to industry regulations, relevant law, and your organization’s policies and procedures. These standards must consider a third party’s system architecture and the interconnection components that will provide access to your organization and support data sharing. You may require documents that show the technology used by the vendor, such as firewalls, IDS, data loss prevention, and VPNs. You can also review relevant system and security logs as well as audit reports. Information should also include ports through which network traffic travels as well as protocols used.

Logical Controls

Technical standards for logical security refer to the controls the third party will have and use to grant access and limit authorization to data. Your role will be to review and enforce the use of acceptable logical security technical standards based on interconnection requirements. These logical security controls include systems used to manage user profiles, privileged access, and passwords. Advanced technical standards for logical security controls are tokens that generate one-time use codes to enable multifactor authentication and identity systems that enable biometric access control methods. In addition to reviewing the identity and access management tools, you’ll need to understand the vendor’s policies and procedures regarding granting access and credentials for employees. This will include an assessment of the vendor’s process for termination of employees’ access when that access is no longer needed, such as after an employee’s contract terms expires.

Network Connectivity Controls

Technical standards for network connectivity will involve an evaluation of how the vendor’s network is configured, protected, and monitored. This evaluation will confirm whether or not the third party has sufficient network controls in place to prevent, detect, and respond to unauthorized attacks or intrusions. Network connectivity must also consider mobile and cloud connectivity if applicable. Additionally, network connectivity technical standards will outline the only approved methods and technologies a third party may use to connect to the healthcare network. For example, approval may be granted for solutions using VPN or SSH tunnels. If the organization’s risk levels are high enough to warrant the additional costs, some interconnections may be established with direct, dedicated circuits, such as ISDN, T1, or T3 connections.

Connection Agreements

To support the physical and logical controls, organizations must use a number of administrative controls to implement and sustain information privacy and security for third-party interconnections. Connection agreements contain relevant terms and conditions that establish interconnections, with details, specifications, expectations, and responsibilities outlined within the documents. These agreements help healthcare organizations communicate requirements, evaluate performance, and hold all parties accountable for compliance. The more comprehensive the connection agreement, the better job the organization can do monitoring and enforcing the interconnection over time. Connection agreements are also helpful when a healthcare organization’s expectations and requirements exceed those of the third party’s other customers.

Memorandum of Understanding

A memorandum of understanding (MOU) contains business and legal requirements, including purpose and rules of engagement, necessary to support the interconnection between the healthcare organization and the third party. A good MOU clearly lists areas that both sides must abide by, such as confidentiality of data. Technical configurations are not part of the MOU, however; those are covered in accompanying interconnection security agreements (ISAs). Although not a legally binding contract, an MOU is a formal agreement and is often created before a contractual relationship is formed. The document establishes an outline of how the two organizations will work together based on roles and responsibilities. An MOU is often used in conjunction with a service level agreement (SLA).

Service Level Agreement

Healthcare organizations may choose to require a written SLA before hiring a third party. These can be legal contracts with binding conditions enforceable in court, or they can represent informal obligations between the two parties. Either way, an SLA will cover important, measurable performance expectations and the responsibilities of the provider as well as the customer. An SLA also covers how problems will be handled. When a disaster happens, the SLA will guide actions and obligations for the recovery of systems covered by the agreement. Finally, the SLA must include terms and conditions for ending the agreement, including what happens in data disposal.

The most effective SLAs include scheduled times in which the customer and service provider meet to discuss ongoing operations. This communication may integrate into the overall risk management process, where issues concerning risk assessment and mitigation are also included in the monitoring of the SLA. But the SLA covers more than just the management of risk. Service providers will have obligations to provide availability of information, upgrades to hardware and software, and/or improvements in general customer service depending on what services are being provided. In short, the SLA can be considered an additional administrative control within the risk management process. The SLA should be enforced, but changes should be permitted as situations warrant. Communication is a vital part of ensuring that the SLA is never static and helps the healthcare organization and third party achieve a successful partnership.

To protect healthcare information for your organization, you may have to manage one or more SLAs. The SLA may be a portion of your overall risk management strategy. The following are some suggestions for properly managing the SLAs under your purview:

•   Be proactive and review compliance regularly.

•   Establish measurable objectives that meet business or clinical standards, comply with laws or regulatory requirements, and ensure that the service provider agrees to abide by.

•   Monitor these objectives continuously.

•   Communicate with the third party.

•   Communicate to information governance within the healthcare organization.

Doing these activities can help you succeed in your duties. More importantly, active oversight will give the SLA the best chance of being efficient and effective. Too many SLAs are signed and shelved only to be reviewed after a data breach or after service levels have reached such low levels that the agreement is in jeopardy of being terminated for cause.

Interconnection Security Agreements

ISAs include the responsibilities and expectations that establish and maintain network interconnection. They specify technical and security requirements and controls the healthcare organization and third party are expected to implement to ensure information privacy and security. The ISA is intended to protect both organizations and their interconnected systems. This is related to the fact that an organization will not have control over a third party’s firewalls, routers, or DLPs, for example. ISAs are a compensating administrative control to mitigate the risks.

The agreements are developed as early in the third-party negotiations as possible, preferably during system development. As business requirements change, the ISA can be modified to reflect these. The use of an ISA follows guidance from NIST SP 800-53 Rev. 4, Security and Privacy Controls for Federal Information Systems and Organizations, specifically control “CA-3 System Interconnections.” For organizations establishing dedicated connections between information systems, the control asserts organizations can either develop ISAs or describe the interface characteristics between systems in the security plans for the respective systems.³² Components of an ISA can include a description of the agreement’s purpose and benefits, any security requirements, and a network diagram depicting the interconnection. The ISA is reviewed annually; as changes are made to the interconnections over the life of the contract, the ISA must be updated accordingly, not only at annual review.

Contracts (Standards and Practices)

When a formal, legally binding document is required, a contract may be used. Contracts include standards, practices, and clauses that exceed the level of formality and enforcement of an SLA. Contractual provisions are helpful for data security concerns. Every contract has variations, and an overall template is hard to illustrate, but some commonalities exist.

To begin with, the contract should hold the third party to relevant privacy and security standards that the healthcare organization complies with, including external regulations and internal policies and procedures. Additionally, contracts will consist of terms and conditions related to the following:

•   Compliance  The third party must adhere to relevant regulations. In the United States, this would start with HIPAA. The contract may be the business associate agreement (BAA), or the BAA may be part of the entire contract. The third party will also have to comply with relevant state laws. All compliance requirements must be covered specifically in the contract’s compliance section. For organizations that extend globally, or those that transfer data across borders, the contract would include compliance requirements for laws of other countries, such as the EU GDPR. Beyond compliance with laws, compliance with standards should also be included. For example, the third party must adhere to applicable Payment Card Industry Data Security Standard (PCI DSS) requirements or applicable NIST standards.

•   Confidentiality  If the third party is required to handle sensitive healthcare information, the confidentiality provision must be present in the contract. The information is defined, permitted uses are explained, prohibited uses are described, and return or disposition provisions are outlined upon the termination of the contract.

•   Data loss prevention and response  The third party will take on responsibilities for preventing data loss and will also need to know how to respond to potential or actual data loss by complying with the healthcare organization’s incident response policies as well as any governing regulatory guidelines. The contract should allocate responsibilities and outline procedures accordingly.

•   Indemnification  Some will argue the sections covering indemnification can be the most impactful in a contract. Indemnification, or the provisions for damages or compensation if things go wrong, becomes crucial in the event of a security breach or abuse of personal information. The contractual language should also include information regarding insurance to cover data loss events. Any regulatory obligations in the country where the patients reside will be provided. Also, the indemnification clause will include a duty to cooperate in investigations and resolution actions. In some cases, the healthcare organization will want to add provisions for controlling these investigations and any notification actions to patients or regulators, even if the vendor is responsible for some or all of the related costs.

•   Limits to liability  In the event the third party causes a data loss or breach, the contract should limit liability (or hold harmless) for the healthcare organization. On the other hand, there can be limits imposed on the liability of the third party, because too high of a threshold or unlimited liability may far exceed the value of the contract. Not many third-party vendors would accept that much risk and would instead choose not to provide the service to the healthcare organization. It is a delicate balance. But the healthcare organization needs to be protected from undue litigation and data breach recovery costs resulting from a third party’s failure to perform or to comply with applicable laws.

Chapter Review

Health information technology (HIT) involves the design, development, creation, use, and maintenance of information systems used within healthcare organizations. As the healthcare industry has evolved from paper documents and printed images to digital files and databases, the importance of HIT has increased. HIT helps providers and payers improve medical care and public health, lower costs, increase efficiency, reduce errors, and improve patient satisfaction, while also optimizing reimbursement for ambulatory and inpatient healthcare providers.

HIT consists of many types and formats of information systems along with technology peripherals such as scanners and printers. Some HIT may appear to be technically the same as regular office automation and business systems, but as an HCISPP, you must realize that HIT is not the same. HIT has important privacy and security concerns that must be addressed to ensure the secure use and transfer of healthcare information. The best information security practices used in other industries may not be appropriate for HIT. Understanding this and developing tailored approaches to delivering information privacy and security in healthcare is central to your success.

In this chapter, we introduced some of the HIT used. Major categories of HIT include electronic health records (EHRs), a central component of the HIT infrastructure. An EHR is a patient’s official, digital health record and is often shared among multiple healthcare providers and agencies. Other types of HIT in the healthcare organization are the patient health record (PHR), or the patient portal that an individual may use to track his or her own record of care. The electronic record sources feed into a health information exchange (HIE), which is a group of healthcare providers who agree to share data to improve patient care for their defined population.

EHRs are a system of systems that connect to and depend on interoperability with networked medical devices. Medical devices are special-purpose computing systems that are regulated by the US Food and Drug Administration (FDA). Some examples are picture archiving and communication systems (PACS) and patient monitoring telemetry systems in the intensive care unit (ICU). The privacy and security impacts of these classes of HIT are numerous, and you must be aware of them and address them. The potential for increased patient safety risk and patient harm are significant if medical devices are not properly protected.

Added to privacy and security risks are interoperability issues between systems. Information blocking or other forms of system incompatibility bring about a specific problem in HIT that relates to data availability. This, too, is an area where you will play a role in designing, implementing, and monitoring systems that can communicate securely.

We also covered data lifecycle management (DLM) in terms of how to maintain confidentiality, integrity, and availability as data is created, stored, used, archived, and destroyed by the healthcare organization. At any of these phases, there are important tools, techniques, and practices to help you protect the data. The use of data leads to a discussion of the sharing of data with external, third-party organizations. It is important to note that some third parties, such as cloud service providers, that deal with data on behalf of the healthcare organization may provide services to other organizations in other industries. These cases emphasize the need for all third parties to interconnect with healthcare organizations using technical trust models. In addition to the technical configurations and concerns, administrative controls such as memorandums of understanding and interconnection security agreements are an imperative.

Implementation and enforcement of the information privacy and security concepts described in this chapter will help your healthcare organization realize the benefits of HIT. There is broad consensus that HIT improves patient care and research, enhances provider practices, and reduces cost over the long term.

Questions

1.  You are provided a network vulnerability scan of the hospital network. There are numerous critical unpatched vulnerabilities on many of the devices. You work with the person who runs the centralized vulnerability patching team to develop a remediation approach that includes automated security patching of systems. Which of these steps would you take next?

A.  Contact system owners to advise them of the updates.

B.  Schedule the remediation patching after clinical hours.

C.  Exclude medical devices from the updates.

D.  Quarantine vulnerable systems per policy.

2.  An organization that facilitates the electronic sharing of healthcare information between providers and payers is a description of

A.  Health information exchange (HIE)

B.  Health insurance exchange (HIE)

C.  Health information establishment (HIE)

D.  Health insurance establishment (HIE)

3.  In using an electronic health record (EHR) with computerized provider order entry (CPOE), which is true?

A.  Nurses are permitted to change prescriptions when they see data entry errors.

B.  Insurers are able to suggest alternative medications or generic options in real-time.

C.  Patients with known allergies receive a contraindication alert prior to a prescription being submitted.

D.  Encryption enables providers to submit digital orders without any signature.

4.  You receive an overnight package to your data center. The invoice describes an encrypted hard drive containing contents of a physician’s office that is part of your healthcare network. There are directions for you to degauss the media and transfer it to the radiology department. Which phase in data lifecycle management would you consider the data?

A.  Archive

B.  Store

C.  Share

D.  Destroy

5.  Which of these is an external threat to the privacy and security of HIT?

A.  Hacking of a medical device implanted inside a patient

B.  Health information exchanges between organizations

C.  Cloud hosting organization disclosing closure of potential vulnerability

D.  Laboratory specialist contracted to work in the clinic who copies patient data

6.  Mainview Healthcare Systems has entered into merger discussions with Heart of Gold Healthcare. Each healthcare organization has an impressive HIT inventory, including EHRs, networked medical devices, and a significant presence for patients on the Internet through PHRs. You are the lead security engineer for Mainview. Which of these scenarios best depicts your main concerns at this point?

A.  The Heart of Gold EHR was implemented three years before your EHR. There is almost three times as much data to export into the disaster recovery storage systems.

B.  The EHRs are manufactured and supported by two competing companies. There may be a need for significant engineering to connect the systems securely.

C.  To connect the medical devices from Heart of Gold, multiple firewall rules must be implemented. These will expose Mainview to threats unlike any time before.

D.  Medical devices in Mainview are managed by a third-party biomedical firm with remote access to the network. Heart of Gold manages medical devices with internal staff and has expressed reluctance to allow any external, third-party access.

7.  Which of the following appropriate medical device security approaches would explain why your organization provides input and follows the FDA MedWatch services?

A.  Medical devices are out of scope for the organization’s information security incident response plan.

B.  Regulations mandate that medical device interoperability be maintained.

C.  Vulnerability management of medical devices is integrated into the organization’s information security program.

D.  International sources contribute to security approaches and most manufacturers are global.

8.  Which of the following security concerns would still be the responsibility of a healthcare organization that uses an EHR solution hosted by a cloud services provider that is proprietary to a customer of the cloud host organization?

A.  Patching

B.  Access

C.  Firewall

D.  Configuration

9.  In an organization that mandates third-party connectivity by way of a virtual private network (VPN), which of the following would you expect?

A.  Medical billing contract employee receives monthly charges for patient care via secure e-mail

B.  Healthcare organization employees use Infrastructure-as-a-Service cloud hosting for storage

C.  Patients provided with unique credentials to establish a secure web portal for access

D.  Outsourced data science team use BYOD and special security application to login remotely

10.  Which of the following is a set of documents that outlines expectations between two organizations to address items such as technical specifications and configuration responsibilities for interconnection?

A.  SLA

B.  MOU

C.  BAA

D.  ISA

Answers

1.  C. This illustrates the concept that even the best practices for information privacy and security in other industries may not be best for healthcare. The first step when dealing with a scan of the entire healthcare network is to make sure you can separate medical devices from regular office automation or business systems. C is the best option of those given. Medical devices may require special handling, especially legacy systems, but medical devices are regulated by law and good manufacturing processes after their sale. You will need to identify those on the report and exclude them from the initial remediation. Then you will need to develop a plan to remediate the medical devices according to organizational policy, manufacturer guidance, and any patient safety concerns. The medical devices need to be as secure as possible, and the rest of the healthcare network must be as protected from the vulnerable medical devices as much as possible. None of that should put patient care at risk or disrupt the mission of the healthcare organization. A would be acceptable, but simply advising owners would not address the risk to medical devices by pushing a security patch automatically. The eventual patching may be done at night when the healthcare organization is closed or there is minimal patient care activity, but B would not prevent medical devices from being patched and possibly disrupted. D is partially correct in that the guidance for medical devices and all networked systems should be covered in organizational policy that must be followed, but quarantine or isolation is very likely going to cause disruption to medical devices and will negatively impact patient care.

2.  A. More than just a play on words, it is important to distinguish the health information exchange from any other type of exchange. B is an actual exchange (or type of exchange) found in each US state in accordance with the Affordable Care Act. However, it does not support exchanging anything more than insurance information options for enrollees. Providers would not use a health insurance exchange to collect information about patients. C and D are not actual types of organizations.

3.  C. With the computing capabilities to reconcile numerous databases and transactions, EHRs provide near-instantaneous drug–drug contraindication alerts that improve patient care and safety. A is incorrect because nurses (excluding advanced nursing professions such as nurse practitioners) would not have authority to alter a physician’s prescription order. B is not typically a feature of EHRs, especially considering the variety of insurers that would require access. D is incorrect because encryption of the data would not remove the need for a signature (digital or otherwise).

4.  D. Degaussing will destroy the data on the hard drive. In degaussing, the electronic media is sanitized so that no remnants of data could be re-created from the disk. A degaussed drive removes startup files along with all other data. We will never know why the radiology department wants a useless hard drive. All other answers are valid phases in data lifecycle management, but degaussing is a step taken when information is determined to be obsolete.

5.  A. An implantable medical device hacked from an external source is the best example of an external threat to HIT. Along with the benefits of HIT, new information and privacy threats have emerged, some with internal sources and others external in origin. B is not a threat if the exchange has appropriate information security transfer controls in place. C is incorrect because, although cloud computing does introduce new threats, the disclosure and remediation of a vulnerability are normal operations. It is not the best example of a threat based on the actions the cloud hosting company appears to have taken. D is incorrect because it is an example of an internal threat to privacy and security through a third party. The contract employee is located within the organization and has access to the HIT network. Additionally, the fact that this party is copying data may be a required part of normal duties.

6.  B. Interoperability is the major concerns at this point, and this answer suggests possible challenges. A is not an obstacle but may be more of a need for financial projections to increase storage capability if disaster recovery and business continuity requirements call for the data to be maintained. C is also a normal course of business, and although the risks of more interconnections are real, the process of managing firewall rules is a normal course of business. The management of medical devices by internal or external staff, onsite or remotely, as depicted in D is something the organizations will need to address. Of the choices, D is not as urgent as addressing interoperability challenges, which will directly impact patient care.

7.  C. A successful approach to managing security for medical devices is to integrate them into the organization’s overall information security program. This will include monitoring logs and responding to alerts, of which FDA MedWatch is a good source, as part of the incident response plan. A is incorrect because these devices are within scope of the security incident response plan according to MedWatch. B is incorrect because the use of MedWatch is voluntary and would not focus on interoperability issues. D is incorrect because international sources would not have a connection to the important content that would be covered in FDA MedWatch.

8.  B. Access to the system and data will remain the responsibility of the healthcare organization, because the cloud service provider is probably not going to have the ability to determine authorized users and responsibilities. In most cloud computing environments, even in a Software as a Service (SaaS) relationship, the healthcare organization controls access. A is incorrect because as a hosted solution, the scenario assumes maintenance of the hardware and software is managed by the cloud services provider. C is also not likely the responsibility of the healthcare organization but would be part of the cloud provider’s infrastructure. D may not be a security control, but it is also not the right answer based on the scenario, because the healthcare organization probably has no ability to configure the system or application other than to customize screens or administer users.

9.  D. Of the options, this is the only one that is descriptive of a VPN connection with external access through a secure, dedicated connection. A describes a secure transfer to an external, third party but not via VPN. B is not a third party and does not describe a VPN connection, although the cloud-to-healthcare organization connection will be a secure connection. C involves patients, not third parties such as vendors, and the connection is web-enabled or certificate (PKI) based.

10.  D. Interconnection security agreements (ISAs) outline the technical and configuration details that will establish and secure the interconnections. A, a service level agreement, will focus more on the satisfaction of terms and conditions for security and performance. B, the memorandum of understanding, is an important document but it addresses business and operational expectations. C, the business associate agreement, in the United States, will contain significant points of responsibilities and expectations between the healthcare organization and its third party, but not to the specificity of an ISA, which would the complement BAAs.

References

1.  The ECRI Institute’s “Top 10 Patient Concerns for 2019” can be downloaded by registering at https://www.ecri.org/landing-top-10-patient-safety-concerns-2019.

2.  Browning, J. G., and S. Tuma. 2015. “If Your Heart Skips a Beat, It May Have Been Hacked: Cybersecurity Concerns with Implanted Medical Devices.” Southern Carolina Law Review, 67, 637.

3.  Kirk, J. 2012. “Pacemaker hack can deliver deadly 830-volt jolt.” Computerworld, October 17, https://www.computerworld.com/article/2492453/pacemaker-hack-can-deliver-deadly-830-volt-jolt.html.

4.  Newman, L. H. 2019. “A Model Hospital Where the Devices Get Hacked—on Purpose.” Wired, August 6, https://www.wired.com/story/defcon-medical-device-village-hacking-hospital.

5.  Beavers, J., and S. Pournouri. 2019. “Recent Cyber Attacks and Vulnerabilities in Medical Devices and Healthcare Institutions.” In Blockchain and Clinical Trial, 249–267. Cham, Switzerland: Springer.

6.  McLean, R. 2019. “A hacker gained access to 100 million Capital One credit card applications and accounts.” CNN Business, July 30, https://www.cnn.com/2019/07/29/business/capital-one-data-breach/index.html.

7.  Brewster, T. 2017. “Medical Devices Hit by Ransomware for the First Time in US Hospitals.” Forbes, May 17, https://www.forbes.com/sites/thomasbrewster/2017/05/17/wannacry-ransomware-hit-real-medical-devices/#41f1d7a425cf.

8.  Weiner, J. P., T. Kfuri, K. Chan, and J. B. Fowles. 2007. “‘e-Iatrogenesis’: The most critical unintended consequence of CPOE and other HIT.” Journal of the American Medical Informatics Association, 14(3), 387–388.

9.  The Joint Commission. 2019. “Sentinel Event.” https://www.jointcommission.org/resources/patient-safety-topics/sentinel-event.

10.  Scholl, M., et al. 2008. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. National Institute of Standards and Technology Special Publication 800-66 Rev. 1, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-66r1.pdf.

11.  Smallwood, R. F. 2018. Information Governance for Healthcare Professionals: A Practical Approach. Boca Raton, FL: Routledge/CRC Press.

12.  Donaldson, S. E., S. G. Siegel, C. K. Williams, and A. Aslam. 2018. Enterprise Cybersecurity Study Guide: How to Build a Successful Cyberdefense Program Against Advanced Threats. Apress.

13.  HealthIT.gov. 2019. “What is an electronic health record (EHR)?” https://www.healthit.gov/faq/what-electronic-health-record-ehr.

14.  HealthIT.gov. 2019. “Guide to Privacy & Security of Electronic Health Information.” https://www.healthit.gov/topic/health-it-resources/guide-privacy-security-electronic-health-information.

15.  AHIMA. “Fundamentals of the Legal Health Record and Designated Record Set.” Journal of AHIMA 82(2): expanded online version.

16.  HealthIT.gov. 2016. “What is a personal health record?” https://www.healthit.gov/faq/what-personal-health-record-0.

17.  Islam, S. R., D. Kwak, M. H. Kabir, M. Hossain, and K. S. Kwak. 2015. “The Internet of Things for Health Care: A Comprehensive Survey.” IEEE Access, 3: 678–708.

18.  US Food and Drug Administration (FDA). 2018. “Medical Device Overview.” https://www.fda.gov/industry/regulated-products/medical-device-overview.

19.  US Food and Drug Administration (FDA). 2020. “Cybersecurity.” https://www.fda.gov/medical-devices/digital-health/cybersecurity.

20.  US Federal Bureau of Investigation (FBI). 2015. “Internet of Things Poses Opportunities for Cyber Crime.” Alert No. I-091015-PSA. https://www.ic3.gov/media/2015/150910.aspx.

21.  US Food and Drug Administration (FDA). 2018. “Regulatory Controls.” https://www.fda.gov/medical-devices/overview-device-regulation/regulatory-controls.

22.  US Food and Drug Administration (FDA). 2020. “Classify Your Medical Device.” https://www.fda.gov/medical-devices/overview-device-regulation/classify-your-medical-device.

23.  Jansen, W., and T. Grance. 2011. Guidelines on Security and Privacy in Public Cloud Computing. NIST Special Publication 800-144. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf.

24.  Ponemon Institute. 2016. “The Economic Risk of Confidential Data on Mobile Devices in the Workplace.”

25.  Grand View Research. 2016. “Health Information Exchange Market Analysis by Setup (Private, Public)…to 2024.” https://www.grandviewresearch.com/industry-analysis/health-information-exchange-hie-market.

26.  The Office of the National Coordinator for Health Information Technology (ONC). 2020. HealthIT.gov: “Guide to Privacy & Security of Electronic Health Information.” https://www.healthit.gov/topic/health-it-resources/guide-privacy-security-electronic-health-information.

27.  Candeias, V. 2018. World Economic Forum: “How to unleash the enormous power of global healthcare data.” https://www.weforum.org/agenda/2018/12/global-healthcare-data-is-a-vast-untapped-resource-until-now.

28.  Kent, J. 2018. Health IT Analytics: “Big Data to See Explosive Growth, Challenging Healthcare Organizations.” https://healthitanalytics.com/news/big-data-to-see-explosive-growth-challenging-healthcare-organizations.

29.  National Institute of Standards and Technology (NIST) 2015. NIST Big Data Interoperability Framework: Volume 1, Definitions. NIST Special Publication 1500-1. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-1.pdf.

30.  Isaak, J., and M. J. Hanna. 2018. “User Data Privacy: Facebook, Cambridge Analytica, and Privacy Protection.” Computer, 51(8), 56–59.

31.  Arghire, I. 2019. “InfoTrax Settles with FTC Over Data Breach.” SecurityWeek. https://www.securityweek.com/infotrax-settles-ftc-over-data-breach.

32.  Joint Task Force Transformation Initiative. 2015. Security and Privacy Controls for Federal Information Systems and Organizations. NIST Special Publication 800-53 Rev. 4, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.