or Your Life is in Their Hands

As developers, there are some areas we generally shy away from. Nobody really wants to write apps that blow people up (real people, not game people), nobody wants to code the same thing that ten other apps already do, and nobody wants to make apps that interface with the medical community. The medical community is protected by HIPAA - the Health Insurance Portability and Accountability Act - and if you screw up your implementation, the Health and Human Services or Civil Rights arms of the government might crush your company with the kind of fines that might cause it to be dissolved. With that weight hanging over their heads, most developers will think twice or three times about making medical apps.

But really, it's not that bad.

If your application handles protected health information then you need to be HIPAA compliant. If you aren't, then you're subject to potential civil and criminal penalties as a result of HIPAA violations. You just need to be careful when you're holding, transmitting or disseminating information about what's going on inside people.

First a few definitions. PHI stands for Protected Health Information, that is any information held by a Covered Entity which concerns health status, provision of health care, or payment for health care that can be linked to an individual. A Covered Entity is a doctor, a medical practice, health care clearinghouses, employer sponsored health plans, health insurers, and medical service providers that engage in certain transactions - transactions that are about PHI. There is also EPHI, which is just the electronic form of PHI.

The HIPAA rules apply to both Covered Entities (they are covered by HIPAA) and their Business Associates. Business Associates are anyone doing business with Covered Entities, like you, Joe Developer.

HIPAA is neatly divided into five broad (some, very broad) rules: the Unique Identifiers Rule, the HIPAA Privacy Rule, the Transactions and Code Sets Rule, the HIPAA Security Rule, and the Enforcement Rule. Let's examine each in turn.

The Unique Identifiers Rule

All covered entities using electronic communications (physicians, hospitals, health insurance companies, etc) must use a single new National Provider Identifier.

The NPI replaces all other identifiers used by health plans, Medicare, Medicaid, and other government programs. The NPI does not replace a provider's DEA number, state license number, or tax identification number. The NPI is 10 alphanumeric digits, with the last digit being a checksum. The NPI cannot contain any embedded intelligence. The NPI is unique and national, never re-used, and except for institutions - a provider usually can have only one. An institution may obtain multiple NPIs for different "subparts" such as a free-standing cancer center or rehab facility.

This is probably the easiest of all the rules for developers to follow - you need to use a well-defined unique identifier to reference each bit of HIPAA stuff. It makes sense; otherwise you might get someone else's health records by mistake, which would violate HIPAA and the health care police would drop by parachute onto your facility, cut a hole through your roof, drop through and put a black bag over your head as they take you to their torture facility. Or so I've heard.

The HIPAA Privacy Rule

The use and disclosure of PHI held by Covered Entities and Business Associates that engage in certain transactions must be kept private by observing HIPAA regulations.

PHI here is covered is interpreted broadly to include any part of an individual's medical record or payment history. Covered entities must disclose any PHI requested by the individual within 30 days. They also must disclose PHI when required to do so by law or legal administrative request. A covered entity may disclose PHI to facilitate treatment, payment, or health care operations without patient authorization.

A reasonable effort must be made to disclose only the minimum necessary information required to achieve its purpose. Covered entities are required to notify individuals of uses of their PHI and keep track of all disclosures.

Protection of PHI extends to 50 years after death.

I mean, wow, this is a hell of a burden for Covered Entities and their Business Associates. Hold PHI securely, provide it when asked for, or needed, or demanded by the government. Tell people when it's been used. And keep it all for 50 years?! If there was ever a need for a comprehensive storage and notification system, the HIPAA Privacy Rule screams for it.

The Transactions and Code Sets Rule

HIPAA-covered health plans are now required to use standardized HIPAA electronic transactions.

Hooray! Finally something software is good at: well-defined transactions. While there may be some ambiguity, developers still can come out on top, except... Look at just the next level of categories for transactions:

• EDI Health Care Claim Transaction Set
• EDI Retail Pharmacy Claim Transaction
• EDI Health Care Claim Payment/Advice Transaction Set
• EDI Benefit Enrollment and Maintenance Set
• EDI Payroll Deducted and other group Premium Payment for Insurance Products
• EDI Health Care Eligibility/Benefit Inquiry
• EDI Health Care Eligibility/Benefit Response
• EDI Health Care Claim Status Request
• EDI Health Care Claim Status Notification
• EDI Health Care Service Review Information
• EDI Functional Acknowledgement Transaction Set

Tractable, yes. And well-defined. Which only means there are lots of gaps and things that looked good on paper but may not work so well in practice. But that never happens in any other sort of software project, right?

The HIPAA Security Rule

All EPHI must be kept secure by using administrative, physical, and technical security safeguards.

That's three safeguards, which come down to:

1. Administrative : policies and procedures designed to clearly show how the entity will comply.
2. Physical : controls to protect against inappropriate physical access to protected data.
3. Technical : controls to securely access computer systems, enabling covered entities to protect communications containing PHI transmitted electronically over open networks from being intercepted by anyone other than the intended recipient.

Us developers, we be good at all that eStuff, and much of this follows from the kinds of web development and cloud technologies that have come to the forefront over the last decade. This is very heartening, as long as things aren't completely unreasonable. But more on that in a moment.

The HIPAA Enforcement Rule

There are civil monetary penalties for violating HIPAA rules and establishes procedures for investigations and hearings for HIPAA violations.

This is what keeps most companies out of the medical space. Since HIPAA was enacted by the government, the most frequent violations have come from:

• Misuse and unauthorized disclosures of PHI.
  
• No protection in place for health information.
• Patient was unable to access their health information.
• Using or disclosing more than the minimum necessary protected health information.
• No safeguards of electronic protected health information.

Oh, and those aren't just violations. They're prosecuted violations. Fines can be LARGE my friends, and the government takes HIPAA quite seriously.

So, in short…

If your device or application shares the user's personal health data held in the app or device with a covered entity (such as a doctor) then you are dealing with protected health information and need to be HIPAA compliant.

If you are building a device or application that collects the user's personal health information, but it is not shared with a covered entity at any point in time, then you do not need to be HIPAA compliant and do not violate the HIPAA Privacy Rule.

And for your edification, here's a HIPAA Compliance Checklist

• You must put safeguards in place to protect patient health information.
• You must reasonably limit use and sharing of protected health information to what's minimally necessary to accomplish the intended purpose.
• You must have agreements in place with service providers that perform functions for Covered Entities. And Business Associate Agreements ensure that service providers - the Business Associates - use, safeguard and disclose patient information properly.
• You must limit who can access patient health information, and logs of the patient health information you capture and dispense must be kept and protected.
  

And finally, some Takeaways

HIPAA isn’t hard to understand, you just have to concentrate on where the personal health information is and who can see it, and track what you do with it.

Certification will keep you out of trouble, but it’s the spirit of safely handling an individuals’ health information that’s the real point. You should really care that you are protecting people. The spirit of HIPAA should be followed to make reasonable health systems.

Meteor is a great fit for HIPAA... More will be upcoming soon!