This HIPAA training is provided free for use. Haekka offers a fully integrated training platform in Slack, enabling customers to meet their compliance, privacy, and security training requirements using modern, relevant content delivered 100% in Slack.

Introduction to HIPAA

HIPAA isn’t hard. It’s just opaque, and the organizational penalties can be high, so people fear it. HIPAA also does not map well to the way people work today. This HIPAA training will make HIPAA relevant and easy to follow.

HIPAA stands for Health Information Portability and Accountability Act. It was enacted by Congress in 1996. It went into effect in stages from 2001 to 2006. The intention of HIPAA is to standardize healthcare transactions and to create protections for the use of protected health information (PHI).

At the time it was written, HIPAA was almost exclusively concerned with traditional healthcare organizations - care delivery organizations and health insurance companies. Because HIPAA was focused on data exchange and portability, It also covered healthcare clearinghouses that process and facilitate the exchange of healthcare data.

HIPAA was originally written before the first Internet bubble. Since that time, both the healthcare market and the technology market have changed considerably. As such, HIPAA has been updated, most notably in 2013 with the HIPAA Omnibus Rule, which expanded coverage to service and technology partners of healthcare organizations.

The big example of how HIPAA was expanded is that HIPAA now covers cloud and SaaS providers that have healthcare customers. In a world of APIs, app ecosystems and marketplaces, and data sharing, HIPAA coverage can expand across multiple technology and organizational layers.

Despite this expansion in 2013, traditional healthcare organizations remain the focal point for HIPAA.

For the purposes of this HIPAA training, the area we are focused on is the protection of PHI. When it comes to protecting PHI, the essence of the HIPAA rules can be distilled down into two sections.

1. Privacy. Ensuring access to PHI is only allowed for approved purposes (care delivery and billing are the most common purposes under HIPAA). This is where your privacy policies and procedures come from. This is the when and why of HIPAA.
2. Security. Ensuring best practices to secure processes and technology. This is where your policies and procedures are implemented. This is the how of HIPAA.

HIPAA is really that simple.

When you are uncertain about compliance in any of your day to day work, do not hesitate to reach out to your manager, human resources, compliance people, or data protection officer (if you have one). It is their job, and a requirement of regulation, for them to help you navigate these waters. You are not alone.

Your responsibility, regardless of the functional area in which you work, if you work for an organization that in some way touches PHI, is to make sure you are always focused on protecting PHI from unauthorized access.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Organizations Covered under HIPAA

HIPAA is strict in how it defines entity types. And those entity types determine whether organizations need to comply with HIPAA and determine the liability of the organization.

When HIPAA was written, it was explicit about the types of organizations that needed to comply with it. HIPAA defines two types of organizations:

1. Covered Entities. These include healthcare providers, healthcare insurance companies, and healthcare clearinghouses (healthcare transaction processors).
2. Business Associates. These are organizations that covered entities work with 3rd party organizations to help carry out operations and have access to health data. The most common business associates are electronic health record (EHR) companies and revenue cycle management (RCM) companies.

Covered entities are a relic of traditional healthcare delivery. HHS defines covered entities as entities that deliver care and “electronically transmits health information in connection with certain transactions”; “transactions” here mean traditional insurance claims. The last ten years have seen new technology-enabled healthcare delivery models and services, many of which do not fit the mold of how HIPAA defines covered entities and, as such, do not have to comply with HIPAA. Direct to consumer mobile or web apps that collect and provide medical guidance or “care”, either by providers or AI / ML, but do not transmit standard transactions, are not covered entities under HIPAA.

In 2013, HIPAA was updated to extend the definition of business associates to include 3rd party organizations that assist business associates. It called this new layer of business associates “subcontractors”, or essentially business associates of business associates. The most common subcontractors are technology companies like cloud service providers (AWS, Microsoft Azure, and Google Cloud Platform).

Under HIPAA, covered entities are the owners of health data. They also own the liability for health records if a data breach occurs. When a covered entity works with a business associate, they extend that liability to the business associate through a business associate agreement. When a business associate works with a subcontractor, they extend their own liability to the business associate through a business associate agreement.

As you can imagine, there are 1,000s of covered entities and almost all of them are large organizations with complex operations. Most covered entities work with many different 3rd party organizations as business associates. Business associates, increasingly reliant on technology partners, have many subcontractors. Because of this chain of liability from covered entities to business associates to subcontractors, there are tons of business associate agreements and tons of liability in healthcare. It’s a mess and a lawyer's dream.

The main thing for you to understand is the type of entity you work for and the 3rd parties that are covered under business associate agreements.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Agreements under HIPAA - Business Associate Agreements (BAAs)

The most important form of agreement under HIPAA is the business associate agreement (BAA). Much of where the rubber meets the road in HIPAA is defined in business associate agreements. BAAs are a key requirement of HIPAA and are mandated between business associates and covered entities as well as business associates and subcontractors.

BAAs define the responsibilities and liabilities of entities under HIPAA. Covered entities are at the root of HIPAA and all liability under HIPAA emanates out from them. Covered entities technically “own” PHI and patients. Business associates provide technology and services to covered entities.

A business associate agreement could include clauses on breach reporting times, use of de-identified data, responsibilities during a breach, liability for certain security features and configurations. and a host of other elements.

There is not a standard template for BAAs. As BAAs chain together entities from covered entities through multiple business associates, the responsibilities and liabilities become very opaque.

Below is an example of a chain of organizations linked by business associate agreements.

• A covered entity works with a telemedicine provider. There is a BAA in place between them that mandates the telemedicine provider to notify the covered entity of a breach within 72 hours.
• The telemedicine provider leverages a cloud platform for its technology. There is a BAA between the telemedicine provider and the cloud platform provider. Under the BAA, the cloud platform provider is mandated to notify the telemedicine provider of a breach within 60 days (max allowable under HIPAA).

The above is a simple and pretty typical example. In this example, the telemedicine provider may not learn about a data breach for 60 days and only then would be able to notify the covered entity. Many times, BAAs from covered entities put clauses into BAAs that require their business associates to have terms as strict, or more stringent, than the covered entities BAAs. In practice, this can easily be violated.

If you are a business associate, read and understand your BAAs as they will define many of your requirements under HIPAA.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Covered by HIPAA

HIPAA is concerned with protected health information (PHI). Think of PHI as identifiable data, or personally identifiable information (PII), that is associated with health data. PII + health data = PHI. Health data can be health status (condition, medication, etc), payment for health services, and delivery of care.

To determine if data is PHI, one additional filter needs to be applied. According to Health and Human Services (HHS) - PHI is personal health information held by covered entities. Identifiable health data held by an Internet site or mobile app that is not owned or being used by a covered entity is not PHI. Many direct to consumer health companies, such as personal health record storage companies, are not covered entities so the identifiable health data they collect, store and process is not PHI.

HIPAA is focused on traditional care delivery organizations and has not been updated to reflect new approaches to care, especially direct to consumer health offerings. As such, not all identifiable data is PHI.

While HIPAA remains behind the times when it comes to care delivery models, the definition of PII has evolved over the last several years with expanded digital footprints and new technologies. In addition to traditional items like names, social security numbers, medical records numbers, things like social media account names, IP addresses, cookies, and even web browser profiles can identify individuals or be used to trace the identity of individuals.

The US Government defines PII as “information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other personal or identifying information that is linked or linkable to a specific individual.”

PII does not have a strict list of items. It needs to be determined on a case by case basis considering different ways of combining data.

The rule of thumb you should follow is to use your best judgment in assessing if data is considered PII and, if combined with health data, is it PHI.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

HIPAA - Privacy Rule

The Privacy Rule defines the administrative requirements of HIPAA. It’s easiest to think of the Privacy Rule as the “what” of HIPAA.

Entity types

Covered entities (care providers, insurance companies and clearinghouses) and business associates (3rd parties that support covered entities.

Protected Health Information (PHI)

Protected health information (PHI), or the data covered under HIPAA.

Required disclosures of PHI

Covered entities must disclose PHI in two situations - 1) to the individual (or their authorized representative) and 2) to HHS for the purpose of an investigation.

Permitted disclosures of PHI

In addition to the above 2 required disclosures, PHI can be disclosed for the following explicit reasons:

1. Delivery of care;
2. Payment for care.
3. Healthcare operations.

Delivery of care and payment for care are self-explanatory. “Healthcare operations”, on the other hand, is a general bucket allowing for interpretation and sometimes abuse of PHI. “Healthcare operations” includes business functions, fundraising, fraud prevention, case management, de-identification, and for improving activities of covered entities. Recently, these generic uses of PHI have been used to allow for mass data sharing for data analytics (ML and AI).

Minimum necessary

PHI should only be collected and accessed in the minimum necessary way for the covered entity to carry out its functions.

Training

HIPAA requires that all workforce members (employees, consultants, volunteers) receive training about HIPAA and the policies and procedures of the organization.

Privacy Officer

A privacy official must be appointed to be responsible for creating and maintaining privacy policies and procedures.

Policies and procedures

Policies and procedures must be created and ensure alignment with HIPAA requirements.

Penalties

Violations under HIPAA are $100-$50,000 per violation, with an annual cap of $1.5M.

Notice of Privacy practice

Covered entities must provide customers with clear notice about the types of data collected, the use of the data being collected, the individual’s rights in terms of the data, and a point of contact information related to individual data. This is similar to what newer regulations, such as GDPR and CCPA, require in terms of data subject requests, data usage, and disclosures.

There’s more to the Privacy Rule but those details are only relevant if you are a healthcare compliance attorney or Privacy Officer for a covered entity or business associate.

The Privacy Rule provides the definitions for HIPAA and the first step towards a compliance program.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

HIPAA - Security Rule

The Security Rule defines the technical requirements of HIPAA. Like many compliance regimes, it is heavily aligned with NIST security standards. The Security Rule is divided into three categories of requirements - 1) Administrative, 2) Physical, and 3) Technical.

Requirements in the HIPAA Security Rule are either Required or Addressable, which is a bit confusing because all of the HIPAA requirements are actually required. The main difference between Required and Addressable is that Addressable requirements can be met with other, mitigating controls.

Administrative Safeguards

Risk Assessment

Under HIPAA, every organization must assess the risk to PHI. The process involves identifying threats, risk, and impacts to an organization if PHI is breached. Mitigating controls should be established and documented for all risks.

This should be done on a regular basis. As a rule of thumb, a risk assessment should be performed on a regular, annual cadence as well as with significant changes to procedures or technologies.

The definitive guide on performing risk assessments and managing risk is NIST - https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.

Security Personnel

Similar to the Privacy Rule personnel requirement, an individual needs to be appointed to create and maintain security policies and procedures.

Information Access

Role-based access policies and procedures need to be implemented. HIPAA audits frown on shared accounts, even privileged accounts like root or admin. All accounts should be assigned to individuals and only individuals that need access to PHI should be granted access to PHI.

Workforce Training

All workforce members have to be trained in security policies and procedures. In practical, day-to-day work, specific procedures and types of security implementations (backups schedules, encryption standards, etc) should be readily accessible to ensure ongoing compliance.

Evaluation

Organizations need to do regular assessments of how their security posture aligns with the Security Rule. Some form of regular, external audit, vulnerability assessment, and/or penetration test should be performed as a part of ongoing evaluation.

Physical Safeguards

Facility Access

Access to physical facilities (offices, data centers, etc) needs to be restricted. In the case of cloud-based technology, this is addressed by the cloud services provider (AWS, Microsoft Azure, etc).

Device Security

Computers and other devices that access PHI or systems with access to PHI need to be secured. This falls under the bucket of endpoint or perimeter security.

Technical Safeguards

Access Management

Technical security controls need to be implemented to secure technology that has access to PHI.

Audit Controls

Tools need to be implemented to log access to systems and data.

Integrity Controls

PHI needs to be monitored to ensure it is not improperly modified or deleted

Data Transmission

Data in transit needs to be secured. The most common means is through end to end encryption.

The Security Rule defines the ways in which an organization is required to implement the technical controls and procedures.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Roles under HIPAA

There are two important roles defined under HIPAA. Many companies that are new to HIPAA appoint one data officer as a checkbox for HIPAA. Both roles can be filled by the same person though, for best security practices, the duties would ideally be separated between multiple people. The distinction between the roles is important as there are a lot of responsibilities associated with each.

One role is defined by the Privacy Rule and one role is required by the Security Rule. Similar to the distinction between the rules themselves, the privacy officials define how to do things (policies and procedures) and the security official needs to ensure implementation aligns with those policies and procedures.

Privacy Official

The privacy rule mandates that organizations appoint a privacy official. The key task for this official is to create and maintain the organization’s privacy policies and procedures. These policies and procedures need to address all of the requirements of HIPAA. In addition, the privacy official is often, and should, be responsible for answering questions about permitted disclosures of PHI.

Security Official

The security official required by the Security Rule is in charge of implementing the privacy policies and procedures. Sometimes this means creating additional procedures that map privacy policies to day to day work. We see this most when it comes to applying privacy policies to modern technology such as cloud-based technologies.

The two roles under HIPAA correspond to the two rules of HIPAA.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Penalties under HIPAA

Penalties under HIPAA have been updated several times since HIPAA was first written. The most recent updates were rolled out as a part of the HIPAA Omnibus rule in 2013.

HIPAA violations fall under the purview of the Office for Civil Rights (OCR) under Health and Human Services (OCR). HIPAA violations are issued for violating, or not adhering to, HIPAA rules. Violations do not necessarily require a security incident or data breach to be issued. In fact, violations can be reported freely on this HHS website - https://ocrportal.hhs.gov/ocr/smartscreen/main.jsf.

Penalties for HIPAA violations are most frequently civil in nature though individual criminal punishment, while exceedingly rare, is possible. For both civil and criminal penalties, their are tiered penalties, outlined below.

Civil Penalties

Criminal Penalties

HIPAA violations and penalties result from not complying with HIPAA and do not require a breach to be issued.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Breaches and Security Incidents

Data breaches and security incidents are often spoken of in the same context. While they are related, they are not the same. And the distinction between the two terms is very important in HIPAA.

• Security Incident is an event that puts corporate systems and data at risk. It is often, but not always, the result of not complying with security policies.
• A data breach is when covered information, under HIPAA it is PHI, is disclosed in an unauthorized manner or non-permissible way.

A security incident increases the risk of a data breach but it is not a data breach. An example might be a misconfigured server where a default account password might not have been changed. In order to determine if this incident resulted in a data breach, an investigation must be conducted to assess if the vulnerable server account was used to gain unauthorized access to data on the server or accessible from the server.

Every security incident and breach needs to be investigated, with the investigation and outcome well documented.

Under HIPAA, there are no reporting requirements for security incidents.

Under HIPAA, there are several reporting requirements for data breaches that covered entities must follow, listed below.

• Individuals. Individuals with data impacted by a data breach need to be notified within 60 days.
• Media. If more than 500 individuals are impacted by a breach, the media needs to be notified within 60 days.
• HHS. If more than 500 individuals are impacted by a breach, HHS needs to be notified within 60 days. If a breach impacts less than 500 individuals, HHS can be notified annually.

Business associates have slightly different reporting requirements than covered entities. Business associates are required to notify the covered entities they support within 60 days of a breach. Business associates should also assist covered entities in identifying the impacted individuals. The requirements of business associates are typically defined in a business associate agreement (BAA).

Every security incident must be investigated and, if it is determined that a data breach has occurred, the proper notifications should be done as fast as possible and no later than 60 days from the determination that a data breach occurred.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Subjects Rights under HIPAA

Data subject rights have gotten a lot of attention lately because of GDPR and CCPA. Some of the most hotly discussed requirements in these new regulations pertain to individual data rights. These data rights have rightly raised public awareness of privacy issues.

With HIPAA, data rights are not new. Under HIPAA, individuals have the right to their data as well as the right to have their data sent to another individual or provider. Unfortunately, there is not a prescribed process or technology to request and access medical records.

According to HIPAA, covered entities have up to 30 days, at the maximum, to provide access to medical records. Additionally, covered entities can charge a reasonable fee based on the cost of providing medical records (printing, CD, USB, etc).

There are two exceptions to these data rights under HIPAA - psychotherapy notes and information used for an investigation.

State laws can be stricter than HIPAA when it comes to patient access to their own medical records. In these cases, the stricter state laws take precedent.

Data subject requests not new under HIPAA and fall on covered entities to process the requests and provide the data to individuals.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Retention under HIPAA

Contrary to what most people think, HIPAA does not define specific rules around data retention for medical records or PHI. Requirements around data retention are defined by state medical boards, not HHS.

HIPAA is more concerned with portability and privacy than long term data retention. Because of that, HIPAA does have requirements for certain retaining data, just not medical records.

When most people think of medical records retention regulations, what they are actually thinking about our state medical board requirements.HIPAA requires that covered entities retain their policies and procedures, as well as assessments. In retaining this data, especially policies, some form of version should be implemented to track dates of changes and authors of changes.

Typically, retaining medical records is prudent for follow-up care, medical-legal reasons, and payment for healthcare services.

Under HIPAA, you don’t have to retain PHI but you should keep records of privacy policies and procedures.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Anonymization under HIPAA

HIPAA explicitly allows for the de-identification of PHI and prescribes two methods to carry it out Following these methods, de-identified data is not longer PHI and HIPAA does not govern how it is used or where it is shared.

The two methods HIPAA defines for de-identification of PHI are:

1. Expert Determination. A “person with appropriate knowledge of and experience” determines that risk of re-identification of PHI is very small.
2. Safe Harbor. Data that identifies an individual is removed from the records. The list of data items that need to be removed is defined by HIPAA and can be found on this page.

HIPAA also allows for the re-identification of de-identified data. The means, or any unique coding or algorithms, used to re-identify data cannot be shared. If those are shared, it is a violation of HIPAA. In essence, the means of re-identification needs to be handled like PHI.

Business associates, increasingly technology companies that support covered entities, cannot de-identify data unless it is explicitly allowed in business associate agreements. This is often a point of contention in negotiations between technology companies and covered entities.

There are prescribed methods to de-identify PHI and, once data is de-identified, HIPAA does not apply anymore. If you’re a business associate, check your BAA.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

HIPAA Training

If you work for an organization and your role touches PHI in some way or even has the potential of touching PHI, then you should receive training specific to HIPAA and your organization’s policies and procedures.

At a minimum, HIPAA requires training in two buckets:

1. Privacy training for employees on privacy, policies, and procedures at onboarding and with changes to organizational policies and procedures; and
2. Security training for employees.

All training needs to be documented.

Practicing the bare minimum checks the box on HIPAA training requirements but it is unlikely to be successful at ensuring employees understand and follow privacy policies and procedures. Since following policies and procedures is an essential part of passing audits, ensuring employees comprehend privacy policies is essential. The best way to do that is to through continuous training and exposure to relevant content.

HIPAA prescribes bare minimum training requirements for privacy and security but doing the bare minimum won’t lead to following policies and procedures.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

HIPAA and Technology

HIPAA is not new. It was written before there was a “cloud”. Also, the organizations that need to comply with HIPAA in 2020 is incredibly broad, which is why HIPAA can be frustratingly vague.

Increasingly, incumbents and new entrants into healthcare are using modern technology. As healthcare modernizes its technology stack, it is dragging HIPAA along for the ride.

When it comes to software development in any regulated industry, both security and privacy need to be a part of the system development life cycle (SDLC). Privacy reviews should be a part of feature documentation before any software is actually written. Then there should be a privacy signoff before features are put into a production product. These reviews and signoffs should be documented.

The other major technology area where there remains confusion and ambiguity is the cloud. The major cloud providers are, in this order, 1) Amazon Web Services (AWS), 2) Microsoft Azure and 3) Google Cloud Platform (GCP). The cloud has ushered in a new term - HIPAA Eligible. The cloud providers have 100s of cloud services. Some, but not all of those cloud services are HIPAA eligible. This basically means that the cloud providers will sign a BAA with you if you want to use these HIPAA eligible services for PHI. HIPAA eligible does not mean the cloud service is configured in a way that complies with the HIPAA Security Rule, doing that is up to the cloud customer.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Audits under HIPAA

Contrary to popular belief and usage, the term “HIPAA Compliant” does not really mean anything. It doesn’t mean anything because it can mean countless things. Did an organization or a product pass a HIPAA audit? And by “pass”, how did the auditor assess the organization or product? An audit is also a point in time. The day after the audit, the organization could change a fundamental thing but the audit would still be a “pass”.

HIPAA does not have approved auditors and does not have an approved certification. As such, many people throw around the term “HIPAA Compliant” without much regard for what it means. This is the reason many covered entities require annual or even quarterly security assessments of all of their partners and vendors.

There have been attempts to fix this. The most popular is HITRUST, which is anchored on a meta-framework that maps to HIPAA, is prescriptive in what it requires, has approved assessors, and issues a true Certification. Some covered entities, especially insurance companies, take HITRUST Certifications in place of their own security assessments.

Whether you do a traditional HIPAA audit or a try for a HITRUST Certification, the most important thing to do is create policies that map to HIPAA (or HITRUST), use those policies to establish procedures for how work should be done, and then document how those procedures are followed across your organization. Having ready access to a body of evidence, your documentation will make any audits and security assessments faster. That alone will also significantly reduce the risk to your organization in the case of a data breach.

Don’t put any stock in the words “HIPAA Compliant”; instead, look for evidence of implementation of policies and procedures.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

© 2020 DayZero Inc. All rights reserved.

Questions? Reach out to us - hello@haekka.com