How a Remote or Offshore Team Handles PHI Properly

Two questions get merged into one and the merge causes most of the confusion. "Is offshore allowed?" is a contract question. "Is this team handling PHI properly?" is a controls question. The answers are independent, and a delivery model is only sound when both are answered separately and in writing.

What HIPAA actually says about location

Nothing. There is no data-residency requirement in either the Privacy Rule or the Security Rule. The rules apply to protected health information wherever it is created, received, maintained, transmitted or accessed, and a workforce member in another country is subject to the same obligations as one in Ohio.

That is the accurate legal statement, and it is also incomplete, because it describes only the federal floor. What constrains most healthcare work is the contract sitting above that floor.

What contracts say, which is where the real gate is

Medicare Advantage and Part D. CMS requires sponsors using offshore subcontractors that handle Medicare beneficiary protected health information to report them in the HPMS Offshore Subcontractor Data module within 30 calendar days of signing a new offshore contract, and to complete an annual attestation. Offshore means physically located outside the United States and its territories, and the territories named are American Samoa, Guam, the Northern Mariana Islands, Puerto Rico and the US Virgin Islands. The attestation covers the subcontractor's name and functions, a description of the PHI provided, the safeguards adopted, and audit requirements. See the CMS guidance on the HPMS offshore module.

State Medicaid. CMS has no equivalent preemptive Medicaid policy, so states set their own terms in contract, and several prohibit offshore access outright. Texas Uniform Managed Care Contract terms prohibit performing work or maintaining information outside the United States and bar remote offshore access to state health and human services systems or data. Arizona requires services involving secure, sensitive or personal client data to be performed within US borders. Mississippi's Medicaid BAAs prohibit PHI moving beyond US jurisdiction without express authorization. Georgia prohibits suppliers from providing services from offshore locations.

Since NEMT is overwhelmingly a Medicaid benefit resting on 42 CFR 440.170(a), this is a live commercial gate rather than a theoretical one. It is also state specific, changes with contract cycles, and deserves counsel review against the actual contract rather than a summary. The practical consequence for a provider evaluating a BPO is simple: ask where the work is performed, function by function, and get it in writing.

The federal answer and the contractual answer point in different directions. HIPAA permits offshore handling of PHI. Your Medicaid contract may prohibit it. The vendor's job is to tell you which functions run where before you find out from your state.

The visibility problem, documented

The most useful federal finding on outsourcing chains is GAO-06-676, published in September 2006. It found that 57 percent of Medicare Advantage contractors didn't know whether their domestic vendors further transferred PHI offshore, along with 29 percent of Medicare fee-for-service contractors and 26 percent of state Medicaid agencies. Over 40 percent of surveyed organizations had experienced a privacy breach within two years.

The report is two decades old and its numbers shouldn't be quoted as current. The structural point survives: outsourcing chains go dark past the first tier unless somebody asks for the list. HIPAA anticipates this at 45 CFR 164.308(b)(2), which requires a business associate to obtain satisfactory assurances from its own subcontractors, and at 164.314(a)(2)(i)(B), which carries it into the contract.

Access control: named accounts and least privilege

Unique user identification at 45 CFR 164.312(a)(2)(i) is a required implementation specification. Not addressable. Every agent gets a named account, always, and shared team logins are a compliance failure before they are anything else, because they remove the identity that every log entry depends on.

Least privilege then does the rest of the work, anchored in the information access management standard at 164.308(a)(4) and the minimum necessary standard at 164.502(b) and 164.514(d):

• Scope by client. An agent assigned to one contract shouldn't be able to load another contract's queue. In a multi-client operation this is the control with the largest blast radius attached to it.
• Scope by function. Dispatch and billing need different fields. Granting both to everyone is convenient and expensive.
• Grant per assignment, remove at reassignment. Access that accumulates across a career is the normal failure mode and it is invisible until an audit.
• Control export. Most spread happens through a file someone pulled to work faster.

Multi-factor authentication

MFA today is reached through the person or entity authentication standard at 164.312(d), which is a required standard, rather than being named explicitly in the rule text. It is also an Essential goal in the voluntary HHS Healthcare and Public Health Cybersecurity Performance Goals published in January 2024 with CISA.

The January 2025 proposed Security Rule update would make MFA an explicit mandate and add a definition at 45 CFR 164.304. That rule isn't in force, HHS has projected July 2027 for final action, and no vendor should describe it as a current requirement. The correct framing is that MFA is expected practice now and likely to be mandatory later, so put it on everything that reaches PHI, including the client platforms agents log into rather than only the vendor's own email.

Devices, storage and the physical desk

Workstation use and security are at 164.310(b) and (c), and device and media controls including disposal are at 164.310(d). For a remote team the specifics matter more than the policy, because there is no shared floor enforcing habits by default.

• Managed devices only, with full-disk encryption and enforced screen lock. Automatic logoff is addressable at 164.312(a)(2)(iii) and there is no good reason to skip it.
• No personal machines touching PHI, and no removable media.
• No local storage. Work happens in the client platform; nothing lands on the endpoint.
• Controls on copy, print and screenshot, since a screenshot is the fastest way to create an unmanaged copy of a manifest.
• A private workspace, not a shared room. Clean desk, no paper, no personal phones or cameras at the desk. For home-based agents this needs to be a stated condition of the role, checked, rather than an assumption.

Logging, and the review that gets skipped

Two requirements are commonly collapsed into one, and the second is the one that matters.

Audit controls at 164.312(b) are a required standard: record and examine activity in systems containing ePHI. Information system activity review at 164.308(a)(1)(ii)(D) is a separate required implementation specification: regularly review records of information system activity such as audit logs, access reports and security incident tracking reports.

Logging is a purchase. Reviewing is a habit, and it is the half that quietly doesn't happen. A remote operation should be able to say who reviews, on what cadence, what triggers a look, and give an example of something a review actually caught. If nothing has ever been caught, nobody is looking.

Screen recording creates a second PHI repository

Screen and call recording is widespread in BPO delivery and defensible as an audit and workforce-security measure under the same requirements above. It also has a consequence that is easy to miss: a recording of a screen displaying PHI is ePHI.

That means the recordings need the same encryption, the same access control, the same retention limit and the same disposal discipline as the source system, plus documentation under 164.316, which requires policies to be retained six years and reviewed as the environment changes. A vendor that records screens and can't say where those recordings live, who can view them and how long they are kept has moved risk into a less-governed system rather than reducing it. Being specific about this is a genuine differentiator, because most vendors aren't.

Screening, training, sanctions and offboarding

The workforce security standard at 164.308(a)(3) covers authorization and supervision, workforce clearance and termination procedures, all addressable. Security awareness and training is at 164.308(a)(5). The sanction policy at 164.308(a)(1)(ii)(C) is required.

For a distributed team the two that carry the most weight are training before access and offboarding on the same day.

• Training before first access, not in the first month. An agent shouldn't be able to reach PHI before the training record exists.
• Phishing simulation and refreshers, because the threat that reaches a remote agent arrives by message, not by the front door.
• A sanction policy that has been used. One that never has is one nobody enforces.
• Same-day offboarding across every system, including client platforms, VPN, chat, ticketing and the recording store. Offboarding that runs on a weekly batch leaves a window measured in days, and departures are exactly when the window matters.
• An access inventory per person, so offboarding is a checklist rather than a memory exercise.

The control map

Note the "addressable" column carefully, because it is widely misread. Addressable doesn't mean optional. 45 CFR 164.306(d) requires an entity to assess whether the specification is reasonable and appropriate, and if it decides not to implement it, to document why and implement an equivalent alternative where reasonable. Skipping an addressable specification without that written analysis isn't compliance with a flexible rule. It is a gap with no paperwork behind it.

How we run it

SS Support Network is a US-registered company in Vancouver, Washington, operating with a 24/7 global delivery team. We say that plainly rather than implying a footprint we don't have, because where the work happens is exactly the thing a Medicaid contract may constrain, and a client should be able to check it against their own contract before signing anything.

The controls we run to: HIPAA training before an agent touches client work, role-based and logged access, and a Business Associate Agreement signed with every healthcare client before any PHI is handled. Our incident process is written down: contain, assess scope, notify your designated contact promptly, support the notification timeline your BAA requires, and never conceal an incident. Automation is disclosed, never makes clinical decisions, and PHI isn't fed into third-party AI tools without your written approval and a compliant data path.

The structural decision that matters most is that we work inside your systems rather than copying your data into a parallel platform of our own. For a distributed team that single choice removes an entire class of problems: there is no second database to secure, no export to govern, and no vendor-side copy to return or destroy at the end of a contract.

We hold no SOC 2 and no HIPAA certification, because no HIPAA certification exists, and our trust center says so. We will complete a reasonable security questionnaire as part of your due diligence, which is the kind of proof you can verify. For the contract side of this conversation, our walkthrough of what a BAA actually obligates covers the clauses, and the vendor question list covers what to ask everyone else.

Frequently asked questions