In a previous post we threatened you with a future post on HIPAA, the rules that govern healthcare privacy and the protection of individual health information in the US. So due to popular demand (actually only 2 mHealth geeks asked for it) here is our brief intro to HIPAA.
HIPAA stands for the Healthcare Insurance Portability and Accountability Act of 1996 and it is administered by the Office of Civil Rights (OCR) division of the US Department of Health and Human Services (HHS) (welcome to the alphabet soup of US government regulatory agencies!). As the name suggests, HIPAA is intended for health insurance plans, healthcare providers, clearing houses (middle-men companies that transfer claim and payment data back and forth between providers and insurers), and their associates. The term “associates” is meant to capture any entity that deals with these explicitly covered entities or that stores private health information. This of course includes any software or health IT (HIT) company that develops software or systems that store or manipulate information covered by HIPAA.
So what is this information? A term that you will commonly come across in HIPAA discussions is protected health information (PHI). This defines the type of information covered by HIPAA and includes all “individually identifiable health information” held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. In other words, if a piece of health information can be associated with a specific individual, however it is transmitted, it is protected by HIPAA. A corollary to this is that if a piece of health information is anonymized (that is all identifiable information is removed), it is not protected by HIPAA. This is not as simple as just removing the name because there may be other ways one can infer the identity of a person from other health information included in the record, depending on circumstances. For example, if there are 3 patients on a unit of whom only one is 57 years old, and I remove the name but leave the date of birth and period of stay in the record, one could conceivably track the record back to its owner with a little effort, therefore the record is not truly anonymized and is considered PHI.
HIPAA has two main parts, the Privacy Rule and the Security Rule.
The Privacy Rule addresses the nuts and bolts of the law, it defines PHI, permitted disclosures (eg, to patient, family or third parties), the types of transactions that are covered by HIPAA, administrative and auditing requirements, etc. The privacy rule covers all forms of PHI transfer or communication (oral, electronic, written, etc). This rule sets the privacy standards, which is why it’s also called the Standards for Privacy of Individually Identifiable Health Information.
The Security Rule, or more affectionately called the Security Standards for the Protection of Electronic Protected Health Information, covers protected health information in electronic form (e-PHI). The rule does not provide explicit and extensive guidelines as to how e-PHI should be safeguarded, only general guidelines. These guidelines are outlined under the General Rules section of the Security Rule which reads as follows:
The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI.
Specifically, covered entities must:
- Ensure the confidentiality, integrity, and availability of all e-PHI they create, receive, maintain or transmit
- Identify and protect against reasonably anticipated threats to the security or integrity of the information
- Protect against reasonably anticipated, impermissible uses or disclosures
- Ensure compliance by their workforce
The Rule does not dictate those measures but requires the covered entity to consider:
- Its size, complexity, and capabilities
- Its technical, hardware, and software infrastructure
- The costs of security measures
- The likelihood and possible impact of potential risks to e-PHI
The Risk Analysis and Management section of the Security Rule outlines in very general terms some measures a covered entity should take to periodically audit its security processes:
A risk analysis process includes, but is not limited to, the following activities:
- Evaluate the likelihood and impact of potential risks to e-PHI
- Implement appropriate security measures to address the risks identified in the risk analysis
- Document the chosen security measures and, where required, the rationale for adopting those measures
- Maintain continuous, reasonable, and appropriate security protections
What is meant by reasonable and appropriate measures to make a system or software HIPAA-complient is largely left to the developer. However, it is safe to say that HIPAA compliance should include the usual data security measures including:
- Password protection including strength assessment and periodic change enforcement capabilities
- Strong encryption algorithms (on media and in network transfer); for example, AES 128-bit key
- Physical security of systems and network
- Access control layers
- Full transaction auditing capability
- Etc, etc
HIPAA does not define a clear HIPAA certification process or certifying authority. Many big and small auditing and computer security companies provide HIPAA auditing services, and if you are undertaking a project that involves interaction with HIPAA covered entities or the storage or transfer of e-PHI, you are well advised to consult such an auditor and/or a HIPAA attorney.
More information on the HIPAA rules can be obtained on the HHS website here:
Summary of the HIPAA Privacy Rule:
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html
Summary of the HIPAA Security Rule:
http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html
Enjoy!