Healthcare software projects rarely fail because somebody wrote bad code. They fail because the integration list was longer than anyone admitted, because the compliance question was answered in a sales call instead of a contract, or because the spec described a workflow nobody on the ward actually follows.

If you are weighing up a development team in Vietnam for a healthcare build, the country is not really the variable. The variable is whether the engagement is set up so those three things surface in week two rather than month seven. This is what that looks like in practice.

Compliance is a boundary, not a feature

The single most expensive misunderstanding in this field is treating compliance as something a development vendor can deliver to you. It is not. HIPAA, GDPR and Vietnam's own Decree 13/2023/ND-CP all place obligations on the organisation that holds the data — the covered entity, the controller, the processor. Your software is one of the things those obligations touch, not a substitute for them.

What a development partner can genuinely be held to is narrower and much more concrete:

  • Where the data lives and who can reach it. Which cloud region, which accounts have production access, whether any real patient data ever appears on a developer's laptop.
  • What the system records. An audit trail that answers "who looked at this record, when, and from where" is an engineering requirement with a testable definition. Ask for it in the spec, not in the brochure.
  • Encryption, in transit and at rest. Unremarkable in 2026, but still worth writing down, along with who holds the keys.
  • What happens to data in the non-production environments. This is where most of the real risk sits. A staging database restored from a production backup is the oldest mistake in the industry and it is still being made.
  • A signed agreement that reflects all of the above. If you are a US covered entity, that is a Business Associate Agreement. If you are handling EU residents' data, it is a Data Processing Agreement with the Article 28 terms in it.

A vendor who tells you their software "is HIPAA compliant" is describing something that does not exist. Software can be built so that a compliant operation is possible. The operation is yours.

The practical test

Ask any prospective team to describe how they would set up development without putting real patient data in front of a developer. A team that has done regulated work will answer immediately — synthetic data generators, de-identified extracts, a seeded test set that covers the awkward cases. A team that has not will tell you they are careful.

Integration is the long pole, every time

Ask a healthcare client what they want built and you will hear about the interface. Ask them what the system has to talk to and the room goes quiet, then somebody starts listing. The list is always longer than the first answer.

In a typical build you are looking at some combination of:

  • An EHR or HIS that exposes HL7 v2 messages — a pipe-delimited format from the late 1980s that remains the most common way clinical data moves between systems, and whose implementations differ meaningfully from site to site.
  • A newer system speaking FHIR, which is genuinely better, and which you will probably be mapping to and from HL7 v2 anyway because the other end has not moved.
  • DICOM, if imaging is involved, with file sizes that change your storage and bandwidth assumptions entirely.
  • A laboratory or pharmacy system whose vendor charges for the integration and schedules it at their convenience.
  • At least one critical process that runs on a scheduled CSV over SFTP, which somebody set up years ago and which nobody wants to touch.

None of this is exotic. All of it takes time, and most of it cannot be estimated accurately until someone has seen real message samples. This is why a fixed-price quote for a healthcare build, given before anyone has looked at the interfaces, is a guess with a number attached. It will be wrong in one of two directions, and only one of those is good for you.

If you take one thing from this: get the integration inventory out of the client's head and onto paper before anyone quotes. Every system, every direction, every format, and who owns the other end.

What a twelve-hour offset actually does

Vietnam is UTC+7. That is six hours ahead of London, twelve ahead of New York, and three behind Sydney. The honest version of what this means:

It is good for handover work and bad for debugging together. A clearly specified task handed over at the end of a European day comes back finished the next morning. A production incident at 3pm New York time is 2am in Ho Chi Minh City.

It punishes vague specifications harder than a co-located team would. When the answer to a question takes until tomorrow, ambiguity compounds. This is a real cost, and it is the main reason offshore projects run long — not skill, but the latency on every unanswered question.

Two things reduce it considerably. The first is a daily overlap window that both sides treat as fixed — typically two to four hours, which for European clients is straightforward and for US East Coast clients means an early call or a late one. The second is giving the offshore team enough context to make small decisions without asking. A team that understands why the feature exists will make the right call on the details; a team working from tickets alone will stop and wait.

For a regulated build, add one more: decide in advance who is allowed to approve a change that touches clinical workflow, and make sure that person is reachable inside the overlap window.

Structuring the first engagement

The pattern that tends to work, whoever you hire:

1. A paid discovery, scoped in weeks

Two to four weeks, with a fixed fee and a defined output: the integration inventory, a data model, the compliance obligations written down with who owns each one, a prioritised scope, and an estimate for phase one with its assumptions listed. You should own that output outright, including the right to take it to a different vendor. A team unwilling to agree to that is telling you something.

2. Phase one, deliberately small

One workflow, end to end, including the hardest integration. Not the easiest one — the hardest. The point of phase one is to find out what the work is really like while the commitment is still small. If the awkward integration is deferred to phase three, you will discover the problem after you have spent the budget.

3. Then the rest, with the estimates re-done

Estimates made before phase one are hypotheses. Estimates made after it are based on something. Any vendor who will not revise an estimate downward as well as upward after a discovery phase is not estimating, they are negotiating.

Questions worth asking any vendor

  • Walk me through how you handle patient data in development and staging.
  • Which healthcare interface standards have you implemented directly, and what broke?
  • Who owns the code, the infrastructure accounts and the documentation during the project, and after it?
  • If I ended this engagement at the end of phase one, what exactly would I have?
  • What is your daily overlap with my team, and who specifically is in it?
  • What would make you tell me this project should not go ahead?

That last one is the most useful question on the list. A team that has an answer has thought about failure. A team that cannot imagine advising against the work is selling.

Where Vietnam fits

The sensible case for building here is not that it is cheap, although the rates are lower than Western Europe or North America. It is that there is a deep pool of engineers working in a timezone that suits Asia-Pacific and Europe, with an established industry around software services and a labour market that has been doing this work for long enough that the practices are not novel.

The sensible case against is the same as anywhere else: a distributed team costs you in communication latency, and a regulated project costs you in rigour. Both are manageable. Neither is free, and anyone who tells you otherwise has not done one.

If you are at the stage of writing down your integration list and want a second opinion on which parts are genuinely hard, get in touch — that conversation is usually short and usually worth having before you ask anyone for a number.