Patient Pattern Compliance

- HIPAA Training

CLOSE MENU

Introduction to HIPAA Training


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


We are in the business of providing compliant infrastructure to our customers so that they do not have to worry about the nuances of devOps and scaling and managing infrastructure - all they have to worry about is their application - its capabilities and its security and their own internal policies. We take care of everything else.

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 senstitive 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 their and their customers’ sensitive data and we have a duty to protect that 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.


Original material and content was created by Patient Pattern, Inc, and 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. Please email info@patientpattern.com with any questions or problems accessing the training.

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. I can remember doing my first HIPAA audit at HCA as a consultant, way back before I went to medical school or knew what an EHR was, and having to do a find-and-replace to assure we caught any misspellings of “HIPAA” before submitting the report to HCA. 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 to 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 and 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

2. The cloud

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.

3. There are heavy penalties for violating it

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.

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 created this tutorial at Patient Pattern because we wanted something that we could distribute to all new hires 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. As we talked to early customers and prospects, we also realized that we were getting asked the same questions about HIPAA time and time again.

Seeing an opportunity to help the industry and ideally reduce the barriers to people coming into healthcare from outside the industry, both things we’re passionate about at Patient Pattern, we decided to reuse some of our existing content, from our blog, and generate a bunch of new content. If you have feedback or suggestions, please email us.

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.

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 PHR for a hospital is a business associate, and the hosting provider that the developer uses (ideally Patient Pattern) is a subcontractor. The developer signs a BAA with the hospital and with the hosting provider, again ideally Patient Pattern.

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

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

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 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 Patient Pattern and Revion.com. Patient Pattern 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 Patient Pattern 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.

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

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.

Overview

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 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 Patient Pattern 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 + De-identifying

We devoted an entire post to “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, etc).

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 uses to secure PHI. You probably remember getting these, and signing them, every time you’ve gone 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 obtaining PHI in violation of the HIPAA Privacy 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 electronic protected health information, or 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 setting 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.

When you use Patient Pattern, we cover much of risk environment for you as we manage many aspects of the architecture. We work with you to define areas that you need to address in terms of risk, and will work closely with you if and when you decide to go forward with a full audit.

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, including the ones that we use at Patient Pattern, more than meet the requirements in the Security Rule for facilities. Typically compliant Infrastructure-as-a-Service vendors, like Revion.com, AWS and Firehost, 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. We control and monitor access at our offices using both keys and uniquely-assigned fobs.

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. 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 Patient Pattern addresses the different specifications, on our HIPAA page.

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.

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.

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 Patient Pattern and Revion.com. Patient Pattern 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 Patient Pattern 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.

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

Protection and privacy come into play once the individual 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, zipcode, street address etc.
2 Geographic locators Everything (street address, city, precinct, zipcode, lat long 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.

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

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 Patient Pattern or any vendor doing business with customers who have PHI data: - Given the business we are in, we should not have to request access to any 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 we continue to grow and evolve in services provided in which case, you will be explicitly informed), you, as an employee of Patient Pattern 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): - Appointment reminders – PHI may be used to contact members and patients about appointments for health care and treatment. In a Patient Pattern context, our customers might use our Messaging services to communicate this kind of information) - 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 Patient Pattern context, we enter into BAAs with all of our clients as we provide infrastructural services to them. However, we have put guidelines 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 a relatively small number 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, and that is why we created Patient Pattern; 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 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 needs 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.

Patient Pattern Breach Policy

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

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

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

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

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. That’s actually a very common use case for us at Patient Pattern, where most of our early customers are business associates, and their customers are covered entities.

We spent a lot of time and a lot of money with our attorneys on our BAAs because this is a new area, an area we don’t think is well defined yet; we don’t think the existing BAA templates are adequate or even make sense for most hosted vendors. 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 associate 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 responsible. 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 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. 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 to. 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. Our policy at Patient Pattern is breach notification within 4 hours, along with some very detailed plans to help you mitigate the risk of a breach.

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, email us and we’ll walk you through ours and answer any questions you might have about it.

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

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

The Privacy officer for Patient Pattern, Inc., is Brett Kellgren. 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 Patient Pattern, Inc., is Brett Kellgren. 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 is 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 7 characters, no dictionary words, at least one number and at least one special character. 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. 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 fob and/or key to access the offices. This fob is unique to you. 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

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

Dowloading 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 Patient Pattern team, to read up on it occasionally as well. Notify the Chief Privacy Officer 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 found on 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 Patient Pattern Inc. You will receive an annual reminder to take this test as well.

Important

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.

Format of Self Study

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

Protecting Health Information

This set of questions is to help you guage your understanding of the privacy rule and the regulations governing protected health information and the Patient Pattern 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?:

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?:

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?

The privacy rule gives patients the right to control how their information is used and disclosed.

To maintain confidentiality we need:

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?

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

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?

Zipcodes (except for a small set) cannot be used to uniquely identify an individual. Neither can gender.

Who protects PHI?

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

If you suspect someone is violating the Patient Pattern privacy policy, you should:

Report the suspicion to your manager or supervisor.

The HIPAA Omnibus Rule provides what penalties for violation of HIPAA rules.

The penalties have increased dramatically. See 5.4 for more details


Security

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


Customer or customer’s data can be cached within your laptop

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

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. Since we are all issued Macs, please close the lid and ensure that a login prompt comes up when re-opened.

It is optional to encrypt my laptop’s disk.

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

This is only permitted if the external drive is also encrypted. We recommend backing everything up to the company Box account.


Technical Security

This set of questions will help you guage your understanding of the technical security requirements under HIPAA and the Patient Pattern 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.

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 Patient Pattern policy for password strength?

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 Patient Pattern Inc. at any time.

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

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?

Brett Kellgren is the Chief Privacy Officer.

Who is the Chief Security Officer?

Brett Kellgren is the Chief Security Officer.

You have questions and concerns about training - compliance or security related. You should reach out to:

All training related concerns should be communicated either to the Chief Privacy Officer or your manager.

You receive some questions about the Patient Pattern 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 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:

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:

The Chief 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 click on this link and fill it out.

Your Chief Security Officer will receive an email shortly and will schedule a time with you to go over any questions or concerns you might have.

Thank you!