Our view: a non-exhaustive pre-purchase workflow audit for healthcare reception

Answering a call is one stage of patient access. Booking, routing, callbacks, and resolution may depend on workflows that extend beyond the conversation.

An MGMA Stat poll of 216 medical-group leaders found widespread EHR and practice-management workarounds. Its accompanying article recommends auditing the workflow actually used before adding automation (MGMA). Separately, Patient Prism reports a proprietary analysis of 364,152 calls across 476 locations that divides failed bookings among connection, scheduling, service-fit, and financial barriers (Patient Prism).

Together, these sources support examining the existing workflow and distinguishing connection failures from downstream barriers. They do not evaluate automation deployments or establish how a particular system would perform.

Our non-exhaustive workflow audit

Our view is that buyers can trace a bounded set of representative calls from entry through final ownership before comparing products. This is a proposed operating framework, not a framework attributed to either source.

1. Select representative call paths

Choose a small sample that reflects the administrative work under evaluation. Non-exhaustive examples include:

• A caller requesting a new appointment.
• An existing patient rescheduling or cancelling.
• A request with no matching appointment availability.
• A request that does not fit the selected service line.
• A booking delayed by an eligibility or financial question.
• A call that enters a queue, creates a callback, or transfers to another owner.

Record the intended endpoint for each path. “Call answered” and “request recognized” are intermediate states when the intended endpoint is a completed administrative task.

2. Map the workflow actually used

For each path, follow the work across people, systems, queues, and informal steps. The audit can capture the following workflow stages and questions:

Stage	Questions to record
Entry	Where does the call arrive, and what happens if no one answers?
Identification	What information is collected, and where is it checked?
Rule application	Which scheduling, service-fit, or financial rule controls the next action?
System action	Is the request written immediately, deferred, or copied into another system?
Exception	What happens when availability, configuration, or information is missing?
Handoff	Who receives the work, through which queue, and with what context?
Callback	Who owns the return contact, and how is its status recorded?
Completion	What evidence shows that the requested administrative task finished?

The important artifact is the observed path, including spreadsheets, notes, duplicate entry, side-channel messages, and other workarounds found during the audit. The MGMA excerpt makes the narrower point that workarounds are widespread among its 216 poll respondents and recommends examining the workflow in use before adding automation (MGMA). It does not establish that every organization has the same workarounds.

3. Classify the blocking condition

Use categories that preserve operational differences instead of grouping every incomplete booking under call handling. Patient Prism’s proprietary analysis uses connection, scheduling, service-fit, and financial barriers (Patient Prism).

A local audit can start with those categories and add organization-specific subcategories. For example:

• Connection: The caller did not reach the intended workflow.
• Scheduling: No usable slot, rule, or scheduling path was available.
• Service fit: The requested service did not match the location or service line.
• Financial: A financial or eligibility-related condition interrupted completion.
• Ownership: The request entered a queue or callback process without a clear next owner.
• Configuration: The operating rule and configured system behavior did not align.
• Capacity: The workflow reached a real constraint in staff, appointment, or service availability.

The final three categories are our proposed additions. They are not categories attributed to the Patient Prism report excerpt.

4. Separate conversation capability from task completion

We propose assigning each procurement claim to a distinct level:

1. Documented capability: The product documentation describes an action.
2. Configured capability: The action is enabled for the buyer’s intended workflow.
3. Tested path: A representative scenario completes in a controlled test.
4. Observed operation: The configured path produces measured results during a bounded deployment period.

A demonstration of pickup, transcription, or intent recognition establishes only what the demonstration directly exercises. Buyers can ask for evidence covering the downstream write, exception path, queue, callback, and final owner relevant to each audited scenario.

5. Identify the constraint automation is expected to change

For every failed or delayed path, ask:

• Which step is the candidate system expected to change?
• Does it have authority to complete that step, or can it only collect information?
• Which scheduling and service rules are available to it?
• What happens when the relevant system cannot accept a write?
• Which conditions create a queue, callback, or human handoff?
• Who owns deferred work?
• How will the buyer distinguish a connection improvement from a completed booking?

The purpose of this mapping is to make any existing workaround visible before it becomes part of the proposed automated path. It also asks buyers to distinguish an entry bottleneck from capacity, configuration, service-fit, or financial barriers that may require separate operational decisions.

A bounded procurement checklist

The completed audit can become a scenario-based request for evidence. We recommend treating the following as a non-exhaustive checklist rather than a universal or sufficient pre-purchase review.

This checklist covers administrative workflow behavior only. It does not cover privacy, security, consent, call recording, data retention, or access-control review. Those areas require separate review under the buyer’s requirements.

Workflow coverage

• Which audited scenarios can the product attempt?
• Which can it complete without creating deferred work?
• Which rules remain with staff or another system?
• How are unsupported requests identified and routed?

System actions

• Where does each read or write occur?
• Is that connection documented, configured, tested, or observed for the proposed deployment?
• How are partial, duplicate, rejected, or deferred writes represented?
• What reconciliation path exists after a failed write?

Queues and callbacks

• What event creates a queue item or callback?
• Which team or role owns it?
• What context accompanies the handoff?
• What status marks the work as complete, expired, or returned?

Evaluation

• Are connection, scheduling, service-fit, and financial barriers reported separately?
• Are task attempts distinguished from completed tasks?
• Are transferred and deferred requests visible as separate outcomes?
• Does each rate include its denominator and evaluation period?
• Can the pilot compare results by representative call path rather than only in aggregate?

Human review

• Which administrative exceptions receive human review?
• How can staff correct an action or assume ownership?
• Which situations remain outside the automation’s configured scope?
• Who reviews pilot results and approves expansion to additional workflows?

This article concerns administrative workflow support. It does not evaluate clinical judgment or medical advice.

What remains unknown

The supplied excerpts do not provide the underlying records, full methodologies, organization-level distributions, or post-automation outcomes. They also do not establish that the reported barrier mix applies to a particular health system or medical practice.

A local audit is therefore evidence about that buyer’s workflow, not a substitute for broader validation. A pilot can test whether a proposed system changes the identified step while keeping materially different failure categories separate.

If the audit identifies a bounded workflow suitable for implementation and evaluation, build with Super Genius Labs.