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.

A HIPAA compliant home office is a working environment set up to support HIPAA compliance when a covered entity, business associate, or a member of either’s workforce works from home. Because of the different functions that can be performed from – and services that can be provided by – a home office, the requirements for HIPAA compliance can vary considerably.

What is a Home Office in Healthcare?

Although a home office is most often considered to be a remote working environment “in a location other than an employer’s central workplace”, a home office in healthcare could be the main working environment for a solo healthcare practitioner, a part-time employee of a covered entity, or a home business that provides medical transcription services as a business associate.

Regardless of whether a home office is a remote or a main working environment, is used full-time or part-time, or by an individual or a team, a home office has to be set up to comply with HIPAA whenever the function being performed in – or service being provide by – a home office involves the creation, receipt, maintenance, or transmission of Protected Health Information (PHI).

What Might a Home Office be Used For?

Working from home has become increasingly viable for a range of professions, including many in healthcare. A home office in healthcare can be used to perform many different functions for patients or to provide a range of services to covered entities and business associates. Examples of how a home office might be use for a healthcare function or service include:

• Telemedicine Provider
• Medical Transcriptionist
• Medical Coder/Biller
• Healthcare IT Specialist
• Behavioral Health Professional
• Epidemiologist
• Health Coach
• Patient Navigator
• Biostatistician
• Clinical Research Coordinator
• Medical Educator or E-Learning Specialist
• Medical Customer Service Representative

Some of these home-based functions and services can be subject to state or local employment regulations, while others may require an employee to work from home some of the time and the employer’s central workplace at other times. Nonetheless, whatever the working arrangement, whenever a home office is used to create, receive, maintain, or transmit PHI – in any media or format – it is necessary the home office is a HIPAA compliant home office.

The Requirements for a HIPAA Compliant Home Office

The requirements for a HIPAA compliant home office consist of much more than some people think. This is because the aim of the Administrative Simplification Regulations is to protect the privacy of individually identifiable health information and ensure the confidentiality, integrity, and availability of electronic PHI regardless of where the information is created, received, stored, or transmitted.

Therefore, it does not matter whether the functions being performed and the services being provided take place in a home office, a healthcare facility, or a secure data center. The requirements for HIPAA compliance are the same. This means the same policies, procedures, and safeguards have to be implemented, and the same penalties can be applied for violations of HIPAA.

The requirements for a HIPAA compliant home office will mean different things to different types of home workers. For example:

• A solo healthcare practitioner will have to comply with all applicable provisions, standards, and implementation specifications of the Administrative Simplification Regulations
• A home business operating as a business associate may only have to comply with the applicable standards of the Privacy Rule and the Security and Breach Notification Rules.
• An employee of a covered entity or business associate will have to comply with their employer’s policies and procedures – which may be different from in the central workplace because of the unique threats of home working.

Consequently, for some home workers, the requirements for a HIPAA compliant home office may include conducting an audit to determine where and how PHI is created, received, stored, or transmitted, conducting a risk assessment to identify potential impermissible uses and disclosures of PHI and security vulnerabilities, and developing procedures for notifying individuals and HHS’ Office for Civil Rights in the event of a data breach.

For homeworkers that maintain PHI in the home office – in any media or format – the requirements for a HIPAA compliant home office may include installing a safe or lockable file cabinet to keep paper records and data backups, developing a continuity of operations plan, and ensuring all devices used to store electronic PHI – including mobile devices – are PIN-locked and have automatic logoff activated to prevent unauthorized access to PHI.

What are the Unique Threats of Home Working?

Home working expands the cyberattack surface, and while cyberattacks are not unique to home working, home offices can be more vulnerable to an attack due to a lack of advanced security defenses and – when a home office is a remote office – less oversight by corporate security teams. In addition to the increased level of vulnerability, there will likely be less support to help home workers respond to and recover from a successful attack.

Other than the cybersecurity threats, home workers may be subject to distractions (children, pets, visitors, etc.) which can result in paper records or electronic devices being left unattended. There may also be times when they forget to lock away paper records and data backups, forget to keep device screens directed away from people who might see what is on them, or carelessly make a comment that constitutes an impermissible disclosure of PHI.

In many cases, one of the most important unique threats of home working is the ease with which it is possible to develop non-compliant practices “to get the job done”. The non-compliant practices can range from failing to provide a patient with a Notice of Privacy Practices, to installing software without the capabilities to support HIPAA compliance, to failing to enter into a Business Associate Agreement before storing PHI in a cloud storage service.

Conclusion: Ensure Your Home Office is HIPAA Compliant

No matter how you use your home office, if the function you perform or the service you provide involves the creation, receipt, storage, or transmission of PHI, you have to have a HIPAA compliant home office. If you fail to ensure your home office is HIPAA compliant, it is more likely you will be the victim of a cyberattack or other HIPAA violation for which the financial penalties can be substantial.

If you are unsure of the home office compliance requirements – either as an individual or an employer with a remote working team – it is recommended you review our HIPAA compliance checklist to better understand which provisions of HIPAA may be applicable. Alternatively, it is advisable to seek professional compliance advice about which standards of HIPAA you are required to comply with and how best to comply with them.

The post What is a HIPAA Compliant Home Office? appeared first on HIPAA Journal.

HIPAA-regulated entities must ensure that protected health information (PHI) is safeguarded against unauthorized access, but many covered entities and business associates do not know how to secure healthcare data properly and leave sensitive information exposed.

The HIPAA Security Rule

The HIPAA Security Rule established national standards to protect individuals’ electronic personal health information (ePHI) that is created, received, used, or maintained by HIPAA-covered entities and their business associates. The Security Rule requires appropriate administrative, physical, and technical safeguards to be implemented to ensure the confidentiality, integrity, and availability of ePHI. All regulated entities must assess security risks throughout their organziation and implement a range of different safeguards to protect against unauthorized ePHI access, and ensure all risks are reduced to a low and acceptable level.

How to Protect Healthcare Data and Comply with HIPAA

The HIPAA Security Rule was developed to be flexible to ensure that it applies to covered entities of all types and sizes and includes required implementation specifications that must be implemented by all regulated entities, and addressable implementation specifications, which require an assessment to determine if the specification is reasonable and appropriate. If not, the Security Rule permits an alternative mechanism to be implemented to meet the standard addressed by that specification.

Administrative Safeguards

Administrative safeguards under HIPAA are defined as “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s or business associate’s workforce in relation to the protection of that information.”

Administrative safeguards include security management processes to prevent, detect, contain, and correct security violations. These include a comprehensive, organization-wide risk analysis to identify all risks and vulnerabilities to ePHI, risk management processes to reduce risks and vulnerabilities to a low and acceptable level, a sanctions policy, and information system activity reviews.

Staff members must be assigned responsibility for security, policies and procedures must be implemented to ensure workforce security, and a security awareness and training program is required for all members of the workforce. Administrative safeguards also include authorization, supervision, information access management, and contingency planning.

Physical Safeguards

HIPAA defines physical safeguards as “physical measures, policies, and procedures to protect a covered entity’s or business associate’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.”

Physical safeguards include facility access controls to restrict access to physical PHI and electronic systems where ePHI is stored, contingency operations, facility security plans, access controls and validation procedures, and maintenance records.

Physical safeguards are required for workstation use and workstation security, with policies and procedures implemented to ensure that job functions can be performed in a secure way, prevent inappropriate use of computers, and restrict access to authorized users. Device and media controls should be implemented that govern the receipt and removal of hardware and electronic media that contain ePHI into and out of a facility, and the movement of the devices within the facility.

Technical Safeguards

HIPAA defines technical safeguards “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.” Technical safeguards include hardware, software, and other technology that protects and limits access to ePHI through access controls, audit controls, integrity controls, authentication, and transmission security.

Access controls are required to restrict access to ePHI to authorized individuals only, audit controls are necessary for monitoring activity on systems containing ePHI, integrity controls prevent the improper alteration or destruction of ePHI, and transmission security ensures that ePHI is protected when it is transmitted over an electronic network.

The HIPAA Security Rule does not specify the specific technologies that should be used to secure healthcare data and restrict access. HIPAA-regulated entities have the flexibility to implement security measures to comply with each standard and achieve its objectives. The HHS Security Series provides guidance on the administrative safeguards, physical safeguards, and the technical safeguards of the HIPAA Security Rule.

The Insider Threat Problem in Healthcare

Security Rule compliance requires ePHI to be safeguarded to ensure the confidentiality, integrity, and availability of ePHI and many of the implementation specifications are concerned with preventing access to ePHI by unauthorized third parties; however, threats can originate from within an organziation. Employees, contractors, interns, and other staff members can be just as dangerous as outside actors, in fact some of the most damaging incidents have been caused by insiders.

According to Verizon’s Data Breach Investigations Report (DBIR), insider incidents are on the rise. For several years, healthcare was the only industry where insiders caused more breaches than external actors. While the situation is improving, the 2023 DBIR indicates 35% of healthcare data breaches were caused by insiders.

Insider threats take many forms and include careless and negligent workers, where there is no conscious decision to act inappropriately. Disgruntled employees pose a significant threat and perform deliberate actions to cause harm to their organziation. Malicious insiders abuse their privileges for personal or financial gain, and threat actors often recruit or coerce individuals into stealing data or performing other actions such as installing malware. Insider threats are one of the biggest security challenges to address in healthcare. Insiders usually have legitimate access to ePHI and knowledge of internal systems and data locations, and their actions can be difficult to identify as cybersecurity solutions such as intrusion detection systems are primarily focused on detecting and blocking external threats.

Securing healthcare data against insider threats and detecting insider threats promptly requires a combination of measures including security policies, screening of new hires, user activity monitoring, logging, auditing, incident detection and response, user and entity behavior analytics, and employee education. Malicious insider threats are far less common than negligent and careless employees, which often cause the most harm. Accidental data leaks and employee errors are by far the largest risk and cause the most data breaches. Oftentimes, these incidents are the result of unclear security policies, employees’ lack of awareness of policies, and a failure to provide security awareness training. Improving education is vital in combatting these incidents. Security policies should be easy to understand, security awareness training should be provided regularly, employees must be made aware of the HIPAA Rules and the sanctions policy for violations.

Risk can be reduced through administrative safeguards, such as ensuring employees have appropriate access rights to ePHI and systems containing ePHI. Audits should be performed of access rights to check who has access to data and systems, and to ensure that the rights are appropriate. Detecting incident incidents quickly is vital. One of the reasons why insider breaches are so harmful is they often go undetected for long periods. Having the right software in place is critical in this regard. For instance, Safetica offers a software solution for healthcare organizations that can help with the discovery of ePHI, restrict whether data can be shared with third parties, control and monitor employee access to ePHI, and rapidly detect unauthorized access and employee errors that may expose ePHI, providing insider threat and data leak protection.  Safetica can limit file operations with personal information and ePHI, such as uploading, copying, printing, and even taking screenshots, all of which feature in the list of common HIPAA violations. Without systems in place to manage ePHI, unauthorised access to medical records can persist for years without detection. According to Safetica CTO Zbyněk Sopuch, “One of the key use cases of utilising data loss prevention tools like Safetica in healthcare settings is to ensure that access to sensitive ePHI is given only to the right personnel by monitoring and controlling the flow of data, preventing unauthorised access while safeguarding sensitive information and staying in compliance with HIPAA regulations.” Systems like Safetica provide immediate alerts for data security incidents. It has been found that real time alerts, which has been  proven to reduce repeat offences by staff by 95%. 

Securing healthcare data is complex and involves implementing robust encryption protocols, strict access controls, regular security audits, up-to-date software patching, comprehensive staff training in data handling and privacy regulations, utilizing strong authentication methods, employing intrusion detection systems, and maintaining physical security measures to prevent unauthorized access or breaches and ensure the confidentiality, integrity, and availability of sensitive patient information.

The post How to Secure Healthcare Data appeared first on HIPAA Journal.

What information hospitals can give over the phone depends on the purpose of the phone call, the recipient of the information, and any restrictions or authorizations in force at the time. The phone system being used can also impact what information hospitals can give over the phone.

The most common reasons for asking the question what information can hospitals give over the phone are:

• Healthcare providers want to make sure they comply with HIPAA,
• Patients want to know if their privacy rights have been violated, or
• Families want the maximum information possible about a loved one.

Unfortunately, there is no A, B, and C answer to the question what information can hospitals give over the phone because patients have the right to restrict some or all disclosures and restrict who information is shared with. Additionally, patients have the right to authorize disclosures beyond those permitted by the Privacy Rule to individuals who enquire about the patient’s health.

Therefore, although §164.510 of the Privacy Rule permits hospitals to disclose directory information to individuals who enquire about a patient by name, there are many scenarios in which a request for information could be denied (including because a healthcare provider believes the disclosure is not in the patient’s best interest) or in which it is possible to disclose more than directory information.

What is Directory Information?

Directory information – in the context of what information can hospitals give over the phone – consists of the name of the patient, the location of the patient in the healthcare facility, the patient’s religious affiliation, and the patient’s condition described in general terms that does not communicate specific medical information about the individual.

Hospitals cannot provide any information over the phone about a patient’s past medical history if it is unrelated to the current medical condition, but can discuss treatment plans, drugs, and therapies with a caregiver over the phone provided the identity of the caregiver is verified. Note: some hospitals may require identity verification for any individual enquiring about a patient’s condition even though this is not required by HIPAA.

The Right to Restrict or Authorize Information

The right to restrict what information hospitals can give over the phone not only appears in §164.510 of the Privacy Rule. §164.522 gives patients the right to request privacy protections for PHI; and, although hospitals do not have to agree to most requests, the failure to agree to justifiable requests for privacy protections could result in a complaint to HHS’ Office for Civil Rights.

With regards to patient authorizations, in most cases authorizations are initiated by a covered entity to facilitate a use or disclosure of PHI not permitted by the Privacy Rule. However, there is nothing in the Privacy Rule that prevents a patient authorizing the disclosure of PHI to friends or family members over the phone – although hospitals need to be conscious of the fact that a patient also has the right to revoke an authorization at any time.

What Information Can Hospitals Give Over the Phone for TPO Purposes?

Hospitals can make disclosures of PHI over the phone for treatment, payment, and healthcare operations (TPO). However, how much PHI can be disclosed in a phone call depends on the purpose of the phone call. For example, there are no limitations on what information can be provided to a healthcare provider for the treatment of a patient; but, if the phone call is to a health plan to request authorization for the treatment, the minimum necessary standard applies.

It is also the case that restrictions and authorizations can apply to what information hospitals can give over the phone for TPO purposes. For example, a healthcare provider cannot refuse a request from a patient to restrict PHI disclosures to a health plan if the disclosures relate to a healthcare service the patient (or somebody on behalf of the patient) has paid for privately.

Why the Phone System being Used Might also Matter

Phone calls made by hospitals are either made over a Public Switched Telephone Network (PSTN) or over a Voice over Internet Protocol (VoIP) system. If using a VoIP system, it is necessary for a Business Associate Agreement to be in place with the software vendor before PHI is disclosed in a phone call. The same requirement does not apply to PSTN phone services.

If a hospital has deployed a VoIP system, and a Business Associate Agreement is not in place with the vendor of a VoIP system, the hospital is not allowed to disclose PHI over the phone. Note: some healthcare telephone communications are possible with patients under the FCC’s TCPA Omnibus Declaratory Ruling and Order unless a patient has rescinded their consent to be contacted by phone.

Conclusion: Why it is Important to Know What Information Hospitals Can Give over the Phone

The reasons it is important to know what information hospital can give over the phone are the same as the reasons for asking the question what information can hospitals give over the phone:

• Healthcare providers want to make sure they comply with HIPAA,
• Patients want to know if their privacy rights have been violated, and
• Families want the maximum information possible about a loved one.

The failure to comply with HIPAA, a violation of a patient’s privacy rights, or refusing to give families information that a patient has authorized can result in complaints to HHS’ Office for Civil Rights and a potential compliance investigation. To mitigate the risk of an investigation and the disruption this will cause, hospitals should develop policies and procedures for giving information over the phone.

The post What Information Can Hospitals Give Over the Phone? appeared first on HIPAA Journal.