The Health Insurance Portability And Accountability Act (HIPAA) was signed into law in the year 1996. It is a legislation which provides security provisions and data privacy, in order to keep patients’ medical information safe. In the year 2013, HHS put in place the HIPAA Omnibus Rule, in order to implement a few modifications to the earlier version, in accordance with certain guidelines, which were set in 2009 by the HITECH Act.
At a high level, HIPAA requirements are divided into 5 Rules, which are:
1. Privacy Rule Defines Protected Health Information (PHI) and dictates privacy disclosure rules for all types of PHI, including verbal and paper-form.
2. Security Rule Sets reasonable high-level standards for technology used to store, process, create, transmit, or access PHI in electronic form.
3. Breach Notification Rule Defines rules for the discovery, timing, and notification of a breach, and exceptions.
4. Enforcement Rule Adds the teeth to HIPAA compliance by allowing penalties to be assessed for HIPAA violations.
5. HITECH Act & Final Omnibus Rule Merges the HITECH Rules to enhance the "original" HIPAA Rules above and adds some more clarification in 2013.
This HIPAA primer is designed for Technology Startups servicing the Healthcare space, who are considered "Business Associates" under HIPAA. This is usually because they do not fit the definition of a "Covered Entity" (i.e. they are not Health care providers, a Health Plan, or a Health care Clearinghouse). However, these startups may have those Covered Entities as customers. These customers may then designate them as Business Associates and require them to be HIPAA compliant.
Business associate functions and activities include: claims processing or administration; data analysis, processing or administration; utilization review; quality assurance; billing; benefit management; practice management; and repricing. Business associate services are: legal; actuarial; accounting; consulting; data aggregation; management; administrative; accreditation; and financial.
HIPAA Privacy Rule for Startups (Business Associates)
Privacy Rule obligations for your Tech Startup generally depend on the language in the Business Associate Agreement (commonly referred to as a "BAA") you have signed with your customer (do read it even if you're not a lawyer) and the type of services you provide. Boilerplate BAA language will usually not be customized to the services you provide. It will assign Privacy Rule obligations to you as they relate to the services you provide at a high level. It is up to you to decide which parts of the rule apply to you. However, you can greatly reduce your obligations as much as possible by making sure that you:
Do not verbally discuss PHI
Do not print out PHI
Limit access to ePHI as much as possible
Where access cannot be limited; De-identify PHI as much as possible
These rules can be put into your organization's policy and training documentation and shouldn't be too hard to implement at a tech startup which isn't directly in the business of provide care.
There are also some other ways to reduce exposure to your HIPAA Privacy Rule obligations. Before signing the BAA, clarify with your customers as to who owns the obligations with respect to the HIPAA-assigned patient rights, namely:
Patients' Access to PHI
Patients' Amendment of PHI
Patients' Accounting of disclosures of PHI, and their right to
Prevent further disclosure of PHI
It is likely that covered entity customers like hospitals or health plans may actually want to retain their direct line of communication with their patients and proxy any requests that need your interaction. This is a win-win scenario which reduces the time you spend handling individual requests from patients and also the liability of reviewing and approving such sensitive requests.
HIPAA Security Rule for Startups
As far as Healthcare Startups are concerned, the HIPAA Security Rule is responsible for the majority of the effort required to achieve HIPAA compliance. The HIPAA Security Rule has four major sections, created to identify relevant security safeguards that help achieve compliance: 1) Physical; 2) Administrative; 3) Technical, and 4) Policies, Procedures, and Documentation Requirements.
Organizations must implement reasonable and appropriate controls and management policies and procedures to comply with all HIPAA administrative, physical, and technical safeguards. Understanding these controls is part of the required HIPAA Risk Assessment that all organizations must perform on a regular basis under HIPAA.
Under the HIPAA Security Rule, implementation of standards is required, and implementation specifications are categorized as either “required” (R) or “addressable” (A). For required specifications, covered entities must implement the specifications as defined in the Security Rule. For addressable specifications, a covered entity must assess whether the implementation of the specification is reasonable and appropriate for its environment and the extent to which it is appropriate to protect ePHI. Following the security risk assessment, the covered entity must either implement the addressable specification, or document why it would not be reasonable and appropriate to implement and identify alternative and/or compensating safeguards as reasonable and appropriate.
This may all sound complicated and confusing. Overseer Security can make this process as hands-off for your as possible. Email us at firstname.lastname@example.org to find out how we can help.
HIPAA Breach Notification Rule for Startups
HIPAA Business Associates are generally required to report violations to the original owners of the PHI data. This means that they are required to notify their customers and not the department of Health and Human Services ("HHS"). The Breach Notification Rule sets a reasonable timeline for notification (no later than 60 days). However, your customers' Business Associate Agreements may define a different set of rules, which may pre-empt the Breach Notification Rule. Some common issues are where a BAA may;
Require a shorter delay in notification (e.g. 5 days instead of 60 days)
Require notification of "security incidents" where the term is defined in an overly broad manner (e.g. it does not exclude Internet backscatter noise, like pings)