Shipping ambient clinical documentation, HIPAA-aligned, in one quarter.

Most "AI in healthcare" stories die at the seam between the model and the workflow. The transcription works, the inference is fine, and then the note never makes it into the EHR, the specialist refuses to use it, or the compliance team kills it in pre-production review. This playbook sets out how we structure an ambient-documentation engagement so it survives that seam: the brief we push back on, the build order we follow, and the failure modes we plan around. The scenario is a composite of the briefs we see; the numbers are targets we put in writing at kickoff, not results we are claiming here.

The brief, and what we decline.

The brief usually asks for "an ambient documentation platform" with a six-month timeline and a multi-vendor RFP. We push back, hard, on two assumptions baked into it. First, that the unit of delivery is a platform. It isn't, the unit of delivery is a clinician completing a usable note in under 90 seconds, in their specialty, with their charting conventions. Second, that the right shape is a single horizontal model serving every specialty identically. It isn't, and pretending otherwise is the most common reason these deployments stall.

We come back with a different brief inside 48 hours: a 14-week production engagement, one specialty live in week six, the next wave in week ten, and the remainder in a staged rollout through weeks eleven to fourteen. Fixed scope. Fixed price for the first specialty, T&M for the rest with a capped budget.

The approach.

Integration engineers from Resource Augmentation & Managed Services go onto the integration layer in week one. The AI Solutions practice takes the model and eval work. Clinical informaticists are embedded from the client side, full-time, with veto power over every release decision. That veto is not a courtesy; it is the mechanism that keeps the build honest.

Eval-first, model-second

We refuse to discuss model selection until the eval harness is built. The harness is the deliverable. Once it exists, the model question collapses: run the candidates against the same harness, pick the one that wins on the metrics that matter (specialty-specific clinical accuracy, latency, hallucination rate on deliberately out-of-distribution prompt sets), and move on. The model becomes a swappable component.

One specialty fully shipped, before any horizontal work

The first specialty to go live should be the one led by the most skeptical clinician in the system, not the easiest workflow. If the build cannot earn that endorsement, the rollout dies at the political level regardless of the technical work. Earn it by week six and every specialty after it gets dramatically easier.

HIPAA is a column in the build plan, not a phase

BAAs in place before line one of code. PHI never leaves the client's environment. The audit trail is scoped before the eval harness and built alongside it. The compliance officer reviews the architecture at week three and signs off by week five, so the final pre-production review confirms decisions instead of discovering them.

What we hold ourselves to.

• A measurable documentation-time baseline, captured before rollout. If the improvement cannot be measured against it, we do not claim it.
• Zero tolerance on PHI exposure. The audit pipeline and access model are designed and reviewed before any clinical data flows.
• Clinician satisfaction instrumented in-app from the first cutover, with mandatory free text on dissatisfaction, because a silent clinician is not a satisfied one.
• Model spend capped at the week-one projection. The eval gate exists partly to kill the variant that would quietly double it.

Three failure modes we plan around.

The playbooks we trust are the ones that tell you where this kind of build goes wrong. Here are the three we design against.

1. The undersized operator console. Clinical informaticists need a different surface than engineers do. Built late, it becomes the bottleneck on every remaining specialty, so we scope it in parallel with the first cutover, not after it.
2. The over-engineered eval harness. The temptation is to build for specialty variations you do not yet know you need. Speculative branches turn into dead code. We build the harness for the first specialty and extend it cutover by cutover.
3. Informal training. The first weeks of adoption carry avoidable friction when "training" stays ad hoc. A short, structured cohort per specialty, run from day one, removes most go-live questions before they reach the support queue.

The engagement shape.

An engagement like this combines three Xperion practices under one MSA: Resource Augmentation & Managed Services for the integration engineering bench, Intelligent AI Solutions for the build, and Technology Consulting for the model-risk-governance work that closes the procurement review. No vendor handoffs, no separate contracts, and one named senior partner accountable from kickoff through post-launch hyper-care.

This is the part a fragmented vendor stack cannot deliver. Not because any single vendor's model is wrong, but because their operating model cannot compress the integration, governance, and clinical-workflow work into one team. Ours is built to. How we work explains why, in detail.