What protects confidentiality and PHI stored on or transmitted through a computer?

HITECH breach reporting

“The HIPAA Breach Notification Rule, 45 CFR §§ 164.400–414, requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information. Similar breach notification provisions implemented and enforced by the Federal Trade Commission (FTC), apply to vendors of personal health records and their third-party service providers, pursuant to section 13407 of the HITECH Act.

Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt. The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.

Valid encryption processes for data at rest are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices

Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated

The media on which the PHI is stored or recorded has been destroyed in one of the following ways:

Paper, film, or other hard copy media have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed. Redaction is specifically excluded as a means of data destruction.

Electronic media have been cleared, purged, or destroyed consistent with NIST Special Publication 800-88, Guidelines for Media Sanitization such that the PHI cannot be retrieved.”14

Protected Health Information

PHI is defined as any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a healthcare service such as diagnosis or treatment under HIPAA. The HIPAA Privacy Rule protects the 18 common identifiers listed as follows that are often associated with medical records:

Names

All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (a) the geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (b) the initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000

All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older

Phone numbers

Fax numbers

Electronic mail addresses

Social Security numbers

Medical record numbers

Health plan beneficiary numbers

Account numbers

Certificate/license numbers

Vehicle identifiers and serial numbers, including license plate numbers

Device identifiers and serial numbers

Web Universal Resource Locators (URLs)

Internet Protocol (IP) address numbers

Biometric identifiers, including fingerprints and voiceprints

Full face photographic images and any comparable images

Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by the investigator to code the data)

The HIPAA Privacy Rule prescribes 18 identifiers that usually need to be properly safeguarded under HIPAA requirements. However, when separated (as opposed to multiple single patient identifiers in aggregate), data identifiers may not necessarily be designated as PHI. For example, a patient’s name in isolation would not be considered PHI since the name alone is not directly connected with that individual’s other PHI and the name would be considered publicly available information. Healthcare organizations need to be very cautious since data sets and the 18 protected identifiers can quickly change context, thus requiring organizations to comply with HIPAA Privacy and Security Safeguards. In the previous example, a name (not associated with any other identifiers) was considered public information and not considered to be PHI. However, that same name associated with additional healthcare data (e.g., patient treatment and billing information) would be considered PHI and would be required to be protected in accordance with the HIPAA Privacy and Security Rules. Now that we understand the relationship between data sets, PHI, and the 18 protected identifiers, we need to discuss some specific mitigation strategies to ensure HIPAA compliance. These fall under the category of data de-identification.

Do not ignore individual states in breach investigations

A PHI breach at Beth Israel Deaconess Medical Center (BIDMC) in 2012 illustrates the fact that federal regulators are not the only officials eyeing your security efforts—or lack thereof. The Boston medical center had to pay $100,000 to the state of Massachusetts because it failed to protect the PHI and other personal information of nearly 4000 patients, as well as personal information of 194 state residents, including 102 BIDMC employees. This happened despite the fact that BIDMC had policies in place that required staffers to encrypt laptops and physically secure them. The incident resulted from the fact that an unauthorized person broke into a BIDMC physician’s office and stole his unencrypted personal laptop. According the office of Maura Healey, the state’s Attorney General “The laptop was not hospital-issued but was used by the physician with BIDMC’s knowledge and authorization on a regular basis for hospital-related business.” [14].

You are likely to see more states taking action when data breaches involving PHI are uncovered because the federal government is encouraging it. The HITECH Act gives state Attorneys General the authority to bring civil actions on behalf of its residents when they get wind of HIPAA violations. In fact, the Office of Civil Rights has even developed a training course to help AGs investigate these claims. In the words of the civil rights office, “OCR welcomes collaboration with SAG seeking to bring civil actions to enforce the HIPAA Privacy and Security Rules, and OCR will assist SAG in the exercise of this new enforcement authority. OCR will provide information upon request about pending or concluded OCR actions against covered entities or business associates related to SAG investigations. OCR will also provide guidance regarding the HIPAA statute, the HITECH Act, and the HIPAA Privacy, Security, and Enforcement Rules as well as the Breach Notification Rule.” [15]. Chapter 4: Risk Analysis will go into more detail on state and federal regulations that apply to PHI.

Despite all the high profile cases in which government authorities have imposed heavy fines on healthcare organizations, a recent analysis indicates that only a small percentage of providers who report breaches and found themselves on the federal “Wall of Shame” actually are fined. A recent report on more than 1140 large breaches from ProPublica, a nonprofit investigative journalism group, revealed that only 22 resulted in fines [16]. That translates into less than a 2% likelihood of being fined.

The same report did not, however, discover such laxness on the part of the California Department of Public Health, which imposed 22 fines in 2014 alone, and an additional 8 in January and February of 2015. One possible reason the federal government has penalized so few healthcare providers is because it is understaffed and overwhelmed. The Office only has about $39 million to spend and fewer than 200 staffers. That would also explain the long interval between the time a data breach is reported and the time a fine is imposed.

Nonetheless, the Office of Inspector General at the Department of Health and Human Services issued a rather severe critique of the OCR in 2013, stating that it has not carried out its responsibility to perform security audits outlined by the HITECH Act.

3.9 Protection of privacy of end-users

According to HIPAA regulation Electronic Protected Health Information (ePHI) consists of 18 different demographic parameters to recognize a user. The creation of ePHI aims to store, receive, or transfer health information electronically, keeping in mind the security rules or standards set by HIPAA. Confidentiality ensures that without adequate patient authorizations, ePHI is not disclosed. Integrity ensures that ePHI is accessed by relevant and approved parties who come under the healthcare organizations. Availability permits patients’ ePHI only if they follow HIPAA security standards. Examples of ePHI are name, address, email address, medical records, etc.

As mHealth applications’ usage erupts in the global landscape, the need for assuring no pilferage of information gathered directly or indirectly during the interaction is of supreme importance. The nature of diagnostic requires a close interaction in the cyber-physical space and therefore has a potential risk exposure of valuable information to the domains unintended for future hazards. The potential risk can be bifurcated in privacy-related and security-related domains. Therefore various techniques and tools for assessing security and/or privacy need to be closely assessed and evaluated for mitigating risk and creating a robust platform for interaction (Nurgalieva, O’Callaghan, & Doherty, 2020).

The majority of applications developed globally are based on two platforms: Android or iOS, depending on the end interface available to the consumer and the service provider, thereby enabling an extensive data transfer back and forth between both the medical professionals and patients. Therefore the reliability of secure third-party servers and trustworthy internet communication services is a critical cog in the development wheel of the mHealth applications in terms of customer experience and effective treatment (He, Naveed, Gunter, & Nahrstedt, 2014). The significant transition of the physical way of diagnosing ailment to a diagnostic setup in a virtual environment would also need a safe and secure payment structure with a hassle-free experience for both the professionals and the patients; henceforth the need for secured payment gateways and online financial transactional support with monitoring and governing authority is also a must for the mushrooming of this setup.

Owing to the global upsurge usage of mHealth applications for diagnostics and treatments through a seamless virtual experience digitally, a well-defined sequence of procedures can be utilized as a ready reference for both parties involved for substantial benefit. It can be an essential document for problem resolution dealing with data privacy, security, and confidentiality concerns. Moreover, a precise cut formulation of guidelines would also enforce trust in the interaction, and this will further foster the bond between the professionals involved with the patients. On analyzing the various source points of data security, privacy, and confidentiality, one can conclude that there is a significant amount of overlap in the mentioned three areas. Hence, reasonable documentation is, therefore, also required to distinguish between the three (Bhatnagar et al., 2020; Singh et al., 2020; Spigel, Wambugu, & Villella, 2018).

Health Insurance Portability and Accountability Act

Cloud providers and customers that handle protected health information (PHI) are required to comply with the security and privacy requirements established in support of HIPAA. The HIPAA security and privacy rules focus on health plans, health care clearinghouses, health care providers, and system vendors. HIPAA requires that PHI is sufficiently protected when entrusted to third parties, such as cloud providers. The level of security should be kept up to standard across all environments. HIPAA addresses administrative safeguards, workforce security, information access management, security awareness and training, security incident procedures, contingency plans, evaluations, physical safeguards (facility and user devices), and technical safeguards (access control, audit control and integrity, authentication, encryption).

Areas with Protected Health Information

The risk assessment for areas with protected health information (PHI) should address the multiple ways in which protected and privileged information can be compromised and how that information should be protected utilizing integrated physical and electronic security systems. The design should include access and audit systems to be applied, and where appropriate, to areas housing electronic and written PHI. Risks related to PHI are primarily related to electronic storage and transmission of PHI, secondarily the physical location of records and ease of viewing or accessing them and finally to the destruction of records related to PHI.

Working closely with the organizational privacy officer or other leadership with privacy oversight, the security representative should design and implement integrated protective measures, applied to both physical and electronic spaces. This should include signage, registration area design, furnishings to facilitate securing information and secured areas for equipment such as printers. Areas primarily utilized for the storage of health information should be designed with a penetration-resistant perimeter. Access to these areas should be controlled and restricted. Intrusion alarms should be utilized in areas not staffed at all times. Video surveillance systems for areas housing PHI should be in place, including waste disposal areas.

Citrix and HIPAA, Sarbanes-Oxley, FERPA

Application virtualization provided by Citrix products is functioning in all aspects of our information technology environment, including many organizations that are governed by federal and/or state guidelines. We will only cover the most well known to provide you with examples of how measures are being taken to secure information technology infrastructures.

The Health Insurance Portability and Accountability Act (HIPAA) was enacted by the U.S. Congress in 1996. This act requires the establishment of a national set of standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers.

The act also addresses the security and privacy of health data. The standards are meant to improve the efficiency and effectiveness of the nation's health care system by encouraging the widespread use of electronic data interchange.

The Privacy Rule of the act requires that reasonable steps must be taken by health care providers to ensure the confidentiality of communications with individuals. The Privacy Rule pertains to all Protected Health Information (PHI) including paper and electronic.

The Security Rule deals specifically with Electronic Protected Health Information (EPHI). It lays out three types of security safeguards required for compliance:

Administrative Safeguards

Physical Safeguards

Technical Safeguards

For each of these types, the rule identifies various security standards, and for each standard, it names both required and addressable implementation specifications. Required specifications must be adopted and administered as dictated by the Rule. Addressable specifications are more flexible. Individual covered entities can evaluate their own situation and determine the best way to implement addressable specifications. The standards and specifications are as follows:

Administrative Safeguards Policies and procedures designed to clearly show how the entity will comply with the act. These are your written documents providing direction for anyone using the information technology infrastructure, whether as an administrator or as a user.

Physical Safeguards Controlling physical access to protect against inappropriate access to protected data. Are the servers in a secured location?

Technical Safeguards Controlling access to computer systems and enabling covered entities to protect communications containing PHI transmitted electronically over open networks from being intercepted by anyone other than the intended recipient. Information systems housing PHI must be protected from intrusion. When information flows over open networks, some form of encryption must be utilized.

The Family Educational Rights and Privacy Act (FERPA) is a federal law that protects the privacy of student education records. This act applies to all schools and educational institutions that receive funds under an applicable program of the U.S. Department of Education.

The Sarbanes-Oxley Act of 2002 (SOX or Sarbox) is a federal law that was enacted in response to a number of major corporate and accounting scandals including those affecting Enron, Tyco International, and others. These scandals, which cost investors billions of dollars when the share prices of the affected companies collapsed, shook public confidence in the nation's securities markets.

The legislation establishes new or enhanced standards for all U.S. public company boards, management, and public accounting firms. It does not apply to privately held companies.

27.5 Security Analysis

In this section, we show that the proposed HIPS system satisfies the predefined security requirements [31, 37].

Privacy and Confidentiality: First of all, all PHI (and MHI) files are encrypted which prevents the storage server and other malicious parties to learn the content of the PHI, achieving both patient privacy and PHI data confidentiality. Second, the unlinkability property of the privacy requirement is guaranteed by having the patient, family, or P-device actively control the retrieval of the encrypted PHI from S-server and return plaintext PHI to the physician, based on the SSE and PEKS primitives, breaking the link present in Ref. [14] where the physician can directly query the server. Moreover, the distributions of the secret keys in privilege assignment and the nounce in emergency health information retrieval are through secure encryption schemes to provide confidentiality for sensitive messages. The confidentiality of the patient data shared between the delegator and delegatee to facilitate cooperation is assured by the PEKS primitive, which essentially protects patients' health data privacy. Furthermore, secret information contained in message exchanges remains confidential by using encryption schemes (i.e., ℋℐℬℰ, ℐℬℰ ).

Fail-Open: We developed family-based and P-device-based approaches as the backup mechanisms for emergency situations. Both approaches are effective in successfully retrieving the needed PHI in the absence of the patient and preserve the privacy properties as described above.

Access Control: The fact that in our HIPS system the physician must always request the patient, family, or P-device for accessing the PHI facilitates access control. The patient and family can reject inappropriate access requests by subjective judging. P-device relies on A-server as a trusted authority to verify the eligibility of the physician for accessing both PHI and MHI. As a result, only physicians with certain access rights can learn the content of PHI or MHI through legitimate requests. In addition, fine-grained access control has been ensured by the minimum-privilege delegation requirement. The goal of the delegatee is to ultimately access the PEKS-encrypted patient data with proper assigned role. However, in order to prevent other entities in a same role who are not delegated to access the data, the proxy signature-based basic access control has to be in place. By performing proxy signature verification, the verifier can be ascertain of an entity's delegation status.

Accountability: This requirement can be easily satisfied when either patient or family is executing the protocols due to the assumption we made earlier that possible sources of PHI leakage can be recalled. When the P-device-based approach is leveraged, the patient can check back his P-device after the emergency is resolved to obtain the records (RDs) created in emergency health information retrieval. RDs contain information on which physicians interacted with P-device at what times, necessary for the patient to contact A-server (with A-server's signature as proof), to obtain the traces (TRs, with physician's signature) from A-server as evidence to hold the physician(s) accountable. Even if the PHI is not leaked, the patient can check the keywords in the RDs to determine if the physician should be held accountable for searching any PHI other than appropriate.

Minimum-Privilege Delegation: This requirement is specially treated with the fine-grained access control. The role-based delegation is too general to restrict the delegated privilege to be precisely minimum necessary, which is the reason to use the PEKS-based access control. Through encrypting the exact patient data to be accessed by the delegatee, the delegator actively and effectively restricts the privilege of the delegatee to only those data intended or PEKS-encrypted for later retrieval.

Adaptability: By using the role-centered approach for both delegation and revocation, instead of more specific entity-based approach, the changing credentials or availability of a delegatee is fully dealt with by the policy server of the delegatee's organization, without intervention of the delegator or interruption of any delegation and revocation procedures, which are thus transparent to the delegator.

On-Demand Revocation: The advanced revocation mechanism based on dynamic accumulators is dedicated to handling on-demand revocation. Through the update of the accumulated values performed by the delegator and maintained at the storage server, the delegatee with a revoked public key will be automatically restrained from further access. This technique is also very efficient in that the storage cost incurred by the accumulated values is independent of the number of revoked entities or the total number of entities in the delegator's dynamic group.

Availability: When the patient or family is available, the S-server that stores the desired PHI can be looked up using the keyword index. In the protocol description, we implicitly assumed that the S-server is inside its parent A-server's domain so that the standard IBC suffices. As mentioned in system setup, the hierarchical IBC (HIBC) will be used if the S-server is outside its parent A-server's domain. The patient can be provided a temporary key pair (similar to TPp/Γp) at level 3 of the hierarchical tree, enabling the patient to interact with any S-server throughout the country. In emergencies, the interactions between the physician or P-device and any A-server can be carried out similarly. The HIBC infrastructure ensures the availability of desired PHI wherever the PHI is stored.

Data Integrity: Since the PHI and MHI are encrypted, no one except the patient him/her self can perform any meaningful modifications. Although the actual modifications to the PHI are performed by an authorized physician, the patient must agree and retrieve the plaintext PHI for the physician. Note that it is technically possible for the family and P-device to retrieve the plaintext PHI for a physician to modify. However, the family or P-device would not be able to store the modified PHI back, which involves a file collection update and can only be performed with the patient's secret key not distributed to any other entity. The protocol message integrity is ensured by including HMAC or digital signatures in the message exchanges. Moreover, the integrity of both the stored patient data and the exchanged messages during interactions is guaranteed by either signature schemes (i.e., ℋℐDS, ℐℬS), or message authentication code (i.e., ℋℳAC).

Authenticity: This objective is achieved leveraging cross-domain and in-domain authentication based on hierarchical ID-based signature ℋℐDS and standard ID-based signature ℐℬS, respectively.

Another requirement on the delegation in distributed EHR system is the onward delegation [15], where the appointed proxy signer is able to further appoint other proxy signers in order to complete a task, thereby forming a delegation chain. Since our EHR system is concerned with the sharing of sensitive patient data, it is inappropriate to enable delegation chain which would be in violation of our fine-grained access control rationale. Intuitively, fine-grained access control is developed due to the delegator's insufficient control over the delegatee's access to patient data. If the delegation chain is allowed by the delegator, the proxy signer can further delegate an entity without the delegator's awareness. In other words, the delegator voluntarily surrenders some of his/her control power. In some other application scenarios, e.g., cooperative research for statistical studies, where patient data have been preprocessed to remove sensitive information, the delegation chain can be adopted to support onward delegation and alleviate the burden on the delegator. In this case, our proxy signature-based delegation can be easily adapted to provide onward delegation mechanism [15].

4.2.1 HIPAA

As previously stated, the Health Insurance Portability and Accountability Act of 1996 establishes federal standards for protecting patients’ health information. Entities that have access to medical history, such as doctors, dentists, hospitals, and health insurance companies, are required to protect the privacy of patient information by adhering to prescribed guidelines (HIPAA Health Insurance Reform: Security Standards; Final Rule, 2003).

The law requires that any entity possessing Protected Health Information (PHI) must “protect against reasonably anticipated threats to the security or integrity of the information,” according to the US Department of Health and Human Services. Note that PHI and PII are similar in that they refer to an individual’s private data. PHI extends that concept to include medially related information, such as lab results, diagnosis, treatments, medications, and prescriptions. There is no official HIPPA certification for business entities, including cloud storage providers. The current best practice is to provide authorization and access controls, and to encrypt data in motion and at rest. It is “felt” that adopting these best practices helps address the obligation to protect storage of PHI.

There are four areas of HIPAA that directly impact the storage of PHI in the cloud:

Policy – Establish access control policies, procedures, and technology to restrict access to PHI by authorized personnel only

Physical Security – Control physical access to areas where PHI is stored

Technical Security – Implement technical security mechanisms, such as encryption, to protect PHI data in motion and at rest

Backup – Establish appropriate data backup, disaster recovery, and emergency operation strategies

HIPAA applies to “covered entities,” which is defined as (1) health plans, (2) health care clearinghouses, and (3) health care providers who electronically transmit any health information. These entities are bound by the privacy standards even if they contract with others organizations, called “business associates” to perform some of their essential functions. The law does not give the Department of Health and Human Services (HHS) the authority to regulate other types of private businesses or public agencies through this regulation. For example, HHS does not have the authority to regulate employers, life insurance companies, or public agencies that deliver social security or welfare benefits.

Most health care providers and health plans outsource some of their health care activities and functions. They often use the services of other persons or businesses. The HIPAA privacy rule requires that a covered entity obtain satisfactory assurances from its business associates that the associate will appropriately safeguard the PHI it receives or creates on behalf of the covered entity. These assurances must be in writing, whether in the form of a contract or other agreement between the covered entity and the business associate.

Cloud service providers are considered business associates under the HIPAA privacy rules. A covered entity’s contract with its business associate must:

Describe the permitted and required uses of PHI by the business associate.

Provide that the business associate will not use or further disclose PHI other than as permitted or required by the contract or as required by law.

Require the business associate to use appropriate safeguards to prevent use or disclosure of PHI other than as defined in the contract.

If a covered entity knows of a breach or violation by the business associate of the contract, the covered entity is required to take reasonable steps to remedy the breach or end the violation, and if such steps are unsuccessful, to terminate the contract with the business associate.

HIPAA specifies the overall general requirements for covered entities as it pertains to protecting PHI. These are followed by a set of administrative and technical requirements, which can be either required or addressable. If an implementation specification is described as “required,” the specification must be implemented. The concept of “addressable implementation specifications” was developed to provide covered entities additional flexibility with respect to compliance with the security standards. In meeting standards that contain addressable implementation specifications, a covered entity must do one of the following for each addressable specification:

Implement the addressable implementation specifications

Implement one or more alternative security measures to accomplish the same purpose

Not implement either an addressable implementation specification or an alternative

The covered entity’s choice must be documented. The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. This decision will depend on a variety of factors, such as the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered, as well as the results of the risk assessment on which the decision was based (HHS, 2014).

Security infrastructure

As with other technologies, we’re not going to spend time getting into the details of network, server, or storage security. We are going to discuss overall infrastructure security as it relates to BC/DR in a healthcare organization. However, items that should be on your list are things like data loss prevention technologies, e-mail security and encryption, data encryption (data at rest, data in transit), access control lists, group policies, firewalls, DMZs, intrusion prevention and detection systems, and related technologies your organization has implemented to keep data safe.

From the data presented earlier, it’s clear that PHI and financial data (credit card, insurance information, patient insurance identification data, etc.) are targets for attackers. When data for your organization are compromised, you have a disruptive event that has to be addressed and remediated. Throughout, we’ve focused on physical events such as fires and earthquakes, but in this chapter, we’ve pointed out numerous logical threats that can be seriously disruptive to your business and which must be addressed in your planning. When performing your BIA and risk assessment phases, you must ask and answer questions such as:

What data do we have that might be vulnerable to current threats (SQL injections, for example)?

How would our systems and processes be impacted if we had to contain or take a system or set of data offline to investigate a malware infection?

What alternative systems could our clinical staff use in these events? What backup plans should patient care providers have?

How would we determine if the threat was addressed and stopped?

How would we determine if any PHI or PCI data were breached?

How would we determine the scope of the impact and appropriate remediation steps?

What other parts of the business would be impacted if any of our Tier 1 or Tier 2 applications were compromised? How would we respond?

What plans do we have for recovering from this type of disruption?

What function would our incident response team play and what would their scope of work be?

Who would we have to notify and in what order?

As you can see, the list can go on, but these are the same kinds of questions you have to ask in the aftermath of any business disruption or disaster event. The difference is logical threats and events are less tangible and are sometimes harder to think through. Addressing a fire in the data center is fairly well defined; addressing a malware outbreak on a virtual server running three different applications is different.

Real World