“Securing PHI shouldn’t get in the way of saving a life.”
In a hospital, a one-second delay can cost a life, so immediate access to patient data is critical. However, balancing the need to access medical data while securing patient health information (PHI) isn’t an easy task. This paper presents a use case showcasing how a healthcare organization implemented a sensitive data governance solution that safeguards PHI without forcing practitioners to change the way they work.
Executive Summary
A healthcare professional’s need for timely, easy access to patient health information is at odds with the traditional approach to protecting such information by “locking it down.” That approach, which increases security by restricting access, is so common that it has become synonymous with IT security. This belief has led some healthcare professionals to erroneously believe that IT security is antithetical to good medical practice.
This paper describes the structural challenges associated with managing and securing digital patient health information. It presents an in-depth use case showing how a healthcare organization can implement a solution that safeguards Electronic Protected Health Information (ePHI or PHI) without forcing practitioners to change their procedures. With such a solution, the twin goals of PHI security and patient care become complementary, not competitive.
Challenge
The frequency and sophistication of data breaches in the healthcare industry have increased exponentially, along with the volume of exposed records and financial losses resulting from breached records. Data from the healthcare industry is regarded as being highly valuable. This has become a major lure for the misuse and pilferage of healthcare data.
In the past three years, the average cost of a data breach in healthcare grew 53.3%. Further, healthcare breaches are the most expensive of any industry, with an average cost of $10.93 million per breach in 2023.1 The main causes of healthcare data breaches are hacking/IT incidents, with unauthorized access/disclosure incidents also commonplace.
The security rules in the Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) require Covered Entities to prevent data-at-rest PHI leaks, but systemic obstacles in the healthcare industry regularly result in such leaks.
Securing PHI
Consider the following events from recent years:
- In January 2015, in one of the nation’s biggest data breaches of all time, health giant Anthem notified some 80 million of its members and employees that it had been the target of a cyberattack. Hackers swiped Social Security numbers, addresses, dates of birth, income data, and other highly personal information. Anthem faced several civil class-action lawsuits, which were settled in 2017 at a cost of $115 million.3
- In June 2019, American Medical Collection Agency, or AMCA, a medical debt collection company announced that an unauthorized user gained access to AMCA’s internal system from August 1, 2018 through March 30, 2019, exposing the personal data of over 21 million individuals, including Social Security numbers, payment card information, medical records, and more. AMCA failed to detect the intrusion, despite warnings from banks that processed its payments. In 2021, AMCA settled a lawsuit filed by 41 state attorneys general for up to $21 million.4
- In July 2023, health giant HCA Healthcare announced the theft of unencrypted identity and medical information from HCA’s computer systems, which could impact more than 11 million people. A class action lawsuit has been filed, claiming that HCA ”did not use reasonable security procedures and practices appropriate to the nature of the sensitive information it was maintaining” for its patients and customers, such as encrypting the data or deleting it when it’s no longer needed.5
- In May 2023, Managed Care of North America (MCNA Dental) – a provider of dental benefits and services for state Medicaid and Children’s Health Insurance Programs – reported that a cyber incident had impacted 8.9 million individuals. Information taken included protected health information such as names, addresses, telephone numbers, email addresses, birth dates, Social Security numbers, driver’s license numbers, government-issued ID numbers, health insurance information, Medicare/Medicaid ID numbers, group plan names and numbers, and information related to the dental and orthodontic care provided. A $10M ransom was demanded by the hackers to return the data. When this wasn’t paid, they published the stolen data on the open web.6
Healthcare organizations have largely succeeded at restricting PHI access to low-level employees (e.g., interns, billing staff and nurses) through their Health Information System (HIS) consoles. These staff members are not allowed to export or save PHI outside the HIS. In contrast, hospital and department administrators, doctors, managing nurses and administrative managers tend to have less restricted access to patient health information. Administrators, practitioners, and managers regularly read, write and export PHI to laptops and desktops in Excel documents and other reports. These files sit like landmines on hospital system’s workstations, e-mail servers, and laptops, waiting to be breached.
Balancing the Need to Access Medical Data with Securing PHI
A typical patient profile or record includes a name, address, date of birth, contact information, social security number, medical record number, ICD or CPT codes, medication, expected discharge dates, and referral and insurance information. Additional information may include Drug Enforcement Administration (DEA) numbers, National Provider Identifier (NPI) numbers and Personal Identification Numbers (PINs). Patient Information stored in a centralized HIS is usually secure. However, not all data stays within the confines of the HIS.
In fast-paced, high-stress hospital environments, timely access to patient information can mean the difference between life and death. Often the HIS console was either not sufficiently accessible or could not perform the custom functions required by medical and billing staff.
Consequently, healthcare practitioners and administrators regularly export information from the HIS to make it more easily accessible. In contrast to secured centralized storage, such as in the Spirion Enhanced Analytics (SEA) data warehouse, these copies are often saved on insecure computers and are shared as internal e-mail attachments. Old copies of PHI are often overlooked and forgotten until they leak. And while precautions like enabling full disk encryption can reduce the risk of some data leakage due to lost or stolen endpoints, they do nothing to protect the data from exfiltration by malware or ransomware occurring while the user is logged into the endpoint.
Further, healthcare providers have been aggressively acquiring independent physician owned medical practices, which often lack the safeguards that larger institutions have put in place.
Continuing large-scale data breaches have brought data protection and data loss issues to the forefront of information security conversations. Increasingly, data protection isn’t achieved only by preventing adversaries from gaining access to or exfiltrating data from data stores. To successfully protect data stores, organizations have come to realize that they need to secure sensitive stored data, and classify that data to apply the appropriate security controls.
In response to HIPAA privacy and security rules, several healthcare systems and hospitals have implemented Spirion Sensitive Data Platform (SDP) and Spirion Sensitive Data Watcher (SDW) to find and protect PHI outside of controlled medical records systems. The use case in this document is based upon the actual experience of several SDP customers in the healthcare industry, and takes place within a representative but fictional healthcare system, IntraSystem Regional Healthcare (IRH), and a representative but fictional IRH hospital, Big City Medical Center (BCMC).
IRH is a regional hospital system comprised of hospitals, urgent care centers, homecare and hospice, lab services, radiology and occupational health clinics, including BCMC. BCMC suffered a data breach one year ago. In response to the breach, BCMC and IRH officials conducted a HIPAA risk analysis.
The remainder of this paper examines how PHI data leaked out of IRH’s secure HIS during the regular course of handling patient data, why Spirion SDP was necessary for them to govern sensitive data, and the key benefits IRH realized from their SDP implementation.
IntraSystem Regional Healthcare Use Case
IRH is a regional hospital system of one dozen hospitals and other services. All healthcare facilities store information in IRH’s centralized HIS.
BCMC is a 750-bed hospital in the IRH network, specializing in cardiology, cancer care, orthopedics, oncology, and stroke care. All IRH locations, including BCMC, have well-established procedures and training that do not allow lower-level employees such as interns, nurses and billing staff to save or export PHI from the centralized Health Information System.
However, BCMC medical practitioners and administrative managers. such as surgeons, doctors, managing nurses, billing managers, supervising radiologists, physicians, and managing pharmacists are allowed nearly unlimited access to subsets of PHI and regularly export various PHI fields from the HIS to conduct analysis and issue reports.
Complying With HIPAA and HITECH without Impinging on Patient Care
Medical practitioners can become frustrated by the conflicting mandates to provide patient care and guarantee data security. Unfortunately, traditional IT security practices that limit access to vital patient data or impede patient examinations and communications are counterproductive and amplify medical practitioners’ aggravation.
However, when medical and administrative staff are provided with the right tools to mark data as sensitive and when doctors are aware of the location of PHI and are empowered to decide the most appropriate remediation action based upon their professional experience, the twin goals of PHI security and patient care become complementary, not competitive.
STAKEHOLDERS
Here are the departments and stakeholders involved in this use case.
Stakeholder/Concept | Description | Access to HIS |
Health Information System (HIS) | The centralized Health Information System (HIS) maintains all patient health and billing information for all IntraSystem Regional Healthcare (IRH) locations and services. | Access to the HIS is limited by department and administrative rank (See Figure 2) |
IntraSystem Regional Healthcare (IRH) Administrators | IRH is a regional healthcare system that includes several hospitals, including Big City Medical Center. A core group of 20 high- ranking IRH administrators has full, super- user access to all IRH systems and hospitals and regularly exports large portions of the database to Excel files for analysis. Copies of these files are stored on personal, network, and laptop computers and are occasionally e-mailed internally. | 20 people with unlimited admin-level access; access to all patient data from all locations. |
Big City Medical Center (BCMC) Administrators | BCMC Hospital administrators have unlimited access to all patient information from all BCMC departments. Hospital administrators regularly export reports from the centralized HIS containing names, social security numbers, MRNs, and other PHI. These reports are sent to senior management and a less-detailed report is sent to department administrators. Copies of these reports are sometimes stored on personal, network, and laptop computers, and are occasionally e-mailed internally. | 50–100 people with unlimited access to all Big City Patient records (e.g., Read, Write, Delete, Copy, Export, Save As, etc.) |
BCMC Department Administrators | Each BCMC department is headed by one or more department administrators with unlimited access to all department patient information, and who regularly export the information for purposes of internal reporting and analysis. | 70 medical practitioners with unlimited access to all patient records within their department. |
BCMC Medical Practitioners and Administrative Managers | Medical practitioners include surgeons, doctors, managing nurses, billing managers, supervising radiologists, physicians, managing pharmacists, etc. Administrative Managers include billing and insurance department managers, etc. These individuals have unlimited access to a subset of the HIS data, appropriate to their department and job description. | 2,500 medical practitioners with unlimited access to all patient records within their department. |
Low-Level Employees | Low-level employees include nurses, billing employees, interns, volunteers, part-time employees, etc. These individuals may have access to PHI only through the HIS console and are subject to strict data handling controls. | 9,000 individuals with Read/Write Access Only. |
BCMC HIPAA Privacy and Security Officers | HIPAA Privacy and Security Officers are responsible for ensuring BCMC HIPAA compliance by implementing appropriate administrative and technical safeguards. | Access as necessary |
Other IT Security Participants | Other IT security participants include the CIO, CISO, IT Director, an internal HIPAA Security Council, internal auditors, in-house counsel, and others as necessary or appropriate. | Access as necessary |
ExtraSystem Regional Hospitals (ERH) | ExtraSystem Regional Hospitals (ERH) is a neighboring healthcare system that recently offered to acquire Big City Medical Center from IntraSystem. As a standard procedure, ExtraSystem has requested an audit by an external auditor to demonstrate that Big City is compliant with HIPAA privacy and security requirements prior to acquisition. | None prior to acquisition |
Patient | Although the patient does not figure directly in this use case, it is important to recognize that each party should always work in the patient’s best interests. | No direct access |
Reacting to a Breach
One year ago, BCMC suffered a PHI data breach when an Oncology department administrator lost a laptop containing hospital patient reports in unencrypted Excel spreadsheets. An internal investigation determined that the administrator saved weekly patient reports in Excel files for several years, but without a data inventory, it was unclear how many patients were affected. Consequently, BCMC had to send a notification to roughly 27,000 patients – every patient possibly affected – and received substantial negative press.
In the months following the breach, the BCMC HIPAA Compliance and HIPAA Security Officers introduced new security protocols. For example, all Excel files must now be encrypted and may not be “Saved As” a new file. However, some doctors, nurses and administrators quickly figured out how to bypass the encryption and the “Save As” prohibitions by copying and pasting the information to a new document.
Post-Breach HIPAA Risk Analysis
As required by HIPAA, the HIPAA Privacy and Security Officers also conducted a HIPAA Risk Analysis to identify threats to patient confidentiality and security. Risk factors include earthquakes, power failures, network attacks, human error, unauthorized access, and other considerations. Among its conclusions, the risk analysis found that managers, administrators, and a small group of over-permissioned users pose a disproportionately high risk of breaching PHI because of their unlimited access to the core HIS. The same group sharply resists any effort to limit access to patient health information. Consequently, almost all practitioners, managers and administrators have some degree of administrative access to the HIS.
Further, the risk analysis determined that managers and administrators regularly export massive amounts of patient data from the HIS, then store that data on laptop and desktop computers. For the sake of convenience, Medical Practitioners often include identifiable patient data in their reports, including patient names, social security numbers and ICD9 codes. These files can be saved on file servers, desktop computers and laptops and occasionally emailed internally, resulting in large quantities of PHI on many endpoints. For example, users may not be aware of copies of emails and attachments in their email Sent folders or deleted files still recoverable from the operating system’s Recycle facility.
The Compliance Officer also proposed disabling the export feature from the HIS console, but was overruled by BCMC medical practitioners and BCMC administrators, who complained that such controls would have a deleterious effect on patient care. Administrative Managers in the billing, insurance, and financial departments complained that they needed to export patient data for routine billing operations.
The episode raised tensions between medical practitioners, who perceived IT security as detrimental to patient care, and the HIPAA Privacy and Security Officers, who are tasked with compliance and limiting liability. Hospital administrators, many of whom are or used to be medical practitioners, must balance the goals of patient care and patient privacy.
Risk of Unprotected PHI Data
By storing unencrypted PHI data on computers and file servers, IRH employees created several risks:
- PHI data was not secure, so it was more susceptible to breach by a malicious or negligent insider
- PHI data was stored in multiple locations, so it was easier for an outsider to access the data through hacking or social engineering
Solution
To mitigate the risks associated with exporting PHI outside the HIS, IRH administrators, the BCMC CIO, and the HIPAA Security Officer evaluated several security solutions, including Data Loss Prevention (DLP) solutions focused mainly on gateway and network monitoring and blocking (data-in-motion) and Spirion Sensitive Data Platform (SDP).
NETWORK AND GATEWAY SECURITY WITH DATA LOSS PREVENTION
Typically, Data Loss Prevention (DLP) products are designed to scan network traffic for data-in-motion. They are built to block prohibited information as it travels over the network, for example, when an email is sent. Although data-in-motion products may be useful for organizations with a high risk of email breaches, IRH’s research revealed a critical fact: according to the HHS, out of more than 10 million leaks of patient data, only a small number of leaks in the healthcare industry were caused by accidental email disclosures.
In addition, data-in-motion products do not empower doctors to clean the sensitive data at its source. Instead of shredding information, data-in-motion products continue to block the target data without ever addressing the core issue: information should be encrypted, permanently erased, redacted or quarantined.
IRH and BCMC administrators were justifiably concerned that repeatedly blocking medical practitioners from using patient data would negatively impact their productivity and create new risks to security when frustrated doctors bypassed the blocks. For example, some DLP products monitor email, but not USB thumb drives. Others may monitor HTTP traffic but not FTP traffic. Some will search Word documents but ignore documents users have disguised by changing the file extension (e.g., renaming “ssn.doc” to “ssn.doc.jpg”).
Most importantly, IRH administrators found that during their evaluation, most data-in-motion DLP products had very high false positive rates. Because data-in-motion products need to be fast, they trade off accuracy. In practice, this means that legitimate emails or other network traffic is blocked at a higher rate and some unauthorized traffic gets through, causing frustration and information overload for network administrators.
Security can’t be achieved only by preventing adversaries from gaining access to or exfiltrating data stores.
MANAGING SENSITIVE DATA-AT-REST
IRH and BCMC administrators evaluated Spirion Sensitive Data Platform (SDP) and learned that it addressed IRH and BCMC’s most pressing risks. SDP performs in-depth searches of unstructured and structured PHI data where it is stored, allowing organizations to stop leaks at their source. SDP was able to search every file and email on all desktops, network servers, and Cloud repositories, and display those locations with sensitive data. Administrators and managers discovered that they could use its reports to improve patient security without impinging on patient care.
Because SDP searches and cleans all patient data at its source, Word documents, uploaded files, information copied to a USB drive, images, email attachments, cloud storage, and other business-critical and regulated data are secured. In addition, IRH and BCMC administrators can rest easier knowing that the hospital won’t suffer a data breach should a cleaned computer ever be lost, stolen, or hacked.
IRH and BCMC administrators were particularly impressed with SDP’s low false positive results, due to its advanced validation algorithm. For example, rather than matching any nine-digit number as a social security number, SDP uses Social Security Administration data combined with keyword searches, file-type specific analysis, and proprietary analysis to drastically reduce false positive results. Administrators were also pleased that SDP automatically created a robust PHI data inventory and that they were able to use a centralized management console to create a vast array of customized reports that demonstrated system-wide HIPAA compliance and gap analysis, along with detailed reports for IT professionals tasked with cleaning up unnecessary PHI. They were also able to use real-time and dynamic persistent classification to tag and label data to increase awareness.
SDP’s Optical Character Recognition (OCR) feature was useful to search scanned medical documents. Full regular expression and dictionary support permitted searching for MRNs, ICD9, ICD10, CPT and other medical codes.
Implementing SDP
After evaluating several vendors, the IT security team determined that SDP best addressed BCMC’s primary HIPAA risks, as well as supporting their longer-term goals for sensitive data governance and data security posture management (DSPM). They decided to install it in phases as part of their overall risk reduction plan. Phase One was a pilot discovery phase, in which SDP was installed on the 30 computers belonging to the IRH’s most technically capable early adopters and for the hospital administrators who had the most sweeping access to the Health Information System (HIS).
Hospital administrators and medical practitioners were initially concerned that SDP would decrease their productivity and have a negative impact on patient care, but their fears were quickly allayed. SDP can remotely and invisibly search in the background, it does not limit access to any programs or files, and it does not force practitioners to change their procedures. All parties agreed to commence Phase One two months after the breach. Phase Two was an enterprise rollout to all medical practitioners and would commence about three months after Phase One began.
PHASE ONE: PILOT TO EARLY ADOPTERS
As Phase One began, results of each scan were reported to the centralized SDP console and to the appropriate data owners.
Technically capable early adopters were allowed to take their own actions to protect their data, including no action, encryption, redaction, destruction or quarantining to a secure location. Every participant was shocked at the amount of PHI that SDP discovered on their systems.
One surgeon was surprised to find that seven-year-old reports with social security numbers were stored in her Microsoft Outlook Sent Items. SDP alerted a physician to PDF files saved in his My Documents folder that contained ICD9 codes and other patient data. A hospital administrator found years of weekly patient reports stored on his laptop.
In general, each medical practitioner took appropriate action. The surgeon deleted the old email, the physician encrypted the PDF file, and the hospital administrator amended the weekly report to exclude the most sensitive personal information. He also used SDP to digitally shred some obsolete information, and he quarantined other data to a secure network location for later review and remediation as necessary.
The team created a report in SDP that displayed the existence of PHI data and the actions of each user for analysis by the compliance and security staff. By the end of Phase One, 27 of the 30 machines scanned were found to contain PHI inside forgotten files, email messages, or email attachments. SDP found more than 18,000 PHI records. Social Security numbers comprised the largest share of sensitive PHI, followed by patients’ dates of birth, and then Health Information (defined by the organization as ICD9 codes, diagnoses, and medical records).
PHASE TWO: ENTERPRISE IMPLEMENTATION
After the end of Phase One, administrators and medical practitioners discussed the findings of the first phase, including the actions each administrator took to address stored PHI. Feedback from users and analysis from the SDP reports were used to develop administratively and technologically appropriate policy controls on PHI exported from the HIS. Hospital administrators and HIPAA privacy and security officers developed a data security policy and rolled out SDP to the laptops and desktops of most medical practitioners during Phase Two.
Because the SDP agents ran in the background, most doctors were unaware of the scans until they received a weekly report. Administrators were able to track HIPAA compliance over time and satisfy internal auditors that they were taking appropriate steps to safeguard sensitive PHI.
DEPLOYMENT
SDP has two complementary components. The SDP Console is hosted in Microsoft Azure and communicates to Spirion agents on one or more endpoints. The Console centrally manages IRH and BCMC’s Sensitive Data Platform deployment, sets security policies, and provides centralized reporting and data exports needed for DSPM.
The second component is the Spirion Agent, available for Windows, macOS, and Linux systems, which performs scanning, classification, and remediation both on individual endpoints like laptops and on servers and repositories. The Agents can scan any accessible data location and may be run in teams to allow scalable distributed scans to scan even very large repositories quickly.
In this case, IRH had Spirion deploy an SDP Console instance in Azure, then they remotely deployed a pre-configured SDP agent .msi file to BCMC’s secure environment. Once deployed, an appropriate IT staff member remotely configured each endpoint through the Console and scheduled sensitive data scans at regular intervals.
DISCOVERY—UNPARALLELED ACCURACY
IRH and BCMC were able to search all locations across the company infrastructure including computers, web servers, file servers, cloud storage and database servers without installing Spirion Agent software on each device. Using agentless searching from a single administrative workstation, the Compliance Officer would remotely search other desktops, file servers, or any networked computer accessible via a service account. As with an agent, the policies for the agentless search were set, monitored, and controlled from the centralized SDP Console.
During this phase, the SDP agent was installed on workstations and laptops and configured to run in the background, allowing other programs to take precedence over it. The result was that the SDP deployment was transparent to doctors and did not interfere with their daily activities, providing unparalleled accuracy with near-zero false positives.
CLASSIFICATION—REAL-TIME AND PERSISTENT
With SDP’s real-time, persistent classification, IRH and BCMC were able to automatically classify sensitive data with rigorous precision by applying customized rules. The moment a file is created or modified, a classification icon is created on the file to guide end-users on how the document should be handled. The persistent classification is embedded in the file’s metadata, so it remains with the file.
They scheduled scans to automatically discover, classify, and report on sensitive data that was located. They also set up customized workflow processes using SDP Playbooks to notify and alert stakeholders via emailed notifications with attached reports on sensitive data.
Figure 2: With SDP’s persistent classification, classifications can be displayed as icons directly on the file
CENTRALIZED REPORTING
SDP offers customizable pre-defined dashboards to inform oversight and risk management. For board members and executives, the Spirion SPIglass Dashboard summarizes sensitive data risk in business-meaningful financial metrics, for instance, to indicate, for instance, whether a particular exposure is a $25,000 risk or a $20 million risk.
For security practitioners, the Spirion SDV3® Sensitive Data Risk Dashboard offers a quantitative measure of data risk that is directly tied to the sensitivity of personal data stored on IT systems. This dashboard spotlights the riskiest data assets helping teams to prioritize tasks. In addition to displaying the status of sensitive data risks, the dashboards and reports in SDP show long-term trends to enable IRH to demonstrate its continuous improvement on compliance on an ongoing basis.
Figure 3: The SPIglass dashboard provides an executive-level summary of sensitive data risks
For more granular reporting, SDP offers a Custom Reporting feature, in which users can initiate their own ad hoc or scheduled exports of select scan results data for use in other analytics and reporting tools. And for more complex analytics or workflow reporting required, SDP has an add-on data warehouse, Spirion Enhanced Analytics or SEA, that allows SDP scan result data to be accessed, analyzed, and reported on by any SQL-capable third-party tool including Microsoft Power BI.
Figure 4: IRH can create custom reports with Spirion Enhanced Analytics and Custom Reporting
Remediation
For Phase Two, the team was ready to automate many of their remediation tasks using Spirion SDP Playbooks, a workflow solution for automating data protection controls. Remediation capabilities available include:
- Moving sensitive information into a secure quarantine zone for later review or storage
- Redacting data to blur the sensitive data elements
- Restricting access on a file until it can be reviewed
- Destroying the sensitive information with DOD level shred capabilities or redaction
- Invoking other actions through third-party Technical Alliance Partners detailed on the Spirion Marketplace site or executing custom scripts. For instance, sensitive data can automatically be encrypted by invoking the Thales CipherTrust Transparent encryption solution.
IRH decided to continue to let users take their own actions, but they added the additional security step of first moving the data to a secure location, so that it would be immediately safeguarded.
Once PHI data had been discovered, doctors or administrators could then take further actions on the data. With the click of a button, they could encrypt, shred or redact the unauthorized PHI data. With the Playbooks, they were able to easily create a workflow to add a text file in the place of the quarantined file with instructions to the employee on how to access the file, should they need it. The results of Sensitive Data Platform’s searches and end users’ actions were reported back to the Console, providing an audit trail of sensitive data was being managed across IRH.
Figure 5: Spirion Playbooks allow for workflow-based automated protection of sensitive data
ONGOING COMPLIANCE AND PROTECTION
SDP enabled administrators to better comply with HIPAA and HITECH and state privacy guidelines and to develop best practices.
During all phases of deployment, SDP:
- Unobtrusively and accurately found unstructured patient health information across the entire healthcare network including emails, laptops, images, databases, and cloud storage
- Decreased HIPAA security risks via Playbook-based automated data remediation, quarantining, and correcting excess permissions on data locations
- Alerted data owners to the existence of unprotected data with additional options to secure or remediate their data
- Increased awareness of sensitive data locations and concentrations with real-time and persistent file-level classification tags
- Did not interfere with doctors’ access to information or require doctors to change patient care practices, while improving the security behavior and habits of healthcare professionals
- Encouraged the development of appropriate systems, hospital, department and practitioner-specific security polices
- Increased HIPAA compliance transparency to outside auditors and third parties
- Provided executives with the holistic understanding of sensitive data risks that they need to inform their oversight and guide improvements in the organization’s Data Security Posture Management (DSPM)
- Provided a quantitative sensitive data risk metric essential for accurately reporting potential cyber risks to the board and regulators like the SEC.
REDUCING RISK AND COST OF HEALTHCARE
IRH administrators recognized many benefits within the first 12 months:
- IRH saw a drastic reduction in unprotected PHI data on its network
- Compliance officers noticed that medical practitioners began making more responsible data management decisions and following the internal HIPAA security policies without objection
- BCMC administrators were able to quantify and improve HIPAA security and came to appreciate that SDP drastically decreased the risk of and impact from data leaks and breaches
- BCMC saved critical staff time and tens of thousands of dollars on the preparation for their HIPAA audit, allowing the hospital to reallocate resources and make other pressing improvements to IT and network security
- Patients were able to focus on recovering and didn’t have to worry about their health information being compromised
In addition, a planned future deployment of an add-on product from Spirion, Sensitive Data Watcher or SDW, will provide the IT staff with notifications of unusual and potentially malicious user behavior to detect account compromises and possible ransomware infections based on the MITRE ATT&CK framework. SDW also allows automated scanning of newly created files and emails for potentially sensitive data like PHI, providing for a faster response and remediation without having to wait for a periodic scan to occur.
Figure 6: Sensitive Data Watcher Dashboard
Results
PRIVACY-GRADE AUDIT READINESS
A neighboring healthcare organization, ExtraSystem Regional Hospitals (ERH) subsequently started the process of acquiring BCMC from IRH. As a standard procedure, ExtraSystem requested an external audit to confirm that BCMC was substantially compliant with HIPAA privacy and security requirements prior to acquisition.
Fortunately, because BCMC had deployed SDP across its data handling infrastructure and endpoints, the auditors were able to cost effectively verify that BCMC had improved its HIPAA compliance since the breach. Armed with SDP, the compliance officers spent less time dealing with baseline HIPAA compliance and more time focused on other pressing matters.
The net outcome was significantly reducing the costs and uncertainties around sensitive data governance and DSPM, allowing the auditors to give BCMC a clean bill of health and permitting the acquisition proceeded without incident.
Footnotes
1 IBM-Ponemon Institute, “2023 Cost of a Data Breach Report” .
2 The HIPAA Journal, “Healthcare Breach Statistics,” Aug. 21, 2023
3 comparitech, “Medical breaches accounted for 422.7 million leaked records from 2009 to July 2023,” Paul Bischoff, Aug.15, 2023
4 Reuters, “Anthem to pay record $115 million to settle U.S. lawsuits over data breach,” Brendon Pierson, June 3, 2017
5 Health IT Security, “41 States Settle with AMCA Over 2019 Data Breach Affecting 21M Patients,” Jessica Davis, March 18, 2021
6 Healthcare IT News, “HCA Healthcare sued for recent data breach,” by Mike Miliard, July 18, 2023
7 The HIPAA Journal, “Managed Care of North America Hacking Incident Impacts 8-9 Million Individuals,” Steve Alder, May 30, 2023