Forward deployed engineering in healthcare

Healthcare is the third largest segment for this work and the one where the deployment constraints are least negotiable.

The two constraints

The data cannot leave. Patient data is regulated in ways that usually prevent it being copied to a vendor's environment for development. That inverts the normal arrangement: instead of the vendor's tooling processing the customer's data, the work happens inside the customer's infrastructure under their controls.

The workflow cannot stop. A clinical process runs continuously and the consequences of interrupting it are not commercial. There is no maintenance window in the sense most software teams mean, and a deployment that requires everybody to pause is not a deployment anybody will approve.

Among 1,000 postings naming a target industry, healthcare was 17 percent. Our healthcare software compliance guide covers the regulatory requirements; this page is about what they do to an engagement.

What "the data cannot leave" changes in practice

Development happens inside. Their infrastructure, their access controls, their approval for every tool. Which means the toolchain question comes before the engineering question, and the answer is often that a tool the team relies on is unavailable.

The substitute for real data has to be agreed on day one. Synthetic data, a de-identified subset, or a controlled enclave. All three are workable and all three differ from production in ways that matter, so the agreement has to include what the substitute does not represent.

The failure here is discovering in week five that the de-identified set removed the exact field the model needed, or that the synthetic data has none of the messiness that breaks the parser. Agreeing the substitute is a day-one conversation, and it should include a plan for a supervised run against real data before production. The first two weeks covers the setup.

If a model is involved, where it runs is a governance decision. A hosted model call may not be permitted, which changes which models are viable and therefore what the system can promise. Decide this before designing around a capability you cannot use.

What "the workflow cannot stop" changes

Parallel running becomes the default shape. The new system runs alongside the existing process, producing outputs nobody acts on, until its behaviour has been compared against the current one for long enough to trust. Then it takes over gradually rather than at a cutover.

This is slower and it is the only approach that gets approved, and it has a genuine benefit: the parallel period is the best evaluation data anybody will ever get, because it is the real distribution rather than a test set.

Rollback has to be immediate and rehearsed. Not a plan in a document. A tested path that a person on shift can trigger without calling anybody. Our post on what a rollback plan looks like for AI-written features covers the shape.

Deployment windows are set by the service, not by engineering. Which is knowable in week one if somebody asks.

The third constraint nobody puts in the contract

Clinicians will not use a system that adds steps.

This is the one that kills otherwise good deployments. A model with excellent accuracy, presented in a separate application requiring a separate login, will not be used during a shift. The integration point matters more than the model quality, and the only way to know where that point is involves watching the work happen.

What that means for discovery. Sitting with the people doing the work, watching where their hands and attention actually go, and finding the moment where information would change a decision. That is not a requirements interview. Discovery inside the customer environment covers the method.

And the escalation path is clinical. What happens when the system is unsure, who is told, what they see, and what their authority is to overrule it. Those are clinical governance questions with engineering consequences, and they have to be answered by the organization rather than proposed by a vendor. Deciding if a feature needs a human in the loop covers the general judgment.

What tends to go wrong

The pilot ran in a research environment. It works there and cannot be moved into the clinical environment without a rebuild, because the research environment had different data access, different tooling and no uptime requirement.

The de-identified data removed what mattered. Discovered late, and expensive because the preceding weeks were spent building against a shape that does not exist.

No named clinical owner. Somebody has to be accountable for whether this is safe to use, and that person is not the CIO. Without them, the deployment stalls at the last approval.

Integration into a separate application. Correct, unused, and switched off after a quarter.

The verification requirement

A system that influences clinical decisions needs evidence, and the evidence needs to survive the system being changed.

Generated code is not secure by default, so the checks proving behaviour have to be derived from the requirement rather than from the code, and graded by something other than the model that wrote it. That is eval-driven development, and in this sector it is also the artefact that lets the organization change the system later without redoing the whole assurance exercise.

Which makes it the handover deliverable that matters. A clinical team inheriting a system needs to be able to modify it and re-evidence it, and a document describing the architecture does not let them do that. Handover and exit covers the test.

Related: regulated industry software for the cross-sector view.