On Monday, Quest Diagnostics filed notification of a breach in which up to 11.9 million patients’ medical and financial data had been accessed by an unauthorized user via a collections vendor, American Medical Collection Agency (AMCA). The next day, LabCorp followed suit with a similar filing pertaining to 7.7 million patients. The breach occurred through an AMCA-hosted web payment page and included a variety of personal financial and medical data (see the filing links for specific data points that were compromised).
Both incidents stem from an industry-standard scenario in which a large medical provider outsources a portion of its revenue cycle to a vendor.
From outsourced radiology readers to health apps to collections agencies, providers face increasing pressure to connect sensitive data to third parties. When successful, these relationships add value to both the patient and the provider, but they all bring an uptick in risk.
It’s kind of like bringing my second cousin Ted to a family get-together: 99.9% of the time, things go great and he does his impressions. But after that .1% of the time where Ted eats all the chips and offends my Aunt Sheryl, we might stop scheduling get-togethers entirely.
As a gatekeeper of PHI, it’s important to ask yourself every morning over coffee: “How do I ensure that our data sharing is secure 100% of the time?”
While we can only speculate about the vulnerability that led to this breach, this major leak of sensitive data warrants a reminder for healthcare providers large and small to conduct regular due diligence on the entire surface area of a vendor system that their data touches.
The Inherent Risk of Data Sharing Between a Goliath and a David
American Medical Collection Agency is a large collections vendor that services major healthcare providers like LabCorp and Quest, as well as non-healthcare entities through its other brand: Retrieval Masters Creditors Bureau (side note: the business naming guy that they use is not one for subtlety).
This is a multi-million dollar collections vendor. However, with Quest and LabCorp combining for around half of the US clinical lab market, it’s safe to assume these two providers dwarf AMCA in size and access to technical resources.
In every healthcare vendor relationship that requires sensitive data exchange, both parties undergo a formal vetting of HIPAA and security protocol in a checklist fashion. But when it comes to sharing data with a smaller vendor, which is a lopsided situation that many providers must face, this also begs the following higher-level judgments:
- Does this vendor have technical resources dedicated to monitoring security threats and auditing its infrastructure?
- Does this vendor exclusively work in healthcare? If not, does this vendor treat its healthcare data infrastructure with more rigor in regards to user management, segmentation of data, archival of data, and audit logging?
- Is this vendor as incentivized to safeguard data privacy as our company?
If the answer to any of these questions isn’t 100%, that doesn't mean it's the end of the road. Vendors are often willing to alter a workflow, hire additional staff, or contract a third party audit in order to ensure that a deal is mutually secure. After all, vendors also face the pressure of conforming with multiple different client environments.
Before crossing the t's and dotting the i's, consider hiring an outside security auditor or professional hackers to try to penetration-test a sandbox environment provided by the vendor, especially if a smaller vendor is new to the industry or customizing their business process to meet your needs.
The investment is worth it: data security is of mutual financial interest to both the provider and vendor, as well as the privacy of the patient.
If a vendor agreement feels rushed or puts financial pressure on cutting security corners, it's a deal worth skipping.
Avoid Sharing and Storing Data That Is Irrelevant to the Vendor’s Business Need
When it comes to taking on a new vendor, a provider may be tempted to send along a standard data export “because this is what we already send our other vendors.” It’s easier to manage the routine ETL process this way, especially when the vendor list grows. But are you only exporting the minimum amount of data required for this vendor to provide its service to you?
In the case of Quest and AMCA, it’s impossible to tell. But from experience with working with rev cycle data, 19 million patient financial records seems excessive to store centrally without compartmentalizing access to this data. If a malicious entity were to gain access to a system where patient data was stored separately by region, last activity, or call center ownership, would the entity have breached 19 million records, or 190,000 records?
Likewise, if patient medical data is only necessary for sending a collections mailer (such as service rendered), but is not necessary for the patient payment portal (perhaps only claim number would suffice), could you fully separate this data? And if that were the case, would the breach have only affected financial data but not medical data?
With microservices architecture and stringent communication safeguards between pools of data access, a breach might only affect one compartment while the others are unaffected.
It’s a Data Export World: We’re Just Living In It
As an independent healthcare vendor, we’ve received access to healthcare data in a variety of ways. It’s standard to receive a regular export of raw provider data in a delimited format over a secure FTP, and most clients I work with handle this exchange with 100% attention to privacy and security.
But as a provider, it’s also worth asking one big question: For my vendor to accomplish its service successfully, does this even require an export of our data?
Or, is there an effective way for your vendor to accomplish its task directly in your system where your organization’s security protocols govern all, where you control every user account, and you can monitor audit logs to ensure safe access?
If a vendor must access data externally, is there a way you can make this data available as needed by request through a secure API that's already supported by your EHR or billing software?
You could also modify your export logic to only push patient records that matter to the vendor’s workflow. For example, rather than exporting all patient encounters for a given date range, the provider could modify export criteria to only include patient encounters with a non-zero patient balance following 60-days post discharge.
A Final Word of Caution: Sit Down in the Room and Meet Your Vendor’s Developers
As interoperability continues to make the sharing of healthcare data more common, and as more startups (both foreign and domestic) enter the industry, healthcare organizations should make sure that they can speak openly with the development team that will handle data security in person. Vendors should not be afraid to invest in and offer third party audits of their security infrastructure, and both parties should be interested in minimizing the surface area of their shared data.
Have questions related to the recent breach or setting up a secure infrastructure? Reach out to Arcosta at email@example.com.