As a 3rd party, I have "patient search" functionality because I need the PatNum for most API calls. It is my understanding that because PatNums are unique, they are considered PHI under HIPAA. I do not store the PatNum in any permanent storage (even in logs), but it is obviously in temp memory while the app is running.
Would I need a Business Associate Agreement with OpenDental AND with every office that uses my software? I'm not sure how that part of things works, so any advice is welcome.
The API and HIPAA compliance
-
cridertechdev
- Posts: 6
- Joined: Wed Jan 04, 2023 9:27 am
- Contact:
-
nathansparks
- Posts: 172
- Joined: Mon Aug 04, 2008 12:39 pm
Re: The API and HIPAA compliance
This is my position, and loosely, the position of Open Dental at this time, and is not legal advice.
As a third party, whether the patnum (by itself with no medical information) is PHI or not isn't really the point, the fact is that ALL third parties using the API should know they are acting as a Business Associate as defined by the HIPAA and are custodians of PHI whether they store it or not. A summary of the definition from the government's point of view can be found here: https://www.hhs.gov/hipaa/for-professio ... index.html . The fact is that most API calls return PHI, and you do not need to display it, just having it in memory for a moment is 'use'.
BAA's:
You do not need a BAA with Open Dental because you are not accessing patient data for us, you are doing it directly for the clinic/provider. We cannot control what you do with the data as we are not asking you to do anything, we have no business purpose for you to perform, you are performing for the clinic. They must give you permission by entering a key into Open Dental, and should enter in to a BAA with you. We are only providing the software and transport for this, and the clinic/office should have a BAA with us, which they can download a signed version of from our website. We are not giving you data, the clinic is, and they need to know what you are doing with it and that should be defined in the BAA you provide them or that they require you to enter into.
While the responsibility of having a BAA falls to the customer or entity, not the Business Associate, third parties can save some time and headache by providing a BAA for each customer. The advantage of providing your own instead of waiting for some customers to provide one for you to sign are clear (there may be more, but these three are important to me):
1. You will define the scope of usage (what you are allowed to do with the PHI) instead of the customer, or more commonly, the generic author. The specificity of your usage can protect you, but it can also expose you if you define it too narrowly and exceed it. You must not do anything with PHI that the customer has not engaged you to do and that is not reasonable, ethical and legal.
2. You will have consistent breach protocols. While breaches are a worst nightmare scenario, what is worse is if you have 10,000 customers and they each have different notification requirements and terms for a breach. You will not have time to refer to each BAA, and some may say 30 days and some may say 8 hours (for some particular action requirement in a breach).
3. You will not need to read each BAA and/or have a lawyer review it. I have seen absurd content in proposed BAA's that would expose my company to great risk. I simply present one BAA to all customers, I have to read nothing.
As a third party, whether the patnum (by itself with no medical information) is PHI or not isn't really the point, the fact is that ALL third parties using the API should know they are acting as a Business Associate as defined by the HIPAA and are custodians of PHI whether they store it or not. A summary of the definition from the government's point of view can be found here: https://www.hhs.gov/hipaa/for-professio ... index.html . The fact is that most API calls return PHI, and you do not need to display it, just having it in memory for a moment is 'use'.
BAA's:
You do not need a BAA with Open Dental because you are not accessing patient data for us, you are doing it directly for the clinic/provider. We cannot control what you do with the data as we are not asking you to do anything, we have no business purpose for you to perform, you are performing for the clinic. They must give you permission by entering a key into Open Dental, and should enter in to a BAA with you. We are only providing the software and transport for this, and the clinic/office should have a BAA with us, which they can download a signed version of from our website. We are not giving you data, the clinic is, and they need to know what you are doing with it and that should be defined in the BAA you provide them or that they require you to enter into.
While the responsibility of having a BAA falls to the customer or entity, not the Business Associate, third parties can save some time and headache by providing a BAA for each customer. The advantage of providing your own instead of waiting for some customers to provide one for you to sign are clear (there may be more, but these three are important to me):
1. You will define the scope of usage (what you are allowed to do with the PHI) instead of the customer, or more commonly, the generic author. The specificity of your usage can protect you, but it can also expose you if you define it too narrowly and exceed it. You must not do anything with PHI that the customer has not engaged you to do and that is not reasonable, ethical and legal.
2. You will have consistent breach protocols. While breaches are a worst nightmare scenario, what is worse is if you have 10,000 customers and they each have different notification requirements and terms for a breach. You will not have time to refer to each BAA, and some may say 30 days and some may say 8 hours (for some particular action requirement in a breach).
3. You will not need to read each BAA and/or have a lawyer review it. I have seen absurd content in proposed BAA's that would expose my company to great risk. I simply present one BAA to all customers, I have to read nothing.