A HIPAA Security Rule checklist helps covered entities, business associates, and other organizations subject to HIPAA compliance to fulfil the requirements of the Security Standards for the Protection of Electronic Protected Health Information (better known as the HIPAA Security Rule). Complying with the Security Rule Standards can reduce the likelihood of HIPAA violations and data breaches attributable to human error and bad actors.

Introduction to the HIPAA Security Rule

The HIPAA Security Rule in Part 164 Subpart C of the HIPAA Administrative Simplification Requirements consists of regulations, standards, and implementation specifications that have the objective of ensuring the confidentiality, integrity, and availability of electronic Protected Health Information (ePHI) created, collected, maintained, or transmitted by covered entities, business associates, and other organizations subject to HIPAA compliance.

All organizations subject to HIPAA must comply with the “applicable” Security Rule  regulations, standards, and implementation specifications. However, because the Security Rule is technology neutral, organizations are allowed a “flexibility of approach” with regards to what security measures are implemented. The flexibility of approach also extends to how organizations fulfil the requirements of “addressable” implementation specifications.

What is a HIPAA Security Rule Checklist?

A HIPAA Security Rule checklist is a summary of the main regulations, standards, and implementation specifications likely to be applicable to most organizations. The reason for the checklist being a summary is that, due to the different types of organizations required to comply with the Security Rule and the flexibility of approach allowed by the Security Rule, there is no one-size-fits all HIPAA Security Rule checklist that will match every organization’s requirements.

Organizations should use this HIPAA Security Rule checklist as the foundation of their own checklists – paying careful attention when developing a checklist to the General Requirement (§164.306(a)) that organizations not only have to protect against any reasonably anticipated threats to the security and integrity of ePHI, but also protect against any reasonably anticipated uses or disclosures of ePHI not permitted or required by the Privacy Rule.

Who This HIPAA Security Rule Checklist Is For

This HIPAA Security Rule checklist is for any member of the workforce with a responsibility for HIPAA compliance. This could be the HIPAA Security Officer or a member of the Compliance Team depending on the size of the organization, or – if elements of compliance are delegated to other teams – this HIPAA Security Rule Checklist could be a valuable guide for a member of an IT, HR, Legal, or Security Team.

With regards to the types of organization this HIPAA Security Rule checklist should help, it has been designed not only to be relevant to HIPAA covered entities and business associates, but also to subcontractors of business associates, vendors of personal health devices, and organizations that do not qualify as covered entities under HIPAA, but may do so under a state law – for example, the Texas Medical Records Privacy Act.

10 Important Elements of Security Rule Compliance

While it is important to review and understand every Security Rule regulation, standard, and implementation specification, there are ten important elements of Security Rule compliance that will apply to most organizations.

1.     Read the Security Standard General Rules

The Security Standard General Rules include the conditions that apply when exercising the flexibility of approach and determining when an addressable implementation specification is not reasonable or appropriate. It is important not to bypass this section because the standards and implementation specifications within it are relevant to the remainder of the checklist.

2.     Conduct a Thorough Risk Assessment

In order to ensure the confidentiality, integrity, and availability of ePHI, it is necessary to know how and where ePHI is created, collected, maintained, and transmitted. For this reason, it is important to identify any unsanctioned software and apps used by members of the workforce (“Shadow IT”) and any systems or devices they connect to.

3.     Control and Monitor All Access to ePHI

Depending on the outcome of the risk assessment, you will be in a better place to determine what access controls are required to ensure only authorized members of the workforce have access to ePHI. However, it will still be necessary to monitor access in order to identify when passwords are shared impermissibly or when login credentials are compromised.

4.     Develop Training Program and Sanctions Policy

The Security Rule requires all organizations to implement a security awareness training program for all members of the workforce regardless of their access to ePHI. Organizations are also required to develop and enforce a sanctions policy for any violation of a security policy or procedure, regardless of whether the violation results in a data breach.

5.     Implement Procedures for Reporting Security Incidents

The Security Rule requires organizations to implement policies and procedures to manage security incidents; but, in order for this standard to be effective, it is important organizations are made aware of security incidents as quickly as possible. For this reason, it is advisable to implement procedures for reporting security incidents as quickly as possible.

6.     Disaster Recovery and Emergency Mode Operation

Most healthcare providers have to implement measures for disaster recovery and emergency mode operation as a condition of participating in Medicare. However, as downstream disasters can affect healthcare providers’ operations, it is essential that all organizations develop, test, and revise disaster recovery and emergency mode operation plans.

7.     Business Associate and Subcontractor Agreements

The reason for including business associate and subcontractor agreements in this HIPAA Security Rule checklist is to remind organizations to refer to §164.504(e) of the Privacy Rule, which includes important information about conducting due diligence on business associates and subcontractors before releasing ePHI to a third party.

8.     Configure Software to Comply with the Security Rule

Most modern software solutions include the capabilities such as (for example) data integrity controls, encryption, and automatic logoff. However, the software is not always configured by default to comply with the Security Rule. The settings of all software used to create, collect, maintain, or transmit ePHI should be reviewed to ensure it is used compliantly.

9.     Address Threats to Facility, Device, and Media Security

It is a best practice to maintain an inventory of devices and media used to create, collect, maintain, and transmit ePHI; and, in addition to ensuring that the devices and media are protected from unauthorized access, the facilities in which they are located should also be protected from unauthorized access to prevent tampering and theft.

10.   Schedule a Review of the HIPAA Security Rule Checklist

The final implementation standard in the Security Rule requires organizations to maintain documentation, review it periodically, and update it as required in response to environmental or operational changes. Due to the changes expected in 2024, organizations are advised to schedule a review of the HIPAA Security Rule checklist for within twelve months.

Expected Changes to Security Rule Standards in 2024

In December 2023,  the Department of Health and Human Services published a Healthcare Sector Cybersecurity Strategy – a concept paper that proposes measures to secure the healthcare industry from cyber threats in line with President Biden’s National Cybersecurity Strategy.  One of the measures proposed in the concept paper is to update the Security Rule to include new cybersecurity requirements.

Due to the length of time it takes for proposed Rules and changes to existing Rules to evolve into Final Rules, it is unlikely the new cybersecurity requirements will take effect in 2024. However, there are several other Rule changes in the pipeline that are likely to impact Security Rule compliance in 2024. These include (but are not limited to):

• The publication of “recognized security practices” that will be considered when determining the amount of a civil monetary penalty for violating HIPAA.
• The requirement to include disclosures of ePHI for treatment, payment, and healthcare operations in an accounting of disclosures (see 42 USC §17935(c)).
• The application of HIPAA violation penalties to impermissible disclosures of Substance Use Disorder Patient Records currently protected by 42 CFR Part 2.
• A new category of “attested” uses and disclosures to prevent reproductive health care data being used or disclosed for a “non-health” purpose.

Organizations that encounter challenges in preparing for these expected changes – or that have difficulty developing a HIPAA Security Rule checklist – are advised to seek professional compliance advice.

The post HIPAA Security Rule Checklist appeared first on HIPAA Journal.

Google Workspace is HIPAA compliant for services that have “covered functionality”, provided HIPAA-covered organizations subscribe to a Workspace Plan that supports HIPAA compliance and configure the services to comply with the HIPAA Security Rule. To make Google Workspace HIPAA compliant, it is also necessary to agree to Google’s Business Associate Addendum (BAA)  to the Workspace Terms of Service Agreement.

Google Workspace – formally known as G Suite –  is a collection of productivity and communication services that can be integrated with each other to streamline workflows and enhance collaboration. It is a popular choice for organizations in the healthcare industry because most users already have experience of services such as Gmail and Drive, while most other Workspace services have familiar controls and are intuitive to use.

However, most organizations in the healthcare industry are required to comply with HIPAA – a federal law which led to the development of privacy and security standards for “Protected Health Information” (PHI). The standards govern how PHI can be used and disclosed, and what measures must be put in place to protect the confidentiality, integrity, and availability of PHI created, collected, maintained, or transmitted electronically.

In the context of the question is Google Workspace HIPAA compliant, it is important that – when PHI is created, collected, maintained, or transmitted by Workspace services – the services have controls in place to support HIPAA compliance with the security standards, the controls are configured to comply with the applicable implementation specifications, and that members of the workforce are trained on how to use the services compliantly.

Which Workspace Plan Supports Compliance?

Excluding the personal (free) and “solopreneur” editions of Workspace, there are four subscription plans for business. Although the first three plans – “Starter”, “Standard”, and “Business Plus” – include basic administrative controls, they lack important features such as shared Drives, retention Vaults, and Data Loss Prevention. If any of these plans are used, it may be necessary to integrate third party solutions to ensure HIPAA compliance.

The Enterprise Workspace Plan supports HIPAA compliance without additional integrations. The Enterprise Plan does not limit the number of users, has S/MIME email encryption, and includes enterprise endpoint management to support the compliant use of personal devices on site or in the community. The Enterprise Plan also include a unified Security Center which provides data on external file sharing, malware attacks, and other security threats.

However, although the Enterprise Workspace Plan supports compliance, it is important to be aware that not every Google service included in or connected to the Plan can be used in compliance with HIPAA. Google recommends restricting user access to core services without “covered functionality” (i.e., Google Contacts) and all non-core services not covered by the Workspace Service Agreement (i.e., Google Photos, Blogger, YouTube, etc.).

With regards to restricting user access to Google Contacts, the recommendation will affect the functionality of other HIPAA compliant Workspace services. Therefore, we suggest ignoring Google’s recommendation. Instead, administrators should implement a policy prohibiting PHI being stored in Google Contacts and monitoring compliance with the policy via the Security Center. (Note: Names and contact details are NOT PHI when maintained separately from health information – see “What is Considered PHI under HIPAA?” for a full explanation).

Which Services have Covered Functionality?

The Workspace services that can be configured to be used in compliance with HIPAA and that are covered by the Google Workspace HIPAA compliant BAA are currently:

To configure these services in compliance with HIPAA, it is advisable to follow the guidance in Google’s HIPAA Implementation Guide. The guidance will not be suitable for every covered entity and business associate because it may be necessary to (for example) integrate a third party app with a Google service. If the default guidance is not to allow access by third party apps, this element of guidance will have to be circumnavigated.

Covered entities and business associates that encounter issues with configuring covered Workspace services should be able to take advantage of Google’s customer support channels depending on the subscription (The Admin Help pages are very good for resolving technical issues). However, for HIPAA-related issues, it is probably more beneficial to seek accurate and timely advice from an external HIPAA compliance expert.

The Google Workspace HIPAA Compliant BAA

Before any Workspace service is used to create, collect, store, or transmit PHI, it is necessary to agree to Google’s Business Associate Addendum (BAA) to the Workspace Terms of Service Agreement. The Google Workspace HIPAA compliant BAA is relatively straightforward and there are no contentious clauses that may cause further issues. In most cases it is possible for Super Administrators to digitally sign the Addendum via the Admin console.

However, before digitally signing the Google Workspace HIPAA compliant BAA, it is important Super Administrators review the Terms of Service Agreement. While the entire agreement should be reviewed, Super Administrators are advised to pay careful attention to the Customer Obligations in Clause #3, which:

• Prohibit the storage and transmission of PHI without a signed BAA,
• Makes customers responsible for end user compliance with the Agreement,
• Requires customers to prevent and terminate unauthorized use of Workspace, and
• Requires customers to notify Google of any unauthorized use of, or access to, a Workspace account (including compromised passwords).

A failure to comply with the Terms of Service Agreement could result in suspension of the account and the removal of content – regardless of compliance with the Google Workspace HIPAA compliant BAA. If this happened to a Workspace account in which PHI was stored, it would not only result in an operational disruption, but also in a HIPAA violation for failing to ensure the availability of the removed PHI.

Why Provide Training on How to Use Gmail?

Google is not unique in having compliance clauses in both its Terms of Service Agreement AND in its Business Associate Agreement. Most software providers do the same. However, many workplace members will already have personal Google accounts which they use with little consideration for the privacy and security of the information they receive, store, and share. (You can check this theory by asking how many users have 2FA enabled on their personal accounts).

Using Gmail and other Workspace services in compliance with HIPAA is a lot different from using the same services for personal use. To ensure the privacy and security of PHI, workforce members should be trained on permissible disclosures, the minimum necessary standard, and verifying the identity of unknown correspondents who request PHI. It is essential they are also trained on detecting malware, phishing emails, and other threats to the security of PHI.

With regards to what has previously been discussed, it is important that members of the workforce are told not to save PHI with contact information, not to import files from non-covered services (i.e., Google Photos), and not to export files to non-covered services (i.e., Blogger). Even if these access to these services have been disabled, inventive workforce members can often find ways to circumnavigate controls to “get the job done”.

Is Google Workspace HIPAA Compliant? Conclusion

It may appear as if there are a lot of hurdles to overcome in order to make Google Workspace HIPAA compliant, but they are not insurmountable – and the benefits are more than worthwhile. Not only can covered entities and business associates in the healthcare sector share PHI compliantly to streamline workflows and enhance collaboration, but they can also better communicate with patients via a range of chat, phone, and video communication tools.

If you would like to find out more about using Google Workspace in your healthcare environment, Google offers a free 14 day trial for up to ten users. This should be long enough for Administrators to configure covered services in compliance with the Security Rule’s implementation specifications and to identify any user issues that may materialize as a result. If, during the free trial, you encounter HIPAA-related issues, you will also have time to speak with a HIPAA compliance expert before committing to a Workspace subscription.

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

Apple Pay is not HIPAA compliant – but, but due the way the payment service works, Apple Pay does not need to be HIPAA compliant before the service can be used by healthcare providers to collect payments from patients, or by health plans to collect payments from plan members. In addition, the payment service is exempted from HIPAA under §1179 of the HIPAA Act.

What is Apple Pay?

Apple Pay is a mobile payment service available on iPhones, iPads, Apple Watches, and other Mac devices that facilitates online, app, and contactless payments. The service works by allowing users to enter the details of their payment cards into an Apple Wallet app. The app then sends the user’s Apple account and device information to the card issuer and creates a unique Device Account Number for each card.

When a user wants to use Apple App to pay for goods or services, they either click on an Apple Pay button for online and in-app purchases, or run their device over a Near Field Communications (NFC) reader for in-store purchases. Apple Pay sends the payment request and the Device Account Number to the card issuer, where the payment is processed. Apple does none of the processing. It only facilitates the payment.

Because of the way the payment service works, the organization in receipt of the payment never has access to the user’s debit or credit card number – or, in the context of is Apple Pay HIPAA compliant – any information that could be used to identify the user. Even Apple does not know what a user buys, where they bought it from, or how much they paid for it. Due to this high level of privacy, any information sent through the service would not qualify as Protected Health Information  (PHI).

HIPAA Exempts Payment Services Anyway

Even without this high level of privacy, it would not be necessary to make Apple Pay HIPAA compliant and sign a Business Associate Agreement with Apple as §1179 of the HIPAA Act exempts “entities engaged in authorizing, processing, clearing, settling, billing, transferring, reconciling, or collecting payments for a financial institution. The exemption was confirmed by HHS’ Office for Civil Rights in the preamble to the HIPAA Final Omnibus Rule in 2013.

However, this exemption only applies to the payment facilitation element of Apple Pay. If a covered entity or business associate uses Apple Pay for B2B transactions, there is no exemption for PHI stored in an Apple Wallet app to support transactions or reconcile payments. As Apple will not sign a Business Associate Agreement for the Apple Wallet app, it is a violation of HIPAA to store any individually identifying health information in the Apple Wallet app.

It may also be important for covered entities and business associates to identify – and conduct risk assessments on – any third party integration with Apple Pay. If Apple Pay is used (for example) to reconcile payments, the reconciliation software must be HIPAA compliant and Business Associate Agreements must be entered into with the software vendors. Members of the workforce may also need security awareness training on using Apple Pay in compliance with HIPAA.

Is Apple Pay HIPAA Compliant? Conclusion

For the reasons discussed above, Apple Pay does not have to be HIPAA compliant in order for covered entities and business associates to use the service to collect payments from patients and plan members. When used for B2B transactions, covered entities and business associates may have to implement Apple Pay HIPAA compliant integrations and conduct risk assessments if the integrations will create, collect, maintain, or transmit PHI. Covered entities and business associates with questions relating to is Apple Pay HIPAA compliant should seek professional compliance advice.

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

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.