HIPAA training is good for one year because HIPAA training is required to be completed annually to ensure best practice compliance with evolving regulations and organizational policies, though the frequency can vary depending on specific job roles, updates in HIPAA laws, or organizational requirements. New employees who will have access to Protected Health Information (PHI) are mandated by law to receive HIPAA training to ensure compliance with privacy and security regulations. The HIPAA Privacy Rule and HIPAA Security Rule each have HIPAA training requirements for entities handling PHI.

Under the HIPAA Privacy Rule, training is mandated for all workforce members of covered entities and business associates who handle or have access to PHI, ensuring they understand how to maintain the confidentiality and security of this sensitive information. This includes education on the proper use and disclosure of PHI, the rights of individuals under HIPAA, and the entity’s privacy policies and procedures. The HIPAA Privacy Rule states that “A covered entity must train all members of its workforce on the policies and procedures with respect to protected health information”. The frequency of training is specified “as necessary and appropriate for the members of the workforce to carry out their functions within the covered entity”, which is generally interpreted as being at least annual refresher training for all staff.

The HIPAA Security Rule specifically focuses on training regarding electronic PHI (ePHI), emphasizing the importance of securing electronic health records and other digital forms of PHI. It requires that relevant staff are trained on the entity’s security policies and procedures, the handling of ePHI, and awareness of potential security threats.  The HIPAA Security Rule states “Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).”

Both the HIPAA Privacy Rule and the HIPAA Security Rule require that HIPAA training be provided to new employees within a reasonable time frame after hiring and thereafter as needed, typically annually, to ensure staff are up-to-date with the latest regulations, technologies, and threats to PHI privacy and security. The aim is to create a knowledgeable workforce that contributes to the prevention of unauthorized PHI disclosures and enhances the overall protection of patient privacy and data security. It is general best practice that new employees receive HIPAA training as soon as possible.

Documenting HIPAA training helps in proving compliance with federal requirements, reducing the risk of legal issues or fines during audits. Training records are useful for confirming that new hires and staff with access to PHI are properly trained. Training records also allow organizations to track and manage their employees’ training, identifying areas that need further education and ensuring everyone is up to date with current HIPAA rules.

The post How long is HIPAA training good for? appeared first on HIPAA Journal.

The HIPAA Omnibus Rule mandated modifications to the Privacy, Security, and Enforcement Rules in order to adopt measures passed in the HITECH Act, finalized the Breach Notification Rule, and added standards to account for the passage of the GINA Act. The key provisions of the HIPAA Omnibus Rule were:

• Make business associates of covered entities directly liable for HIPAA compliance.
• Strengthen the limitations on uses and disclosures of Protected Health Information.
• Expand individuals’ rights to restrict disclosures of Protected Health Information.
• Expand individuals’ rights to request copies of their Protected Health Information.
• Require modifications to – and require redistribution of – Notices of Privacy Practices.
• Modify the authorization requirements for disclosures of Protected Health Information.
• The adoption of a four-tired civil monetary penalty structure for violations of HIPAA.
• The finalization of the Breach Notification Rule and the revised “harm” threshold.
• The addition of standards to account for the passage of the GINA Act 2008.

What was the HIPAA Omnibus Rule of January 2013?

The HIPAA Omnibus Rule of January 2013 was comprised of four Final Rules which were combined into one Omnibus Rule to reduce the impact of the changes and the number of times covered entities and business associates would need to undertake compliance activities. Although effective in March 2013, some of the changes were already in force due to Interim Rules having been issued following the passage of the HITECH Act in 2009.

For example, an Interim Rule to explain what information the Breach Notification Rule applied to was published in April 2009, followed by a further Interim Rule to implement the breach notification provisions of the HITECH Act in August 2009. The changes attributable to the Genetic Information Nondiscrimination Act (GINA) were published as a Proposed Rule in April 2009, while the proposed modifications to the Privacy, Security, and Enforcement Rules were published in July 2010.

Despite covered entities and business associate having up to four years to prepare for the HIPAA Omnibus Rule mandated changes – and despite the new categories of HIPAA violations to address violations attributable to reasons other than willful neglect – it appears few covered entities and business associates were ready for the Final Omnibus Rule of January 2013. OCR penalties for HIPAA violations doubled over the next five years and have further increased since.

What did the HIPAA Omnibus Rule Mandate in Greater Detail

It is worth noting that the HIPAA Omnibus Rule did not mandate all the modifications passed in the HITECH Act, and that there have been changes to the Privacy and Enforcement Rules since the publication of the HIPAA Omnibus Rule of 2013. One of the main provisions of the HITECH Act not mandated by the HIPAA Omnibus Rule was settlement sharing (which is still under discussion), while the Privacy Rule has been amended twice to accommodate other Acts, and the Enforcement Act is amended every year to account for inflationary increases in the penalties for HIPAA violations.

To best explain what exactly did the HIPAA Omnibus Rule mandate in 2013, we need to look into each of the modifications and finalizations individually:

Make business associates of covered entities directly liable for HIPAA compliance.

Prior to the HIPAA Omnibus Rule of 2013, if a business associate violated HIPAA, the covered entity to whom the business associate was providing a service would be liable for the violation as business associates was considered agents of covered entities. By amending Subpart D of the General Rules and §164.500 of the Privacy Rule, business associates of covered entities – and subcontractors of business associates – became directly liable for their own HIPAA violations.

Strengthen the limitations on uses and disclosures of Protected Health Information.

The new limitations on uses and disclosures of Protected Health Information were themselves “limited”. Rather than making widespread changes to the Privacy Rule, the HIPAA Omnibus Rule only gave patients and plan members the right to opt out of fundraising communications and conditioned the sale of Protected Health Information (that is not de-identified) on an authorization signed by the individual who is the subject of the Protected Health Information or their personal representative.

Expand individuals’ rights to restrict disclosures of Protected Health Information.

Individuals already had the right to request restrictions on how their Protected Health Information is used and disclosed, but – prior to the Omnibus Rule – covered entities were not required to agree to the requests. A new clause in §164.522 required covered entities to agree to a request if the request related to withholding payment information from a health plan when an individual or a person on the individual’s behalf other than the health plan has paid for treatment or medical equipment.

Expand individuals’ rights to request copies of their Protected Health Information.

This change to the Privacy Rule required covered entities (and business associates where applicable) to provide electronic copies of Protected Health Information to individuals in the format requested by the individuals where the information was readily available in that format. The Rule change had a considerable amount of flexibility inasmuch as covered entities could offer to provide electronic information in alternate formats or via a hard copy if no suitable electronic format could be agreed.

Require modifications to – and require redistribution of – Notices of Privacy Practices.

The requirement to modify and redistribute Notices of Privacy Practices arose due to the strengthened limitations and the expansion of individuals’ rights being material changes to privacy practices. Although the requirement already existed (in §164.520(c)), the notes accompanying the Omnibus Rule explain how health plans and healthcare providers can comply with the redistribution requirement to avoid unnecessary costs and administrative processes.

Modify the authorization requirements for disclosures of Protected Health Information.

While the Omnibus Rule added the requirement to obtain an authorization prior to the sale of Protected Health Information, other events were removed from the list of uses and disclosures requiring prior authorization. These included seeking a parent’s authorization before disclosing a child’s immunization status to a school and seeking a personal representative’s authorization for the disclosure of Protected Health Information once an individual has been dead for fifty years.

The adoption of a four-tired civil monetary penalty structure for violations of HIPAA.

When HIPAA was passed in 1996, the penalties for violations of HIPAA were capped at $100 per violation up to a maximum of $25,000 per year. In addition, the penalties could only be issued if there was evidence of willful neglect to comply with HIPAA. The HITECH Act introduced a new four-tier penalty structure and increased the amount of civil monetary penalties that could be issued to $50,000 per violation up to a maximum of $1,500,000. The penalties have since further increased.

The finalization of the Breach Notification Rule and the revised “harm” threshold.

Although the Breach Notification Rule had been effective since 2009, the HIPAA Omnibus Rule of January 2013 added new standards to the Breach Notification Rule and amended existing standards in the Privacy and Security Rules to make it clear what constituted a breach and who was responsible for notifying it. The revised harm threshold made it a requirement to prove no harm was likely to occur following a breach if not notifying it to the individual and HHS’ Office for Civil Rights.

The addition of standards to account for the passage of the GINA Act 2008.

The Genetic Information Nondiscrimination Act of 2008 (GINA) made it an offence for health insurance companies and employers to discriminate against individuals based on genetic information. The HIPAA Omnibus Rule added genetic health information into the definition of Protected Health Information and expressly prohibited health plans from using or disclosing genetic information for underwriting purposes.

The Consequences of the HIPAA Omnibus Final Rule

The consequences of the HIPAA Omnibus Final Rule mandate changes were that individuals became more conscious of their HIPAA rights, that the scale of data breaches became more apparent, and organizations began to take HIPAA compliance more seriously. However, more than ten years after the publication of the HIPAA Omnibus Final Rule 2013, there is still a lot more that can be done to educate individuals about their rights, reduce data breaches, and improve compliance.

One of the concerns with regards to the lack of HIPAA compliance is that large scale changes to HIPAA are forecast over the next few years. Organizations that are not complying with HIPAA now will find it harder to comply with HIPAA in the future. This may not only result in financial penalties, but – according to HHS’ new Cybersecurity Strategy – could result in expulsion from Medicare and Medicaid programs for healthcare providers that fail to meet Cybersecurity Performance Goals.

Covered Entities and business associates that have failed to keep up with the changes mandated by the HIPAA Omnibus Final Rule of January 2013 are advised to assess their current privacy and security practices, implement measures to fill any gaps in compliance, and support the measures with comprehensive HIPAA training. Organizations unsure about any shortcomings in compliance or how to address them should seek professional HIPAA compliance advice.

The post What did the HIPAA Omnibus Rule Mandate? appeared first on HIPAA Journal.

Google Pay is not HIPAA compliant because the text of HIPAA exempts entities from HIPAA compliance if they engage in “authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting payments for a financial institution.” This exemption was confirmed by the Department of Health and Human Services in the preamble to the Final Omnibus Rule in 2013.

Because of the exemption, there is no requirement to make Google Pay HIPAA compliant or enter into a Business Associate Agreement with Google before the service can be used by covered entities and business associates to collect payments from patients and plan members. Covered entities and business associates can also use Google Pay to conduct B2B financial transactions.

What is Google Pay?

Google Pay is a digital payment facilitator. The service enables users to make payments from cards stored in their Google Wallet online, in app, or in-store from a mobile phone, tablet, or Smartwatch with Near-Field Communication (NFC) capabilities. Users can also use the service to send and receive peer-to-peer payments or to transfer money to or from a bank account similar to PayPal.

For businesses, Google Pay provides a convenient and secure way for customers to pay for goods and services. The Google Pay API can be used to set up an autofill checkout for websites and apps, while in-store NFC readers eliminate the necessity for customers to carry physical cards. They can simply tap an app on their phone, tablet, or Smartwatch to complete a payment within seconds.

How Does Google Pay Work?

A further reason why it is not necessary to make Google Pay HIPAA compliant is the way the service “tokenizes” card information stored in a Google Wallet. When a user adds a card to their Google Wallet, Google Pay creates a unique Dynamic Primary Account Number (DPAN) and it is this number – rather than the card number – that is transmitted during a payment transaction.

Although the last four numbers of each payment card are visible in the Google Wallet, Google Pay does not transmit any information that could be used to identify a customer. For this reason, Google would not qualify as a business associate even if the service was not exempted by HIPAA – because the payment part of the service does not create, receive, store, or transmit Protected Health Information.

What Does HIPAA Say about Payment Facilitators?

Payment facilitators such as Google Pay are not referenced in HIPAA because they did not exist at the time. However, §1179 of the Act exempts payment processing and associated transactions from HIPAA compliance – an exemption that was confirmed in the preamble to the Final Omnibus Rule in 2013, which states:

“The HIPAA Rules, including the business associate provisions, do not apply to banking and financial institutions with respect to the payment processing activities identified in § 1179 of the HIPAA statute, for example, the activity of cashing a check or conducting a funds transfer.”

However, while the processing element of a financial transaction is exempt from HIPAA, any PHI maintained to support, manage, or reconcile payments is still subject to the HIPAA’s privacy and security standards. Due to this requirement, covered entities and business associates that conduct B2B financial transactions using Google Pay must not store PHI in a Google Wallet.

Is Google Pay HIPAA Compliant? Conclusion

Google Pay is not HIPAA compliant, but it does not need to be. The service does not communicate any individually identifiable health information or – because of the tokenization process – any information that could be used to identify an individual. In addition, the service is exempted from HIPAA compliance by the HIPAA Act, so there is no need to make Google Pay HIPAA compliant.

What covered entities and business associates need to be aware of is potential compatibility issues with any devices or systems Google Pay is integrated with, the compliance of third party integrations (where necessary), and security awareness among workforce members, patients, and plan members to ensure PHI is not disclosed impermissibly or without authorization during financial transactions.

It is also important that covered entities and business associates conducting B2B financial transactions via Google Pay do not store PHI in a Google Wallet as Google Wallet is not HIPAA compliant. Covered entities and business associates that are uncertain about integrations with Google Pay, third party vetting, or security awareness should seek professional compliance advice.

The post Is Google Pay HIPAA Compliant? appeared first on HIPAA Journal.

Stripe is not HIPAA compliant and – other than its payment processing services – should not be used by covered entities and business associates to create, collect, store, or transmit Protected Health Information (PHI). Stripe does not need to comply with HIPAA for payment processing services due to HIPAA exempting financial transactions from the requirements of the Administrative Simplification Regulations. Despite the exemption, businesses may be restricted in how they can use the payment processing services due to Stripe’s Terms and Conditions.

What is Stripe?

Stripe is primarily a payment processing platform that enables businesses to collect payments from a customer via a wide range of payment options (credit card, ACH transfer, Apple Pay, Bitcoin, etc.). Businesses can integrate the Stripe API into an online store or app, subscribe to a plan that supports in-person card processing, and/or purchase card readers with tap to pay capabilities.

As well as its payment processing activities, Stripe provides billing, identity verification, and fraud management services. The company also offers branded physical and virtual payment cards, and supports thousands of integrations with services such as DocuSign, QuickBooks, and HubSpot. However, if businesses in the healthcare sector want to use these services to create, collect, store, or transmit Protected Health Information (PHI), it is important Stripe is HIPAA compliant.

Is Stripe HIPAA Compliant?

At first glance, the answer to the question is Stripe HIPAA compliant would appear to be yes. Stripe complies with multiple US and International data privacy regulations (i.e., CCPA, GDPR, PIPEDA, EU-US Data Privacy Framework, etc.) and its services can be configured to comply with the Technical Safeguards of the Security Rule (access controls, event logs, encryption, etc.).

However, Stripe is not HIPAA compliant because of the way it records personal data within transaction data and uses the combined data to help detect fraud. To help with the fraud detection process, Stripe shares the combined data with third party payment providers – some of whom have poor security records (i.e. Coinbase) or dubious privacy practices (i.e., PayPal).

Because companies such as Coinbase and PayPal will not enter into a Business Associate Agreement with Stripe, Stripe is unable to enter into Business Associate Agreements with HIPAA covered entities and business associates – a prerequisite before PHI is disclosed to any third party. Because Stripe is unable to enter into Business Associate Agreements, it is not HIPAA compliant itself.

The Payment Processing Exemption

The payment processing exemption (§1179 of the Social Security Act) was included in Title II of HIPAA in 1996 – the Administrative Simplification Regulations – because the objective of the Administrative Simplification Regulations is to increase the efficiency and effectiveness of the healthcare system. It was considered that applying the standards of the Privacy and Security Rules to payment processing  – once the Rules were adopted – would undermine this objective.

In 2002, the Department of Health and Human Services (HHS) published guidance to confirm the exemption would apply “when a financial institution […] conducts any activity that directly facilitates or effects the transfer of funds for payment for health care or health plan premiums”. HHS added, “when it conducts these activities, the financial institution is providing its normal banking […] services to customers. It is not performing a function or activity for, or on behalf of, a covered entity.”

The Department further confirmed the exemption did not apply to business associates in the preamble to the Final Omnibus Rule in 2013 – adding the caveat “A banking or financial institution may be a business associate where the institution performs functions above and beyond the payment processing activities identified above on behalf of a covered entity, such as performing accounts receivable functions on behalf of a health care provider.”

This exemption and the guidance that followed it means that it is permissible to disclose PHI in payment processing transactions, but not in any other activity without a Business Associate Agreement being in place. In the context of is Stripe HIPAA compliant, this means that Stripe can disclose PHI to (for example) Coinbase and PayPal to facilitate payment processing, but not to Coinbase and PayPal to facilitate fraud detection.

Stripe’s Payment Processing Restrictions

Because Stripe provides services around the globe, the payment processing platform has to comply with multiple consumer protection regulations and licensing requirements. In some cases, it is easier for Strips to restrict or prohibit all types of business activity than it is to comply with a diverse range of regulations and requirements or limit international payments for specific business activities.

Some of the activities Stripe restricts or prohibits may surprise businesses in the US. For example, the platform cannot be used to collect payments for insurance services that include medical benefit packages, for telemedicine and telehealth services, or prescription-only pharmaceuticals and regulated medical devices. The full list of prohibited and restricted business activities can be found here.

It is important to be aware that if a business violates Stripe’s Terms and Conditions (of which the restricted business list forms a part), Stripe can terminate access to the payment processing platform immediately. For this reason, if your business is considering using Stripe as a payment processor, it is advisable to thoroughly review the Terms and Conditions and any associated documentation to understand what your obligations are.

The post Is Stripe HIPAA Compliant? appeared first on HIPAA Journal.

Examples of HIPAA violations by employers are easy to find because almost every avoidable HIPAA violation is indirectly attributable to an employer’s failure to implement adequate privacy and security measures, failure to effectively train members of the workforce, or failure to monitor HIPAA compliance. Over the next few years, these failures may become expensive for employers in – or providing a service to – the healthcare industry.

Employers in their role as a covered entity or business associate have the ultimate responsibility for HIPAA compliance. They are responsible for complying with all applicable federal and state regulations, for developing workplace policies and procedures, and for ensuring the policies and procedures are complied with. While these responsibilities may sometimes be delegated to a third party, employers are usually responsible for selecting the third party.

When avoidable HIPAA violations occur, they represent a compliance failure by an employer. Although the violations most often manifest as a data breach, unauthorized access to PHI, or an impermissible disclosure, the root cause is more likely to be the failure to conduct an accurate and thorough risk analysis, identify reasonably anticipated threats and vulnerabilities, and implement adequate measures to prevent violations attributable to the threats and vulnerabilities.

Avoidable vs. Unavoidable HIPAA Violations

To best explain why avoidable HIPAA violations are examples of HIPAA violations by employers, it is important to distinguish between avoidable and unavoidable HIPAA violations.

Avoidable HIPAA violations are those in which reasonably anticipated threats exist, but they are not identified in a risk assessment or inadequate measures are implemented to prevent them. Examples of HIPAA violations by employers in this category include data breaches attributable to “Hacking/IT Incidents” where the risk of remote, unauthorized access has been identified, but the employer has failed to implement a robust password policy supported by two-factor-authentication.

Unavoidable HIPAA violations occur when an employer has conducted an accurate and thorough risk analysis, and implemented measures to prevent HIPAA violations, but violations still occur. Examples of unavoidable HIPAA violations include when a healthcare professional accidently discloses more than the minimum necessary PHI, or when a member of the IT team misuses their login privileges to steal a database of medical records and sell it on the Internet

How Many Avoidable HIPAA Violations Occur Each Year?

It is impossible to determine how many avoidable HIPAA violations occur each year because most violations are reported internally – either by a member of the workforce to their supervisor or by a member of the public to the organization’s Privacy Officer. Relatively few HIPAA violations that do not involve data breaches are reported to – or escalated to – HHS’ Office of Civil Rights (around 5,000 per year), and these mostly relate to impermissible disclosures or the denial of patients’ HIPAA rights.

All data breaches have to be notified to HHS’ Office for Civil Rights. The majority of data breaches qualify as examples of HIPAA violations by employers because 75% of breaches affecting 500 or more individuals are attributable to Hacking/IT Incidents (per 2021 report) – of which 80% are attributable to brute force attacks on weak passwords and employee susceptibility to phishing. Both causes can be avoided by implementing a robust password policy supported by two-factor-authentication.

Specific Examples of HIPAA Violations by Employers

In 2021 – the most recent year for which data is currently available – HHS’ Office for Civil Rights (OCR) received more than 64,000 notifications of data breaches. However, it is only possible to view the details of around 600 of these data breaches because OCR is only required to publish details of data breaches affecting 500 or more individuals. These specific examples of HIPAA violations by employers can be found in the Archive section of the HHS Breach Report and include:

• In December 2021, the Barlow Respiratory Hospital in Los Angeles notified OCR of a ransomware attack affecting more than 10,000 individuals. OCR responded by providing “technical assistance regarding the HIPAA Rules” – implying the employer had not complied with all applicable regulations.
• In November 2021, the Howard University College of Dentistry in DC notified OCR of a ransomware attack affecting more than 80,000 individuals. The breach report reads “the CE implemented additional administrative, physical, and technical safeguards to better protect PHI” – implying adequate measures did not exist beforehand.
• In October 2021, an employee of the Community Eye Center of North Carolina was the victim of an email phishing attack that compromised the PHI of 149,804 individuals. In response to the breach, “staff were retrained on email security” – something that should have been part of an ongoing security awareness training program.
• In September 2021, an employee of the Kentucky-based health plan – Humana Inc. – emailed the PHI of 948 individuals to the wrong recipients. This type of data breaches occurs frequently and is a reasonably anticipated threat that can be avoided with properly configured Data Loss Prevention for email.

Somewhat surprisingly, in 2021 only two data breaches resulted in a financial penalty. A further twelve financial penalties were issued for Right of Access failures. While not all of the remaining ~70,000 complaints and notifications were examples of HIPAA violations by employers, the impression is that OCR does not have adequate resources to effectively enforce HIPAA compliance. However, that might soon be about to change – making non-compliance expensive for employers.

Potential Changes to HIPAA Enforcement in 2024

There are two potential changes to HIPAA enforcement in 2024. The first relates to the “settlement sharing” requirement of the HITECH Act which is yet to be actioned due to the challenges of defining harm and settling on a fair method of settlement sharing. OCR issued a Request for Information in 2022 to move forward with this requirement; and, if the challenges are addressed, OCR could come under pressure from victims of data breaches to issue more financial penalties for HIPAA violations.

More recently, in December 2023, OCR published a Healthcare Sector Cybersecurity Strategy which includes proposals to develop new Security Rule standards to combat cybercrime. Not only will noncompliance with the new Security Rule standards be proactively sanctioned by OCR, but noncompliance could also result in expulsion from CMS’ Medicare program – potentially a more expensive financial penalty for employers in – or providing a service to – the healthcare industry.

Covered entities and business associates concerned that the examples of HIPAA violations by employers mentioned in this article might in future be punishable by financial penalties – or might affect their future eligibility for participation in Medicare – are advised to seek professional HIPAA compliance advice.

The post Examples of HIPAA Violations by Employers appeared first on HIPAA Journal.

PHI in HIPAA is an acronym for Protected Health Information – health information that is created, collected, maintained, or transmitted by a covered entity that relates to an individual’s past, present, or future physical or mental condition, treatment for the condition, or payment for the treatment, and that is protected by HIPAA from impermissible uses and disclosures.

In addition to individuals’ health information being protected from impermissible uses and disclosures, HIPAA also applies to individually identifiable non-health information stored in the same designated record set as PHI that could identify the subject of the PHI or be used with other information stored in the same designated record set to identify the subject of the PHI.

The application of HIPAA protections to non-health information can create misunderstandings about what information should be protected and when it should be protected (evidenced by multiple sources mistaking the “18 HIPAA identifiers” as PHI). This article aims to resolve potential misunderstandings about what is PHI in HIPAA by answering three simple questions:

• What are Designated Record Sets in HIPAA?
• What are the 18 HIPAA Identifiers?
• When is Identifying Information Not PHI in HIPAA?

What are Designated Record Sets in HIPAA?

Designated record sets are records maintained by or for a covered entity that are used in whole or part to make decisions about an individual. For example, an individual’s medical history maintained by a healthcare provider would be a designated record set, and an individual’s enrollment, payment, and claims history maintained by a health plan would be a designated record set.

A designated record set can consist of a single item of PHI or any collection of records in which one or more items qualify as PHI. For example, a photo of a child displayed on a pediatrician’s baby wall is a designated record set (because it implies a previous treatment relationship), as are details of an individual’s emotional support animal if the details include the condition of the individual.

Because a designated record set can consist of a single item of PHI, an individual can have multiple designated record sets maintained by the same organization. Any information maintained in a designated record set is considered PHI in HIPAA, even if the designated record set consists of only one piece of information relating to an individual’s condition, treatment, or payment.

What are the 18 HIPAA Identifiers?

The reason it is important to understand what designated record sets are is to dispel any misunderstandings about the 18 HIPAA identifiers. One of the reasons for potential misunderstandings about what is PHI in HIPAA is that some sources have interpreted the 18 HIPAA identifiers in §164.514 of the Privacy Rule as being PHI. They are not.

The 18 HIPAA identifiers are eighteen identifying pieces of information that have to be removed from a designated record set before the record set can be considered de-identified under the “safe harbor” method of deidentification. While any of the 18 HIPAA identifiers would assume the same protections as health information when maintained in the same designated record set as health information, they are not protected by HIPAA outside a designated record set.

In addition to not being protected by HIPAA when maintained outside a designated record set, the list of identifiers is almost a quarter of a century out of date. There are now many more pieces of information that could be used to identify an individual – and would need to be removed from a designated record set before any health information left in the set is deidentified – including unique occupations, social media aliases, and details about emotional support animals.

When is Identifying Information not PHI in HIPAA?

As explained above, identifying information is not PHI in HIPAA when it is not maintained in a designated record set that contains health information. To help better explain this, we will use the example of Mrs. Doe – who has undergone medical treatment at a hospital where she also volunteers to support nursing staff during meal delivery times.

Mrs. Doe`s medical history will be in one or more designated record sets – which also include identifying information such as her name and telephone number. While maintained in these designated records sets, Mrs. Doe’s name and telephone number are PHI and have to be protected from impermissible uses and disclosures.

However, Mrs. Doe’s name and telephone number are also included in a separate hospital database maintained by the volunteer administrator. As this database does not contain PHI, it is not a designated record set. The identifying information maintained in the database is not PHI and is not protected by HIPAA – even though the database is maintained by a hospital that maintains one or more other databases/designated records sets in which the same information is protected.

Why it is Important to Understand What is PHI in HIPAA

It is important to understand what is PHI in HIPAA so PHI can be protected against impermissible uses and disclosures in compliance with HIPAA. It can be equally important to understand what is not PHI in HIPAA to prevent obstacles to communication and operational efficiency. To demonstrate this point using the example of Mrs. Doe’s name and telephone number –

If the same level of protection was applied to the identifying information maintained in a volunteer database as the identifying information in a designated record set, it may not be possible for the volunteer administrator to contact Mrs. Doe if the nursing staff required more volunteer assistance on a particular shift. This could be because the volunteer administrator did not have sufficient permissions to access a protected designated record set containing Mrs. Doe’s telephone number.

While this is a very simple example to explain why it is important to understand what is – and what isn’t – PHI in HIPAA, similar scenarios could be applied to many different uses of individually identifiable non-health information that could be secured more than necessary due to a misunderstanding of what is PHI in HIPAA. If you are responsible for compliance in an organization, and you are not sure you understand what PHI is in HIPAA, you should seek compliance advice.

The post What is PHI in HIPAA? appeared first on HIPAA Journal.

SOC 2 in healthcare is a privacy and security standard that can provide assurances to the C-Suite, to business partners, and to regulators that an organization has implemented appropriate controls to protect data (SOC 2 Type 1) and is using the controls effectively (SOC 2 Type 2). SOC 2 compliance in healthcare is voluntary, but the benefits of being SOC 2 “ready” can be significant.

What is SOC 2?

SOC 2 stands for System and Organization Controls 2 – one of five sets of standards organizations can use to assess that their privacy, security, and/or administrative processes are adequate to ensure the confidentiality, integrity, and availability of data. In healthcare, SOC 2 is the most relevant of the five sets of standards because SOC 2 controls closely align with the requirements of HIPAA.

Healthcare organizations that have implemented policies and procedures to comply with HIPAA should have little difficulty in attesting SOC 2 compliance and passing an SOC 2 audit. The audit report can then be used to demonstrate that the appropriate controls are in place to protect the privacy and security of healthcare data (Type 1) and that they are being used effectively (Type 2).

The SOC 2 Process

The SOC 2 process consists of determining what “Trust Services Criteria”, what “Control Components”, and what “Points of Focus” within each Control Component apply to your organization. These can then be compiled into an SOC 2 compliance checklist which can be used to assess “point of time” compliance or “ongoing” compliance with the relevant controls.

Once the assessment is complete, you attest that the organization is SOC 2 compliant. To verify the attestation via an audit report, you arrange for an SOC 2 audit conducted by a firm commissioned or certified by the American Institute of Certified Public Accountants (AICPA). Depending on the “Type” of attestation being certified, the audit can take one day (Type 1) or several months (Type 2).

The SOC 2 Controls

The SOC 2 controls consist of  five Trust Services Criteria, within which there can be multiple Control Components and Points of Focus that can be relevant to an organization’s operations. Because different organizations assess themselves on different Criteria, Components, and Points of Focus, there is considerable overlapping of Points of Focus between the five Trust Services Criteria.

Security

Of the five Trust Services Criteria, this is the only one required in an SOC 2 assessment. Its objective is to demonstrate that an organization’s systems and the data stored on them are protected against physical damage, unauthorized access, and unauthorized disclosure. Within the Security Trust Services Criteria there are nine Control Components, each with multiple Points of Focus.

• CC1: Control Environment
• CC2: Communication and Information
• CC3: Risk Assessment
• CC4: Monitoring Activities
• CC5: Control Activities
• CC6: Logical and Physical Access Controls
• CC7: System Operations
• CC8: Change Management
• CC9: Risk Mitigation

Each Point of Focus is required to have at least two control activities so that if one control activity fails, the Point of Focus is still supported by at least one other control activity. For example, a logical access control with two control activities would be a username and password combination supported by two factor authentication.

Availability

For organizations pursuing SOC 2 in healthcare, compliance with the Availability Trust Services Criteria requires little more than compliance with the Administrative Safeguards of the Security Rule (§164.308) relating to data backups, environmental controls to safeguard physical backups, data recovery controls and ensuring that systems have the capacity to manage demand.

Confidentiality

The objective of the Confidentiality Trust Services Criteria is to ensure that PHI maintained in healthcare systems is protected. Omitting overlapping and duplicated Points of Focus, the four most relevant to healthcare organizations relate to data classification and retention, the protection of sensitive information, the encryption of data, and the disposal of data.

Processing Integrity

Although this Trust Services Criteria has been amended to align with the EU-US Data Privacy Framework and the EU’s General Data Protection Regulation, the requirement to ensure data processing is complete, valid, accurate, timely, and authorized aligns with HIPAA’s Technical Safeguards for the integrity of PHI so is worth reviewing.

Privacy

The Privacy Control Components and Points of Focus closely align with HIPAA Privacy Rule standards relating to privacy policies, privacy management, and breach notification. It is not necessary for organizations to comply with the Privacy Trust Services Criteria to achieve SOC 2 in healthcare, but it would be unusual for it to be omitted from the point of view of a business partner or a regulator.

SOC 2 and HIPAA

From the examples provided above, it is easy to see a close relationship between SOC 2 and HIPAA security standards. However, when you review the Control Components and Points of Focus of the privacy Trust Services Criteria, there is an equally close relationship between SOC 2 and HIPAA privacy standards – particularly in the Privacy Management Framework Control Component.

In the context of SOC 2 in healthcare, the contents of the Privacy Management Framework include (but are not limited to):

• Policies and procedures for the creation, collection, use and transmission of PHI.
• Risk analyses for identifying, classifying, and prioritizing vulnerabilities and risks to PHI.
• Procedures to obtain individuals’ authorizations for uses and disclosures when necessary.
• Procedures to prevent, detect, and mitigate the consequences of data breaches.
• Procedures to notify individuals and the relevant authorities in the event of a data breach.
• The provision of a Notice of Privacy Practices and procedures to notify individuals of changes.
• Procedures for responding to access requests and requests for copies of PHI.
• Procedures for amending PHI when requested and informing third parties when necessary.
• Procedures for maintaining and providing on request an accounting of disclosures.
• Procedures for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from individuals.

The Benefits of SOC 2 in Healthcare

The benefits of SOC 2 in healthcare vary depending on what an organization is trying to achieve by going through the SOC 2 process. For example, a business associate may need to prove it has measures in place to protect the privacy and security of PHI before entering into a Business Associate Agreement with a covered entity. In such cases, it may only be necessary for the business associate to demonstrate SOC 2 Type 1 compliance.

Alternatively, a healthcare organization may wish to demonstrate that it complies with SOC 2 Type 2 to qualify for reduced cybersecurity insurance rates, or it may pursue an SOC 2 in healthcare audit report to demonstrate compliance with a recognized security framework. Being able to demonstrate at least one years’ compliance with a recognized security framework could help mitigate regulatory penalties for violations of HIPAA.

Even if no direct motive exists for pursuing SOC 2 in healthcare, the process of determining what Trust Services Criteria, Control Components, and Points of Focus apply can help organizations identify and address potential privacy and security risks to increase their compliance posture. It is important to be aware there are no passes or fails in a SOC2 audit. The auditor compiling the SOC 2 audit report only records a “qualified opinion”.

SOC 2 Certification vs. SOC 2 “Ready”

Because organizations can select which Trust Services Criteria, Control Components, and Points of Focus they wish to include in an SOC 2 attestation, there is no such thing as an SOC 2 certification. The term “certification” usually refers to an SOC 2 audit report which – as discussed above – does not have passes or fails. A more appropriate term  to use is SOC 2 “ready” which, in the context of SOC 2 in healthcare, means being ready for an SOC 2 audit.

Being SOC 2 ready is the ideal state for a healthcare organization to aim for and maintain because, even if the organization does not undergo an SOC 2 audit, it implies the healthcare organization is complying with HIPAA. If your organization requires help with identifying which Trust Services Criteria, Control Components, and Points of Focus apply, or requires advice about how to become SOC 2 ready, it is recommended you speak with an SOC 2 compliance professional.

The post What is SOC 2 in Healthcare? appeared first on HIPAA Journal.

The HIPAA Technical Safeguards consist of five Security Rule standards that are designed to protect ePHI and control who has access to it. All covered entities and business associates are required to comply with the five standards or adopt equally effective measures. However, evidence suggests many covered entities and business associates fail to comply with the HIPAA Technical Safeguards.

Despite advances in technology over the past twenty years, the HIPAA Technical Safeguards (45 CFR §164.312) have remained unchanged since their publication in February 2003. This is not due to lax rulemaking by the Department of Health & Human Services (HHS), but rather testament to the work that went into fine-tuning the standards between the publication of the Proposed Security Rule in 1998 and the publication of the Final Security Rule five years later.

Consequently, it can be beneficial to go back to the Federal Register entry for the Final Security Rule in order to review the analyses published alongside the standards and implementation specifications. This can help covered entities and business associates better understand why the HIPAA Technical Safeguards exist, what their objectives are, and how HHS anticipated covered entities and business associates could comply with them.

The HIPAA Technical Safeguards – the Five Standards

• Access Controls
• Audit Controls
• Integrity Controls
• Authentication Controls
• Transmission Security

Access Controls

The access controls standard requires covered entities and business associates to implement technical policies and procedures to only allow access to ePHI by authorized members of the workforce and software systems that have been granted access rights according to the Information Access Management Standard of the Administrative Safeguards (§164.308(a)(4)). The policies and procedures must meet the requirements of four implementation specifications:

• Unique user identification (Required). Assign unique names and/or numbers to identify users and track user activity.
• Emergency access procedures (Required). Develop (and test) procedures for accessing ePHI during an emergency.
• Automatic logoff (Addressable). Implement procedures that log users out of systems and devices after a period of inactivity.
• Encryption and decryption (Addressable). Implement procedures for the encryption and decryption of ePHI at rest.

When you review the analysis of this standard, it is notable that HHS deleted language relating to “context-based access”, “role-based access”, and “user-based access” and commented that any appropriate access control mechanism is allowed.

It is also notable that HHS changed the implementation specifications relating to automatic logoff and encryption to “Addressable” to allow other forms of (equally effective) inactivity lockout, and to base the adoption of encryption on the outcome of a risk assessment.

Audit Controls

The audit controls standard is a good example of why it can be beneficial to review the analysis of the Final Security Rule. This is because this standard requires the implementation of hardware, software, and/or procedural mechanisms that record access to – and activity in – information systems that contain or use ePHI.

At face value, the purpose of this standard could be interpreted as providing a means to retrospectively review system access and activity following a data breach – which does not align with the objectives of the HIPAA Technical Safeguards “to protect ePHI and control who has access to it.”

However, the analysis references two NIST Special Publications – 800-14 and 800-33 (now withdrawn) – which both advocate the use of automated audit controls to prevent unauthorized access or unauthorized activity as it happens, rather than review these events retrospectively.

At the time (in 2003), the availability of automated audit controls was limited. However, due to developments in cloud computing, solutions such as AWS CloudTrail are relatively inexpensive to implement and simple to configure, and can add an additional layer of defense against data breaches.

Integrity Controls

The integrity controls standard – that covered entities and business associates implement policies and procedures to protect ePHI from improper alteration or destruction – appears to imply that members of the workforce are prevented from typing in the wrong information or inadvertently pressing the delete key.

While this standard can be complied with in part by assigning members of the workforce least privilege or read-only access to ePHI whenever possible, this standard was originally going to be called the “data authentication” standard and would require covered entities and business associates to implement measures such as error correcting memory to prevent data corruption.

Understanding the original intention of the standard helps put the single implementation specification – that mechanisms should be implemented to corroborate that ePHI has not been altered or destroyed in an unauthorized manner – into context. Nonetheless, it is still advisable to assign members of the workforce least privilege or read-only access to ePHI whenever possible.

Authentication Controls

The authentications controls standard appears to repeat the requirements of the access controls standard inasmuch as it requires covered entities and business associates to implement procedures to verify that a person or entity seeking access to electronic PHI is the one claimed. Therefore, issuing each authorized user with a unique password or PIN should satisfy this requirement.

However, when you review the analysis of this standard, HHS comments that covered entities and business associates should verify user IDs using tools such as electronic signatures, call backs, and soft tokens (biometric 2FA would also be an option in 2023). Therefore, it is necessary to do more than issue each user with unique user IDs to comply with this standard.

Transmission Security

The transmission security standard is the sole example of when the HIPAA Technical Safeguards should have been updated to reflect advances in technology. This standard – to guard against unauthorized access to ePHI transmitted over an electronic communications network – was toned down from what was originally proposed due to “switched, point-to-point connections, for example, dial-up lines, have a very small probability of interception”.

HHS also reconsidered the strength of the two implementation specifications relating to integrity controls and encryption because, at the time, there were no interoperable solutions for encrypting email communications. However, as most electronic transmissions are now conducted over the Internet, and as most email services support end-to-end encryption, covered entities and business associates should implement the specifications or equally effective alternatives.

How Organizations Fail to Comply With the HIPAA Technical Safeguards

Despite there being only five standards in the HIPAA Technical Safeguards, many covered entities and business associates struggle to comply with them. There is evidence of this in the HHS Breach Report Archive  – a database of almost 5,000 resolved HIPAA data breaches affecting 500 or more individuals that includes descriptions of how the breaches occurred

Many data breaches are attributable to the misuse or sharing of passwords, the failure to implement logoff controls, or the failure to encrypt data at rest. Many more could have been avoided with automated audit controls, while the failure to assign members of the workforce least privilege or read-only access led to the unauthorized disclosure of tens of thousands of records.

Unfortunately, this might only be the tip of the iceberg. According to HHS’ most recent report to Congress, the agency receives more than 60,000 notifications each year relating to breaches affecting fewer than 500 individuals. While the number of individuals affected by these breaches may not match those recorded on the database, it is fair to assume the causes of the data breaches are much the same as those which are publicly accessible.

Due to the recent restructuring of HHS’ Office for Civil Rights, and the proposed introduction of settlement sharing, it is likely there will be an increase in enforcement action against covered entities and business associates that fail to comply with the HIPAA Technical Safeguards. Organizations that are unsure whether their current efforts meet the requirements of the HIPAA Technical Safeguards are advised to seek professional compliance advice.

The post What are the HIPAA Technical Safeguards? appeared first on HIPAA Journal.