In the past 5 years, a lot has happened in the digital health space. Venture funding in 2018 was close to $10BN and a lot of work is being done.
As our customers progress through their clinical trial journey to FDA clearance and post-marketing, we are frequently asked on how to achieve HIPAA compliance in an era of digital health apps, medical IoT and collection of RWD (real-world data) from patients. I will try and help you make sense out of HIPAA and the HITECH Act (Health Information Technology for Economical and Clinical Health).
On January 25, 2013, the HIPAA Omnibus Rule was published in the Federal Register, which created the final modifications to the HIPAA privacy and security rule. You can see the source of the law here.
The HITECH Act created a supply chain trust model.
According to 45 CFR 164.502(e), the Privacy Rule applies only to covered entities (healthcare providers, health plans and healthcare clearinghouses). Going down the chain, covered entities have suppliers who are defined as BAS (business associates). A business associate is a supplier that creates, receives, maintains, or transmits protected health information on behalf of a covered entity or other business associates.
The HITECH Act requires suppliers in the chain of trust to comply with the Security Rule. A medtech company and its’ cloud service providers, customer engagement service providers et al are all business associates.
The HITECH Act does not impose all Privacy Rule obligations upon a BA but:
1.BAs are subject to HIPAA penalties if they violate the required terms of their BA Agreement (BAA).
2.BAs may use or disclose PHI only in accordance with the required terms of its BAA
3.BAs may not use or disclose PHI in a manner that would violate the Privacy Rule if done by the CE
Down the supply chain and to the right
When we go downstream in the supply chain, the BAA becomes more and more restricted regarding permissible uses and disclosures.
For example, if a business associate agreement between a covered entity and a supplier does not permit the supplier to de-identify protected health information, then the business associate agreement between the supplier and a subcontractor (and the agreement between the subcontractor and another subcontractor) cannot permit the de-identification of protected health information. Such a use may be permissible if done by the covered entity, but is not permitted by the downstream suppliers in the supply chain, if it is not permitted by the covered entity’s business associate agreement with the contractor.
Concrete example of a digital therapeutic.
A physician (covered entity) prescribes a digital therapeutic app. The physician writes a script that is sent to a customer service center, which provides customer support to patients to download and use the app.
The healthcare provider will need a BA with the digital therapeutics company (or its customer service center that may be a separate business), who then has BAAs with other online suppliers for cloud and Braze customer engagement services. Graphically, the supply chain looks like this:
As we move down the supply chain and to the right, we see that the suppliers are providing specific and more restricted digital services.
The golden rule
Although a BA is a formal, regulatory requirement, it includes compliance with the HIPAA Security Rule and possible exposure to Privacy Rule disclosures. To a large degree, the Golden Rule applies – “He who has the gold rules”. For early stage medtech and digital therapeutics companies, your customers have the gold. Do a good job on your homework on your security and privacy risk assessment. Consider external threats as well as possible exploits and cascade attacks on your APIs.
Follow