Building HIPAA Compliant APIs
The new normal will enable HealthTech vertical-based APIs that, behind the scenes, simplify and automate legacy business processes.
Join the DZone community and get the full member experience.
Join For FreeHealth care represents 17% of US GDP, around $4 trillion in 2020. COVID has normalized the use of remote medicine and accelerated the dispersion of health care away from doctors’ offices and hospitals, to services being delivered on smartphones and online apps.
In the midst of this sea change, more patient records are being digitalized, transmitted, stored, and utilized electronically. APIs stand at the vanguard of swiftly enabling new services in this burgeoning market. However, with the advent of these electronic records and the ease at which information can be obtained from an API, now more than ever there’s an existential need to protect patients’ data.
HIPAA/HITECH Laws and Your APIs
Any information that can be used to identify a patient is considered protected health information, or ePHI for electronic Protected Health Information, and its usage is controlled by the federal laws HIPAA & HITECH.
Unlike the PCI standard in FinTech, no one can certify that your app is HIPAA compliant — the Office for Civil Rights (OCR) (part of the Department of Health and Human Services) as the governing body, doesn’t recognize certifications. Rather, the onus is left to you, the API provider, to perform periodic technical and non-technical evaluations to make sure that security policies and procedures meet the letter of the law.
In the past, OCR has vigorously pursued judgments against companies’ HIPAA non-compliance, employing both civil and criminal penalties.
The Health Insurance Portability and Accountability Act (HIPAA) is a Federal Law from 1996 and was significantly amended and expanded by the Health Information Technology for Economic and Clinical Health Act (HITECH) in 2009. The purpose of HIPAA/HITECH is to improve the efficiency and effectiveness of the healthcare system by standardizing and protecting the communication of health information, with particular regard to privacy, security and electronic data interchange.
API Developers Touching ePHI Need to Comply With HIPAA and BAAs
In the simplest form, if your API comes into contact with ePHI then you have to adhere to HIPAA.
There’s another twist for compliance — if you touch ePHI then you also need to sign legal agreements, Business Associates Agreements (BAAs) with the upstream provider of that ePHI, and downstream partners who you might share that ePHI with.
The ultimate upstream providers are the US health care and health insurance providers, they produce the bulk of ePHI and are called Covered Entities. Business Associates are companies that perform work or other functions involving the use of that ePHI, on behalf of the Covered Entity or other Business Associate. BAAs between developers and their vendors/partners must be in place before ePHI is exchanged, otherwise the exchange becomes a HIPAA violation.
In the majority of cases, API products will be developed outside the Covered Entity itself, so this blog post will focus exclusively on Business Associates, those API development companies creating programs/apps using ePHI from Covered Entities and/or other Business Associates.
Let’s look at the illustrative example above. An API company wants to build a product that schedules doctor's appointments. The API company needs to request information from a medical practice such as the name, nature of the visit, specialty of the doctor, etc. Before ePHI is released, the holder of the patient information (the medical practice itself or an electronic healthcare records provider) needs to sign a BAA with the API company. If the scheduling company wants to utilize a product from another vendor, such as an API mapping service that shows doctor office locations, then they need to sign another BAA with that downstream partner. The original API company and its partners are now legally bound to follow both the HIPAA requirements and also those regulations outlined in the BAAs.
When It’s Safe to Not Comply With HIPAA
There are four instances when you don’t have to comply with HIPAA:
1. Don’t Transmit, Store or Process ePHI
One way of protecting your company from HIPAA would be to not transmit, store or process any ePHI. So you can rest easy, here are the 18 unique identifiers (Personally Identifiable Information) that HIPAA specifies become ePHI when used in conjunction with health information:
- Name
- Address
- Dates related to an individual, like birthday or visit date
- Telephone/Fax numbers
- SSN
- Medical record/Health plan/Account number
- Certificate or license number
- Car VIN/Plate number
- Device ID
- Web URL
- IP address
- Finger or voice print
- Names of relatives
- Photos of patient
- Any other characteristic that could uniquely identify the individual
2. School or Employment Records
Health information residing in employment or school records is not considered ePHI.
3. Self-Collected Health Data
Data collected by a user that’s not shared with a physician is not considered to fall under the jurisdiction of HIPAA:
- Steps counted on a FitBit
- Calorie counters
- Blood sugar readings
- Heart rate readings
4. ePHI Stripped of Identifiers
Health data that has been stripped of the above identifiers, also called de-identified or anonymized data, cannot be used to identify an individual and thus doesn’t have to comply with HIPAA.
There are many data providers out there who can anonymize health care data and provide insights into general population trends and value care-based programs.
If your API only uses de-identified healthcare data then it doesn’t have to comply with HIPAA
Key HIPAA Regulations for API Developers
To comply with HIPAA, API developers need to adopt administrative, physical, and technical safeguards to protect the privacy and security of ePHI. This doesn’t just stop at encrypting data at rest, in transit, and in use, it also refers to how encryption keys are distributed, how PHI is referenced when being discussed by members of your team, and the establishment of regular internal audits of your systems. Everyone handling health information needs to fully understand their responsibilities under HIPAA to safeguard ePHI, avoid liability and protect your company.
HIPAA has 3 main regulations:
- Privacy Rule: Defines the standards and requirements for the protection, use, and disclosure of ePHI held or transmitted in any form including electronically and orally
- Security Rule: Establishes the standards for securing ePHI when it is at rest or in transit
- Breach Notification Rule: Dictates what and how notifications of breached ePHI should be made
HIPAA’s Privacy Rule Means Keeping Detailed API Logs
The Privacy Rule defines and limits circumstances in which your company may use and disclose ePHI, it establishes individuals’ rights regarding ePHI and it requires that you adopt administrative, physical, and technical safeguards to protect the privacy of ePHI. Basically, if you implement privacy best practices, then you’ll be able to comply with HIPAA’s privacy requirements.
As a Business Associate, you must grant to individuals the same rights that HIPAA specifies for Covered Entities. You’re only allowed to use or disclose ePHI as defined in the service agreement & BAA with your Covered Entity, or as permitted by your agreement with applicable individuals.
At the outset, you must provide a Notice of Privacy Practices to individuals (a document often sourced or developed in collaboration with your Covered Entity) which outlines how ePHI may and may not be used, and what the rights and obligations individuals have with their ePHI. After that you’ll need to have protocols in place to honor the following rights:
Right to Request Privacy Protection
If an individual requests it, you must:
- Restrict using or disclosing ePHI (with a few carve-outs)
- Deliver ePHI to them in a secure and confidential manner
- Communicate ePHI to them using alternate means
- Not disclose ePHI to a health plan if the individual has already paid for the service
Right to Logs of ePHI Disclosures
Logging API transactions is crucial to fulfilling the HIPAA requirement of individuals requesting an account of the disclosures of their ePHI. If an individual requests it, you must provide an account of each ePHI disclosure including:
- Date of disclosure
- Name of entity or person who received ePHI
- Brief description of ePHI disclosed
- Brief statement of purpose of the disclosure
Right to Access and Amend ePHI
- This is analogous to the Right to Access/Amend/Erase as defined in GPDR and CCPA
-
Request | What’s To Be Provided |
---|---|
Right to Access | Copy of their ePHI or form in a specific format |
Right to Amend | The ability to amend ePHI |
Right to Send | Transmission of a copy of ePHI to another person |
Administrative Requirements
Best practices calls for adopting various administrative issues to ensure compliance:
- Designate a Privacy Officer
- Train employees
- Implement safeguards to prevent intentional and accidental disclosures
- Establish a complaint system
- Sanction employees who violate your HIPAA policies and procedures
HIPAA’s Security Rule Means Encryption and More
Business Associates are required to ensure the confidentiality of ePHI in transit, at rest & in use, to protect against reasonably anticipated threats or hazards to the security of ePHI, and to protect against uses or disclosures that are not permitted by the Privacy Rule.
Fundamentally as an API developer, security falls into three areas: administrative, physical and technical safeguards.
Many of these are generic security best practices like: keeping audit logs on what’s been assessed/changed, choosing appropriate app/computer passwords, not sharing passwords, and encrypting portable devices that contain ePHI.
But some are specific to HeathTech, such as: signing off apps that contain ePHI after use, avoiding using individuals’ names, medical record numbers or account numbers in verbal communication, electronic chat or unencrypted email, promptly reporting any loss or theft of ePHI and informing the Privacy Officer of improper uses of ePHI.
Technical Safeguards for HIPAA Security
Technical safeguards are where API developers will spend the majority of their time when building compliant apps. To ensure the confidentiality of ePHI in transit, at rest & in use, ePHI should be encrypted and special care should be taken with key distribution. There’s been much discussion on what constitutes appropriate encryption, with HIPAA merely requiring a mechanism to encrypt and decrypt e-PHI, but adopting the latest recommendations from NIST would be a safe bet.
Safeguard | What’s Required | How to Implement in an API Environment |
---|---|---|
Access Control | Policy to allow only authorized access to ePHI | Authenticate users Assign unique ID for each user Devise access control rules Implement auto logoff Support emergency access to ePHI |
Audit Control | Formal procedure that records & examines access to systems containing ePHI | Keep API logs of all accesses Regularly run risk assessments to check proper functioning |
Integrity Control | Policy that ensures ePHI is not improperly altered or destroyed | Track any modification to ePHI |
Transmission Security | Technical security measures should guard against unauthorized access to ePHI in transit | Use client-side encryption when possible Verify HTTPS is used |
As an example of a completely secure API deployment that could support ePHI, the architecture below shows a secure proxy enabling zero-knowledge security with on-premises client-side encryption and Bring Your Own Key (BYOK). The privacy benefits of on-premises installation are gained, without the complexity of building and scaling your own data infrastructure. The master encryption keys are never stored on the provider's servers, rather the secure proxy supports popular key stores and handles key rotation automatically. Data is encrypted when in transit, at rest and in use.
HIPAA’s Breach Notification Rule Makes All Breaches Public
A breach is defined as the acquisition, access, use, or disclosure of ePHI in a manner not permitted by HIPAA’s Privacy Rule, which compromises the security or privacy of the ePHI. A breach is presumed unless you can demonstrate a low probability that the ePHI was compromised based on your risk assessment.
As a Business Associate, in event of a breach, you’re required to notify the Covered Entity and their customers within 60 days.
Penalties for Non-Compliance
In 2018 there were over 63K individual breaches of ePHI, including 302 affecting 500 or more individuals, resulting in OCR imposing fines totaling $27M.
HIPAA/HITECH defines a tiered penalty structure with scalable penalties based on the nature and circumstances of the violation, including knowledge and willfulness. Breaches are made public and the Business Associate can be subject to Civil and Criminal penalties.
Civil penalties are in the range $100 - $50,000 per violation, depending on the level of knowledge or intent associated with violation. Employees of a Business Associate who knowingly disclose ePHI in violation of HIPAA can be fined up to to $250,000 and imprisoned for 10 years depending on level of intent behind disclosure.
Health Care Is Ripe for Disruption and APIs Are Center Stage
COVID has acted as an accelerant of existing trends, with perhaps the most profound dislocation being in health care. The new normal will enable HealthTech vertical-based APIs that, behind the scenes, simplify and automate legacy business processes.
Legal Disclaimer: Nothing stated herein is legal advice. It is provided for informational purposes only. You should work closely with legal advisors to determine exactly how HIPAA may affect your business.
Published at DZone with permission of Lawrence Ebringer. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments