Home / Insights
Before Automating Patient Access: A Workflow Baseline for Healthcare AI Pilots
Build a healthcare AI patient-access pilot on a workflow baseline that tracks handoffs, exceptions, rework, human review, limits and accountable decisions.
Before Automating Patient Access: A Workflow Baseline for Healthcare AI Pilots Patient access teams are being offered a growing range of automation and AI capabilities: appointment routing, referral triage, scheduling support, eligibility workflows, intake summaries, contact centre assistance and follow up prompts. A compelling demonstration can make the future state look obvious. The difficult work is understanding the current state well enough to know whether a pilot has improved the operation—or simply moved its failure points. A workflow baseline is the factual description of how work currently arrives, is classified, moves between people and systems, becomes an exception, and reaches a resolution. It is not a vendor scorecard, a promise of savings, or a substitute for clinical, privacy, security or legal review. It is the starting record that lets a practice measure a specific pilot without losing the context in which the results occurred. The NIST AI Risk Management Framework is voluntary and is designed to help organisations incorporate trustworthiness considerations into the design, development, use and evaluation of AI systems. Its lifecycle perspective is useful here: first make the intended use, setting, users, assumptions and limits visible; then decide what evidence and controls are proportionate to the workflow. Why a patient access pilot needs a baseline Access work is rarely one queue. A patient may begin on a website, in a call centre, through a referral, after a portal message, at a front desk or through a payer related workflow. The same request may move through an EHR, scheduling system, CRM, referral platform, phone system, work queue and spreadsheet. The visible appointment is only one outcome of a broader operating path. Without a baseline, teams can mistake speed in one part of that path for improvement across the whole operation. For example: an assistant may route more calls quickly but create more manual corrections downstream; a scheduling tool may shorten a queue while increasing the number of exceptions that staff handle outside the tool; an intake summary may appear complete while omitting the source, uncertainty or escalation context a reviewer needs; or a workflow may work for routine appointments but perform poorly for language needs, complex referrals, insurance questions, urgent symptoms or incomplete records. A baseline creates a common picture for clinical leadership, business operations and technology teams. It gives the organisation a way to define what the tool is meant to support, what it must not decide, who remains accountable for review, and what would cause the team to pause or change the pilot. Eunoia recommendation: Do not start with “Which capability can we switch on?” Start with “Which repeatable access problem are we trying to understand, and what evidence would tell us the pilot helped without creating an unsafe or hidden workload?” Define one narrow operational question The first pilot question should be small enough to evaluate. Avoid a broad objective such as “use AI to improve patient access.” Instead, identify one population, request type and workflow stage. A useful pilot statement might contain five parts: 1. Request type: Which requests are in scope? New patient appointment requests, referral completeness checks, appointment reminders or scheduling requests for an established service line are different problems. 2. Operating setting: Which sites, locations, service lines, channels and hours are included? 3. Proposed support: What does the system do? It may classify, draft, summarise, route, flag missing information or present options. State plainly whether it can take any action automatically. 4. Human role: Who reviews, corrects, overrides or escalates the output? What is the fallback when the system is unavailable or uncertain? 5. Exclusions: What is outside scope? Emergency symptoms, clinical triage, eligibility determinations, financially consequential decisions, minors, certain payer rules or other locally defined scenarios may require a different path. This statement is not paperwork for its own sake. It establishes the boundary that makes a later result interpretable. If the system is later used in a different channel or for a different request type, the team can recognise that the operating context changed instead of treating an expansion as routine. Map the current path, including the detours A workflow map should reflect the work people actually do, not the ideal sequence in a policy document. Begin with a walk through involving staff who receive requests and the people who resolve the difficult cases. Ask them to describe a recent routine request and a recent exception from beginning to end. At minimum, capture: Entry points: phone, portal, web form, referral, fax, in person request or another channel; data received: what arrives, what is missing, where it is stored and what must be verified; handoffs: roles, queues, time of day transitions, external teams and system boundaries; decisions: which rules are applied, who makes the decision and where discretion is used; exceptions: incomplete information, duplicate records, language access, conflicting appointment rules, payer requirements, urgent requests, no availability and system downtime; outputs: appointment, callback, request for information, escalation, referral routing, closed request or another defined outcome; and rework: corrections, transfers, repeated contacts, overrides, manual data entry and work that happens outside the primary system. A simple swim lane map can be enough. The important outcome is not a beautiful diagram; it is a shared account of where a tool would be introduced and where staff would need to notice an incorrect, incomplete or ambiguous result. Establish a measurement set that supports decisions Metrics should describe both operations and controls. A pilot that tracks only volume or speed can hide the costs transferred to a different role. The baseline does not need dozens of measures. Select a small set that helps the accountable owner decide whether to continue, adjust, pause or broaden the test. Operational measures For the defined workflow, establish a reasonable current range for measures such as: time from request receipt to a defined next action; time to final resolution or appointment outcome; queue ageing and backlog by request type; first contact resolution, where a clear definition exists; transfer, callback and repeat contact patterns; the percentage of requests needing manual correction or rework; and staff reported friction points in the current process. Do not treat a single week as a universal baseline. Access operations vary with staffing, seasonality, payer activity, clinic schedules and local events. Record the period observed and note factors likely to distort the comparison. Control and quality measures The pilot also needs evidence about whether it stays within its intended support role. Consider tracking: output categories that require correction, override or escalation; the reason for a correction when staff can record it efficiently; requests that could not be processed because information was missing, conflicting or outside scope; system availability, latency and fallback use; whether the system surfaced enough context for an accountable reviewer to act; feedback from staff and, where appropriate, the experience of people receiving access support; and unexpected uses, workarounds or attempts to apply the tool beyond the agreed workflow. The goal is not to demand perfect accuracy from a complex real world workflow. It is to avoid vague claims such as “the pilot worked” when the team cannot explain the kinds of requests handled well, the cases that required human correction, and the remaining limitations. Design the human review and fallback path before launch Automation has an operating consequence even when it only drafts or routes information. A team should decide how humans remain in the loop for the type of output at issue. For each in scope request, document: when a staff member must review before an action is taken; which signals require escalation to a named role or existing operational process; how staff can override or correct an output without creating a hidden parallel process; how the correction is recorded for a later review; the manual or pre existing fallback when the tool is unavailable, produces an uncertain result or encounters an excluded scenario; and how users will recognise that an output is advisory rather than authoritative, where that distinction matters. The NIST Generative AI Profile highlights documentation of intended purposes, settings, users, assumptions and limitations, and describes governance tools such as human review, monitoring, incident response and change management controls. A patient access pilot can apply those ideas proportionately without presenting a framework as a certification. Create a short pilot decision record A one page record can keep the pilot grounded. Link it to the workflow map and define: | Field | Decision ready question | | | | | Pilot purpose | What specific operational question is being tested? | | Scope | Which sites, channels, request types, users and systems are included? | | Out of scope | What must be routed to existing staff or escalation processes? | | Accountability | Who owns operations, technology, clinical input and the final continue/pause decision? | | Baseline | Which period, measures and known constraints describe the current process? | | Guardrails | What human review, fallback, correction and escalation steps apply? | | Evidence cadence | When will the team review operational and quality signals? | | Stop or pause conditions | What pattern, incident or missing evidence requires a pause? | Use language that reflects uncertainty honestly. If a data source, system rule or operating metric is unknown, record it as unknown and assign a follow up. A baseline should expose evidence gaps rather than smoothing them over. Run the pilot in stages A staged rollout makes it easier to see what changed. A practical sequence can be: 1. Observation: Run the existing workflow and validate the baseline with the people doing the work. 2. Parallel review: Let the tool produce its proposed classification, draft or route while staff continue the established process. Compare outcomes for a defined sample. 3. Limited live support: Use the capability for one narrow request type with the agreed human review and fallback process. 4. Review and decision: Compare the evidence with the baseline, review exceptions and decide whether to continue unchanged, modify the controls, gather more evidence, expand carefully or pause. Document what changed between stages. A new integration, altered routing rule, expanded user group or vendor update may change the meaning of results. The organisation’s healthcare AI change log can be used to connect those events to the pilot record. Questions to take into the first review meeting A short operating review is more useful when it asks questions that can result in action: Did the tool remain within the intended workflow and support role? What did staff correct, override, escalate or route around—and why? Did any queue, handoff or rework pattern change in a way the headline measure would miss? Did the pilot introduce a reliance on a data source, integration or vendor behaviour that needs a control? Are the known limitations, user instructions and fallback path still accurate? What evidence is insufficient to support the next decision? Is there a defined owner for each follow up, and is a pause needed before expansion? The answers should become operational work, not a retrospective presentation. The point of a baseline is to support accountable decisions while the pilot is small enough to correct. Build the foundation before the feature set expands Eunoia Consulting Co. helps healthcare organisations translate AI opportunities into practical workflow baselines, decision records, governance controls, monitoring and change management routines. If your team is assessing a patient access automation opportunity, explore Eunoia’s healthcare operations advisory services or contact the team to discuss a structured, decision ready pilot approach. This is advisory support for internal operating readiness, not clinical, legal, privacy, security or regulatory advice. Sources NIST — AI Risk Management Framework NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile ASTP/ONC — HTI 1 Final Rule This article was produced by the Eunoia Consulting Co. Editorial Team. Eunoia Consulting Co. specialises in AI governance, healthcare operations, and data strategy for healthcare and veterinary organisations.