The short answer is usually yes, with conditions — and occasionally no, in ways that depend on which state your patients are in rather than on anything about the vendor.

The longer answer is worth reading before you sign anything, because the rules distribute risk unevenly. In most of the arrangements below, if something goes wrong, the consequences land on you rather than on the team you hired. That asymmetry is the single most important thing to understand, and it is rarely mentioned in a proposal.

This is a practical guide, not legal advice. On anything consequential, ask a lawyer licensed where your patients are.

What HIPAA actually says

HIPAA does not prohibit protected health information from being accessed or stored outside the United States. There is no geographic restriction in the rule itself. What it requires is that the covered entity complies with HIPAA as a whole, which in practice means three things when a vendor is involved:

  • A signed business associate agreement that meets the regulatory requirements.
  • Reasonable and appropriate administrative, physical and technical safeguards.
  • Access limited to the minimum necessary for the work.

Those obligations are the same whether the vendor is in Ohio or Ho Chi Minh City. The HITECH Act made business associates directly liable for their own violations, so on paper an offshore vendor carries real exposure.

In practice, that liability is weaker than it looks, and this is the part to pay attention to. US regulators' ability to pursue an entity outside their jurisdiction is limited. If there is a breach, the covered entity is the one that handles notification, remediation and the regulatory response, and the one whose name appears in the enforcement record. An indemnity clause against a company with no US presence and no US assets is a sentence, not a remedy.

What follows from that is not "do not offshore". It is that verifiable technical controls matter more than contractual promises, because the controls are what actually prevent the event, and the contract is what you are left with afterwards.

Where the answer is genuinely no

Federal law permits it. Several states and programmes do not, and these restrictions are specific enough that you can check them in an afternoon.

  • Florida. State law restricts certain Florida-licensed providers using certified EHR technology from storing qualified electronic health records outside the United States, its territories or Canada. Vietnam is not Canada. If this applies to you, it is a hard stop for data storage, though not necessarily for every kind of development work.
  • Texas. The state's Uniform Managed Care Contract prohibits work being performed or information being maintained outside the US, and bars remote offshore access to Texas Health and Human Services systems and data.
  • Ohio. Executive orders bar executive agencies from contracting for services performed outside the US, and extend that to subcontractors.
  • Medicaid. Section 6505 of the Affordable Care Act prohibits Medicaid payment for items or services furnished outside the United States. CMS has indicated this is aimed at benefits and services rather than administrative support, but several states apply their own stricter rules on top, and some require prior approval or an attestation.
  • Medicare Advantage and Part D. CMS has not banned offshoring, but plans must attest to offshore subcontractors handling beneficiary information, and those duties typically flow down to providers through contracts.

The practical step: before you scope the project, establish which programmes your patients are covered by and what your own payer contracts say. Payer contracts are frequently stricter than state law and are the thing most often missed, because nobody rereads them when commissioning software.

If your patients are in the EU

Different framework, same shape. Your development vendor is a processor, which means a written contract meeting the Article 28 requirements, and a lawful transfer mechanism for sending personal data outside the EEA. Health data is a special category under Article 9, with a higher bar for processing in the first place.

There is no EU adequacy decision covering Vietnam, so transfers rest on standard contractual clauses plus a transfer impact assessment. This is ordinary, well-trodden work — thousands of European companies use non-adequate countries — but it is work somebody has to do, and it should appear in the project plan rather than being discovered at go-live.

If your patients are in Vietnam

Vietnam's Law on Personal Data Protection (Law No. 91/2025/QH15) took effect on 1 January 2026, superseding the 2023 decree that most published material still cites. It is modelled on the GDPR with meaningful local differences.

Three that matter here. Consent is the dominant lawful basis and must be explicit, specific and easily withdrawn — the broad "legitimate interest" balancing test familiar from the GDPR is drawn far more tightly. Cross-border transfers require a Cross-Border Transfer Impact Assessment filed with the Ministry of Public Security within sixty days of the transfer beginning; it is not an approval you wait for, but it is a document that must exist. And there is a data protection officer requirement, with a five-year deferral for smaller companies that does not apply where sensitive data is involved — health status is sensitive, so if you are processing it in Vietnam, assume the deferral is not available to you.

Enforcement includes fines that can reach a percentage of prior-year revenue for cross-border transfer violations. This is a young law and practice is still settling, which is itself a reason to document decisions carefully.

The question almost nobody asks

Does the development team need real patient data at all?

Most of the time, no — and this is the most useful paragraph in this article. Building and testing software requires data with the right shape: realistic names, plausible dates, the awkward edge cases, the volume. It does not require data belonging to real people. A properly constructed synthetic dataset gives engineers everything they need and removes the entire problem, along with most of the contract negotiation and all of the breach exposure.

Three arrangements, in descending order of how much you should like them:

  1. Synthetic data only. The vendor never touches real records. Generating a good synthetic set costs a few days of work and is frequently cheaper than the compliance effort it replaces.
  2. De-identified data. Real structure, identifiers removed to a defined standard. Better than production data, but de-identification is harder than it looks and re-identification risk is real in small populations — a rare diagnosis in a small town is identifying regardless of whether a name is attached.
  3. Production access, tightly scoped. Sometimes genuinely necessary — a data migration, or debugging a problem that only appears in real records. When it is, it should be time-limited, logged, to named individuals, through your environment rather than theirs, with no local copies.

That third arrangement is where the heavy compliance machinery is needed. Keeping as much work as possible in the first two is the cheapest risk control available to you — and, because it removes most of the compliance effort, one of the larger levers on what the project costs, and a vendor who proposes it unprompted is telling you something good about how they work.

What belongs in the contract

Beyond a compliant BAA or Article 28 terms:

  • Named individuals. Access granted to people, not to a company. A list you receive and that changes only with notice.
  • Subcontractor restrictions. No onward disclosure without written consent. Offshore vendors subcontract more often than clients expect, and a flow-down clause is the only thing standing between you and a party you have never heard of.
  • Where the data physically sits, named by provider and region, with a requirement to notify before it changes.
  • Breach notification in hours, not days, with your own regulatory clock in mind — yours starts whether or not they have told you.
  • Audit and inspection rights that you can realistically exercise, which usually means an annual review and evidence of controls rather than a right to fly to Vietnam.
  • Return and destruction on termination, with written certification.
  • Encryption in transit and at rest, stated as a requirement rather than left as an assumption.
  • Access logging you can read, not only logging that exists.

Then — and this is the part that is routinely skipped — verify some of it. Ask for evidence that the access logs exist and that somebody looks at them. A control nobody has checked is a sentence in a document.

Five questions for the vendor

  1. Have you signed a BAA before, and will you sign ours as written?
  2. Can this project be done with synthetic or de-identified data, and if not, exactly which parts need production access and why?
  3. Who, by name, would have access, and how do you remove it when somebody leaves?
  4. Where would the data be stored and processed, and does any of it leave that region?
  5. Do you subcontract any part of this work?

Reluctance on the first is disqualifying. A good answer to the second is the strongest signal on the list — it means they have thought about your exposure rather than about the scope of their engagement.

Our position on this

We are a Vietnamese company and we would be one of the vendors you are assessing, so take the following as our stated practice rather than as neutral advice.

We prefer to work with synthetic or de-identified data and will propose it wherever the work allows. Where production access is genuinely required, we expect it to be scoped, logged and time-limited, and we will sign a BAA or Article 28 terms. We do not hold a HIPAA certification, because no such thing exists — HIPAA has no certifying body, and any vendor presenting a "HIPAA certificate" is presenting a training record or a consultant's opinion. What we can give you is a documented description of how access is controlled on a given project, which is the thing an auditor would actually want to see.

If you are working out whether your project can be done offshore at all, email us with where your patients are and what the software has to do. If the answer is that it cannot, we would rather say so now than three months in.