AI Deployment Roadmap

The common failure is not technical. It is that a pilot proves an agent works and then nothing happens, because moving from pilot to production requires decisions that nobody was assigned and evidence that nobody collected.

Three patterns account for most of it. First, no baseline: the team never measured documentation time, denial rate or call abandonment before the agent arrived, so the result is unprovable and the renewal conversation becomes a matter of opinion. Second, no owner: the agent is somebody's side project, and the first time it produces an odd output there is no route to a decision. Third, the integration was scoped as a task rather than as a dependency, so it enters a shared queue behind work that was booked months earlier.

A roadmap fixes all three on paper before any of them cost money. Baselines are defined and captured first. Owners are named, including the person who can halt the deployment. And the integration is designed and sized early enough that the queue slot can be requested rather than discovered. If you have not yet chosen a workflow at all, the earlier piece of work is the AI readiness audit, and if you have not chosen a product, it is vendor selection.

It is for organisations past the question of whether and on to the question of how. That usually means a use case is chosen, a vendor is chosen or nearly chosen, and there is a budget line. It is particularly useful where a pilot went well and then stopped moving, because a stalled pilot is almost always a sequencing or ownership problem rather than a product problem.

It is not for organisations that have not decided what to do. Sequencing work you have not chosen produces an expensive wish list. It is also not the right first step for a small practice putting an ambient scribe in front of five clinicians: that deployment is genuinely simple, the vendor's onboarding usually covers it, and the honest advice is to read the use case page, agree who reviews notes, and start. We would rather say that than sell a roadmap for a two week project.

Where it earns its fee is anywhere the deployment crosses more than one department. A prior authorization agent touches revenue cycle, clinical staff, IT and at least one payer relationship. A clinical inbox agent touches every clinician in the organisation. Those are the deployments that need a plan rather than a kick off call.

Week one, baseline and constraints. We measure or arrange the measurement of the current state for the target workflow: volumes, handling time, error and rework rates, and where the work physically sits. In parallel we collect the constraints that will shape everything else, which means your security review process, your change control calendar, your integration queue and any contractual limits in your existing EHR agreement.

Week two, integration and control design. We establish exactly what the agent needs to read and write, and through which interface. For most organisations that is a FHIR API, an HL7 v2 feed, or a vendor specific app framework, and the difference between them is weeks of calendar time. The control set is drafted at the same time, because access scope and audit logging are integration decisions, not policy decisions made afterwards.

Week three, sequencing and thresholds. We order the first three workflows and write the reasoning, then set the success thresholds and the stopping rule for the first one. This is the week that involves the most disagreement, which is the point of doing it before the pilot rather than during it.

Week four, the document and the review. The roadmap is written, then presented to the group that has to approve it, with security, clinical governance and finance in the same room. We revise it once after that meeting and hand over the final version, including the editable budget model.

The full list is above. Four parts do most of the work.

The sequence, with reasoning. Not just an order, but why that order, in terms of your constraints. An organisation with a six month EHR integration queue should almost never start with the workflow that needs the deepest integration, however attractive the business case looks.

The integration design. Named interfaces, named data elements, the access scope each one requires, and what your EHR vendor will need from you to enable it. This is the section your EHR integration team reads, and it is written so they can quote against it rather than run their own discovery.

The control set. Every control mapped to a requirement, so the compliance conversation is a review rather than a rebuild. We map to the HIPAA Security Rule and to the NIST AI Risk Management Framework, and where a state rule applies, to that as well.

The measurement plan. What you record before the agent is switched on, how often, and by whom. A baseline captured after go live is not a baseline, and this is the single most common thing missing from deployments we are asked to rescue.

CARE is the four step method we run: Chart, Architect, Run, Evaluate. The deployment roadmap is the Architect step, and it is designed to hand off cleanly in both directions.

Chart maps the workflows as they are actually run and quantifies which of them an agent could pay for. That is the readiness audit, and its ranked shortlist is the input the roadmap sequences. If you already have equivalent internal analysis, we will use yours.

Architect designs the agent, the integration and the governance as one blueprint rather than three workstreams that meet at go live. That is this engagement.

Run is the bounded pilot, executed against the thresholds and stopping rule the roadmap fixed. Most organisations run it themselves from the document, which is the intended outcome. Where staff readiness is the binding constraint, role based training is what makes Run survive contact with a busy clinic.

Evaluate measures against the baseline captured in week one and decides on the evidence: scale, fix or stop. The roadmap is what makes that decision possible, because it wrote down in advance what each answer would look like.

You can do this without us, and if you have the internal capacity you should. Four rules carry most of the value.

Order by constraint, not by benefit. Rank candidate workflows on the longest dependency rather than the largest saving. If the highest value workflow needs a write back interface that your EHR vendor schedules quarterly, it is not the first project, it is the third. Starting with a smaller workflow that needs only read access buys you a live agent, a real measurement and organisational confidence while the larger integration is queued.

Make the first project small enough to finish in one quarter. A project that spans two budget cycles or two reorganisations rarely survives either. The purpose of the first deployment is not the saving, it is proving the pathway from idea to production works in your organisation.

Separate the pilot decision from the procurement decision. Sign a pilot with a defined end date and an exit, not a three year agreement with a pilot period inside it. Vendors will resist this and some will refuse, which is itself useful information.

Write the stopping rule before you start. One sentence: if the agent does not reach this threshold on this metric by this date, we stop. Written after the fact, it is a post mortem. Written in advance, it is the cheapest piece of governance available, and it is what lets a clinical sponsor back a project they are unsure about.

A workable sequencing table looks like this.

Longer than the vendor demo implies, and the variance is mostly on your side rather than theirs. The honest planning answer is that the software connection is rarely the long pole. The long poles are your security review, your integration team's queue, and the legal work on data access.

Three things reliably shorten it. First, ask for read only access in the first phase wherever the workflow allows it, because a read only scope moves through a security review materially faster than a write back scope and can often be approved by a smaller group. Second, get the interface question answered before you sign anything: whether the vendor connects through a modern FHIR API, an HL7 v2 feed, an app framework specific to your EHR, or a screen level workaround, because the last of those has ongoing costs that never appear in a licence quote. Third, book the queue slot on the strength of the design rather than waiting for a signed contract, since the queue is usually the binding constraint and a design document is enough to hold a place.

Ask your vendor for a named reference at an organisation running your EHR, at your scale, in production rather than in pilot. A vendor that publicly claims an integration and cannot produce that reference has an integration that exists on a roadmap. The EHR pages on this site set out what each major platform actually exposes, and the comparison pages record what we could and could not verify for each vendor.

One more planning note. Certified health IT is subject to the ONC certification programme and to the information blocking rules, and a vendor that responds to an interface request with an unexplained refusal is worth raising with your legal team rather than accepting. That is not a threat to make casually, but knowing the rule exists changes the tone of the conversation.

The engagement is a fixed fee, stated in a written proposal before any work starts, and scaled to the size of the organisation rather than billed by the hour. A five clinician practice and a four hospital system need different amounts of work and should not pay the same figure. The strategy call that produces the proposal is free, and a proposal that recommends a smaller piece of work than you asked for is a normal outcome.

We take no vendor commissions, no referral fees and no paid placements, and we resell nothing. That is a description of the business model rather than a claim to virtue, and it is the only reason the roadmap can conclude that the workflow you were most excited about should go third.

After handover there is no implementation obligation. Many organisations execute the roadmap entirely with their own team, which is a good result and we will say so. Where you want continued involvement, the usual shapes are a governance framework built alongside the rollout, covered by AI governance and compliance, or role based enablement covered by staff training. If you want to sanity check the numbers behind a candidate workflow first, the prior authorization cost calculator and the readiness assessment both run on your own inputs with the assumptions printed on the page.