Developers should know by now, if an app they’re developing includes Protected Health Information (PHI) as HIPAA defines it, the app, the company and the developer must become HIPAA compliant before PHI is transmitted, received, stored or processed. This includes all vendors an app uses for hosting, storage, and data processing of any type. The requirement for full HIPAA compliance follows PHI everywhere it goes, and it applies to every vendor who has contact with PHI.
Every vendor who receives or processes PHI for an app in any way must be HIPAA compliant or the app and the developer are not compliant. Nearly all apps use multiple external vendors to provide various data processing, storage, and delivery services. Choosing vendors wisely is therefore a vital step for developers to becoming compliant, and delivering apps that hospitals, investors and others will take seriously.
Vendors Processing Data for Healthcare Apps Are HIPAA Business Associates
The OCR, HIPAA’s primary enforcer, has made it clear that vendors, including cloud service providers (CSPs), who transmit, receive, store, or process PHI for other entities are Business Associates (BAs) of the entities they engage with. Even if a vendor only stores encrypted data and does not have access to encryption keys, a BA relationship exists. This also applies to any vendors an app may use to process “electronic PHI” or “ePHI”, which is PHI in any digital form. In 2016, the OCR stated:
“When a covered entity engages the services of a CSP to create, receive, maintain, or transmit ePHI (such as to process and/or store ePHI), on its behalf, the CSP is a business associate under HIPAA. Further, when a business associate subcontracts with a CSP to create, receive, maintain, or transmit ePHI on its behalf, the CSP subcontractor itself is a business associate. This is true even if the CSP processes or stores only encrypted ePHI and lacks an encryption key for the data. Lacking an encryption key does not exempt a CSP from business associate status and obligations under the HIPAA Rules.”
Developers using external vendors to process PHI have a Business Associate (BA) relationship with each and every vendor who touches PHI. And a HIPAA-compliant BA Agreement, signed and executed, must be in place before any PHI is transmitted to such a vendor.
Choosing HIPAA Compliant Vendors (BAs) Wisely
Because vendors who process PHI are Business Associates of healthcare app developers, they must be chosen carefully. Having compliant vendors doesn’t make a developer fully compliant, and developers have their own compliance duties under HIPAA. But developer compliance does depend, in part, on the full compliance of all vendors who will be handling PHI.
Here are seven recommendations for choosing HIPAA compliant vendors (BAs) wisely:
- Choose a Vendor Who Actually Knows HIPAA – Most cloud service providers, hosting firms and data processing companies claiming to be “HIPAA compliant” have completed only the minimum technical steps needed to make themselves HIPAA compliant, not their customers. Most have no in-house HIPAA expertise, and many do not have all the administrative elements HIPAA compliance requires. Ask to see evidence of a vendor’s full HIPAA compliance. This includes policies and procedures as well as the vendor’s other administrative compliance elements, such as a recent risk analysis and evidence of training employees on HIPAA.
- Review the Vendor’s BA Agreement (BAA) Carefully – A fully compliant vendor should have a compliant BAA on hand, ready to send. The BAA should contain all the terms HIPAA requires, but be careful of extra terms not required by HIPAA, even if HIPAA permits them. Developers, be sure you note the jurisdiction of the BAA in its terms, as jurisdiction determines the court a developer must use if legal problems arise.
- Review the Vendor’s Service Level Agreement (SLA) for HIPAA Implications – SLAs can address technical issues directly related to HIPAA compliance and PHI, such as:
– System availability and reliability — This affects PHI availability and access reliability.
– Data backups and system recovery – This affects a developer’s and an app’s ability to respond to ransomware or other malware attacks, or other emergency situations.
– How data will be returned or destroyed after use of the vendor’s services terminates.
– Security responsibilities – who is responsible for what when security incidents occur?
– PHI use, disclosure, and retention requirements. - Be Sure the Vendor Has Designated a HIPAA Privacy or Security Officer – This is a critical step many vendors haven’t taken. Designating a Privacy Officer, Security Officer, or HIPAA Officer (the title itself is unimportant) shows a serious commitment to full compliance with HIPAA. The Officer should be a high-level individual in the vendor’s organization, not a front-line employee. Try to speak with the vendor’s HIPAA Officer directly and see if you can get through.
- Understand How the Vendor Handles Security Incidents – While all data breaches may be considered “security incidents”, not all security incidents involve breaches of data. Developers, be sure you understand how a vendor handles and reports security incidents to customers.
- Be Sure the Vendor Has a Breach Notification Plan & System in Place – Data breaches are all-too-common today, and any vendor who doesn’t have a working breach notification system already in place should be suspect. Breach notification is an integral part of HIPAA compliance.
- Check with Other HIPAA-regulated Customers – If everything else about a vendor is positive, be sure to contact a few of the vendor’s existing healthcare customers to determine what sorts of experiences they’ve been having. Be sure to address HIPAA compliance with them.
Developers, your own HIPAA compliance depends in part on the full compliance of the vendors you choose. When PHI is involved, your vendors are your Business Associates. Choose them wisely.
Was this article helpful? Subscribe below to learn more about MedStack and get tips delivered straight to your inbox.
