By Feynman Xu, Ph.D., Founder and CEO, MedArise
LinkedIn: Feynman Xu, Ph.D.
LinkedIn: MedArise
Independent medical practices are being asked to evaluate AI while already managing staffing gaps, payer friction, document backlogs, and patient access demands. The temptation is to start with a product demonstration. A safer and more useful starting point is the workflow itself. Before adding AI, a practice should test whether the work is defined well enough to improve without creating a new layer of supervision.
The following five questions form a practical readiness test. A workflow that fails one of them may still benefit from technology, but the practice should repair the operating model before expecting automation to create capacity.
1. Can the practice name the queue?
A workflow needs a clear entry point and a bounded class of work. “Help with referrals” is not a queue. “Process inbound referral documents from the fax inbox for one location” is closer. The practice should be able to name the trigger, required inputs, approved systems, completion state, and time expectation. If staff describe the work differently, AI will inherit that ambiguity.
2. Is there one source of truth?
Administrative work often spans an EHR, payer portal, fax service, shared mailbox, spreadsheet, and phone queue. The practice must decide which system controls each fact and where the final status is recorded. Otherwise, automation can move faster while leaving conflicting records behind. A useful design names the authoritative source for patient identity, eligibility, authorization status, scheduling, and documentation.
3. Who owns exceptions?
Routine cases are rarely the main burden. Missing demographics, duplicate charts, failed portal access, unclear orders, payer discrepancies, and unreachable contacts create the work that accumulates. The practice should separate recoverable administrative exceptions from decisions requiring clinical judgment, coding interpretation, financial authority, patient consent, or practice policy. It should then assign each exception to a person or role with a response expectation.
4. What is the authority boundary?
Access to information is not permission to decide. A system may be allowed to retrieve records, prepare a packet, place an approved call, update an administrative status, or route a case. That does not automatically authorize it to make a clinical determination, change a code, accept a financial term, or speak for a patient. The authority map should be written before deployment and reflected in permissions, approvals, and escalation paths.
5. Can the practice prove completion?
Activity is not the same as an outcome. Messages generated, calls attempted, and screens opened do not show that work finished correctly. The practice should define the evidence for each completion state, such as a recorded payer reference number, a document stored in the approved location, a scheduled appointment, or a case routed with the required context. The scorecard should track completed cases, turnaround time, backlog age, rework, unresolved exceptions, and staff interventions.
Start with one narrow test
A readiness review should end with a limited pilot, not a systemwide rollout. Select one location, payer group, document class, call type, or aging segment. Capture the starting backlog and staff effort. Include normal cases and known failure modes. Keep a human review path for decisions outside the approved boundary.
This approach aligns with the emphasis on governed, measurable use in the NIST AI Risk Management Framework and with the U.S. Department of Health and Human Services guidance on risk analysis and safeguards for electronic protected health information. The goal is not to automate every step. It is to create reliable capacity without giving up clear human authority.