Legal Documentation
Terms and Policies:
HIPAA:
LAST UPDATED: JULY 16, 2018
This material and content is released as open source. Available educational material for HIPAA is largely outdated in its coverage of technology and utility to vendors is extremely limited. The goal of releasing this as open source is that the growing community of healthcare companies can contribute, enrich, and keep it relevant over time. Refer to the GitLab repository at GitLab.com BroadStreet Policies for the full version history of these policies. Please send e-mail to hello@broadstreet.io to request access.
This is an overview training of HIPAA, with coverage of key definitions and provisions for the handling of HIPAA-relevant data. The material in this book is intended for individuals who work for organizations that provide technology and technology-enabled services to health systems, payers, physicians, pharma, and other healthcare organizations. It leans more heavily on the use of modern, cloud-based technologies than traditional client side software.
The training covers the following topics:
BroadStreet is in the business of providing compliant software as a service (SaaS) to our customers so they can better track community health without having to worry about gathering data, complicated analytics, and can easily communicate in a modern way, via the web. BroadStreet’s mission is to build an end-to-end SaaS solution so our customers can focus on what matters, building health communities.
So why is HIPAA training important? The rationale is best explained by this quote from Cory Doctorow –
We should treat personal electronic data with the same care and respect as weapons-grade plutonium – it is dangerous, long-lasting and once it has leaked, there’s no getting it back.
The goal of this training is to ensure that you understand the importance (and ways) of protecting sensitive data and apply it regularly both at your work and in your personal life. This training is important because it will educate you on:
So please – take the time to read through this carefully.
HIPAA stands for the Health Insurance Portability and Accountability Act. If you’re not familiar with HIPAA, or you haven’t spent a lot of time in the healthcare industry, you may not realize that spelling “HIPAA” wrong is a running joke. Just remember that “HIPAA” vs “hippo” – there’s only one “P.”
What’s interesting about the acronym “HIPAA” is that the “P” does not stand for “privacy” and the “I” does not stand for “information.” It’s interesting because the general perception of HIPAA, which is accurate, is that its main purpose is to “protect” health “information.” The reason for this perception is that the protection of health information is essential to avoid financial penalties for breaches and non-compliance with HIPAA.
While much of HIPAA, especially as it is enforced by compliance officers at large healthcare organizations to avoid financial risk, is about securing data and not releasing it unless authorized, HIPAA also sets rules around how data is exchanged between systems and how authorizations are done to allow for access to individual medical records.
The one other essential acronym with HIPAA is PHI, which stands for Protected Health Information. PHI is often also referred to as “personal health information,” which is an accurate description of PHI. PHI is simple: It’s the combination of a personal identifier (name, DOB, SSN, IP address, email, etc.) with some health-related data (condition, medication, lab, encounter, health payment, etc.).
The spirit of HIPAA is simple:
These HIPAA training materials come mostly from Datica Health, Inc, some of which have been modified by BroadStreet. We would like to thank Datica for being so generous in opening up their HIPPAA compliance and training materials and putting health consumers and the community first.
Well, for three key reasons:
With an increasing move to this amorphous entity called the cloud, with its associated technical complexities, security and privacy guidelines / standards need to be put into place.
The U.S. Department of Health and Human Services (HHS) Office of Civil Rights (OCR) protects and enforces civil rights laws in health and human services, including HIPAA. If the OCR finds an organization to be in violation, the following actions may take place:
There are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised in 2016 as part of the HIPAA Omnibus Rule included in the HITECH Act. The current financial penalties are listed below.
| Violation Category – Section 1176(a)(1) | Each Violation | All such violations of an identical provision in a calendar year |
|---|---|---|
| A. Did not know – The Covered Entity or Business Associate did not know and by exercising reasonable diligence, would not have known that a violation occurred | $110-$55,010 | $1,650,300 |
| B. Reasonable Cause – The violation was due to reasonable cause and not to willful neglect | $1,100-$55,010 | $1,650,300 |
| C.i. Willful Neglect (Corrected) – The violation was due to willful neglect, and timely corrected (generally within 30 days after the covered entity or business associate knew or should have known about the violation) | $11,002-$55,010 | $1,650,300 |
| C.ii. Willful Neglect (Not Corrected) – The violation was due to willful neglect, but not timely corrected | $55,010 | $1,650,300 |
In certain extreme HIPAA cases, individuals can be exposed to criminal risk as well. When criminal action is involved with HIPAA, the OCR hands the case off to The Department of Justice. Individuals are at risk of criminal enforcement and penalties if they “knowingly” obtain, disclose, or use PHI “in violation” of HIPAA rules. You can read a very detailed, legal opinion on what constitutes legal vs civil in the case of HIPAA. There is a lengthy discussion of the terms “knowingly” and “in violation” in that document, which is why we put them in quotes.
HITRUST is an organization that provides external verification of policies and methods. This has been done in collaboration with healthcare, business, technology and information security leaders to establish the HITRUST Common Security Framework (CSF). The most comprehensive certification in the industry for health-related security controls is the certification for the CSF put forward by the HITRUST organization. This can be thought of as a more prescriptive version of HIPAA. Do not confuse HITRUST with the Health Information Technology for Economic and Clinical Health Act, abbreviated HITECH Act.
The CSF was created because of the large number of compliance and risk controls aimed at the healthcare industry. These laws and frameworks overlap significantly and contradict one another in some ways. By standardizing across HIPAA, NIST, PCI, and ISO, HITRUST aims to reduce the burden of compliance on organizations by providing one set of standards to cover all of these requirements.
BroadStreet uses its own tutorial because we wanted something that we could distribute to all new hires working with PHI to give them a crash course on HIPAA. While it’s true there are plenty of HIPAA training options, both free and paid, we didn’t feel that any were created for employees of modern health technology vendors.
We’ve tried to organize this in the most logical way possible. Each section below has multiple subsections, and we provide links to additional resources at the end. There is a quiz towards the end, which is meant to force you to actively engage, and break up the passive nature of the training. If you have feedback or suggestions, please email us.
What is a “covered entity” under HIPAA?
The term covered entity (CE) under the HIPAA Privacy Rule refers to three specific groups that transmit health information electronically. Covered entities under the HIPAA Privacy Rule must comply with the Rule’s requirements for safeguarding the privacy of protected health information. HIPAA defines entities in two broad categories.
Covered Entities. Health care providers, health care providers or payers, and clearinghouses (process claims) fall into this category. If you’re curious, here’s an official site that helps you determine if you’re a covered entity. CEs can further be broken down as:
BroadStreet is a subcontractor for some of our customers and, as such, we do sign BAAs. We also act as a business associate directly for covered entities like enterprises, and sign BAAs in this capacity. We offer the same compliant software in both circumstances, but the relationship is slightly different in the eyes of HIPAA.
HIPAA, at its highest level, is divided into 3 broad areas.
HIPAA Privacy Rule. This portion of HIPAA deals with protection, access, and authorization related to PHI. It sets rules for when and how PHI is disclosed. It also gives individuals ownership of their health records, as well as the right to access them and request corrections to them.
As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.
A quick side note on documentation – as we alluded to earlier, HIPAA is often not prescriptive. This means there are not prescriptive rules on how to implement compliance to protect ePHI in the spirit of HIPAA. Therefore, the general approach has been one of being able to show that the risk of data leakage/breach has been mitigated to the extent possible and the steps taken to do so are documented (and updated when changed). Thus, documentation is in place so that in case of a breach, organizations can show the extent to which safeguards were implemented.
Here’s a quick overview of these code sets and their intended function.
They are all linked to the appropriate browsers where possible so that you can get a better idea as to what they look like.
The HIPAA Privacy Rule sets many of the terms used for HIPAA, outlines the types of entities that need to comply with HIPAA, defines appropriate uses or disclosures of health information, and also covers penalties for HIPAA violations. The Privacy Rule is important to understand, despite the fact that it doesn’t include specific technical requirements or polices, as the Privacy Rule gives an understanding of the types of data, entities, and uses of data that HIPAA is concerned about.
As discussed, the Privacy Rule defines two main categories of entities:
Covered Entities (CEs). These are the traditional players in healthcare – providers, hospitals, health systems, insurers. For some reason clearinghouses are called out as they transform and process health information for payers and providers; the clearinghouse that I always think of is Emdeon.
Business Associates (BAs). These are individuals and organizations that provide services and/or technology to covered entities. In the process of providing those services and technology, the business associate in some way processes, transmits, or stores protected health information (PHI). All software vendors in healthcare, if they somehow touch PHI, are business associates.
A third category of entity, or maybe more accurately a subcategory of business associates, was added in 2013 as part of the HIPAA Omnibus rules in the HITECH Act. The HITECH Act defined a subcontractor as an entity that “creates, receives, maintains, or transmits protected health information on behalf of the business associate.” A subcontractor is a business associate of a business associate. It can be a hosting provider, an email delivery service (email address), or even an analytics platform (IP address), if it in some way touches PHI. At BroadStreet many of our customers are business associates, and we are subcontractors for them, so we meet the new definition of subcontractor.
The Omnibus Rule also defined a PHR (Personal Health Record) vendor, offering a PHR through a covered entity, as a business associate.
PHI is basically personally identifiable data (name, email, phone, etc) combined with some type of health-related data (medication, diagnosis, provider name, etc). More information on this very important topic can be found at “What is PHI?”.
PHI can be de-identified by removing certain elements from the data, in a process called the Safe Harbor method, or through “expert determination”, which seems a bit fuzzy to us as it is ripe for interpretation. It may seem obvious, but the idea with both methods for de-identification is to make it so you can’t identify an individual from a data set.
PHI can only be disclosed for reasons defined by the Privacy Rule, or with written permission by an individual about their own health information. Other than providing access to the individual to his/her medical record, the Privacy Rule allows for disclosing PHI for three main reasons:
There are some other, more obscure reasons for disclosures. The most relevant reasons left are for legal reasons (“required by law”), worker compensation, and for restricted research purposes, amongst others.
In some select cases, in particular marketing, covered entities may disclose PHI, but only with authorization from the individual.
One of the central tenants of HIPAA, as stated in the Privacy Rule, is minimum necessary use of PHI. The idea is relatively simple, don’t disclose any information that is not necessary for the reason for which the information is to be used.
For example, if you’re trying to find out how much a patient owes for a particular procedure, you probably don’t need to disclose that patient’s allergies. In healthcare today minimum necessary is usually observed by either specific HL7 or EDI X12 message types, which confine the amount and type of data in a data exchange.
Covered entities must provide individuals with a notice informing those individuals of their rights, as well as detailing other factors such as the protections the covered entity uses to secure PHI. You probably remember getting these, and signing them, every time you’ve gone to the doctor.
As discussed, The Office of Civil Rights (OCR), within HHS, is responsible for enforcing the HIPAA rules. In addition to civil (financial) penalties, there are criminal penalties for knowingly disclosing PHI or obtaining PHI in violation of the HIPAA Privacy Rule.
The Security Rule is the section of HIPAA that gets most talked about by vendors like us and others with a background in technology. The HIPAA Security Rule works to make HIPAA more prescriptive by operationalizing many of the standards set out in the Privacy Rule. Specifically the Security Rule spells out, in various levels of detail, the ways in which electronic protected health information, or ePHI, needs to be protected. That being said, the HIPAA Security Rule, despite setting implementation specifications, is still not all that specific most of the time.
Many times developers and vendors focus specifically on the areas within the Security Rule to achieve compliance. Even with this area of focus, the specific technical controls only make up a minority of the HIPAA Security Rule.
The HIPAA Security Rule can be broken down into the three main categories below: Administrative, Physical and Technical.
This is actually the largest category of safeguards in the HIPAA Security Rule, accounting for over 50% of the rule. These are not server settings or specifics around technology, they are policies and processes that need to be followed to safeguard data. The biggest and most important area covered in this section, at least for people starting out on the journey towards compliance, is the risk assessment. A risk assessment should be the first step for most organizations wanting to be compliant, and covers documenting architecture, identifying risks related to the protection of PHI, and mitigating those risks.
There are other areas in this category including workforce security, contingency planning, training, and a few others, all of which are necessary to examine and address, but the risk assessment is really the big one in this category.
This category is easy to understand as it’s the physical aspect of securing systems that have access to ePHI. It breaks out to workstations, facilities, and different portable and mobile media. Most data centers today, including the ones that we use at BroadStreet, more than meet the requirements in the Security Rule for facilities. Typically compliant Infrastructure-as-a-Service vendors, like AWS, cover this category of HIPAA for you.
Areas people sometimes neglect are office security and workstation security. These aren’t hard safeguards to meet but they likely involve some process changes, like not allowing cleaning people into your office without supervision, keeping doors locked and tracking visitors, encrypting employee computers, and using workstation firewalls.
The technical category of safeguards is usually what people think of when they think of securing ePHI. The biggest areas are encryption, access controls, and auditing. With encryption, it has to be end to end, and it has to be at rest. At rest is typically harder. We have found that we need to use high performance SSD drives to improve performance issues that arise with encrypting data at rest.
For access controls and logging, basically all activity of servers should be logged and those logs should be monitored with appropriate alerting. All API calls should also be logged, including what was accessed (with ePHI at times), by whom, and when. We have spent a lot of time building a powerful and flexible unified logging solution to meet the requirements in this area.
Beyond the three areas above, there are a few miscellaneous requirements in the security rule. Those additional requirements relate to signing business associate agreements and having policies to, well, manage your policies.
That’s a very high, high-level overview of the Security Rule. You can see pretty detailed information about the Security Rule, and how BroadStreet addresses the different specifications, on our HIPAA page.
The new HIPAA Omnibus (“omnibus” means something with several volumes or chapters) rules that went into effect on 9/23/2013, amongst other changes, created a category of entities called subcontractors. The OCR announced a final rule that implements a number of provisions of the Health Information Technology for Economic and Clinical Health (HITECH) Act.
Previously HIPAA rules only defined two categories of entities: covered entities and business associates. Covered entities are basically providers, payers, and clearinghouses. Business associates are basically entities that work with covered entities to perform a service or services to store, transmit, and/or process PHI. The new HIPAA rules expanded the number of categories of entities by 50% with the addition of subcontractors; for those of us in health tech, we think this is a pretty big deal.
As discussed, subcontractors are entities that business associates use to process, create, or store PHI. Subcontractors don’t have business associate agreements, or really any direct relationships, with covered entities; but, starting 9/23/2013, theses subcontractors need to have business associate agreements (BAAs) with business associates. It’s all very obvious and confusing at the same time. Essentially you can think of subcontractors as a business associate of a business associate.
The best examples of subcontractors we can think of are hosted services providers like AWS. BroadStreet is a subcontractor for some of our customers and, as such, we do sign BAAs. We also act as a business associate directly for covered entities like enterprises, and sign BAAs in this capacity. We offer the same API-based services for developers in both circumstances, but the relationship is slightly different in the eyes of HIPAA.
At BroadStreet we know that subcontractors, as defined by HIPAA, have existed for a long time. As more health apps and services have shifted to hosted, or cloud based, and more infrastructure tools (app dev, logging, analytics, data collections, etc) have become mainstream, covered entities and business associates have begun to rely on “subcontractors”. The new HIPAA rules now mean those subcontractors need to work with business associates to assure all parties are covered in terms of liability.
This is a very exciting and major shift for health tech. HIPAA has finally acknowledged subcontractors and the role they play in creating, processing, and transmitting PHI. That’s important for health tech to build smart, scalable, and interoperable tools. As a developer in healthcare, if you’re considering acting as a business associate, or selling services to a covered entity, you need to understand if you fit into a certain entity category as defined by HIPAA.
We encourage you to read the rest of the rules, or at least one of the commentaries that covers them in more detail, to see about the other changes that are a part of the Omnibus rule.
When people talk or write about HIPAA, it’s always presumed that there’s an enforcement aspect, though enforcement is rarely explicitly discussed. As much as people and organizations value the privacy and security of the personal health information of their customers (patients, members, users/consumers), the fear of fines and other penalties are the major drivers of compliance and security efforts. Penalties, whether fines or otherwise, are quantifiable, and expose organizations to very real financial risk if proper controls, both tech and policy, aren’t put into place and followed.
HHS sets the rules for HIPAA and enforcement is carried out by The Office of Civil Rights (OCR), within HHS. OCR is tasked with the responsibility of investigating complaints. Based on an investigation, the OCR determines if the covered entity, or the business associate of a covered entity, was in compliance with the security and privacy rule. The investigation branches at whether an organization is in violation of HIPAA rules or not. If the organization is not in violation, the findings are documented and the case is closed. HIPAA is not always prescriptive, and has terms like “reasonable”, so there is some interpretation and gray area at this stage.
In a recent report by the OCR, the Security Rule accounted for the majority, or 60%, of violations, followed by Privacy Rule violations and then Breach Notification violations. That recent report also cited a lack of complete or accurate risk assessments as a widespread problem, with up to two third’s of entities lacking full and timely risk assessments. Risk assessments are incredibly valuable and should inform much of your security and privacy posture as an organization.
If the OCR finds an organization to be in violation, the following actions may take place:
As outlined, there are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised considerably in 2016 as part of the HIPAA Omnibus Rule included in the HITECH act. The current financial penalties are listed below.
HIPAA Financial Penalties
| Violation Category – Section 1176(a)(1) | Each Violation | All such violations of an identical provision in a calendar year |
|---|---|---|
| A. Did not know – The Covered Entity or Business Associate did not know and by exercising reasonable diligence, would not have known that a violation occurred | $110-$55,010 | $1,650,300 |
| B. Reasonable Cause – The violation was due to reasonable cause and not to willful neglect | $1,100-$55,010 | $1,650,300 |
| C.i. Willful Neglect (Corrected) – The violation was due to willful neglect, and timely corrected (generally within 30 days after the covered entity or business associate knew or should have known about the violation) | $11,002-$55,010 | $1,650,300 |
| C.ii. Willful Neglect (Not Corrected) – The violation was due to willful neglect, but not timely corrected | $55,010 | $1,650,300 |
Prior to these rules, the fine associated with each HIPAA violation was capped at $25,000. This number is now over $1.5 million per violation.
In certain extreme HIPAA cases, individuals can be exposed to criminal risk as well. When criminal action is involved with HIPAA, the OCR hands the case off to The Department of Justice. Individuals are at risk of criminal enforcement and penalties if they “knowingly” obtain, disclose, or use PHI “in violation” of HIPAA rules. You can read a very detailed, legal opinion on what constitutes legal vs civil in the case of HIPAA. There is a lengthy discussion of the terms “knowingly” and “in violation” in that document, which is why we put them in quotes.
In addition to the OCR, and the Department of Justice to a lesser extent, recently the FCC has waded into enforcing the privacy of health data through its mandate to protect consumers. The financial penalties from the FCC are lower than those from the OCR; but, the FCC has the power to require annual privacy audits, as it has done with companies like Google and Facebook, and these audits, over time, have the potential to be very expensive for companies. This move by the FCC is new, and still making its way through the courts, so it’s still uncertain how the FCC will fit in with HIPAA enforcement.
The acronym: PHI stands for Protected Health Information (PHI) – not personal health information (although that’s in essence what it implies), not personally identifiable health information (I’ve seen it used although that would technically be PIHI) and I’m sure there are variants of this that you’ve heard as well.
The definition: Wikipedia definition describes protected health information (PHI) as any information about health status, provision of health care, or payment for health care that can be linked to a specific individual.
HHS provides an even simpler definition of PHI – individually identifiable health information transmitted or maintained in any form or medium by a Covered Entity or its Business Associate; the definition of a “business associate” has been extended with the HIPAA Omnibus rule that went into effect in 2013. The term “information” is interpreted rather broadly and includes any part of a patient’s medical record or payment history.
The key here is this phrase “that can be linked to a specific individual.” Which is where the other acronym, PII (Personally Identifiable Information) – [here’s the link to the Wikipedia article on that][http://en.wikipedia.org/wiki/Personally_identifiable_information] – becomes relevant. The major difference between PHI and PII is that PII is a legal definition – i.e. PII is anything that could be used to uniquely identify an individual. PHI is a subset of PII in that a medical record could be used to identify a person – especially if the disease or condition is rare enough.
For information to be considered PHI, it must meet all of the following three conditions:
Health information that is not linked to an individual by one or more of the 18 HIPAA identifiers (see the next section) and for which there is no reasonable basis to believe that the information can be used to identify the individual is not protected health information. Individually identifiable health information ceases to be PHI 50 years after death.
PHI can be in oral, written or electronic form.
The core of the HIPAA regulations is to ensure that ownership of any and all medical data is retained solely by the individual. The individual can then decide to parcel out access to others – providers, family members, employers if needed or necessary or simply by preference of the record owner. Only an individual has the right to grant access to their medical data. This was mainly done for the following reasons:
Protection and privacy come into play once the individual has been uniquely identified. There are after all more than 30 million Americans who have diabetes. Which leads to the question of what data can be used to uniquely identify an individual. The generally accepted set of individually unique data elements include the following:
| ID | Data Element | Description |
|---|---|---|
| 1 | Name | Well, of course i.e. first name, last name, maiden name combinations. One could argue that just any one of the above doesn’t uniquely identify an individual after all “James” is a pretty common name. But it could be possible to identify an individual using a combination of data i.e. first name, zipcode, street address etc. |
| 2 | Geographic locators | Everything (street address, city, precinct, zipcode, latitude-longitude coordinates etc.) are considered PII. The first three digits of the zipcode are usually considered ok for use except in the case of certain zipcodes which cover a small population (less than 20,000). There are currently 17 zipcodes that fit that profile – 036, 692, 878, 059, 790, 879, 063, 821, 884, 102, 823, 890, 203, 830, 893, 556, 831. So three digit zipcodes are ok to be used except for the above listed ones. |
| 3 | Dates | Pertaining to significant events in an individual’s life – birth, death, marriage, admission, discharge etc. Just the year is generally considered fine for use except in the case of the very elderly (>89 years of age; in which case they would be represented by an aggregate category e.g. =>90 ) |
| 4 | Phone numbers | Well, of course. |
| 5 | Fax numbers | This is, IMHO, a carryover from the old days. Do you know a lot of people with a personal fax number? But, it does make sense. |
| 6 | Electronic mail addresses (email) | Check |
| 7 | Social Security numbers | Check |
| 8 | Medical record numbers | This is usually a “random” number and could be used if one also knew the institution that assigned it. |
| 9 | Health plan beneficiary numbers | This is your insurance card / member ID. |
| 10 | Account numbers | Bank numbers etc. |
| 11 | Certificate/license numbers | Drivers license, birth certificate number etc. |
| 12 | Vehicle identifiers and serial numbers, including license plate numbers | If it’s good enough for the police to track someone down… |
| 13 | Device identifiers and serial numbers | Medical devices have unique serial numbers. Your computer’s MAC id is unique as well. |
| 14 | Web Universal Resource Locators (URLs) | This is a bit murky but is in here to cover all possibilities. http://www.facebook.com isn’t very unique. But if logged within a specific application, could indeed be very unique to an individual. |
| 15 | Internet Protocol (IP) address numbers | Your IP address can be used to easily identify your address. There are several free services that offer this (do a quick google search for address from ip and try this as an example |
| 16 | Biometric identifiers, including finger and voice prints | Don’t forget retinal images. |
| 17 | Full face photographic images and any comparable images | Check |
| 18 | Any other unique identifying number, characteristic, or code | Re code – note this does not mean the unique code assigned by the system to code the data. |
These 18 elements are the core set of data elements that individually or in combination can be used to uniquely identify an individual. And, considering the fact that the above list of identifiers has fax numbers and not Twitter @usernames, Facebook IDs, or a host of other modern, more common identifiers, it’s clear that the PII list is not the most up to date and some more thought should go into recognizing and protecting identifiable information. However, since patient data is valuable in clinical trials, medical case studies etc., the above list is used as a guideline to ensure privacy.
If another approach is used, ensure a statistically small/negligible risk of re-identification which is validated by a statistics expert (you have to love the interpretability of that rule).
You are expected to be able to:
Only access, use or disclose PHI if your job allows you access and that access is required for your job. In our case, this is rarely, if ever needed. The general approach should be that if a client sends you any such information without an explicit agreement in place, then delete it immediately without opening.
If for some reason, while providing support to a customer, you are able to view such information, do not copy, download, screenshot or retain access to any such data and report this immediately to your manager or our Chief Security Officer.
The intention at every step should always be:
This following section is for informational purposes only. As a general policy (there might be exceptions as we continue to grow and evolve in services provided in which case, you will be explicitly informed), you, as an employee of do not need access to PHI.
HIPAA allows covered entities (CE) to create, receive, access, use, or disclose PHI without patient authorization when the workforce member’s job duties involve certain activities. These activities include, but are not limited to:
There are other uses and disclosures where patient authorization is not required, including (and these are the ones that currently apply to us):
If you are not sure about whether or not you can use or disclose PHI, check with your manager or the Chief Security Officer.
A breach is defined as unauthorized exposure of ePHI or disclosure that’s not authorized or allowed under the HIPAA Privacy Rule. The breach rules were amended in 2013 as part of the HITECH Act.
HITECH Act Sec. 13402(b) Notification of Covered Entity by Business Associate states:
HIPAA requires notification of a breach “without unreasonable delay” but allows, at a maximum, 60 days to report a known breach. Most covered entities that we’ve worked with want that timeline to be much shorter. This can be a sticking point in business associate discussions. Some hosting providers have polices in place for breach reporting that are 30 days, 45 days, even 60 days out; this typically does not align with what hospitals or a payers or another large enterprise organizations in healthcare would expect from a business associate agreement and a breach policy for a business associate that they are working with. Despite the 60 day window HIPAA rules also require “evidence demonstrating the necessity of any delay.” If it takes 60 days, there must be reasons for such a delay.
Breach policy and breach notification are extremely important. There are templates for breach notification, but the policy alone does not mitigate risk. There needs to be an understanding within the organization, business associate or covered entity, of what a breach is and what the breach policy is. There also need to be auditing and logging and other systems (IDS) in place to detect and investigate a breach. Detecting the breach is often the challenge which is why having a comprehensive audit log is necessary and more importantly, being able to generate alerts off the log is critical.
Breaches come in a variety of forms, from hacking/IT related to loss of hardware (e.g., laptop). The Centers for Medicare & Medicaid Services (CMS) tracks and publishes breaches affecting greater than 500 records published, which makes searchable how many records were affected and the type of breach. Many of the breaches are hardware breaches, and many can happen because of employee carelessness.
Although “Hacking/IT Incidents” may not yet account for the majority of breaches, there is great potential to have a breach with a malicious hacker breaking into a private network or any sort of cloud-based storage, especially public cloud. This potential has fueled much of the slow pace of ePHI to the cloud.
There are ways to mitigate that risk, but, when there is a breach there are several important factors to be a aware of:
BroadStreet has a formal breach notification policy that addresses the requirements of notifying affected individuals and customers of a suspected breach of ePHI. These policies outline the relevant and responsible parties in case of a breach, forensics work to discover extent of breach, reason for breach, correction of infrastructure to prevent future breach, and requirements of notifying customers of a breach within 24 hours. BroadStreet is a defined Business Associate or subcontractor according to HIPAA regulations and the specific customer relationship.
BroadStreet has Breach Notification policies in place and they include a brief description of the breach, including the date of the breach and the date of the discovery of the breach, if known. BroadStreet breach notification policies include a description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of PII were involved) and what the source of the breach was. Our breach notification policies include steps the individual should take to protect themselves from potential harm resulting from the breach. Our policies also provide the contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, Web site, or postal address.
If you want to learn more about BroadStreet’s policies for handling breaches, our policies in general are accessible here.
Please ensure that you have read through it.
A breach is the unauthorized acquisition, access, use, or disclosure of PHI that compromises the privacy or security of the PHI. We are all responsible for protecting our members’ and patients’ confidential information. If a breach occurs, immediately notify your supervisor or the Chief Security Officer.
No matter how curious you might be regarding the health of a coworker, a friend, a celebrity, or a family member, do not access a medical record unless you are authorized to do so. Never access or discuss a fellow employee’s PHI unless it is for purposes allowed by law and required for your job.
Do not discuss any PHI information at home or outside of work.
Avoid discussing PHI in public areas, including talking on a cell phone where others may overhear. Lower your voice when you must share PHI in areas where others might overhear.
Violating BroadStreet policies, federal regulations, and state laws and regulations can lead to disciplinary action – up to and including termination, personal fines, civil and criminal penalties and suspension of professional licenses.
You are responsible for understanding this information and any additional information necessary to comply with all laws and policies that affect your job.
If you have questions about what you must do, talk to us.
The HIPAA Privacy Rule outlines the types of entities that are covered by HIPAA and entities that have to follow the HIPAA security and privacy rules. The main categories are clearinghouses, covered entities (CEs) — typically hospitals, payers, and providers, and business associates. Business associates are far away the biggest cohort of cloud computing companies.
Business associates are people or organizations who contract and provide services and/or technology for covered entities. In the process of providing those services or those technologies, business associates handle, process, transmit, or in some way interact with electronic protected health information (ePHI) from those covered entities. With this ePHI access, business associates are required to sign what’s called a business associate agreement (BAA). Below is the actual language from HIPAA 164.308.
(b)(1) Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with §164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
(b)(2) A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with §164.314(a), that the subcontractor will appropriately safeguard the information.
Business associate agreements are basically legal contracts that outline the ways in which business associates follow HIPAA, as well as the responsibilities and risks that the business associate takes on. They typically define the type of services that the business associate is providing, the type of data that they are interacting with, stating that they will follow HIPAA and not disclose PHI without authorization. They also should address areas around breach notifications and penalties. Traditionally, pre-cloud and prior to the HIPAA Omnibus changes of 2013, BAAs were boiler plate. Here’s the template BAA from HHS.
Business associate agreements became a lot more interesting with the passing of the new HITECH HIPAA Omnibus Rule in 2013, which expanded upon that definition of business associate to include something called subcontractors. Subcontractors are typically service or technology organizations that provide additional services to the business associates, which are providing services for the covered entities. With subcontractors and APIs and SaaS, there is now a chain of entities touching ePHI in some way, and each of them need to have BAAs in place that are consistent and not contradictory to one another. As an example, a business associate selling to hospital A can’t have a breach notification policy of less than 24 hours if the hosting provider they use has a physical breach notification policy of 2 months.
As the internet, cloud computing, and APIs have broken down silos, more and more applications rely on different layers of technology and services, considered subcontractors. These subcontractors have to sign business associate agreements with business associates, who in turn have to sign a business associate agreement with covered entities.
If you boil it down, business associate agreements are just contracts that outline the ways in which different organizations are going to handle electronic protected health information (ePHI), the types of responsibilities that those organizations take on, some of the very specific rules around their obligations with regards to HIPAA. This last one, the obligations of subcontractors, is an area in which you want to pay close attention. Specifically read what the subcontractor’s obligations are in terms of timeliness of breach notification, because that was a part of the changes in the HIPAA Omnibus Rule that just went into effect.
At a high level, that’s what business associate agreements are, and you are expected to have those for all of the various technology and services companies that you work with that might in some way interact with, process, store, or have access to ePHI. If you’re a business associate or you’re a covered entity, we happily sign BAAs. And if you’re interested in seeing one of our BAAs, it is available at email us.
The following set of sections lays out elements of our policy that you need to adhere to and that we monitor to ensure ongoing compliance.
The full set of policies that we have in place **(in case you have further questions or need clarifications) are available here.
BroadStreet has two Privacy Officers and a Security Officer appointed to assist in maintaining and enforcing safeguards towards compliance.
The Privacy Officers for BroadStreet is Tom Schmitt and Tracy Flood. Under this role, responsibilities include:
The Chief Security Officer for BroadStreet is James Walters. Under this role, his responsibilities include:
Since we manage critical systems potentially containing sensitive PHI information on behalf of our clients, we need to ensure that all access to systems adheres to the following rules. If you notice any violation of these, please report it immediately to the Chief Security Officer.
BroadStreet implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.
Your responsibilities in this context are:
The rule is very simple. You do not need access to PHI data. Do not download, store or open any communication containing PHI.
Workforce sanctions are described in more detail here.
In summary,
HIPAA will continue to evolve. We will try our best to keep up with it and ensure our documentation is up to date. We encourage you, as part of the BroadStreet team, to read up on it occasionally as well. Notify the Chief Privacy Officer if you notice any discrepancies.
A listing of HIPAA regulations and how we map to them is available here
More details can be found on the HHS website, summary is available here and of course, the Wikipedia page for HIPAA.
This training needs to be taken annually. If you are a new employee working with ePHI, you must take this within 30 days of starting employment with BroadStreet Inc. You will receive an annual reminder to take this test as well.
You are required to meet with your supervisor, manager, or designated training administrator, to review the answers to the knowledge check questions and to fill out the course completion forms.
All questions are presented as multiple choice. There could be more than one correct answer.
This set of questions is to help you guage your understanding of the privacy rule and the regulations governing protected health information and the BroadStreet policies in place to address them.
What provides the establishment of a nationwide framework for the protection of patient confidentiality, security of electronic systems and the electronic transmission of data?:
HIPPA
HIPAA
HITECH
HIIPA
This is the definition of HIPAA. Note: HIPAA has two A’s. HIPAA is an acronym for Health Insurance Portability and Accountability Act.
What does PHI stand for?:
Personal Health Information
Private Healthcare Information
Protected Health Information
Public Health Information
PHI is a specific HIPAA term that means Protected Health Information. PHI can be defined as any information that can lead to the identity of an individual or the contents of the information can be used to make a reasonable assumption as to the identity of the individual.
Why is the Privacy Rule important?
Ensures that my tax bill is not seen by anyone
Sets procedures for how a privacy fence needs to be installed
Gives individuals rights to control the use and disclosure of PHI
Gives individuals rights to march at the capital about their privacy rights
The privacy rule gives patients the right to control how their information is used and disclosed.
To maintain confidentiality we need:
Both privacy and security measures to be in place
More legislation to regulate the health care industry
More oversight staff to guard records
All of the above
Having both privacy and security measures in place help protect patient confidentiality.
What defines the format of electronic transfer of information between providers and payers to carry out financial activities?
HIPAA
Privacy
EDI
Security
EDI standards have been defined for electronic data exchange to exchange data between providers and payers. Specific EDI formats are EDI 835, EDI 837 etc.
PHI includes all health information that is used/disclosed – except PHI in oral form
True
False
PHI includes all health or patient information in any form whether oral or recorded, in paper, or sent electronically.
What are examples of protected health information that might be connected to an individual?
Telephone number
Address
Zipcode
Date of Birth
Gender
ZIP codes (except for a small set) cannot be used to uniquely identify an individual. Neither can gender.
Who protects PHI?
The government
My organization and me
Our auditors
Our customers
The government protects PHI through the HIPAA regulations. BroadStreet and you are required to protect health information through its practices and compliance with the HIPAA regulations.
If you suspect someone is violating the BroadStreet privacy policy, you should:
Say nothing
Report the activity to your supervisor for further follow-up
Approach the person yourself and inform them of the correct way to do things.
Watch the person closely in order to determine that you are correct with your suspicions.
Report the suspicion to your manager or supervisor.
The HIPAA Omnibus Rule provides what penalties for violation of HIPAA rules.
limited
tougher
more lenient
fewer
The penalties have increased dramatically. See 5.4 for more details
This set of questions will help you guage your understanding of the physical security requirements under HIPAA and the BroadStreet policies in place to meet them.
Customer or customer’s data can be cached within your laptop
Yes
No
Customer data should not be ever downloaded locally onto your laptop.
It is ok to walk away from you computer without locking it or logging off
Yes
No
Your computer may contain senstive data – SSH keys, passwords. Always lock your computer at the minimum before stepping away even if it’s for a few minutes.
It is optional to encrypt my laptop’s disk.
Yes
No
It is mandated that you must encrypt your laptop’s hard drive so that even if it is stolen/lost, no sensitive data can be accessed.
It is ok to backup my laptop onto a portable external drive
Yes
No
This is only permitted if the external drive is also encrypted. We recommend backing everything up to the company Box account.
This set of questions will help you guage your understanding of the technical security requirements under HIPAA and the BroadStreet policies in place to meet them.
You are responsible for your username/password when accessing the computer system as well as all information accessed under this login.
True
False
If you suspect that someone knows your password or has been compromised in any way, change your password immediately and notify the Chief Security Officer
What is the BroadStreet policy for password strength?
Miniumum 8 characters - any combination of words and letters
Minimum 8 characters - no dictionary words, one number, one special character
Minimum 8 characters - all numbers
Whatever's easy to remember
Do not use easy to guess passwords while ensuring a high degree on entropy. When choosing a password, it is important to make sure it isn’t easy for others to guess. Your password is something you need to protect at all times.
The information I access in computer systems may be audited by BroadStreet Health Inc. at any time.
True
False
Our organization runs random audits to verify what users have accessed is appropriate for their assigned job responsibilities.
Joe Lewis (hypothetical name), the CTO of AllThingsPHI (hypothetical name) calls you and asks for his SSH key to be reset and sent to him at a particular email address. You should
Do so immediately, the customer is always right
Reset the SSH key and send it to him to the email address we have on file
Ask him to create a support ticket. Confirm to email on file. Then initiate a change
Tell him you cannot do that
This is a more complicated form of phishing and that we should guard against. Do not change or supply sensitive information without verifying the person’s identity. If there is any doubt, do not make any changes.
This is to ensure that you know whom to reach out to in case you have any questions or concerns.
Who is the Chief Privacy Officer?
Tom Schmitt and Tracy Flood are Chief Privacy Officer.
Who is the Chief Security Officer?
James Walters is the Chief Security Officer.
You have questions and concerns about training – compliance or security related. You should reach out to:
Chief Privacy Officer
Chief Product Officer
Your manager
Chief Security Officer
All training related concerns should be communicated either to the Chief Privacy Officer or your manager.
You receive some questions about the BroadStreet BAA from one of our customers. You should reach out to:
Chief Privacy Officer
Chief Product Officer
Account Manager
Chief Security Officer
All BAA related questions should go to the Chief Privacy Officer. No changes should be made to any BAA without explicit consent / authorization from him / her. It is also fine to route this request to the Officer via the Account Manager or your direct manager
You notice or suspect a partner or an employee trying to access customer data. You should:
Say nothing
Report the activity to your supervisor for further follow-up
Approach the person yourself and inform them of the correct way to do things.
Watch the person closely in order to determine that you are correct with your suspicions.
The correct thing to do is to notify your supervisor immediately.
In the above scenario, if the person you suspect is your supervisor, you should:
Say nothing
Report the activity to the Chief Security Officer
Report the activity to the Chief Privacy Officer
Watch the person closely in order to determine that you are correct with your suspicions.
The CSO is responsible for all investigations of privacy and security policy violations
Thanks for going through this training and taking the quiz. We are doing this on the honor principle – this is the right thing to do and we hope you appreciate the gravity and responsibility that we take on behalf of our clients.
Thank you!
© 2023 BroadStreet