Cordata Training Handbook

    Introduction to HIPAA Training

    last modified: May 30, 2017

    Summary of Training

    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 training is intended for Cordata associates that provide technology and technology-enabled services to our healthcare partners and clients. It leans more heavily on the use of modern, cloud-based technologies than traditional client-side software.

    The training covers the following topics:

    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:

    1. Ways to prevent accidental and intentional misuse of sensitive data
    2. Ways to make sensitive data secure without it being too onerous
    3. The fact that it’s not just about complying with some lengthy regulations - it is about doing the right thing. Our customers have entrusted us with sensitive data and we have a duty to protect it to the best of our abilities.
    4. There are significant penalties associated with non-compliance to organizations and employees of those organizations. Lack of attention will impact not only us but our customers.

    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. Most people, especially in IT, will have some story about a consultant or vendor delivering a report or sending emails with HIPAA spelled wrong. Just remember, it’s not like “hippo” - there’s only one “P.“

    What’s interesting about the acronym “HIPAA” is that the “P” in HIPAA 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. PHI stands for Protected Health Information. PHI is often 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 - 1. to secure and protect personal health information 2. to enforce standards for electronic transactions in healthcare

    Why all the fuss about HIPAA

    Well, for three key reasons:

    1. It is the right thing to do.

    Our customer’s depend on us to protect their data. It is our responsibility as partners to be diligent in protecting customer data.

    2. The cloud.

    An increasing move to this amorphous entity called the cloud, with its associated technical complexities, security and privacy, requires guidelines / standards need to be put into place.

    3. There are heavy penalties for violating it.

    If the OCR (Office for Civil Rights) finds an organization to be in violation, the following actions may take place: - Voluntary compliance; - Corrective action; and/or - Resolution agreement

    There are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised considerably as part of the HIPAA Omnibus Rule included in the HITECH act. The current financial penalties are listed below. Prior to these new rules, the fine associated with each HIPAA violation was capped at $25,000. This number is now $1.5 million per violation.

    Violation Category - Section 1176(a)(1) Each Violation All such violations of an identical provision in a calendar year
    A. Did not know $100-$50,000 $1,500,000
    B. Reasonable Cause $1000-$50,000 $1,500,000
    C.i. Willful Neglect - Corrected $10,000-$50,000 $1,500,000
    C.ii. Willful Neglect - Not Corrected $50,000 $1,500,000

    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.

    Organization of this tutorial

    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 are exercises sprinkled throughout to break up the passive nature of the training.

    HIPAA defines entities in two broad buckets:

    1. Covered Entities. Health systems, 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.

    2. Business Associates. These, most likely you if you’re reading this, are entities that provide services to covered entities and through those services access, transmit, process, or store PHI. Changes to HIPAA that went into effect in the fall of 2013 expanded the definition of business associate to include “subcontractors”, or entities that provide services to business associates. A simple use case - a developer that builds a Personal Health Record (PHR) for a hospital is a business associate, and the hosting provider that developer uses is a subcontractor. The developer signs a BAA with the hospital and as well as with the hosting provider.

    Covered Entities

    What is a “covered entity” under HIPAA?

    The term “covered entity” under the HIPAA Privacy Rule refers to three specific groups, including health plans, health care clearinghouses, and health care providers 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. Below is a more detailed list of those who fall under the covered entity category under HIPAA.

    Business Associates

    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 by far 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).

    Subcontractors

    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, these subcontractors need to have 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 Amazon Web Services, Datica, Prominic, and Rackspace.

    At Cordata 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 solutions 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.

    HIPAA, at its highest level, is divided into 3 broad areas.

    1. 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.

    2. HIPAA Security Rule. The Security Rule sets standards for the security of technology used to access, store, transmit, or process PHI. It is concerned with electronic PHI, or ePHI. It operationalizes much of the Privacy Rule. It’s not always prescriptive in how to secure technology, and some aspects are left to interpretation. This section of HIPAA is the most relevant to app developers from a practical standpoint. One additional thing to know is that certain implementation specifications laid out in the security rule are either required, meaning you have to do them, or addressable. Addressable specifications are ones in which an entity needs to either 1) implement the specific implementation as written, 2) implement an alternative specification, or 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

    3. Administrative Simplification. This area of HIPAA relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). As the name implies, the intent is to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. The common code sets range from X12 or NCPDP (pharmacy-related) and include DRG, ICD, CPT, NDC, SNOMED-CT, and LOINC amongst others.

    A quick side note on documentation - as we alluded to earlier, HIPAA is not prescriptive. 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 documented (and updated when changed). These reams of documentation are in place so that in case of a breach, companies can show the extent to which safeguards were implemented.

    Datica##The Privacy Rule 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.

    Entities

    The Privacy Rule defines two main categories of entities:

    1. 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.

    2. 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 associates in some way process, transmit, or store 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.

    The Omnibus Rule also defined a PHR vendor, offering a PHR through a covered entity, as a business associate.

    PHI + De-identifying

    Our partner Datica provides a nice post in “What is PHI?” because it’s an incredibly important topic in HIPAA. It’s basically personally identifiable data (name, email, phone, etc) combined with some type of health-related data (medication, diagnosis, provider name).

    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. The idea with both methods for de-identification is to make it so you can’t identify an individual from a data set (duh!).

    Use or disclosing of PHI

    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:

    1. Treatment. Probably the most obvious reason for disclosure, exchanging PHI between providers for treatment, management, and consultation happens all the time.
    2. Payment. In order to collect payments from insurers, disclosure of PHI is essential.
    3. Operations. We think of this as the catch-all bucket. It encompasses many administrative functions such as quality reporting and different types of operational analytics. This is also where disclosures for medical education fall in.

    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.

    Minimum necessary

    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. 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.

    Notice of Privacy Policies

    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 use to secure PHI. You probably remember getting these, and signing them, every time you go to the doctor.

    Penalties

    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 obtain PHI in violation of the HIPAA Privacy Rule.

    The Security Rule

    The HIPAA Security Rule operationalizes 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 ePHI needs to be protected. The Security Rule, despite setting implementation specifications, isn’t all that specific most of the time.

    The Security Rule is the section of HIPAA that gets most talked about by vendors like us and others with a background in technology. 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

    This is actually the largest category of safeguards in the HIPAA Security Rule, accounting for over 50% of the rule. These are not server configuration settings or specifics around technology, they are policies and processes that need to be followed to safeguard a. 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 it 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.

    Physical

    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, such as Rackspace, more than meet the requirements in the Security Rule for facilities. Typically compliant Infrastructure-as-a-Service vendors, like AWS and Rackspace, 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.

    Technical

    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. Our partner Datica uses 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. Our partner Datica provides a 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 manage your policies.

    This area of HIPAA relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). As the name implies, the intent is to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. The common code sets range from X12 or NCPDP (pharmacy-related) and include DRG, ICD, CPT, NDC, SNOMED-CT, and LOINC amongst others.

    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.

    DaticaThe 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.

    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.

    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 Amazon Web Services, Datica, Prominic, and Rackspace.

    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 excited 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 new 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.

    Enforcement

    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: - Voluntary compliance; - Corrective action; and/or - Resolution agreement.

    There are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised considerably last year 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 $100-$50,000 $1,500,000
    B. Reasonable Cause $1000-$50,000 $1,500,000
    C.i. Willful Neglect - Corrected $10,000-$50,000 $1,500,000
    C.ii. Willful Neglect - Not Corrected $50,000 $1,500,000

    Previous to these new rules, the fine associated with each HIPAA violation was capped at $25,000. This number is now $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 with HIPAA enforcement.

    The acronym: PHI stands for Protected Health Information - 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: Here’s the wikipedia definition. Protected health information (PHI) is 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. This 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 - 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:

    1. The information is created, received, or maintained by a health provider or health plan.
    2. The information is related to past, present or future health care or payment for that health care.
    3. The information identifies a member or patient, or there is enough information to be able to identify the individual.

    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.

    Protection of PHI

    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:

    1. Privacy: Obviously we would prefer that our neighbor (or in some cases, family members) not know about whatever condition we might be suffering from or medication we are taking.
    2. Bias and discrimination: AIDS, mental health and other conditions have some (albeit declining) social stigma associated with it. The HIPAA PHI provisions ensure that employers and others do not have access to one’s medical record and use the information contained within to discriminate against the individual based on their health information.

    Obviously protection and privacy come into play once the individual can / has been uniquely identified. There are after all 25.8 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, zip code, street address etc.
    2 Geographic locators Everything (street address, city, precinct, zip code, lat long coordinates etc.) are considered PII. The first three digits of the zip code are usually considered ok for use except in the case of certain zip codes which cover a small population (less than 20,000). There are currently 17 zip codes that fit that profile - 036, 692, 878, 059, 790, 879, 063, 821, 884, 102, 823, 890, 203, 830, 893, 556, 831. So three digit zip codes 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.

    Anonymization & De-identification

    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).

    Datica# What Does It Mean For You

    You are expected to be able to: 1. Recognize PHI that requires protection, 2. Determine when it is permissible to access, use or disclose PHI, and 3. Reduce the risk of impermissible access to, use or disclosure of PHI.

    When it is permissible to access or use PHI?

    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.

    Minimum necessary PHI

    The intention at every step should always be: - To use or disclose/release only the minimum necessary to accomplish the intended purposes of the use, disclosure, or request. - Requests from customer employees: - Identify each workforce member who needs to access PHI. - Limit the PHI provided on a “need-to-know” basis. - Requests from Cordata or any vendor doing business with customers who have PHI data: - If for some specific purpose, PHI data is requested, then you should limit the PHI provided to what is needed to accomplish the purpose for which the request was made and no more.

    What Uses or Disclosures of PHI Are Permitted by Law?

    This following section is for informational purposes only. As a general policy (there might be exceptions as continue to grow and evolve in services provided in which case, you will be explicitly informed.

    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): - Business Associates – PHI may be used by contracted business associates to perform certain functions on a client’s behalf. Business associates must sign a business associate agreement and agree to safeguard PHI. In a Datica context, we enter into BAAs with all of our clients as we provide infrastructural services to them. However, we have put guideline and technology in place to minimize, restrict and in some cases, eliminate access to PHI. As a contractor, we may not copy, use, or disclose PHI for any purpose other than specifically allowed in our Business Associate contract. If you inadvertently access or disclose PHI in ways not allowed in your contract, the law requires you to immediately report the disclosure to your supervisor or contract manager, and your company to report the breach to our client.

    If you are not sure about whether or not you can use or disclose PHI, check with your manager or the Chief Security Officer.

    Definition of Breach

    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 - A business associate of a covered entity that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured protected health information shall, following the discovery of a breach of such information, notify the covered entity of such breach. Such notice shall include the identification of each individual whose unsecured protected health information has been, or is reasonably believed by the business associate to have been, accessed, acquired, or disclosed during such breach.

    Notifications

    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, and the range we usually hear is somewhere between 24 hours and 5 days. 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 is typically not in line with what a hospital or a payer or another large enterprise 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 go on to require “evidence demonstrating the necessity of any delay.” If it takes 60 days, there have to be reasons given for that delay.

    Breach policy and breach notification are things that 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.

    Expectations vs Reality

    The majority of breaches are actually not software breaches. They’re not hacking into a system that causes the unauthorized disclosures. Breaches affecting over 500 records are published by CMS. You can see there’s a searchable database of breaches that have occurred, how many records were affected and the type of breach. The vast majority of breaches are hardware breaches. The majority, if not almost all of the breaches, seem to happen because of employee carelessness. It seems like it’s almost always a contractor’s laptop that’s been unencrypted and has been storing tons of patient records. The laptop is stolen from a car or a house or a coffee shop or an airport or whatever.

    “Hacking/IT Incident” only accounts for 68 breaches, a relatively small number. 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, and that is why we partnered with Datica; but, the important thing when it comes to a breach is actually having a process in place that details the steps to take in case of a breach. How do you assess what information was exposed in an unauthorized way and then how do you go about notifying relevant parties of that breach? The necessary notifications includes anybody from the actual patient whose medical record was exposed, to the media, covered entities, and business associates. The notification policy should lay out plans for forensics to discover the extent of the breach and the cause of the breach. There is typically a chain of command that is outlined in a breach notification strategy that lays out, in detail, who is responsible for different aspects of notification and mitigation. The rules also put the burden on the business associate “of demonstrating that all notifications were made as required” by HIPAA.

    The policies should be consistent with what is in the requirements of a business associate agreement in as it relates to timing to report a breach. 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, and the range we usually hear is somewhere between 24 hours and 5 days. This can be a sticking point in business associate discussions. Despite the 60 day window HIPAA rules also go on to require “evidence demonstrating the necessity of any delay.” If it takes 60 days, there have to be reasons given for that delay.

    Breach policy and breach notification are things that 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.

    Penalties

    If the OCR finds an organization to be in violation, the following actions may take place: - Voluntary compliance; - Corrective action; and/or - Resolution agreement.

    There are monetary penalties associated with HIPAA violations, and the amounts of such violations were raised considerably last year as part of the HIPAA Omnibus Rule included in the HITECH act. The current financial penalties are listed below. Previous to these new rules, the fine associated with each HIPAA violation was capped at $25,000. This number is now $1.5 million per violation.

    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 $100-$50,000 $1,500,000
    B. Reasonable Cause $1000-$50,000 $1,500,000
    C.i. Willful Neglect - Corrected $10,000-$50,000 $1,500,000
    C.ii. Willful Neglect - Not Corrected $50,000 $1,500,000

    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.

    Cordata Breach Policy

    Cordata 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. Cordata is a defined Business Associate or subcontractor according to HIPAA regulations and the specific customer relationship.

    Cordata 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. Cordata 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.

    At Cordata we have both a breach policy and a breach checklist that we can follow in the case of a breach. If you want to learn more about our policies for handling breaches, our policies in general are accessible here and the breach policy specifically is accessible here.

    Please ensure that you have read through it.

    Datica# Preventing Breaches

    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.

    Do not peek

    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.

    Think Twice When You Talk About PHI

    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.

    Prevent Unauthorized Access to Facilities and Secure Areas

    Prevent Unauthorized Access to and Disclosure of Electronic PHI

    Provide Physical Security for Portable Computing and Storage Devices

    Secure PHI in E-mail and E-mail Attachments

    Do NOT under any circumstances email or upload via attachments, any PHI data.

    Violating Cordata 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.

    Datica# Business associates agreement

    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 by far 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.

    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 defines the type of services that the business associate is providing, the type of data that they are interacting with, states 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. That’s actually a very common use case for us at Datica, where most of our early customers are business associates, and their customers are covered entities.

    In this new paradigm of health technology there are interesting definitions around which entities are responsible, both technically and financially in the case of a breach, for different aspects of the HIPAA rules. We tell our prospective customers to read their current business associated agreements that they have with their hosting providers or other services companies to get a sense of what the legal responsibility is for the business associate and the aspects to which the subcontractor is ultimately. Regardless of who is issuing the BAA, you should read through it in detail because at some point a compliance or security officer likely will read it and you want to be as proactive about compliance issues as you can.

    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 subcontractors 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. We have had several early customers come to us because the time period for breach notifications with their existing hosting provider is not acceptable for covered entities they are selling into. We’ve talked to several companies that have run into roadblocks with enterprises because their business associate agreements with their hosting providers had been out of line, and especially relating to breach notification.

    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, process, store, or have access to ePHI.

    HIPAA and You

    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. To see how these policies map to HIPAA requirements - go here.

    Key contacts and roles

    Cordata has a Security Officer and Privacy Officer appointed to assist in maintaining and enforcing safeguards towards compliance.

    The Privacy officer for Cordata is Thom Shumard. You all have access to his email and phone number through our internal directory. Under this role, his responsibilities are to:

    The Chief Security Officer for Cordata is Eddie Sorrell. You all have access to his email and phone number through our internal directory. Under this role, his responsibilities are to:

    System Access

    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.

    1. All systems access must be requested formally to the VP of Engineering, Privacy Officer, or Security Officer via this form. If access if granted, it will be retained for future reference.
      • You will only be given access if it is deemed necessary to perform your job function. All access requests are treated on a ‘least-access principle”.
    2. Your email ID (or other unique identifiers such as SSH keys) are unique to you and must not be shared with anyone else within or outside the company.
    3. You have been given a laptop by the company. Only use this laptop for any work related to the company or accessing its systems. Do not utilize any personal systems to do so without explicit permission from the Chief Security Officer.
    4. Passwords must adhere to the following standards
      • Personal workstation passwords: minimum 8 characters, no dictionary words, at least one number and upper case and lower case letters. Passwords must be changed every 90 days.
      • System level passwords: all access is primarily governed by SSH keys. VPN access is required as a first step. VPN password standards are much more stringent and will be communicated to you as and when required. It is not documented here to minimize risk. No default passwords should be used. Passwords must be encrypted.
    5. Ensure your personal workstation is set to log you off and / or lock if you step away from it.
    6. Properly lock or take your workstation with you when leaving for the day.
    7. Keep a clean desk, do not leave intellectual property or sensitive information available for others to see when away from your desk.
    8. Do not use your laptop for any illegal or harmful activities. If you’re not sure, don’t do it.

    Physical Access

    You have been given a key to access the offices. Do not share it under any circumstances with anyone inside or outside the company.

    Do not let anyone “tailgate” you into the office.

    Incident Management

    Cordata 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: - If you detect any unauthorized or suspicious activity / access of our (or our customers systems) that has not been detected by the IDS or other protections, then immediately report it to management, the Security Officer or Privacy Officer. - Since you detected the event, you might be called upon to be part of the Security Incident Response Team SIRT

    Downloading PHI data locally

    The rule is very simple. You do not need access to PHI data. Do not download, store or open any communication containing PHI.

    Sanctions

    Workforce sanctions are described in more detail here.

    In summary,

    Violations

    Further Reading

    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 Cordata team, to read up on it occasionally as well. Notify the Privacy Officer, Thom Shumard, and Security Officer, Eddie Sorrell, if you notice any discrepancies.

    HIPAA Rules

    A listing of HIPAA regulations and how we map to them is available here

    More details can be got from the HHS website, summary is available here and of course, the Wikipedia page for HIPAA.

    Self Study and Quiz

    This training needs to be taken annually. If you are a new employee, you must take this within 30 days of starting employment with Cordata. You will receive an annual reminder to take this test as well.

    Important

    You are required to meet with your supervisor, or manager, to review the answers to the knowledge check questions and to fill out the course completion forms.

    Format of Self Study

    All questions are presented as multiple choice. There could be more than 1 correct answer.

    Protecting Health Information

    This set of questions is to help you gauge your understanding of the privacy rule and the regulations governing protected health information and the Cordata 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 - [x] 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 - [x] 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 - [x] 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: - [x] 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 - [x] 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 - [x] 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? - [x] Telephone number - [x] Address - [ ] Zipcode - [x] 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? - [x] The government - [x] My organization and me - [ ] Our auditors - [ ] Our customers

    The government protects PHI through the HIPAA regulations. Cordata and you are required to protect health information through its practices and compliance with the HIPAA regulations.

    If you suspect someone is violating the Cordata privacy policy, you should: - [ ] Say nothing - [x] 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 - [x] tougher - [ ] more lenient - [ ] fewer

    The penalties have increased dramatically. See 5.4 for more details

    Security

    This set of questions will help you gauge your understanding of the physical security requirements under HIPAA and the Cordata policies in place to meet them.

    Customer or customer’s data can be cached for future reference within your laptop - [ ] Yes - [x] No

    Customer data should not be stored on your laptop. It may be necessary to have ePHI for troubleshooting an account through a support request, but this data is to not permanently reside on your laptop.

    It is ok to walk away from you computer without locking it or logging off - [ ] Yes - [x] No

    Your computer may contain sensitive 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 - [x] 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 - [x] No

    We recommend backing everything up to the company Google Drive account.

    Technical Security

    This set of questions will help you gauge your understanding of the technical security requirements under HIPAA and the Cordata 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 logon. - [x] 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 Cordata policy for password strength? - [ ] Minimum 8 characters - any combination of words and letters - [x] Minimum 8 characters - any combination of letters, upper and lower case to include a number - [ ] 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 Cordata at any time. - [x] True - [ ] False

    Our organization may run 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 - [x] 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.

    Key Contacts

    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? - [ ] Eddie Sorrell - [ ] Jon Stonis - [ ] Chanda Woodall - [x] Thom Shumard

    Thom Shumard is the Chief Privacy Officer.

    Who is the Chief Security Officer? - [ ] Gary Winzenread - [x] Eddie Sorrell - [ ] Thom Shumard - [ ] Laura Venerable

    Eddie Sorrell is the Chief Security Officer.

    You have questions and concerns about training - compliance or security related. You should reach out to: - [x] 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 Cordata BAA from one of our customers. You should reach out to:

    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 Security Officer.

    You notice or suspect a partner or an employee trying to access customer data. You should: - [ ] Say nothing - [x] 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 - [x] 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 (Security Officer) is responsible for all investigations of privacy and security policy violations

    Final steps

    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.

    If you have read through the manual and completed the quiz, please notify your manager and privacy officer, Thom Shumard of completion.

    Thank you!

    Eddie Sorrell