HIPAA Compliance
General Compliance, HIPAA

Before PHI Enters a SaaS Workflow

Building a Vendor Evidence Register 

Written by Coco Yang 

Introduction

A clinic can approve a scheduling platform and still miss the place where patient information leaves the approved path. An intake form may pass data to the scheduler, which sends a notification through an email service, creates a record in a customer relationship management system, and copies details into an analytics tool. The vendor review may have covered the scheduling platform. The actual workflow contains four or five services.

That is why a product name and a "HIPAA compliant" statement are not enough to document a SaaS decision. The review needs to identify the exact service, plan, configuration, integrations, users, and data flow. It also needs a record of what each source supports, what it does not support, and what still requires an answer from the vendor.

A vendor evidence register provides that record. It is not a certification score and should not replace legal, privacy, security, procurement, or clinical review. It is a practical way to keep the evidence behind a decision visible before protected health information (PHI) enters a software workflow.

Start With the Workflow, Not the Vendor Name

The first question is not simply, "Does this vendor support HIPAA?" A more useful starting question is, "What will this organization do with this exact service?"

Write down the product edition and paid plan, the features that will be enabled, the people who will have access, and the systems that will send or receive data. Include support tools, exports, backups, browser extensions, mobile applications, application programming interfaces, automation services, and optional artificial intelligence features. Then identify where PHI is expected to be created, received, maintained, or transmitted.

This boundary matters. A vendor may make a business associate agreement (BAA) available only for certain products, plans, customers, or configurations. An integration may be provided by another company. A feature may use a separate sub-processor or different retention setting. HHS guidance on cloud computing advises covered entities and business associates to understand the cloud environment they are using so they can conduct their own risk analysis and enter into appropriate agreements.

A simple workflow sentence helps anchor the review. For example: "Patients submit contact and appointment information through Form A; the data is stored in Scheduler B; staff members access it through managed accounts; appointment reminders are sent through Service C; no PHI is sent to analytics." If the team cannot write that sentence with confidence, it is too early to approve the workflow.

Keep Different Kinds of Evidence Separate

Vendor material often arrives as a mixed folder of contracts, reports, help-center pages, questionnaires, and sales statements. These sources do not answer the same questions.

A BAA is contractual evidence. HHS explains that a business associate contract establishes permitted and required uses and disclosures, requires safeguards, addresses incident reporting, applies restrictions to relevant subcontractors, and covers return or destruction of PHI at termination when feasible. The review still needs to confirm that the agreement applies to the exact legal entity and service being purchased.

A SOC 2 report is security-assurance evidence. It can help a reviewer understand the systems, controls, time period, exceptions, and subservice organizations described in the report. It does not establish that the vendor will sign a BAA, that the intended product is included in the BAA, or that the customer's configuration is appropriate.

Product documentation explains how features work. It may describe access controls, audit logs, retention settings, encryption, data regions, or deletion behavior. Marketing language is a weaker source. It can point the team toward a question, but it should not be treated as proof that a contract, report, or technical control covers the planned workflow.

Keeping these evidence types separate prevents one familiar logo or badge from doing more work than it should.

What to Record

The register does not need to be elaborate. A spreadsheet, ticket, or procurement record can work if it preserves enough context for another reviewer to reconstruct the decision. For each item, record:

  1. The source title, owner, and location.
  2. The date it was retrieved and, when applicable, its effective period or report period.
  3. The legal entity, product, plan, feature, and region it covers.
  4. The conclusion the source supports.
  5. Conditions and limitations stated in the source.
  6. Questions that remain open and the person responsible for resolving them.
  7. The date or event that will trigger another review.

Short conclusions are more useful than broad labels. "Vendor says HIPAA compliant" is difficult to act on. "BAA offered for the Enterprise plan; analytics add-on not named; vendor confirmation pending" tells the next reviewer what is known and where the uncertainty sits.

The same discipline should be used for security evidence. Instead of recording "SOC 2 available," note the report type, review period, system description, relevant exceptions, complementary customer controls, and whether important subservice organizations are included or carved out.

Check the Operational Questions

Contracts and assurance reports are only part of the review. The intended use also depends on routine operational details.

Ask which sub-processors may create, receive, maintain, or transmit PHI. Confirm how administrators and support personnel obtain access, whether that access is logged, and how emergency support is handled. Review default retention, backup retention, deletion timing, export behavior, account termination, and the process for returning or destroying data.

Incident language deserves the same attention. Identify where the vendor describes security incidents and breach notification, who receives notice, and whether the timing and cooperation terms match the organization's requirements. Customer-side safeguards should also be explicit: identity management, multifactor authentication, role design, device controls, logging, staff training, approved integrations, and procedures for offboarding users.

A signed BAA does not configure the product. HHS risk-analysis guidance makes clear that regulated organizations must identify potential risks and vulnerabilities to all electronic PHI they create, receive, maintain, or transmit. The vendor's evidence informs that work; it does not perform the organization's risk analysis for it.

Use Evidence States Instead of a Single Verdict

A binary field labeled "compliant" hides too much. Evidence is often conditional, incomplete, inconsistent, or old. A small set of evidence states makes the record more honest:

  • Supported: the source directly supports the conclusion for the identified scope.
  • Conditional: the conclusion depends on a plan, configuration, contract, location, or customer action.
  • Missing: the needed source has not been obtained.
  • Conflicting: two sources disagree or describe different scopes.
  • Stale: the source no longer reflects the current product, contract, report period, or workflow.

These are evidence states, not compliance determinations. They help the organization route questions to the right owner and avoid treating silence as approval.

Review Again When Something Changes

An annual vendor review is useful, but a change in the workflow can make last month's evidence incomplete. Set event-based review triggers for a new contract or BAA, a plan change, a new integration, a material sub-processor update, revised retention terms, a new artificial intelligence feature, a security incident, or a change in the type of PHI being handled.

The register should also have an owner. Procurement may hold contracts, security may review assurance reports, privacy or compliance may assess uses and disclosures, and the operational team may know the actual configuration. Someone must be responsible for assembling those pieces and recording the final conditions of use.

Conclusion

A SaaS review is easier to defend when another person can see exactly what was reviewed, when it was reviewed, and which workflow the decision covered. Begin with the data path. Separate contractual, assurance, product, and marketing evidence. Record scope and dates. Preserve unresolved questions. Reopen the review when the service or workflow changes.

The purpose of a vendor evidence register is not to produce a universal badge. It is to make the reasoning behind a decision inspectable before PHI enters the workflow. Final decisions should remain with the organization's qualified legal, privacy, security, compliance, procurement, and operational professionals.

About the Author

Coco Yang is the Founder of ComplySaaS, an educational SaaS vendor compliance research project that organizes public HIPAA, BAA, PHI, and SOC 2 signals, source dates, workflow conditions, and verification questions. Her work is limited to documented vendor-research practice; she is not presenting herself as an attorney, auditor, healthcare provider, or compliance certifier. Company website: https://www.complysaas.com/

References

U.S. Department of Health and Human Services. "Guidance on HIPAA & Cloud Computing."

U.S. Department of Health and Human Services. "Business Associate Contracts."

U.S. Department of Health and Human Services. "Guidance on Risk Analysis."

National Institute of Standards and Technology. "SP 800-66 Rev. 2: Implementing the HIPAA Security Rule."

Copyright © 2026 American Institute of Healthcare Compliance All Rights Reserved

Share 0
Post 0
Share 0
Read More
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
Telehealth
HIPAA, Telehealth

Audio-Video Telehealth, Mobile Device Management & You

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


This article addresses how to track telehealth policies while addressing HIPAA compliance and mobile device management as the United States enters into a post-pandemic era. The information is an overview and should not be used as legal or consulting advice. Health care providers need to look toward long-term telehealth policies, ensure compliance and realize there is remaining work to be done. 


Scroll to the end of this article for “Basic Telehealth Terminology” if you are new to telehealth or if you are a mobile device app developer!


Most Providers Utilize Audio-Only Telehealth


More than two-thirds of providers utilizing telehealth use audio-only, according to a recent Telehealth Survey conducted November 2021 through December 2021 by the American Medical Association (AMA). According to this survey, 85% of physician respondents indicate they currently use telehealth. Those reporting a decrease in use since first offering it, now indicate doing a mix of in-person and virtual care. Of physician’s using telehealth, the trend indicates 93% are conducting live, interactive video visits with patients and 69% are doing audio-only visits.  


Considering this survey and other reports on audio-video services, concerns seem to focus on potential overutilization, equity and quality of care. 


A concern expressed to AIHC, by our Compliance and HIPAA Officer members, surrounds mobile devices used by providers and practice managers and the organization’s responsibility to comply with applicable rules, regulations and mobile device policies.


So, how do policies apply? 

 

If your providers use a mobile device to access an organization’s internal network or system, the owner of that network or system’s policies and procedures apply to your use of the mobile device to gain such access. It is your organization’s responsibility to understand and follow the organization’s policies and procedures.


If an organization allows providers and professionals to use mobile devices for work, the organization should have reasonable and appropriate mobile device policies and procedures. The policies and procedures should describe any configuration requirements for mobile devices used by providers and professionals for work. It is your responsibility to understand and follow your organization’s mobile device policies and procedures. But, what about using personally owned mobile devices for work?

  • "Bring Your Own Device" or BYOD refers to using a personally owned mobile device for work. Providers should be reminded to let their organization know when they want to use a personally owned mobile device. Many organizations have centralized security management to make sure mobile devices accessing their internal networks or resources are compliant with their security policies. Centralized security management includes:

o Configuration requirements, such as installing remote disabling on all mobile devices; and


o Management practices, such as setting policy for individual users or a class of users on specific mobile devices.


It is the provider’s responsibility to understand and follow the organization’s mobile device policies and procedures. Registering the provider’s mobile device with the organization allows the organization to control who has access to its network or system and will keep unauthorized persons from accessing its network or systems.

  • Registering these mobile devices with your organization may also help the organization or law enforcement find your mobile device if it is lost or stolen. Providers should be directed to contact their organization’s Privacy Officer or Security Officer to register their mobile device.

Utilizing Step 4 from ONC’s 5-Step Process to Manage Mobile Devices Used by Health Care Providers & Professionals, the list of questions below is a way to take inventory of potential safeguards needed to address risk areas.


Mobile Device Management


 If your organization allows the use of mobile devices, what should the organization do about managing the use of mobile devices?


   o Has the organization identified all the mobile devices that are being used in the organization? How is the organization keeping track of them?


   o Has the organization assigned responsibility to check all mobile devices used for remote access, to find out if selected security/configuration settings are enabled?


   o Should there be a regular review and audit of the mobile devices? 


Misuse of Mobile Devices


 Does the organization have written procedures for addressing misuse of mobile devices?


   o If so, what are the consequences when a mobile device is misused and the incident poses risk of a data breach?


Should the Organization Allow BYOD?


 Is this a policy already in place, where providers are using their own devices?


   o Should the organization let providers and professionals use their personally owned mobile devices within the organization?


 Should providers and professionals be able to connect to the organization’s internal network or system with their personally owned mobile devices, either remotely or on site?


Restrictions on Mobile Device Use


 Does the organization restrict how providers and professionals can use mobile devices?


   o Can providers and professionals use mobile devices to access internal networks or systems, such as an EHR?


   o Are providers and professionals restricted from using mobile devices when they are away from the organization?


   o Can providers and professionals take their mobile devices home?


   o Should the organization allow texting or emailing of health information?


      Is there encryption allowing compliant texting and emailing from the mobile device?


Security/Configuration Settings for Mobile Devices


 Will the organization institute standard configuration and technical controls on all mobile devices used to access internal networks or systems, such as an EHR?


   o If so, is the organization's current mobile device configuration document, including connections to other systems/applications, inside and outside of the firewall.


Information Storage on Mobile Devices


 Are there restrictions on the type of information providers and professionals can store on mobile devices?


   o If so, where and for how long should the data be stored?


 Are providers and professionals allowed to download mobile applications to mobile devices? If so, what type(s) of applications are approved?


Recovery/Deactivation of Mobile Devices


 Does the organization have procedures to wipe or disable a mobile device that is lost or stolen?


 Does the organization have standard procedures to recover mobile devices from providers and professionals when their employment or association with the organization ends?


Mobile Device Training


Training is always a challenge, but if your organization cannot achieve effective training and compliance, you may need to reconsider how telehealth is delivered to your patient population.


 How is the organization training its workforce (management, doctors, nurses, and staff) on policies and procedures?


 How does the organization hold its workforce (management, doctors, nurses, and staff) accountable for non-compliance? 


What Additional Information Should I Know for Compliance?


Covered entities must comply with HIPAA Privacy and Security Rules to protect and secure health information, even when using mobile devices as described above. Taking it a step further, health care leaders are responsible to ensure that mobile device procedures and policies have been developed and properly implemented to protect the health information patients entrust to you.


Make Tracking Audio-Only Policy Easy


A great resource is utilizing the National Telehealth Policy Resource Center called “CCHP,” short for Center for Connected Health Policy. CCHP has been tracking audio-only policies across the country and offers access to state audio-only policies via CCHP’s Policy Finder Tool.


As AIHC advises, another resource is legal advice through your malpractice insurance company. At no additional charge, a risk attorney can be made available to help review which policies impact your type of practice and organization.


Free HIPAA Compliance Resources


Another reliable resource is found at HealthIT.gov, the official website of the Office of the National Coordinator for Health Information Technology, otherwise known as “ONC.” ONC offers basic guidance in these five steps 1) Decide; 2) Assess; 3) Identify; 4) Develop, Document and Implement; and 5) Train entitled “five steps organizations can take to manage mobile devices used by health care providers and professionals.”


Does Your Organization Have a Trained (Certified) HIPAA Privacy/Security Officer?


Your HIPAA Compliance Officer can serve as the best resource to help your organization navigate the telehealth and mobile device compliance issues facing your providers today. AIHC offers an online course covering both privacy and security with the option of certification (proctored and administered online).  The cost of certification is covered in the tuition price. Learn more.


It is highly recommended that mobile health app developers and Managed Service Providers (MSPs) have an in-house HIPAA Compliance Officer contributing input to ensure technology is compliant.


Are You a Mobile Health App Developer?


Integrating protections into your technology to create HIPAA compliant products is necessary for your company to succeed. Health care providers are subject to the HIPAA rules as covered entities to protect identifiable health information when it is created, received, maintained and/or transmitted. These protections are required under Federal and State Privacy, Security and Breach Notification Rules. A few basic resources to reference are:


The Office for Civil Rights (OCR) HIPAA website devotes a webpage under Special Topics entitled “Resources for Mobile Health Apps Developers.”


The Federal Trade Commission (FTC) offers a webpage entitled “Mobile Health Apps Interactive Tool” to help you locate federal laws to follow.


For Beginners - Basic Telehealth Concepts


Telehealth is also referred to as Telemedicine. It is the use of telecommunications technology to provide health care services to persons who are at some distance from the provider. This type of patient encounter involves a spectrum of technologies.


Coverage and payment for telehealth can include consultation, office visits, individual psychotherapy, pharmacologic management and other services delivered via an interactive audio and video telecommunications system.  

  • Providers are located at the distant site; and
  • Patients are located at the originating site.

Provider at the distant site - As stated above, providers are at the “distant site,” referring to where the provider is at time of service. The provider can communicate with the patient using an interactive audio and video telecommunication system that permits real-time communication with the beneficiary.


When telehealth is used, it is considered to be rendered at the physical location of the patient, and therefore a provider typically needs to be licensed in the patient’s state. During the COVID-19 public health emergency (PHE), many states waived this requirement or provided specific exceptions. Click Here for Cross-State Licensing information.


Medicaid programs often restrict the type of providers that can be reimbursed when delivering services via telehealth. During the COVID-19 PHE, the list of providers in Medicare and many state Medicaid programs expanded to include professionals such as occupational and physical therapists and speech-language pathologists. Federally Qualified Healthcare Centers (FQHCs) and Rural Health Clinics (RHCs) were also allowed to provide services in some cases. These policies are temporary and most will expire at the end of the PHE.


I also recommend utilizing the TELEHEALTH.HHS.GOV website for providers – “Getting Started with Telehealth.” This webpage provides many additional links to more resources your organization can use to navigate this complex topic.


Temporary telehealth policies during the PHE were implemented to provide improved access to health care during the COVID-19 pandemic. The federal government has been encouraging providers to use telehealth to conduct virtual appointments and has made the telehealth “rules” more flexible. For instance, audio-only delivery of care has rarely been reimbursed historically. But due to COVID and the PHE, temporary policies allow this modality to deliver some services.


The PHE is reviewed and potentially extended every 90 days. When the PHE ends, coverage for telehealth may change. Monitor these updates by using the CCPH website referenced earlier in this article found at https://www.cchpca.org/.

Read More
HIPAA Compliance
HIPAA

Allowing Workforce Members to Access Their Own Medical Records?

Written by: J. David Sims, CHITSP, CHMSP, Board Member of AIHC

J.David Sims is a Managing Partner at Security First IT, LLC; Speaker & HIPAA Instructor; Help Me with HIPAA Podcast Host; Contributor with the Federal HICP 405(d) Task Group & HIC-TCR Task Group; Founder & CEO of HIPAA for MSPs




The Health Insurance Portability & Accountability Act (HIPAA) has provisions to protect the contents of medical records. At a recent AIHC HIPAA training event, this topic came up. We would like to share some resources to the question that was asked. The information contained in this article is not consulting or legal advice and is provided for educational purposes only.


We have a problem with certain members of our workforce accessing their own medical records. These are people with fairly high levels of security and can access most records. I am a Certified HIPAA Compliance Officer (CHCO) through the AIHC organization and a compliance specialist. Our compliance committee wants the “industry standard” of this statement and evidence that this is industry standard. Do you have an idea of where I should look or any additional resource I can use to support that an employee should not access his/her own records? We want to institute a policy prohibiting this behavior.


Response

This is one of those areas that you won't find specifically mentioned (as HIPAA can't address every possible scenario). Therefore, we must look at what HIPAA does say and how does that fit into this scenario.


First, there should be a proper process for any patient (employee or otherwise) to request their medical records and have them presented within 30-days of request. Allowing employees to bypass this process could cause some issues. For example:

  • Do you have a current policy regarding restriction of access according to the employee’s work-related duties? Is accessing his/her own records outside of this policy? It most likely should be.
  • Will bypassing this process bypass documentation of the request, documentation of the records retrieval and documentation of the record controls?
  • Will they have access to notes that a "regular" patient would not and should not have access to?

Keep in mind that when I say documentation, I mean proof of the proper action that can stand up to an audit or investigation. So, if an entity is planning to allow this action, there should be a documented policy and procedure of how this will be handled.


Now, although it is possible that an employee can access and review their own medical records, let's look at two specific parts of HIPAA to see if this action will pass.

For uses of protected health information, the covered entity’s policies and procedures must identify the persons or classes of persons within the covered entity who need access to the information to carry out their job duties, the categories or types of protected health information needed, and conditions appropriate to such access.

  • I've underlined what I believe to be a key in this sentence. Would it be part of the employee's job duties to access their own records?

Let's assume the answer is "yes." Here's what else is given in this guidance: Where the entire medical record is necessary, the covered entity’s policies and procedures must state so explicitly and include a justification.


Another portion of the text identifies "non-routine disclosures or requests." I think a case could be made that an employee accessing their own records would be a non-routine disclosure. Here's what they say about this: “For non-routine disclosures and requests, covered entities must develop reasonable criteria for determining and limiting the disclosure or request to only the minimum amount of protected health information necessary to accomplish the purpose of a non-routine disclosure or request. Non-routine disclosures and requests must be reviewed on an individual basis in accordance with these criteria and limited accordingly.”


So, if your practice can make a case for this type of access, there must be a review of this activity every single time. I don't know about you, but it seems following the normal patient record request would be less strain on the practice at this point. But let's keep going.


We can wrap up with the Minimum Necessary Requirements portion. However, it is obvious that any PHI access has to be for the purposes of a job function or role. I do not see any way to interpret employee access to their own medical records as part of their job or role. But maybe some Covered Entities can make that case.

  • Next, let's look at Uses and Disclosures: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html

There are 3 distinct areas in which the use or disclosure of PHI is permitted... for treatment... for payment... for healthcare operations or “TPO” as we call it. If to this point a Covered Entity (CE) has determined that it is ok for an employee to access their own medical records, let's then pass this through the test of TPO.


The employee can access the PHI if the employee is involved in their own treatment. It would be unusual and rare that an employee is allowed to treat themselves and realize that Medicare and other insurances will not reimburse a provider when treating him/herself or a family member – so these circumstances cannot be billed. Aside from HIPAA, there can be other liabilities, risks, and legal problems if this is allowed.


The employee can access the PHI if the employee is involved in the payment activities. Allowing an employee to manage their own payments, adjustments, eligibility, coverage, claims, bills, justification of charges, utilization review, collections, etc., would likely not be recommended by most lawyers or accountants... not to mention insurers. In fact, it creates a “nightmare” from a compliance standpoint.


The employee can access the PHI if the employee is involved in Health Care Operations. “Health care operations” are certain administrative, financial, legal, and quality improvement activities of a covered entity that are necessary to run its business and to support the core functions of treatment and payment. These activities, which are limited to the activities listed in the definition of “health care operations” at 45 CFR 164.501.


Ok, now that we've taken our scenario and passed it through the filter of Minimum Necessary Requirements and TPO, your committee can determine how they would like to proceed with this decision.


Two final things I'll say about it:


First, if they choose to allow the action, I highly recommend a specific policy and procedure for it and a "mini" risk assessment to identify what the risks are to the CIA of the PHI and developing a risk management plan for things that are identified.


Second, this is such a low priority compliance matter that I would not necessarily spend a lot of time on it. I don't see OCR spending resources to investigate an employee accessing their own records, but I certainly can't say it won't happen. With all the activities and actions that carry a much higher likelihood and impact to the patient and the organization, this carries a very low probability of impact. Is the employee going to look at their records and then file a complaint with HHS that their PHI was improperly disclosed? People can be crazy, so maybe... lol.


This is one of those areas where technically you can make a case for or against it. Although, I see the case against it as being stronger. It really would be easier to just follow the same patient record request process for everyone. If you're a patient, you're a patient (even if you're an employee too). OCR investigators have a lot of leeway in their investigations so if this matter were to come up in an investigation, it can really depend on the investigator and whether they want to push this issue or make an example of the organization.


Personally, I just don't like taking the risk of potential issues that my organization can easily avoid. If there is a question of right or wrong, I'm going to lean toward what is easier to prove as being the right thing to do rather than fight like hell to make a case that the wrong thing was right.


Need HIPAA support? Contact J. David Sims, Managing Partner of Security First IT, LLC and Contributor with the Federal HICP 405(d) Task Group & HIC-TCR Task Group.

 

Want more great training information on HIPAA privacy and security compliance? Register for the online HIPAA course today! 


No classes to attend. Course materials are on-demand and available to you for 3 months. Training is for experienced health care consultants, business associates, HIPAA Privacy or Security Officers, IT Consultants, Practice Administrators, Office Managers, Compliance Officer Executives, and Administrators involved in developing and enforcing confidentiality and privacy and security as a Covered Entity or Business Associate.

Read More
HIPAA Compliance
HIPAA

Scenarios That Can Lead to HIPAA Violations – Are you doing anything to avoid them?

Written by: Salman Rashid




HIPAA, which stands for the Health Insurance Portability and Accountability Act, is a monumental piece of legislation in the U.S. that was enacted in 1996 in order to reduce healthcare fraud and facilitate the transfer of worker’s coverage when they switch or leave jobs.


Decades later, with several new standards introduced within the law, this Act is now best known for protecting the privacy of patients and health plan members’ medical information and, as well as ensures that health information is kept secure and patients are notified whenever there’s a breach of information.


As beneficial as it may sound, HIPAA can be devastating for those who do not follow the rules. There are two types of entities that must abide by the rules and regulations of HIPAA. One is covered entities and the other is their business associates. A single instance of a HIPAA violation can range from thousands to millions of dollars. HIPAA violations are categorized into four tiers, the more severe and neglected the violations are, the higher the tier.


So today, we’ll discuss a few scenarios that can lead to a HIPAA violation so that you can take appropriate actions to comply with the law.


Common types of HIPAA violations


Shortfall in encryption

The risk of leaving Protected Health Information (PHI) unsecured is straightforward. Encryption adds layer of protection, including cybersecurity and all other best practices. Even if someone is somehow able to get their hands on PHI, whether by stealing or cyber hacking, they won’t be able to access the information if there’s an added layer of protection without the passcode. Even though encryption is not a strict HIPAA requirement, it is highly recommended because encryption can better protect PHI from prying eyes. Many progressive healthcare organizations have also implemented biometric patient identification solutions for enhanced protection.


Shortfall in training

individuals who might come into contact with PHI in the course of their work. However, it’s best to provide training for everyone in the organization so they understand the purpose of HIPAA and learn the best practices to better protect themselves from fines and penalties, as well as patients’ healthcare data. Often employees inadvertently access PHI or violate the law because they do now possess enough knowledge. It is recommended to train all the staff members on the law and the particular policies and procedures set forth by the organization.


Sharing or Gossiping PHI

Gossiping is an innate nature of all human beings. Especially healthcare workers may be tempted to discuss a patients’ medical case with their coworkers or in a place where conversations can be overheard. However, PHI should be off-limit unless the other person is involved in the patients’ health care. Healthcare workers with access to PHI should also be very careful about the information they share with others. Information might be shared out of curiosity, but the consequences are the same regardless of the intent. Sharing patients’ information on social media without the patients’ consent is also prohibited.


Disposing of medical records improperly

This is a very common scenario in many healthcare organizations where they dispose of PHI without shredding them first or in a place where it is visible or can easily be stolen. Either way, if PHI falls into the hands of the wrong person, there could be serious HIPAA consequences. Staff members should understand PHI contains valuable and sensitive information like financial numbers, social security numbers, etc., and should be shredded or destroyed before disposal, or wiped from the hard drive.


Avoiding HIPAA violations


There could be several other ways HIPAA can be violated. Staff members must be provided with up-to-date and frequent training so that they understand the purpose of HIPAA and avoid actions that can lead to a HIPAA violation. Healthcare organizations must also understand that HIPAA is not a one-time implementation. It requires continuous development, monitoring, and application. Part of it also includes conducting risk assessments to identify potential vulnerabilities and gaps within the practice to mitigate problems before a violation occurs. Many healthcare organizations also utilize HIPAA compliance software applications to streamline their efforts, some of which are simple, affordable, and very easy to implement and use.


Author Bio

Salman Rashid is an avid reader, loves writing on healthcare issues, and loves all things related to technology, especially PCs and smartphones. He’s also a Digital Marketing Analyst at RightPatient, a platform that helps enhance patient safety across hospitals. He can be contacted at salman@rightpatient.com.

Read More