Security and Privacy
Considerations in the Electronic
Health Record (EHR)
Abstract
This document presents an overview of some of the security and privacy considerations to be factored into EHR system design and operation. The content of this document serves to provide representative examples of managing the security and privacy of certain types of sensitive data in an Electronic Health Record (EHR) system. Data discussion touches on data in motion (processing, transmission) and data at rest (storage, destruction).
The content of this document is limited in scope and is not intended to be an exhaustive discussion about the subject area. The information presented is based on our experience in the healthcare industry and EHR systems in general. FOR QUESTIONS RELATED TO THE OPERATION OF EHR SPECIFIC PRODUCTS PLEASE CONTACT THE OEM DIRECTLY.
Introduction
This document is not intended to be an Electronic Health Record (EHR) all-topic treatise on EHR system design best practices as they relate to security and privacy and EHR records. The scope of that topic far exceeds what has been captured in this brief point-topic paper.
The document is intended to provide some high level security and privacy insight that affects EHR system design considerations. In addition, the document touches on some of the other areas being confronted by EHR system designers.
It must be noted too that the use of strong encryption algorithms is critically important to the end-to-end handling of data. Encryption of data in each of its states (storage, processing, transmission and destruction) is one remedy. EHR Security and Privacy Frameworks
All certified Electronic Health Record (EHR) systems are designed to incorporate Security and Privacy frameworks. These frameworks are of necessity, as EHR systems are not only designed to ensure proper controls are instilled for the handling of electronic Protected Health Information data (PHI), but also of the operating system, applications, utilities,
communication devices and the physical platform. For discussion purposes in this paper, ‘handling’ of data within the context of the EHR is collectively described as being focused on data in motion (processing, transmission) and data at rest (storage, destruction).
But not all data are handled equally. By law, some health information must be afforded special protections or require a higher degree of security.
Accordingly, system features and operational practices must be incorporated into the EHR system design. Collectively, these help to ensure protections of sensitive information and afford assurances that sufficient safeguards shield this information.
A legal, moral, and ethical duty also exists to protect all sensitive
information by ensuring that security and privacy safeguards are in place, enforced, and monitored.
Designers especially must be aware of these ‘high-risk’ groups to ensure electronic systems do not include features and functionality that increase risk of inappropriate use or affect safeguards for sensitive information
Categories of PHI That May Warrant a Higher Degree of Security in an Electronic System
All data should be considered sensitive, but some data are more sensitive than others. More sensitive health data relates to conditions, tests, and records of high-profile patients, minors, and in general terms, those vulnerable. A persons DNA serves as one example. If compromised, a person’s DNA cannot be changed like a password. Implementing security features for such categories can present challenges in EHRs because desired functionality may not be present in all hardware or software, or simply may not be fully evolved. The following categories provide examples.
EHR, HIE and IT Risk Management
Logical and reliable methods for authenticating patient identity warrant special security because they directly relate to delivering quality care and improving patient safety.
Just as the Internet is comprised of heterogeneous systems, so too are healthcare systems. The variability and incompatibility of patient
identification systems in healthcare facilities is a two edged sword. On one side, the local uniqueness tends to be a desired attribute, based in part on needs and financial consideration. Emphasis must be added here that when these systems were designed, they probably weren’t designed with Health Information Exchanges (HIE) being brought on line. Consequently, the data distribution view was vertical (within a hospital) and not horizontal (shared across HIE). A system of identifying patients between entities must exist for interoperability to occur. Currently, there is no record-to-record matching standard in the industry.
Safeguarding patient information is critical to preventing identity theft, medical identity theft, fraud, and abuse. Improved physical and logical access control systems are part of the answer; however, the solution must embrace and incorporate Information Technology (IT) risk management at the enterprise level.
This may seem difficult for any number of reasons, however absent this need incurs a major shortcoming in EHR system design. Protection of data must be end-to-end and nothing less.
Think of a teeter-totter, when properly balanced it enables all parties to
The system design must accommodate not only technical solution supported with point-product, but must also incorporate governance from the top of the pyramid down. It must be pervasive, penetrating through the layers past the technical point safeguard to the individual user and vigilance. Top to bottom, policy, procedure, safeguard to vigilance. Your firms EHR will need to ‘transact’ with another firms EHR. Who wants to be alone on the teeter-totter?
Special circumstances may arise in which patient identification or access to individual patient records may require anonymity or special precautions, such as in the case of celebrity or high-profile individual. This may also be of necessity due to workplace privacy, a domestic violence incident, child or vulnerable adult abuse, litigation, organ donor program participant, or prisoner. In such cases, EHRs should enable use of a “record hold,” de-identification mechanism, access restriction, or alias to afford greater protection for a specified period of time.
Diagnosis or Condition
The law affords special protection to certain diagnoses or conditions. EHR system design must be able to identify and manage these types of data appropriately.
Mental health records are generally protected at a higher level of confidentiality, as they may contain a patient’s innermost personal information. Many of the individuals receiving service for mental health issues are vulnerable. Every individually identifiable piece of information must be protected, and EHR design must be suitably, and in accordance with regulation, be protected.
HIV/AIDS and sexually transmitted diseases is another category with special privacy concerns. Public health reporting of these conditions is required, and the secure transmission of the information is a special consideration when working with electronic data. When releasing HIV/AIDS records for other purposes, it is necessary to identify testing and treatment for these
conditions through the use of flags or warning messages. An electronic system should facilitate exclusion or segregation of HIV test results to protect against release without appropriate consent from the patient. Ideally a system would also flag treatment of HIV/AIDS or a sexually
transmitted disease when producing copies of records. When permitted to be released by the patient, the Privacy release should also be securely but
Substance abuse and chemical dependency records require special consideration beyond what has been identified for mental health and HIV/AIDS records. EHR systems must provide mechanisms that enable
facilities to manage the extra layer of protection for this information required under 42 CFR, Part 2, particularly for release of information purposes.
Release of these records requires special authorization clearly indicating the patient’s consent. When released, these records must include a written statement prohibiting redisclosure or repurposing by the recipient.
Patients have a right to revoke an authorization to release records in writing or verbally, and institutions must have mechanisms to track and comply with this requirement. Records in this category are not released in response to a subpoena unless accompanied by the patient’s signed consent or valid court order. Architecting the system so these consents or court orders are ‘zoned’ and stored separately from the data is critically important.
In an acute care environment or multispecialty practice the security of records is challenging. EHR systems must have the ability to segregate any records related to treatment of substance abuse and chemical dependency. Treatment of these conditions typically encompasses multiple medical
specialties and documentation types. EHR systems require continued development of functionality to manage security, add levels of security, block access to specific notes or lab results, track versioning, and mask sensitive entries for release of information.
Forensics
In addition to the basics of security and privacy noted, forensics comes to play. For the EHR system to even ‘boot-up’ it should be required to be running Network Time Protocol (NTP). Various levels of NT stratum may be applied, with stratum level 2 or better being applied (access permitting). This is important when reconstructing audited events from journals and logs, especially when it is necessary to delve into breach related details. It is recommended that NTP be run on all systems in the enterprise which connect with the EHR, and likewise, within the practice.
Two other areas benefitting from the use of NTP is that of Incident Response and Business Continuity Planning/Disaster Recovery, both of which are
mandated under HIPAA. Circumstance & Category
related clinical documentation a high-risk category. Abortion, family
planning, and genetic testing are controversial due to personal and religious beliefs and insurance qualifications. Individuals, particularly public figures, are often scrutinized and harassed by the media for details regarding cosmetic surgery. EHR system designers should focus on increasing the security of this category to protect patient privacy and livelihood.
Traceability
Electronic systems should enable the core security features of role-based access, passwords, and audit trails. It is also recommended that aliases or alternative account numbers be assigned to individuals undergoing special procedures or tests such as the ones listed here. The EHR must be able to connect the alias or alternative account number back to the patient’s legal name and account number in a secure fashion to ensure the individual has a complete medical record and to enable accurate billing while still protecting the privacy of the patient.
Ultra-Sensitive Information
Genetic testing and DNA is especially sensitive. As previously noted, unlike a password, compromised DNA cannot be changed.
The Genetic Information Nondiscrimination Act of 2008, signed into law in May 2008, prohibits discrimination on the basis of genetic information with respect to health insurance and employment. Additionally, over 40 states already have enacted legislation related to genetic discrimination in health insurance, and over 30 states have adopted laws regarding genetic
discrimination in the workplace, according to the National Human Genome Research Institute.
The Council for Responsible Genetics notes that “in all cases, state and federal laws have primarily addressed the unlawful use of genetic data, side-stepping the question of whether employers and insurance companies should have access to genetic information in the first place.”
How all this translates to EHR and systems design also needs to be considered with respect to security, privacy, accessibility.
Consent & Custody
Issues of consent and custody may require the unique handling of health information if the patient is unable to consent to disclosures either
include wards of the state, incapacitated or incompetent individuals, inmates or detainees, minors, minors in a custody conflict, and parties involved in adoptions. Records of the deceased are also included in this category.
Parents, guardians, or a designated individual who represents the interest of the patients that fall within this category are required by law to verify their right to access health information. EHR system designers must account for this and incorporate appropriate provisions and protections in systems. Inmates or detainees are unique in that they may lose rights to obtain their physical medical record under HIPAA. They are not permitted to have copies while they are incarcerated because of the possibility of danger to another inmate or staff member. If the facility deems this potential danger could occur, it must note the reason for withholding the record. Inmates have the ability to view and communicate their health status with their healthcare provider. After release from incarceration, the detainees regain the ability to receive copies of their health information. Accordingly, provision for EHR ‘record-hold’ for an extended period (possibly to the death of the person in question), and then release of that information to the appropriate legally permitted entity must be factored in EHR design.
Special Circumstance
EHRs must have the functionality to adequately secure records for minors involved in child custody conflicts or adoptions. Recommended practices for protected access to health information of minors include:
Identifying the necessary process. For example, the Indian Health
Service guideline for release of information to insurance or law firms requires the person acting in loco parentis (collectively, “parent”) to obtain the information and then disclose to a third party. Legal
representatives should be consulted regarding guardianship, powers of attorney, and other related issues.
Identifying the individual that has authority to access records.
Implementing alerts or flags to identify patients in this category.
Creating high security lockout access for these files with a VIP access
code.
In most situations, minors must give consent prior to release of their substance abuse records.
Research
Data generated, collected, and reported in support of clinical trials by a clinical investigator at an investigative site are source data. They may be found in progress notes, patient diaries, orders, ECGs, x-rays, lab results, and other ancillary test results maintained by the healthcare facility as part of the patient’s medical record.
Analysis of the data by the clinical investigator and study sponsor may lead to decisions about specific treatments (e.g., a drug’s efficacy and safety). These data, when captured and stored electronically, are subject to FDA rules, specifically 21 CFR Part 11, which outlines security and electronic signature requirements for research records and research source
documentation.
In addition to security practices already recommended for EHRs in general (such as audit trails and role-based access controls), organizations should employ technical security features that identify, protect, and authenticate research records. These features include alerts to identify patients who are research subjects and clinical trial participants and unique document types for research notes and research consents.
EHR system designers should leverage electronic signatures (21 CFR Part 11 standards) and enable available features such as unique ID and password entry at the time of each signing. Signature manifestations should include the printed name of the signer, date, time of signature execution, and meaning of the signature (such as approval or authorship or other). System Considerations for High-Risk Data
EHR system designers realize they must offer product that offers security features consistent with targeted market needs. EHR design must have the ability to limit access and provide screening controls to only those staff working directly with the patient or those with administrative responsibilities (such as risk management, legal, and HIM). Screening controls should
include the ability to redact sensitive information that should not be disclosed.
User activity must be tied to a unique user identification to reliably maintain an audit trail of navigation, documentation, and other activities. Audit trails are essential in tracking user activities such as document viewing, manual printing, addendums, retracted or restored documents, and follow-up
or otherwise electronically signed. Ideally the EHR system ‘root’
administration account limits the number of administrators to no more than three, with one being ‘super-root’ and the other two assistant
administrators. Each account should have a unique user ID and password. Forms and Releases
EHR system design security benefits from a system’s ability to map a record to a scanned copy of a release, power of attorney, or other legal document specifying the privileges of a personal or authorized representative.
Architecturally ‘zoning’ these types of records separate from the data related to these records should be incorporated into the design. EHR system design should ideally require a user to enter justification for any manual printing as well as prevent unauthorized screen printing and unauthorized download to portable storage devices. A two person rule (segregation of duties) also strengthens security and privacy.
Sentinel Event
In the instance of a sentinel event or other pending legal process, the EHR should have the capability to move the record into a “restricted unit,” which immediately locks down access and restricts it to personnel directly involved in the review, such as legal and IT risk management. Such functionality protects the record from being viewed by staff members curious about the incident details. The record can be “opened” to a particular staff member for a brief period of time if additional documentation needs to be entered, but the access should be limited.
EHR security features should also provide permitted users (Internal
Audit/Security) with the ability to track on-line-real-time security issues such as inappropriate access and printing. Flags and alerts in the design should provide a mapping of elsewhere in the EHR record data are located.
EHR and HIM Professionals
HIM professionals, entrusted with the protection of data, must ensure that a given EHR system includes functionality that will enable the organization to meet its regulatory and operational requirements.
When it comes to protecting high-risk information, HIM professionals should work with Information Security/Internal Audit to identify the location of that information in the organization and verify state-specific guidelines related to
the categories. A risk register (electronic in the EHR system) ideally should be available and used.
As the emphasis on the privacy and security protection of information continues to increase, in both public and professional sectors, EHR vendors are enhancing security features in their systems to accommodate sensitive information handling requirements.
Conclusion
A wide variety of EHR systems are available on the market today, some better than others. Decisions about which EHR system is best suited for each individual environment is an open question, one that each organization purchasing or leasing an EHR must answer. Cost, ease of use, high
availability, fail back (Disaster Recovery as well as Incident Response), scalability, and manageability for resources and applications all come into play. Overlaying these, security and privacy.
Unfortunately for EHR users, few if any have had the opportunity to work directly with the team that is responsible for designing an EHR. It is no small task and requires teams of individual specialists to ‘make it happen.’ The security and privacy framework your vendor chose to implement will dictate how your system may (or may not) accommodate some of the referenced considerations in this paper. Ultimately, the vendors apply for, and more often than not, receive a stamp of approval from the certifying body to release the EHR to market. And that is where the real security and privacy is tested.
One last note. The author is a believer in end-to-end robust encryption. It helps ensure the user on a day-to-day basis and especially so in the event of breach, with data properly encrypted, far less ramifications will be faced than that of the firm that chooses not to encrypt (data in the clear). We all read about that happening far too often today.
Questions or Comments
Please let us know what you thought about this article. Health Compliance Partners tries to bring what is thought to be relevant, timely and user beneficial information to market. Your insight is appreciated. Please contact:
© Health Compliance Partners 2012
Health Compliance Partners St. Petersburg, FL
33702
Produced in the USA 07-12
All rights reserved.
Health Compliance Partners makes no
representation or warranty regarding third party product or service including those under other names or designations.
Health Compliance Partners, the Health Compliance Partners logo, Compliance with Assurance, and Compliance Guardian are trademarks of Health Compliance Partners, LLC, in the United States and/or other countries.
All products referenced may be trademark registered or trademarks of their respective company.
Information about EHR products is obtained from the manufacturers of those products or their published announcements. Health Compliance Partners has not tested those products and cannot confirm the performance, compatibility, or any other claims related to these products.
Questions on the capabilities of EHR products should be addressed to the suppliers of those products. Therefore, no assurance can be given that any system or individual user will achieve regulatory compliance or conformance equivalent to those stated herein.
Health Compliance Partners reserves the right to change specifications or other product or service
information without notice.
Health Compliance Partners PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in certain transactions.
