HIPAA Compliance
HIPAA

Strong BAAs Build a Chain of Trust

Business Associate Agreements & Covered Entity Compliance 

Written by Joanne Byron, LPN, BS, CCA, CIFHA, CHA, COCAS, CORCM, CHCO, HPOC, OHCC, CMDP, ICDCT-CM/PCS 

Building a chain of trust between healthcare providers (Covered Entities) and Business Associates (BAs) is a regulatory requirement under HIPAA designed to ensure that Protected Health Information (PHI) remains secure throughout its entire lifecycle, even when handled by third parties.

This chain of trust ensures that privacy and security obligations flow down to every subcontractor that creates, receives, maintains, or transmits PHI. This can produce increased confidence with your organization’s ability to earn and maintain patient trust.


Is Your Organization a Covered Entity, Business Associate or Both?

According to the Office of Civil Rights (OCR), the HIPAA enforcement agency, a Covered Entity (CE) is one of the following:

A Health Care Provider

A Health Plan

A Health care Clearinghouse

This includes providers such as:

  • Doctors
  • Clinics
  • Psychologists
  • Dentists
  • Chiropractors
  • Nursing Homes
  • Pharmacies

...but only if they transmit any information in an electronic form in connection with a transaction for which HHS has adopted a standard.

This includes:

  • Health insurance companies
  • HMOs
  • Company health plans
  • Government programs that pay for health care, such as Medicare, Medicaid, and the military and veterans health care programs.

This includes entities that process nonstandard health information they receive from another entity into a standard (i.e., standard electronic format or data content), or vice versa.

It may not always be straightforward. If you are not sure if your organization is a covered entity – the Centers for Medicare & Medicaid Services (CMS) provides a an educational website and also a Covered Entity Decision Tool (58-pagePDF).

A HIPAA covered entity (CE) acts as a business associate (BA) when it performs functions or services involving protected health information (PHI) on behalf of another covered entity. This activity-specific role requires a Business Associate Agreement (BAA) for that specific work, even while the organization acts as a CE for its own operations.

The key distinction is that the "business associate" status applies to the service being performed (e.g., providing administrative services) rather than the entity's status as a healthcare provider or payer.

Key Scenarios and Requirements:

  • Services for Another CE: If a hospital (CE) handles billing or provides administrative services involving PHI for an unaffiliated clinic (another CE), the hospital acts as a BA.
  • Subcontractor Relationships: If a BA hires a covered entity to perform work involving PHI, that hired CE is acting as a BA to that BA.
  • Data Sharing: While sharing for "treatment" between CEs doesn't need a BAA, sharing for services to one another (e.g., managing a personal health record or PHR) does. Common examples include patient portals, health apps, and online trackers, which can contain medical history, diagnoses, and medication logs. According to OCR, it is an electronic application used by individuals to maintain and manage their own health information, rather than records solely controlled by a doctor or insurer (EHR).

          PHRs are often, but not always, covered by HIPAA regulations. Key details include:

  • Control: Unlike Electronic Health Records (EHRs) managed by providers, PHRs are managed by the individual or their caregiver.
  • Types: They can be tethered (linked to a provider) or standalone (independent).
  • HIPAA Coverage: If a PHR is provided by a HIPAA-covered entity (like a health plan or doctor), it is covered under the HIPAA Privacy Rule.
  • Alternative Protection: If a PHR is offered by a company not covered by HIPAA, it is governed by the FTC’s Health Breach Notification Rule.
  • Compliance: When acting as a BA, the entity must adhere to HIPAA Security Rule and Privacy Rule requirements for the PHI it handles for that specific relationship.

A covered entity functions as a business associate in the following type of situations:

  • Centralized Administrative Services: A hospital (CE) provides billing, claims processing, or data analytics services for an independent physician group or affiliated clinic.
    • A hospital acting as a central billing clearinghouse for independent physician groups.
  • Specialized Clinical Services: An independent laboratory (CE) that typically treats patients directly acts as a BA if it analyzes data for a health plan's quality improvement program.
    • A large health system providing laboratory services.
  • Data Processing Support: A health insurance company (CE) assists another health plan with data processing or administrative tasks.
    • Managed Service Providers or IT support that requires access to another entity’s patient records.
  • Patient Safety Organizations (PSOs): PSOs are specifically treated as business associates when they receive and analyze patient safety event reports from other providers. Key Covered Entity Requirements regarding use of PSOs:
    • Risk Analysis & Mitigation: CEs must perform risk assessments to identify threats to ePHI, including data shared with PSOs, and implement appropriate security measures.
    • Staff Training & Governance: Implement comprehensive training on identifying PSWP and handling it according to both HIPAA and safety rules.
    • Breach Reporting: Any unauthorized disclosure of PSWP is treated as a breach, requiring prompt response and reporting to the Office for Civil Rights (OCR)

Compliance Obligations for the Dual Role

When acting as a business associate, the covered entity is required to:

  • Sign a BAA: It must execute a formal agreement with the other covered entity before PHI is shared.
  • Adhere to BA Duties: It must follow the specific privacy and security requirements outlined for business associates, including reporting breaches and following "minimum necessary" standards.
  • Segregate Data: Large organizations often use internal "self-BAAs" or separate departments to ensure PHI from their BA activities is not improperly mingled with their own patient data.

For more detailed regulatory definitions, you can refer to the HHS Summary of the HIPAA Privacy Rule.

When a BAA is NOT Required Between Covered Entities

Not all exchanges of PHI between covered entities trigger a business associate relationship. A Business Associate Agreement (BAA) is generally not required for:

  • Treatment Purposes: When two independent providers disclose or exchange PHI for treatment purposes, such as a doctor referring a patient to a specialist or treating a shared patient.
  • Standard Payment Activities: When a provider submits a claim to a health plan and the plan pays it; both are acting on their own behalf as covered entities.
  • Organized Health Care Arrangements (OHCA): When entities participate in a joint arrangement, such as a group health plan and its insurer, to perform joint health care activities.
  • Conduit Exception: Organizations that only transport PHI and do not access or store it, such as the U.S. Postal Service, internet service providers (ISPs), or private couriers.
  • Incidental Access: Personnel who might see or hear PHI by chance while providing services, such as janitors, maintenance workers, or electricians, where the access is not the purpose of the work.
  • De-identified Data: Sharing data that does not contain identifiers, as long as it cannot be re-identified.

Not sure if a BAA is required?

Do you need help determining if a specific service your organization provides requires a Business Associate Agreement? Consult with a HIPAA-experienced attorney or consultant instead of “guessing” or consulting with an unqualified professional.

Act Now to be HIPAA Compliant

The HIPAA Final Rule is expected to be published in May 2026, with a 60-day effective date followed by a 180-day grace period for compliance. Covered entities should begin updating their policies now to meet these more stringent requirements.

Establishing a strong chain of trust under HIPAA requires vendor contracts to be updated, compliant and translate legal requirements into operational controls. A robust BAA ensures that all parties involved in creating, storing, and transmitting ePHI (overed entities, business associates, and subcontractors), are bound by the same rigorous privacy and security standards, mitigating risk in an era where nearly half of all HIPAA breaches involve third-party vendors.

A legally binding Business Associate Agreement (BAA) is the foundational document of the chain of trust.

A robust BAA ensures that all parties—covered entities, business associates, and subcontractors—are bound by the same rigorous privacy and security standards, mitigating risk in an era where nearly half of all HIPAA breaches involve third-party vendors.

  • Mandatory Clauses: The BAA must explicitly outline permitted uses/disclosures, require the implementation of safeguards (administrative, physical, and technical), and mandate prompt breach reporting.
  • Defined Scope and Data Flows: Explicitly mapping where Protected Health Information (PHI) is created, stored, or transmitted to ensure the "minimum necessary" standard is applied.
  • Subcontractor Flow-Down Obligations: A crucial component requiring the business associate to bind any subcontractors to the same level of security and privacy protections.
  • Stringent Breach Notification Procedures: Defining clear timelines (e.g., within 60 days, or faster, such as 24-hour notice for emergency plans) for reporting incidents to the covered entity.
  • Security Safeguards Requirement: Mandating administrative, physical, and technical safeguards, including encryption in transit/at rest, multi-factor authentication (MFA), and regular risk assessments.
  • Termination and Destruction Protocol: Ensuring that upon contract termination, PHI is either returned or securely destroyed, with no further retention.
  • Audit and Compliance Rights: Granting the covered entity the right to audit the vendor's security controls and requiring access to records for HHS investigations
  • Pre-engagement Requirement: The BAA must be signed before any PHI is shared.

Do Your Due Diligence - Trust is built on verification, not just contracts. Conduct comprehensive risk assessments to evaluate a vendor's security posture, policies, and procedures before partnering.

  • Verify the vendor’s compliance.
  • Review the vendor's documented risk analyses, audit trails, and, if applicable, third-party certifications.

Best Practices for Maintaining the Chain of Trust –

  • Regular Updates: Reviewing and updating BAAs whenever services, technologies (e.g., cloud, AI), or regulations change, such as preparing for upcoming 2025 HIPAA revisions.
  • Vendor Due Diligence: Assessing a business associate's security posture before signing a BAA, rather than relying solely on the contract for security.
  • Employee Training: Ensuring the business associate trains its staff on the specific requirements of the BAA.
  • Assigning Liability: Clearly defining which party covers financial penalties, legal fees, or remediation costs in the event of a breach.

Consult with a HIPAA legal expert to assist your organization as you update your BAAs to be compliant to the New Final Rule. By tightening your BAAs and relationships with vendors, you will move from a compliance posture to an active, operationalized partnership that protects patient data, reputation and builds patient trust.

About the Author

Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, COCAS, CORCM, OHCC, ICDCT-CM/PCS is an educator with  Officer of the American Institute of Healthcare Compliance, a Licensing/Certification non-profit partner with CMS. She shares her experience of over 40 years as a nurse, consultant, auditor, and investigator in the healthcare field.

References

Copyright © 2026 American Institute of Healthcare Compliance All Rights Reserved

Share 0
Post 0
Share 0
Read More
HIPAA Compliance
HIPAA

42 CFR Part 2 HIPAA Alignment Update

This article is written by the American Institute of Healthcare Compliance Audit Education Department 

By February 16, 2026, all HIPAA-covered entities—including healthcare providers, health plans, and healthcare clearinghouses—that create, receive, or maintain Substance Use Disorder (SUD) records subject to 42 CFR Part 2 must update their Notice of Privacy Practices (NPP). The update requires clearly detailing enhanced protections for SUD records. The information in this AIHC update is not legal or consulting advice, but for educational purposes to prompt compliance.

Does this new rule apply to my organization?

Yes, it can, but this requirement is specifically targeted at those handling Part 2 records. Entities must ensure their websites and privacy policies reflect these changes by February 16, 2026. Covered entities, including health plan sponsors and providers, must align their notices with the new, stricter privacy rules for sensitive SUD information by this date.

Tips to Update Your NPP

The NPP must contain the elements, information and statements specified in 45 CFR 164.520 and must include a specific header, a description of permitted uses/disclosures (treatment, payment, operations), individual rights, covered entity duties, and contact information for complaints.

It must be provided by the first service date and, as of February 16, 2026, align with updated substance use records regulations.

Key elements mandated by 45 CFR 164.520 include: 

  • Required Header: A specific statement regarding how medical information is used and the patient's rights.
    • i.e., “THIS NOTICE DESCRIBES HOW MEDICAL INFORMATION ABOUT YOU MAY BE USED AND DISCLOSED AND HOW YOU CAN GET ACCESS TO THIS INFORMATION. PLEASE REVIEW IT CAREFULLY.”1
  • Permitted Uses and Disclosures: A detailed description of how the covered entity may use or disclose Protected Health Information (PHI) without the patient’s written authorization,2 including for treatment, payment, and healthcare operations.
  • Individual Rights: Information on the right to access, amend, request restrictions, receive confidential communications, and receive an accounting of disclosures.
    • A statement that other uses or disclosures will only be made with the individual’s authorization, and that the individual has the right to revoke her/his authorization subject to certain limitations.3
    • A summary of certain specified rights the individual has concerning his/her information.4
  • Covered Entity Duties: Statements confirming the entity's responsibility to protect privacy, provide notice of privacy practices, and abide by the terms of the notice.
  • Complaints Procedure: Instructions on how individuals can file complaints with the covered entity or the Secretary of Health and Human Services (HHS).
  • Contact Information: A designated person or office to contact for further information.
  • Effective Date: The NPP’s effective date.5
  • Special Considerations: Specific language regarding the restriction of uses/disclosures for underwriting purposes, the sale of PHI, and marketing, as well as updated, clearer descriptions regarding substance use disorder records.
  • Posting the Notice: The NPP must be prominently posted on the entity's website and physically at the service location by February 16, 2026 and, for plans without a website, distributed to participants by April 17, 2026 (within 60 days of the change).

Key Considerations:

Update Policies & Retrain Workforce - Organizations should act promptly to review their existing notices and implement the required changes before the deadline. Review and update internal privacy policies, procedures, and training materials to comply with the final rule.

Review your BAAs - Business Associate Agreements should be reviewed to ensure they account for the enhanced protections of SUD information.

For more information, check the updated Fact Sheet 42 CFR Part 2 Final Rule:

https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/fact-sheet-42-cfr-part-2-final-rule/index.html.

References:

https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.520

1 45 CFR 164.520(b)(1)(i)

2 45 CFR 164.520(b)(1)(ii)

3 45 CFR 164.520(b)(1)(ii)

4 45 CFR 164.520(b)(1)(iv)-(vii)

5 45 CFR 164.520(b)(1)(viii)

Copyright © 2026 American Institute of Healthcare Compliance All Rights Reserved

Share 0
Post 0
Share 0
Read More
Artificial Intelligence in Healthcare
Artificial Intelligence

Part 2: Who Regulates Healthcare AI?

Artificial Intelligence & Regulatory Compliance


Written by Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, COCAS, CORCM, OHCC, ICDCT-CM/PCS




This article follows Part 1 - Basics of Artificial Intelligence (AI) and Healthcare Compliance published by AIHC on June 6, 2023.  AI is advancing rapidly, so we encourage you to reference the new Artificial Intelligence article category for the latest articles.  As stated in Part 1, the Office of the National Coordinator for Health Information Technology (ONC) and the Agency for Healthcare Research and Quality (AHRQ), with support from the Robert Wood Johnson Foundation, turned to an independent group of scientists and academics to consider how AI might shape the future of public health, community health, and healthcare delivery.  The question remains, how will the use of AI be regulated for health care use?


Artificial Intelligence/Machine Learning has gained heightened attention globally.  Augmented Intelligence has been embraced as a concept by physician organizations to underscore that emerging AI systems are designed to aid humans in clinical decision-making, implementation and administration to scale healthcare, according to Act Online Key Terminology for AI in Health.


Although the United States is making progress in developing domestic AI regulation, including with the National Institute of Standards and Technology (NIST) AI Risk Management Framework, the existing laws and regulations that apply to AI systems is still a work-in-progress.  The goals are to protect people from unsafe or ineffective systems. 


So, Who Regulates Healthcare AI?


What seems like a simple question is really a complex situation.  This article only scratches the surface of various regulatory agencies involved in the regulation of AI.  The Health & Human Services (HHS) response to OMB Memorandum 21-06 “Guidance for Regulation of Artificial Intelligence Applications” was drafted in November 2020 and is directed to the heads of all Executive Branch departments and agencies, including independent regulatory agencies.  Much has happened since then.


On April 25, 2023, the Federal Trade Commission (FTC), the Civil Rights Division of the U.S. Department of Justice (DOJ), the Consumer Financial Protection Bureau (CFPB), and the U.S. Equal Employment Opportunity Commission (EEOC) released a joint statement highlighting their commitment to "vigorously use [their] collective authorities to protect individuals" with respect to artificial intelligence and automated systems (AI), which have the potential to negatively impact civil rights, fair competition, consumer protection, and equal opportunity.


The joint statement from the DOJ, FTC, CFPB, and EEOC signifies a growing awareness and concern among federal agencies about the potential risks and challenges posed by AI and automated systems. As AI continues to become more integrated into all aspects of daily life, the importance of addressing potential biases, transparency issues, and flawed design becomes increasingly critical.


Federal Trade Commission (FTC) Raises Concerns


The FTC’s mission is to protect consumers and competition through preventing anticompetitive, deceptive and unfair business practices.  This is achieved through law enforcement, advocacy, and education without unduly burdening legitimate business activity.  The FTC Act’s prohibition on deceptive or unfair conduct can apply if you make, sell, or use a tool that is effectively designed to deceive – even if that’s not its intended or sole purpose. The FTC’s action should help protect healthcare organizations by limiting deceptive or exaggerated promises of what a medical device or AI software can actually do.  It’s not uncommon for advertisers to say that some new-fangled technology makes their product better – perhaps to justify a higher price or influence labor decisions.


On May 18, 2023, the FTC issued a warning that the increasing use of consumers’ biometric information and related technologies, including those powered by machine learning, raises significant consumer privacy and data security concerns and the potential for bias and discrimination. Biometric information refers to data that depict or describe physical, biological, or behavioral traits, characteristics, or measurements of or relating to an identified or identifiable person’s body.


The Federal Drug Administration & AI


The Food & Drug Administration (FDA) released a discussion paper in 2019 and then an action plan on January 21, 2021 regarding Artificial Intelligence and Machine Learning, or AI/ML.  This action plan describes a multi-pronged approach to advance the Agency’s oversight of AI/ML-based medical software.  Then, in April 2023, the FDA is publishing a draft guidance, "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions."

  • This draft guidance proposes a science-based approach to ensuring that AI/ML-enabled devices can be safely, effectively, and rapidly modified, updated, and improved in response to new data.

The approach the FDA is proposing in this draft guidance would put safe and effective advancements in the hands of health care providers and users faster, increasing the pace of medical device innovation in the United States and enabling more personalized medicine.

  • This means, for example, that diagnostic devices could be built to adapt to the data and needs of individual health care facilities and that therapeutic devices could be built to learn and adapt to deliver treatments according to individual users' particular characteristics and needs.

National Institute of Standards and Technology (NIST) AI Risk Management Framework


Released on January 26, 2023, NIST’s AI Risk Management Framework or “AI RMF” which is intended to be used voluntarily to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems.  The Framework was developed through a consensus-driven, open, transparent, and collaborative process with the intention to build on, align with, and support AI risk management efforts by others.


Recently NIST launched the Trustworthy and Responsible AI Resource Center (AIRC), which will facilitate implementation of, and international alignment with, the AI RMF.  We recommend watching the introduction video:  https://www.nist.gov/video/introduction-nist-ai-risk-management-framework-ai-rmf-10-explainer-video


For healthcare HIPAA covered entities, NIST is likely a familiar organization to you.  NIST published prior documents related to AI.  The initial draft of the AI RMF was published March 17, 2022 and a second draft on August 18, 2022.


The Health Insurance Portability and Accountability Act (HIPAA)

Public Law 104-191


The Office for Civil Rights (OCR) is responsible for enforcing the HIPAA Privacy and Security Rules (45 C.F.R. Parts 160 and 164, Subparts A, C, and E). One of the ways that OCR carries out this responsibility is to investigate complaints.  As health care organizations evolve with the use of AI, there is increased potential for cyber criminals to exploit vulnerabilities.


At the present, there are two exclusions existing in the HIPAA Privacy Rule that allow Covered Entities to share Protected Health Information (PHI) with device vendors and other organizations without the authorization of the individual(s) to whom the PHI relates. The two exclusions can be found in 45 CFR §164.512(b)(1) and 45 CFR §164.512(i)(1). Respectively, they relate to:

  • Disclosures to vendors regulated by the Federal Drug Administration are permitted by the Privacy Rule for the “purpose of activities related to the quality, safety or effectiveness of such FDA-regulated product or activity”.   The FDA regulates the sale of all medical device products, including personal health devices that transmit data to AI-driven healthcare solutions as described above.
  • PHI can also be disclosed without authorization for research purposes without being de-identified if the disclosure is approved by an Institutional Review Board or Privacy Board. In such circumstances, the disclosed PHI must remain in the possession of the Covered Entity and the disclosure(s) can only be for the purpose of preparatory research (i.e., programming a “Supervised Learning Algorithm”).


Conclusion


Simply stated, a shift to AI calls for new skills.  It warrants increased knowledge of HIPAA privacy, security and anticipating other legal issues surrounding it’s use in healthcare.


Needless to say, it is important to maintain a robust HIPAA program and utilize information from the National Institute of Standards and Technology (NIST) AI Risk Management Framework as mentioned above.


In the context of HIPAA, healthcare data, and AI technologies, AI developers and vendors should consider that HIPAA only provides a federal floor of privacy and security standards. Often, other state and federal laws can apply that pre-empt HIPAA – particularly with regard to healthcare adjacent data – or apply to more organizations than Covered Entities and Business Associates.  Also, many Managed Service Providers (MSP) companies providing services to healthcare organizations should be aware of AI applications and security vulnerabilities.


If your organization plans or is using AI for medical diagnostics, reference the annual joint publication by the U.S. Government Accountability Office (GAO) and the National Academy of Medicine published each September entitled “Technology Assessment – Artificial Intelligence in Health Care – Benefits and Challenges of Machine Learning Technologies for Medical Diagnostics”.   A new publication is posted each year: https://www.gao.gov/products/gao-22-104629


AIHC will continue to post articles related to artificial intelligence with regards to healthcare compliance.  Click Here for additional articles on various HIPAA topics.  Click Here for articles relating to Artificial Intelligence. Visit the AIHC Certifications page with online compliance learning opportunities.

Share 0
Post 0
Share 0
Read More
Release of Information
HIPAA, Release of Information

OCR Enforcement of HIPAA Right of Access and Release of Information (ROI)

Written by: Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, COCAS, CORCM, OHCC, ICDCT-CM/PCS




The article addresses the HIPAA Privacy Rule for Covered Entities regarding time limitations to respond to an individual’s request for access of protected health information or “PHI.” This article is not all inclusive and should not be used as legal or consulting advice. Scroll down for hyperlinks to free and low-cost training related to Right of Access & ROI.



What Is HIPAA Right of Access?


The HIPAA Privacy Rule generally provides individuals with a legal, enforceable right to see and receive copies, upon request, of the information in their medical and other health records maintained by their health care providers and health plans. This right is known as the HIPAA Right of Access.


HIPAA Right of Access policies have evolved over the years to ensure that patients have equitable access to their medical records. HIPAA requires covered entities to provide patients with access to their medical records. The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted in 2009, helped right of access policies evolve to reflect the growing use of EHR systems.


HIPAA Enforcement


HIPAA compliance it monitored by the Health & Human Services (HHS) enforcement agency, the Office for Civil Rights (OCR). The Office for Civil Rights is responsible for enforcing the Privacy and Security Rules. Enforcement of the Privacy Rule began April 14, 2003, for most HIPAA covered entities. Since 2003, OCR's enforcement activities have obtained significant results that have improved the privacy practices of covered entities. OCR also works in conjunction with the Department of Justice (DOJ) to refer possible criminal violations of HIPAA.


In 2019, the OCR launched the HIPAA Right of Access Initiative to advocate for individuals trying to obtain their health records in a timely manner at a reasonable cost as required by covered entities in the HIPAA Privacy Rule.


Complying With the HIPAA Privacy Right of Access Rule


If your organization is not responding timely to requests for medical records, a complaint to the Office for Civil Rights can trigger an investigation resulting in fines and other consequences, such as being posted on the OCR HIPAA website and a forced Corrective Action Plan.


A dedicated government webpage lists HIPAA News Releases & Bulletins listing OCR cases after investigating organizations which includes Right of Access settlements. Click Here to access this page. https://www.hhs.gov/hipaa/newsroom/index.html


The July 15, 2022, Health & Human Services (HHS) Press Release announces the resolution of eleven investigations and the enforcement actions taken with these eleven organizations related to violations of patient’s rights under HIPAA. In this press release the OCR Director Lisa J. Pino states:


“It should not take a federal investigation before a HIPAA covered entity provides patients, or their personal representatives, with access to their medical records. Health care organizations should take note that there are now 38 enforcement actions in our Right of Access Initiative and understand that OCR is serious about upholding the law and peoples’ fundamental right to timely access to their medical records.”

 

So, how timely must a covered entity be in responding to individuals’ requests for access to their PHI?


This is addressed under 45 CFR 164.524(b)(2) of the HIPAA Privacy Rule regarding access of individuals to protected health information (PHI). Under the HIPAA Privacy Rule, a covered entity must act on an individual’s request for access no later than 30 calendar days after receipt of the request.


If the covered entity is not able to act within this timeframe, the entity may have up to an additional 30 calendar days as long as it provides the individual, within that initial 30-day period, a written statement of the reasons for the delay and date when the entity will complete its action on the request. The 30-day timeline applies regardless of the following circumstances:

  • The PHI that is the subject of the request is maintained by the covered entity or by a business associate on behalf of the covered entity, or the covered entity uses a business associate to fulfill individual requests for access.

o The 30-day clock starts on the date that the covered entity receives a request for access, so any delay in obtaining the necessary information from a business associate or forwarding the request to the business associate for action “uses up” part of the allotted time.


o Alternatively, the 30-day clock starts when, instead of the covered entity, a business associate receives a request directly from an individual because the covered entity instructed the individual through its notice of privacy practices (or otherwise) to submit the access request directly to its business associate for processing. 

  • The covered entity negotiates with the individual on the format of the response. Covered entities that spend significant time before reaching agreement with individuals on format are depleting the 30 days allotted for the response by that amount of time.

  • The PHI that is the subject of the request is old, archived, and/or not otherwise readily accessible.

As noted by OCR, these timelines are outer limits. The government expects that covered entities should be able to respond to requests for access well before these outer limits are reached. However, in cases where a covered entity is aware that an access request may take close to these outer time limits to fulfill, the entity is encouraged to provide the requested information in pieces as it becomes available, if the individual indicates a desire to receive the information in this manner.


Resources to Comply With ROI and Right of Access


Learn more about 45 CFR § 164.524 - Access of individuals to protected health information. Free and reasonably priced training for you and your workforce is listed below:


Right of Access Specialist - Online Course

AIHC HIPAA Compliance Training Videos Free

Legal Information Institute (Cornell Law School) Free

HIPAA Online Privacy Course (Earn 12 AIHC and AHIMA CEUs)

Read More
HIPAA Compliance
HIPAA

How to Handle Passwords Like a Boss!

Written by: J. David Sims, CHITSP, CHMSP, Managing Partner at Security First IT, LLC; Board Member with the American Institute of Healthcare Compliance; Podcaster, Speaker, & HIPAA Instructor; Help Me with HIPAA Podcast Contributor and Federal HICP 405(d) Task Group & HIC-TCR Task Group




Cybersecurity starts with the basics, such as appropriately managing passwords within your organization. The Health Insurance Portability & Accountability Act (HIPAA) requires access controls and password management, which requires a top-down approach within your organization. Whether you are a Covered Entity or Business Associate, handle it like a boss!

In a recent article by Joanne Byron, she discussed one of the biggest challenges with proper password management… password sharing! In this article, I’m going to introduce you to some ways that you can overcome this challenge in your organization.

First, let’s start by setting three ground rules that I use for cybersecurity:

Rule #1 – Security is not convenient

Rule #2 – Security is not optional

Rule #3 – Security should not unnecessarily hinder the user

Understand that by design, security is there to hinder or stop an action. Think of your house for a minute. I have a sign in my yard advertising that I have monitored security in my home. I also have an alarm system, a deadbolt, a dog, and a shotgun. All these things represent different levels of security and incident response. They all cost me money and they are all inconvenient in some way. To protect my family, my most precious assets, is not optional. However, I can’t make this level of security so inconvenient that it doesn’t work. Therefore, I’ve ensured that these levels of security do not hinder my family’s ability to quickly enter and exit the home.

Security is there to deter the bad guys and to keep out those who should not be in my home (like the in-laws).

Passwords are just one layer of security for your electronic Protected Health Information and other digital assets. It is also a layer of security that is heavily dependent on the user… the human. The human must follow your password policy so that proper passwords are created and used in the correct manner. However, like a flowing river, humans will often find the path of least resistance (or create one) to get their job done.

Therefore, it is so important to train employees on your password policy, why passwords matter, what can happen when passwords are shared, and so on. Equally important is that the organization should take reasonable measures to make using passwords not a huge hinderance. Let’s take a look at some solutions to help your team be password ninjas!

Password Managers

Password managers are a fantastic tool for… you guessed it… managing passwords! I could not do without a password manager. At last check, I had over 1700 unique passwords stored in my password manager.

Password managers offer an array of other benefits and services but at its core, a password manager allows you to store all your passwords in a single, secure place. Instead of having to remember dozens or hundreds of passwords, the user only has to remember the one password that opens their password manager. Think of it as a vault for your passwords.

Another feature of most password managers that I love is the ability for me to share a password with someone without giving them the password. There are a few ways this can be used. I can set up a user account for someone and program their password into the password manager so that they can login to the application using their own credentials, and they never see the password. This ensures that a user can’t use their credentials outside of the office to access anything business related.

This is also very helpful for those websites that do not allow for multiple user accounts, but you still need multiple users to access it and use it. I see this often in practices where a business website only gives the practice a single account to use. The practice uses the same username and password for every employee that needs access to that website. Even worse, when employees leave the practice the credentials are not changed, which allows the separated employee to assess the site from anywhere.

There are several additional benefits of a good password manager application, so investigate one for your organization. They are well worth the small investment.

Creating Passwords

Whether you use a password manager or not, you still must deal with creating secure, unique passwords. Remember, you do not want to have the same password used more than once. Using the same password for everything is like having one key for your house, your car, your office, as well as all your past houses, cars, and offices. Oh, and the key has your name and address on it. Can you see how important it is to use different passwords everywhere?

Before we continue, it is important for you to understand that the bad guys aren’t trying to login to your online accounts typing in one password at a time hoping to get lucky. The bad guys use software automation and databases of passwords to throw at your accounts. This is called a brute force attack.

They know that most people are lazy and use terrible passwords. The most common password is 123456. You may laugh, but this password has been exposed in breaches more than 23 million times. It seems that no matter how terrible of a password it is, people still use it. For these people convenience is a higher priority than security. I wonder if these same people leave their car and homes unlocked… because, yeah… fumbling for a key is not convenient either.

Just a few months ago, the cybersecurity world learned of a leaked list of passwords called RockYou2021. This massive list of breached passwords and passwords from other sources comprises an impressive list of 8.4 billion unique passwords. 8.4 billion!!! Is there a chance that a password you use will show up on a list that size? Yeah, most likely. Unless you are one of the smart ones that use good password creation practices.

Since I’ve already mentioned password managers, it is worth noting that most password managers come with a password generator built-in that allows you to select a few criteria for your password and presto, it creates a password for you to use. Whether you’re using a password manager or not, here are some criteria to consider for your secure password:

Size Matters

Length is more important than complexity. Forever and a day we’ve heard that password complexity is necessary. Well, after years of research, we’re finding that all that complexity lends itself to creating other problems.

Many users fulfill this complexity requirement the same way by simply capitalizing the first letter of the password and adding a 1 or ! to the end. If I just guessed 25% of your password, you should be relegated to using a manual typewriter for the next month. Your password should be at least 8 characters (I prefer 12 to 16) minimum. The longer the password, the harder it is for software to crack it.

Change Is Good, or Is It?

Consider eliminating or reducing periodic password resets. We are also finding out that having people change their passwords too often means that they can’t remember them. I can often tell how many times someone has changed their password by how many exclamations they have at the end. Every time there was a password change, they simply added an exclamation.

If you are using secure passwords, there is no need to change them unless they become compromised in any way. However, knowing if they are compromised becomes super important and your organization should subscribe to services that monitor your accounts for compromised credentials. This brings us to the next point.

You Made the List! That Sucks.

Every password should be checked against known “blacklists” that include dictionary words, repetitive or sequential strings, passwords taken in prior security breaches, variations on the site name, commonly used passphrases, or other words and patterns that cybercriminals are likely to guess. Using a password that is on a Blacklist makes the password almost useless. Imagine if your home had one of those digital keypads for keyless entry. Now, imagine that there was a list floating around your town that had your home’s key code. How would it make you feel that thousands of strangers can easily walk right into your home if they desire? Using a compromised password is much the same.

Lie… Seriously!

You know those password hints you had to create to set up your bank account? Chances are, those answers are fairly easy to get by just paying attention to your social media accounts and what you share online. Heck, the answers may even be able to be socially engineered out of you.

When presented with these password hints and security questions… lie like crazy! What’s my mother’s maiden name? NunYoBitNess!

Get creative and have fun with it but remember you may need to use these answers at some point to recover or reset your real password, so you need to keep this information. I hate to keep coming back to password managers, but most of them also allow you to keep secure notes in your vault (it’s not just for passwords).

What Do You Have? What Do You Know?

Multi-factor (MFA) or Two-factor (2FA) authentication requires users to authenticate themselves using something they know and something they have.

2FA has been around for a very long time. If you’ve ever used an ATM machine to get cash, you’ve used 2FA. You used your card (something you have) and your PIN (something you know).

Using 2FA will likely require that you use an “Authenticator” app. There are many available but stick with the known companies like Google, Microsoft, Authy, etc.

I highly recommend using 2FA everywhere it is available. Even if someone has your username and password, it will be difficult for them to get past your additional authentication methods.

Wrapping It Up

Now that you know how to create secure passwords, how to store them safely, and how to manage them properly, you are ready to go out into the world and show everyone in your organization how they too can handle passwords like a boss!

Want More Information on HIPAA Compliance?

Help Me With HIPAA is the most popular, longest running podcast of its kind. Patient care starts from the moment a person entrusts you with their personal information. Join Donna and David each week as they deliver HIPAA and humor in a way you've never experienced. Who says learning can't be fun? Not us!


Train Online in HIPAA Privacy & Security Compliance – Click Here for more information.


Only need short refresher courses or targeted training? Check out the AIHC HIPAA short courses.

Read More
HIPAA Compliance
HIPAA

Is Sharing EHR Passwords a Problem?

Written by: Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, COCAS, CORCM, OHCC, ICDCT-CM/PCS




This article addresses the importance of Electronic Health Record (EHR) security to help health care organizations, health plans, clearinghouses (Covered Entities) and their business associates avoid HIPAA violations under the Security Rule Standard § 164.312(a)(1). To obtain more information about mitigating the risk of a HIPAA violation, please consult with legal counsel or a HIPAA Security Consultant. 

 

What If . . .

 

What would happen if you shared your login and password to your online bank account? How about sharing the password to access your credit cards? How would you feel if you knew your doctor shared his/her password to your personal medical records with an unauthorized user? What if someone in medical billing shared his/her password to your account (containing your medical and financial identity) with someone not authorized to access your information?


What If EHR Passwords Are Shared . . .


Electronic health records (EHRs) incorporate a vast amount of patient information and diagnostic data, most of which is considered protected health information. With the advancement of technology, the emergence of advanced cyber threats has escalated, which hinders the privacy and security of health information systems such as EHRs.


As defined by the Center of Medicare and Medicaid Services (CMS), “An electronic health record (EHR) is an electronic version of a patient’s medical history, that is maintained by the provider over time, and may include all of the key administrative clinical data relevant to that person’s care under a particular provider, including demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports.”


Because this protected information and data can easily get into the wrong hands, individuals should not share passwords with anyone.  


Is This Really a Problem? Doesn’t Everyone Share Passwords?


Due to the sensitive nature of the information stored within EHRs, several security safeguards have been introduced through the Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act.


Prevalence of Sharing Access Credentials in Electronic Medical Records

To summarize an abstract published by PMC (Public Med Central) of the U.S. National Institutes of Health’s National Library of Medicine, it was found that to prevent data leakage, many countries have created regulations regarding medical data accessibility. These regulations require a unique user ID for each medical staff member, and this must be protected by a password, which should be kept undisclosed by all means. A survey was conducted with the following results:

  • A total of 299 surveys were gathered.
  • The responses showed that 220 (73.6%) participants reported that they had obtained the password of another medical staff member.
  • Only 171 (57.2%) estimated how many times it happened, with an average estimation of 4.75 episodes. All the residents that took part in the study (45, 15%) had obtained the password of another medical staff member, while 57.5% (38/66) of nurses reported this.

Their conclusion from this study: the use of passwords is doomed because medical staff members share their passwords with one another. Strict regulations requiring each staff member to have a unique user ID might lead to password sharing and to a decrease in data safety. Click Here to access the full study.


Remember to Comply With the 3 Pillars of Securing ePHI


The three pillars to securing protected health information outlined by HIPAA are administrative safeguards, physical safeguards, and technical safeguards. These three pillars are also known as the three security safeguard themes for healthcare. These themes range from techniques regarding the location of computers to the usage of firewall software to protect health information. A brief list of the HIPAA Security Safeguards:

  • Access control (technical safeguard) is a technique that prevents or limits access to an electronic resource. The intent behind access control techniques is to limit access to only authorized parties. The healthcare facility collects, stores, and secures patients’ data, which is very sensitive. This safeguard can take the form of role-based access control, attribute-based access control, and identity-based access control. Role-based refers to a person’s role in the healthcare facility. For instance, when a provider begins working at a healthcare facility, he/she has access to patient data, but only the patient data for his/her patients. If this provider also serves on a certain committee in the hospital, then another set of privileges is created to enable access to committee resources. When other data is accessed, a log is created that is periodically audited. When a front-desk clerk begins working in a facility, he/she has no reason to access clinical data, but may need access to the administrative data such as address and phone number, depending on the role that the person plays in the organization. Other names for this are media controls, entity authentication, encryption, firewall, audit trails, virus checking, and packet filtering.
  • Physical access control (physical safeguard) is a technique that prevents or limits physical access to resources. The intent of this control is similar to the technical safeguard: It limits access to only authorized parties. A patient in a facility will not have access to any clinic or ward except the one he/she is seen in. A front-desk clerk in the optometry clinic will not typically need access to the emergency room, so his/her access card will not open those doors. A provider in a facility will not typically need access to the server room, so his/her access card will not unlock those doors. Other names for this are physical security, (some) workstation security, assigned security responsibility, media controls (access cards), and physical access control.
  • Administrative safeguards are techniques that are not entirely technical or physical, but may contain a piece of each. These safeguards typically take the form of policies, practices, and procedures in the facility to regularly check for vulnerabilities and continually improve the security posture of the organization. Other names for this control are risk analysis and management, system security evaluation, personnel chosen for certain roles, contingency, business continuity, and disaster recovery planning.

When Someone Shares a Password – It Is a HIPAA Violation Under the HIPAA Security Rule – Technical Safeguard Related to Access Controls. 

 

The Security Rule defines access in § 164.304 as “the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This definition applies to “access” as used in this subpart, not as used in subpart E of this part [the HIPAA Privacy Rule]).” Access controls provide users with rights and/or privileges to access and perform functions using information systems, applications, programs, or files. Access controls should enable authorized users to access the minimum necessary information needed to perform job functions. Rights and/or privileges should be granted to authorized users based on a set of access rules that the covered entity is required to implement as part of § 164.308(a)(4), the Information Access Management standard under the Administrative Safeguards section of the Rule.


Unique User Identification Requirement - § 164.312(a)(2)(i)

 

The Unique User Identification implementation specification states that a covered entity must: “Assign a unique name and/or number for identifying and tracking user identity.”


User identification is a way to identify a specific user of an information system, typically by name and/or number. A unique user identifier allows an entity to track specific user activity when that user is logged into an information system. It enables an entity to hold users accountable for functions performed on information systems with ePHI when logged into those systems using audit trails (addressed toward the end of this article).


Regardless of the technology or information system used, access controls should be appropriate for the role and/or function of the workforce member. For example, even workforce members responsible for monitoring and administering information systems with electronic protected health information or ePHI, such as administrators or super users, must only have access to ePHI as appropriate for their role and/or job function.


Sample questions for covered entities to consider:

  • Does each workforce member have a unique user identifier?
  • What is the current format used for unique user identification?
  • Can the unique user identifier be used to track user activity within information systems that contain ePHI?

So, What Can Happen If We Have Insufficient ePHI Access Controls?

Violating HIPAA law 104-191 can be costly. The HIPAA Security Rule requires covered entities and their business associates to limit access to ePHI to authorized individuals. The failure to implement appropriate ePHI access controls is also one of the most common HIPAA violations and one that has caused financial penalties. 


Financial penalties issued to covered entities for ePHI access control failures include:


Anthem Inc. – $16,000,000 penalty for access control failures and other serious HIPAA violations

OCR Imposes a $2.15 Million Civil Money Penalty against Jackson Health System for HIPAA Violations

OCR Imposes a $1.6 Million Civil Money Penalty against Texas Health and Human Services Commission for HIPAA Violations

University of California Los Angeles Health System – $865,500 penalty for the failure to restrict access to medical records

Colorado Medical Center – $111,400 penalty for the failure to terminate access to ePHI after an employee termination and a lack of a business associate agreement

Controlling Access to ePHI: For Whose Eyes Only?


The government HIPAA privacy/security enforcement agency is the Office for Civil Rights (OCR). OCR published the Summer 2021 Cybersecurity Newsletter on July 14, 2021, which states:


The rise in data breaches due to hacking as well as threats to ePHI by malicious insiders highlight the importance of establishing and implementing appropriate policies and procedures regarding these Security Rule requirements. Ensuring that workforce members are only authorized to access the ePHI necessary and that technical controls are in place to restrict access to ePHI can help limit potential unauthorized access to ePHI for both threats.


A recent report of security incidents and data breaches found that 61% of analyzed data breaches in the healthcare sector were perpetrated by external threat actors and 39% by insiders.


Without appropriate authorization policies and procedures and access controls, hackers, workforce members, or anyone with an Internet connection may have impermissible access to the health data, including protected health information (PHI), that HIPAA regulated entities hold. News stories and OCR investigations abound of hackers infiltrating information systems, workforce members impermissibly accessing patients’ health information, and electronic PHI (ePHI) being left on unsecured servers.


Information Access Management and Access Control are two HIPAA Security Rule standards that govern access to ePHI.


Download this newsletter:

Monitor Audit Trails


Audit trails automatically register and record where, when and who accessed the system. They also record what users do when they access the system. This tracks every change in patients’ information and documents it.


Since all the data is logged in the EHR system, it enables users to review the data at regular intervals and flag activities that seem suspicious. Regular reviews can also help correct mistakes caused by human error that could be flagged as a HIPAA violation. An audit trail answers the following:

  • Which patients’ data was accessed?
  • What time was it accessed?
  • Who retrieved the data?
  • Where was the data accessed from?

EHR software can also be set to send notifications to patients when their information is accessed. This way patients can report breaches as soon as they happen.


Conclusion


Create strong policies and procedures, then communicate these rules to your workforce. Enforce compliance through auditing and monitoring. Explain that when an individual allows another to use his/her password to access ePHI, that individual can alter and perform unauthorized functions and not be held accountable. The audit trail points back to the person who is assigned that password. 


Conduct on-going training of your workforce, which needs to include your C-Suite executives (who are not exempt from the rules). To gain the BEST results, conduct additional quarterly training with your front-line managers and supervisors.  Give them tools to incorporate HIPAA training at EVERY department meeting. If you think annual HIPAA training is sufficient, then you simply are not doing enough to protect your patient’s ePHI.


Additional Resources


Weekly HIPAA Podcasts (free) at:

OCR “The Security Rule” on the HHS website:

Train Online in HIPAA Privacy & Security:

Read More
HIPAA Compliance
HIPAA

Important Update: FTC Clarifies Health Breach Notification Rule- Healthcare Apps and Vendors Are Included

Written by: Susan Walberg, JD MPA CHC




As I have written in previous articles about HIPAA and health-tech, many apps in the marketplace have been largely unregulated with respect to the privacy and security of healthcare data. In order for healthcare-related apps to be regulated, for the most part they needed to be covered under HIPAA. As a result, only the apps that were directly related to providing or billing for healthcare services, or those companies’ ‘Business Associates,’ were required to put specific controls and notifications in place. All the rest were not. The Federal Trade Commission (FTC), the agency responsible for consumer protection, hasn’t really been on the radar in terms of regulatory oversight in this arena.


The many thousands of apps that are selected and used by consumers to manage illnesses, track fitness, and other health-related services do not fall under HIPAA’s requirements and were, for the most part, unregulated. All of this has changed with a September 15, 2021, Policy Statement by the FTC.


According to the Statement, the Health Breach Notification Rule "Helps to ensure that entities who are not covered by the Health Insurance Portability and Accountability Act (“HIPAA”) nevertheless face accountability when consumers’ sensitive health information is compromised.” The Breach Notification Rule is not new, but this clarification is, and signals likely enforcement of a rule that has largely gone unenforced to date. The push to regulate apps came from Congress, and further legislation is likely.


Who is Affected?


The FTC clarifies that vendors of ‘personal health records (PHRs) and PHR-related entities’ have to follow the breach notification procedures outlined in the Rule, which includes notification of consumers, the FTC, and even the media in some cases. These are not HIPAA ‘Covered Entities.’


The Rule covers vendors of PHRs that contain individually identifiable health information ‘created or received by health care providers.’ More specifically, PHRs are defined as an electronic record of “identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.”


The part that may be misunderstood is who the FTC considers a ‘health care provider.’ The FTC considers the developer of a health app or connected device as a ‘health care provider’ because it “furnishes healthcare services or supplies.”


According to the recent Statement, and the definition itself, the rule applies to any app that is capable of drawing information from multiple sources, such as from a consumer and an application programming interface (API). What are some examples? The FTC cites a blood sugar monitoring app that gets information entered by the consumer but also accesses data from the phone, such as the calendar. So all those apps that were previously considered exempt, such as fitness trackers, now need to take note.


What is a Breach?


The second critical aspect of the Statement pertains to what constitutes a breach. While most people consider a breach to be an intrusion, ransomware, or an attack by a hacker, the FTC takes a broader view. Now, it has been clarified, a breach includes unauthorized access, including sharing of information without an individual’s authorization. This is potentially a very big deal for all those apps that fell outside of HIPAA and were not hesitant about sharing consumer data with advertisers, investor-companies, or ‘big tech,’ where such data is often used to build user profiles. If you read my previous article on this topic, it hasn’t been illegal to sell or share consumer information that consumers voluntarily enter into many healthcare apps (unless they fit within HIPAA). Those activities, if not authorized by the consumer, are considered a breach and the FTC has put everyone on notice that more active enforcement of this rule can be expected.  And the penalties? Penalties can be up to $43,792 per violation.


What to Do?


If you are an app developer or own a company involved in developing healthcare apps, you need to review the policies, consumer consent and authorizations, and the technical controls in place. Evaluate where you share consumer data. Look at any data sharing agreements and contracts where sharing data might be part of the deal.


Make sure you review the various rules and regulations that apply to you as well as the various guidance put out by the FTC.  You can find their guidance, enforcement activities, and press releases on their website, ftc.gov. If you’re not sure, get help in figuring out which laws and regulations apply to your organization.


Take note that this area of compliance and enforcement is changing rapidly. Technology got ahead of regulations, especially with changing needs due to COVID.  Check out my website at https://www.susanwalberg.com/

Read More
HIPAA Compliance
HIPAA

HIPAA, The Cures Act and Information Blocking Compliance

Written by Joanne Byron, BS, LPN, CCA, CHA, CHCO, CHBS, CHCM, CIFHA, CMDP, OHCC, ICDCT-CM/PCS


The patient is at the center of the 21st Century Cures Act. Putting patients in charge of their health records is a key piece of patient control in health care, and patient control is at the center of HHS' work toward a value-based health care system. Patients need more power in their health care, and access to information is key to making that happen.


The Office of the National Coordinator for Health Information Technology (ONC) Cures Act Final Rule implements interoperability requirements outlined in the Cures Act.


HIPAA security requires covered entities to protect health information.  This information blocking practice is allowed except as required by law or as specified by the Secretary of Health and Humans Services as a reasonable and necessary activity.  However, it is likely to interfere with access, exchange and/or use of electronic health information (EHI). 

  • EHI is defined as the electronic protected health information (ePHI) in a designated record set (as defined in the Health Insurance Portability and Accountability Act (HIPAA) regulations) regardless of whether the records are used or maintained by or for a covered entity. The designated record set in a physician’s practice typically includes:
    • Medical records and billing records about individuals;
    • Other records used, in whole or in part, by physicians to make decisions about individuals

Why is this important to you?


All Actors will be subject to ONC’s Information Blocking rules and regulations on April 5, 2021.


For the first 24 months after publication of the Final Rule (currently until August 2, 2022), for the purposes of the information blocking definition, EHI is limited to the data elements represented in the US Core Data for Interoperability (USCDI) V1 standard adopted in the Final Rule.

  • EHR vendors are currently updating their products to support the access, exchange, and use of all data elements in the USCDI. This will take time and, for some smaller EHR vendors, may take several months.
  • After August 2, 2022, the definition of EHI expands to that of ePHI described above. At that time, all physicians will be required to make their patients’ ePHI available for access, exchange, and use.

Penalties - Because there are investigations, penalties and disincentives!  Actors that are subject to the information blocking regulations may be investigated by the HHS Office of Inspector General (OIG) if they are the subject of a claim of information blocking.

Further, actors found to have committed information blocking are subject to penalties:

  • Health IT developers of certified health IT, health information networks, and health information exchanges → Civil monetary penalties (CMPs) up to $1 million per violation
  • Health care providers → Appropriate disincentives to be established by the Secretary

Got Your Attention? 

What is behind the Information Blocking and Need to Comply?


The 21st Century Cures Act (Cures) is a landmark bipartisan health care innovation law enacted in December 2016. Cures includes provisions to promote health information interoperability and prohibit information blocking or “info blocking” by “Actors.”  Actors are considered:

  • Health Care Providers;
  • Health Information Networks (HIN) and Health Information Exchanges (HIE); and
  • Health information technology (IT) developers.

In March 2019, the Office of the National Coordinator for Health Information Technology (ONC) issued a Proposed Rule, 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program. They released a final rule in March 2020 and published it in the Federal Register on May 1, 2020.


What are examples of practices that could constitute information blocking?


Section 4004 of the Cures Act specifies certain practices that could constitute information blocking:

  • Practices that restrict authorized access, exchange, or use under applicable state or federal law of such information for treatment and other permitted purposes under such applicable law, including transitions between certified health information technologies (health IT);
  • Implementing health IT in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI;
  • Implementing health IT in ways that are likely to—
    • Restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between health IT systems; or
    • Lead to fraud, waste, or abuse, or impede innovations and advancements in health information access, exchange, and use, including care delivery enabled by health IT.

Additional examples of practices that could constitute information blocking can be found on the Office of the National Coordinator for Health Information Technology (ONC) website at: https://www.healthit.gov/curesrule/


Ah – there are Exceptions!

What are the information blocking exceptions?


Section 4004 of the Cures Act authorizes the Secretary of HHS to identify reasonable and necessary activities that do not constitute information blocking.  The exceptions support seamless and secure access, exchange, and use of EHI and offer actors certainty that practices that meet the conditions of an exception will not be considered information blocking.


A practice that does not meet the conditions of an exception would not automatically constitute information blocking. Such practices would not have guaranteed protection from civil monetary penalties or appropriate disincentives and would be evaluated on a case-by-case basis to determine whether information blocking has occurred.  Physicians must satisfy ALL applicable conditions of an exception at all relevant times to meet the exception as it relates to the access, exchange, and use of EHI. Each exception is limited to certain practices that clearly advance the aims of ONC’s Final Rule and are tailored to align with the following criteria:

  • Be reasonable and necessary
    These reasonable and necessary practices include providing appropriate protections to prevent harm to patients and others; promoting the privacy and security of EHI; promoting competition and innovation in health IT and its use to provide health care services to consumers, and to develop an efficient means of health care delivery; and allowing system downtime to implement upgrades, repairs, and other changes to health IT.
  • Address significant risk
    The exceptions are intended to address what ONC considers a “significant risk” and that Actors would otherwise avoid engaging in out of concern that such activities could be interpreted as info blocking.
  • Subject to strict conditions
    Each exception is subject to strict conditions to ensure practices are limited to those that are reasonable and necessary.

Exceptions are divided into two classes in the Cures Act Final Rule:

  • Exceptions that involve not fulfilling requests to access, exchange, or use EHI; and
  • Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI.

In the final rule, they have identified eight categories of reasonable and necessary activities that do not constitute information blocking, provided certain conditions are met (referred to as “exceptions”). The information below is a summary.  Go to healthIT.gov for more information.


Exceptions that involve not fulfilling requests to access, exchange, or use EHI


1.   Preventing Harm Exception


It will not be information blocking for an actor to engage in practices that are reasonable and necessary to prevent harm to a patient or another person, provided certain conditions are met.  This exception recognizes that the public interest in protecting patients and other persons against unreasonable risks of harm can justify practices that are likely to interfere with access, exchange, or use of EHI.


Physicians must hold a reasonable belief that the practice will substantially reduce the risk of physical harm to a patient or another natural person and the practice is no broader than necessary to substantially reduce the risk of harm. Practices include:

  • Declining to share data that is corrupt, inaccurate, or erroneous.
  • Declining to share data arising from misidentifying a patient or mismatching a patient’s EHI.
  • Refraining from a disclosure that would endanger life or physical safety of a patient or another person.
    • The licensed provider who made the determination must have done so in the context of a current or prior clinician-patient relationship.

Patients may opt to appeal a physician’s use of the Harm Exception. Physicians must implement their practice in a way that allows for the patient whose EHI is affected to exercise their rights under HIPAA or any federal, state, or tribal law to have the determination reviewed and potentially reversed.


The practice must be consistent with a written organizational policy that is:

  • Based on relevant clinical, technical, other appropriate expertise;
  • Implemented in a consistent and non-discriminatory manner; and
  • Conforms each practice to the conditions in the harm exception.

2.   Privacy Exception


It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to protect an individual’s privacy, provided certain conditions are met.  This exception recognizes that if an actor is permitted to provide access, exchange, or use of EHI under a privacy law, then the actor should provide that access, exchange, or use. However, an actor should not be required to use or disclose EHI in a way that is prohibited under state or federal privacy laws.


Sub-exceptions

  • Unsatisfied legal precondition to the release of EHI

a.  Physicians may withhold EHI if a state or federal privacy law imposes preconditions for providing access, exchange or use of EHI (e.g., a requirement to obtain a patient’s consent before disclosing the EHI), if their practice:


     i.   Is tailored to the applicable precondition;

    ii.   Implemented in consistent and non-discriminatory manner; and

   iii.   Either:

  • Conforms to physician’s written organizational policies; or
  • Is documented by a physician on a case-by-case basis
  • Certified health IT developer not covered by HIPAA
  • Denial of individual’s request for ePHI consistent with the HIPAA Privacy Rule


    • a.  HIPAA covered entity or business associate Actor may deny an individual’s request for EHI under the HIPAA Privacy Rule’s right of access if the Actor’s practice complies with the Privacy Rule’s “unreviewable grounds” for a denial of access.


         i.   Unreviewable grounds under Privacy Rule:

    • Certain requests made by inmates of correctional institutions;
    • Information created or obtained during research that includes treatment if certain conditions are met;
    • Denials permitted by the federal Privacy Act; and
    • Information obtained from non-health care providers pursuant to promises of confidentiality.

    Respecting an individual’s request not to share information


    a.  An Actor may decline to provide access, exchange, or use of EHI if it meets the following requirements intended to align with an individual’s HIPAA Privacy Rule right to request additional restriction:


         i.   Individual requests that the Actor not provide such access, exchange, or use of the EHI without any improper encouragement or inducement of the request by the Actor.


    3.   Security Exception


    It will not be information blocking for an actor to interfere with the access, exchange, or use of EHI in order to protect the security of EHI, provided certain conditions are met.  This exception is intended to cover all legitimate security practices by actors, but does not prescribe a maximum level of security or dictate a one-size-fits-all approach.


    General conditions — A practice is not info blocking if it is:

    • Directly related to safeguarding the confidentiality, integrity, and availability of EHI;
    • Tailored to the specific security risk being addressed; and
    • Implemented in a consistent and non-discriminatory manner.

    Actors and their security-related practices may satisfy proposed exception through:

    • Written organizational policies; or
    • Determinations on a case-by-case basis under particular facts and circumstances.

    A practice must meet both:

    • General conditions; and
    • Either the requirements for organizational policies or case-by-case determinations.

    For practices that do not implement an organizational security policy, an Actor must have decided in each case, based on the particular facts and circumstances, that:

    • The practice is necessary to mitigate the security risk to EHI; and
    • There are no reasonable alternatives to the practice that address the security risk that are less likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.

    4.   Infeasibility Exception


    It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided certain conditions are met.  This exception recognizes that legitimate practical challenges may limit an actor’s ability to comply with requests for access, exchange, or use of EHI. An actor may not have—and may be unable to obtain—the requisite technological capabilities, legal rights, or other means necessary to enable access, exchange, or use.  To receive protection, the practice must meet one of the following conditions:

    • Uncontrollable Events: The Actor cannot fulfil the request for access, exchange, or use of EHI due to a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption or act of military, civil or regulatory authority.
    • Segmentation*: The Actor cannot fulfil the request for access, exchange, or use of EHI because the Actor cannot unambiguously segment the requested EHI from EHI that:
      • Cannot be made available due to a patient’s preference or because the EHI cannot be made available by law; or
      • May be withheld in accordance with the Preventing Harm Exception.
    • Infeasible Under the Circumstances: The Actor demonstrates, prior to responding to the request, through a contemporaneous written record or other documentation its consistent and non-discriminatory consideration of certain factors that led to its determination that complying with the request would be infeasible under the circumstances.

    * You may need to provide access to information that is not otherwise protected by federal or state privacy law (e.g., HIPAA Patient Right of Access). You should consider speaking with your compliance officer or practice manager about how to handle such situations. For example, you may still be required to print out an office note and hand redact protected information even if you claim the Infeasibility Exception.


    5.   Health IT Performance Exception


    It will not be information blocking for an actor to take reasonable and necessary measures to make health IT temporarily unavailable or to degrade the health IT's performance for the benefit of the overall performance of the health IT, provided certain conditions are met.


    This exception recognizes that for health IT to perform properly and efficiently, it must be maintained, and in some instances improved, which may require that health IT be taken offline temporarily. Actors should not be deterred from taking reasonable and necessary measures to make health IT temporarily unavailable or to degrade the health IT’s performance for the benefit of the overall performance of health IT.  An Actor’s practice to maintain or improve health IT performance is not info blocking when the practice meets one of the four following conditions:

    • Maintenance and improvement to health IT (e.g., an EHR upgrade).
    • Consistent with existing service level agreements, where applicable.
    • Practices that prevent harm and comply with Preventing Harm Exception.
    • Security-related practices that comply with Security Exception.

    Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI


    6.   Content and Manner Exception


    This is an important exception for physicians who are limited by their EHR vendor’s ability to access, use, or exchange patient information. Physicians are encouraged to discuss the use of this exception with their EHR vendor.  If the burden on the Actor for fulfilling a request is so significant that the Actor chooses to not fulfil the request at all, the Actor could seek coverage under the Infeasibility Exception.


    It will not be information blocking for an actor to limit the content of its response to a request to access, exchange, or use EHI or the manner in which it fulfills a request to access, exchange, or use EHI, provided certain conditions are met.


    This exception provides clarity and flexibility to actors concerning the required content (i.e., scope of EHI) of an actor’s response to a request to access, exchange, or use EHI and the manner in which the actor may fulfill the request. This exception supports innovation and competition by allowing actors to first attempt to reach and maintain market negotiated terms for the access, exchange, and, use of EHI. This exception applies to practices that involve the Actor responding to a request with limited information and in a manner other than what was requested by the requestor.

    • Content:
      • For 24 months after final rule publication, the Actor must respond with the subset of EHI identified by the USCDI data elements.
      • After that date, the Actor must respond with all EHI in a designated record set (i.e., ePHI).
    • Manner of Response: The Actor must respond either:
      • In the manner requested; or
      • In an alternative manner.

    7.   Fees Exception


    It will not be information blocking for an actor to charge fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI, provided certain conditions are met. This exception enables actors to charge fees related to the development of technologies and provision of services that enhance interoperability, while not protecting rent seeking, opportunistic fees, and exclusionary practices that interfere with access, exchange, or use of EHI.


    Fees may result in a reasonable profit. The exception excludes certain fees, such as those based on electronic access to EHI by the individual. ONC divided the Fee Exception into three conditions.

    • To qualify for this exception, the Actor’s practice must meet the “Basis of fees condition,” not include any of the fees addressed in the “Excluded fees condition,” and comply with the “Compliance with the Conditions of Certification condition” if the Actor is a health IT developer subject to ONC’s Conditions of Certification (CoC).
    • This exception will most likely be applicable to EHR vendors rather than physicians or other providers.

    8.   Licensing Exception


    It will not be information blocking for an actor to license interoperability elements for EHI to be accessed, exchanged, or used, provided certain conditions are met. This exception allows actors to protect the value of their innovations and charge reasonable royalties in order to earn returns on the investments they have made to develop, maintain, and update those innovations.


    Conclusion

    Information blocking can occur in many forms for both Actors and Patients. Physicians can experience information blocking when trying to access patient records from other providers, connecting their EHR systems to local health information exchanges, migrating from one EHR to another, and linking their EHRs with a clinical data registry.  Patients can also experience information blocking when trying to access their medical records or when sending their records to another provider.


    The new rules regulate EHR vendors, prohibiting them from blocking information. Like physicians, EHR vendors must comply with these regulations now.  Learn more by reviewing the resources provided below.


    Resources

    AIHC HIPAA Compliance Officer Training

    American Medical Association –

    ONC

    Read More