Vendor Breach Involved PHI Exposure on GitHubSeveral Healthcare Entities Issue Notices to Patients About Incident
Several healthcare entities are reporting health data breaches in the wake of an incident involving a vendor's employee who uploaded files containing patient data to the public-facing, open-source software development hosting website GitHub.
In a statement Wednesday, Med-Data Inc., a revenue cycle management services vendor based in Spring, Texas, said it had experienced "a privacy incident" potentially compromising the data of individuals whose protected health information was provided to the company.
Med-Data assists hospitals, other healthcare providers and health plans with processing Medicaid eligibility, third-party liability, workers’ compensation and patient billing.
Med-Data did not disclose the total number of healthcare providers or patients affected and declined Information Security Media Group's request for additional details about the incident.
This week, however, four Med-Data clients this week issued their own breach notification statements about the incident.
Each of the affected entities said compromised PHI may have included patient names, addresses, dates of birth, Social Security numbers, diagnoses, conditions, claim information, dates of service, subscriber IDs, medical procedure codes, provider names and health insurance policy numbers.
None of the entities disclosed how many of their patients were affected. Also, as of Friday, none of the breaches reported by the affected healthcare entities, or by Med-Data, had been posted on the Department of Health and Human Service's HIPAA Breach Reporting Tool website of health data breaches affecting 500 or more individuals.
In its statement about the incident, Med-Data says that on Dec.10, 2020, it launched an internal investigation after being notified by an "independent journalist" about the discovery of data related to the company's business having been uploaded to a "public website."
Med-Data says the investigation found that a former worker saved files containing protected health information in personal folders created on the website sometime between December 2018 and September 2019 while the person was employed with Med-Data. The files were removed on Dec. 17, 2020, Med-Data says.
In its statement, Med-Data did not name the journalist who made the discovery. However, the company confirmed to ISMG that GitHub was the public website involved in the data exposure.
Privacy blog DataBreaches.net reports that the Med-Data exposed data was discovered on GitHub in November 2020 by Dutch independent security researcher Jelle Ursem. Ursem and DataBreaches.net notified Med-Data in early December of Ursem's discovery, the blog reports.
Med-Data says that, on Feb. 5, a cybersecurity specialist hired to review the exposed data provided the company with a list of individuals whose PHI was affected by the incident.
Unfortunately, incidents involving the inadvertent exposure of PHI on public-facing open-source development websites and repositories are not uncommon.
In August 2020, Ursem and privacy blogger DataBreaches.net published a paper describing nine data leaks found on GitHub public repositories involving PHI (see: Medical Records Exposed Via GitHub Leaks).
In 2017, Emory Healthcare reported to HHS a health data breach affecting 80,000 patients apparently involving an attack on a misconfigured Mongo database.
Healthcare sector entities can take steps to avoid having their PHI fall victim to such incidents, including those involving internal or third-party software development teams, some experts say.
"Security needs to be assessed from different angles," notes Tom Walsh, founder of consulting firm tw-Security. "Most often, the focus is on the front-end security controls of an application that control access to databases. Hackers will often attack the backend - databases."
"Therefore, security needs to be assessed from the backend - databases and data repositories - as well as the front-end apps - the user-friendly interface," he notes.
A software development life cycle policy should define when "real identifiers" are allowed to be used, Walsh says. That's usually in the last phase of testing, before software code gets promoted into production. Once code has been tested, however, real identifiers need to be purged, he says.
"Be sure to check nontraditional locations for PHI" during final stages of software development, Walsh says, noting that those areas include application trouble tickets, which sometimes include a screenshot that contains PHI.
"It is important to remove or sanitize the examples that are sent in association with a trouble ticket once the ticket is closed out," he says.
Transaction logs will also contain real identifiers, according to Walsh. "These audit logs may get backed up and retained for a long time, even after the real identifiers were purged from the system."
The best way to prevent inadvertent exposure of PHI during software development is to use "dummy data" wherever possible, rather than actual identifiers, he says.
Also, "where feasible, periodically run searches or scans for any residual PHI that may inadvertently have been left behind by software developers."