The director of pharmacy at a midsize health system sat across from her chief compliance officer, who had just forwarded an email from the system's largest specialty contract. Buried in the renewal terms was a new line: by the next cycle, network pharmacies handling AI-assisted prior authorization would be expected to demonstrate accreditation against the URAC (Utilization Review Accreditation Commission) Health Care AI Accreditation user track. The director had been telling everyone for a year that her team used AI "responsibly." She had a prior-authorization workflow that had collapsed turnaround from roughly 25 minutes to about 5 minutes per request, a verification step her pharmacists swore by, and a sense that her people were careful. What she did not have was a program: a written, governed, evidence-producing thing she could hand to a reviewer and say "here is how we use AI, here is who is accountable, here is the proof it works." She had a practice. She needed a program. This lesson is about exactly that distance, the gap between using AI well and running a URAC user-track program, and how a pharmacy leader closes it deliberately, before a contract forces the issue under pressure.

From a Practice to a Program

The single most important mental shift for a pharmacy leader operationalizing the URAC AI user track is the move from practice to program. A practice is what individuals do: the careful pharmacist who verifies every AI-assembled prior authorization (PA) criterion against the chart, the technician who knows the pharmacist owns the clinical call, the manager who quietly insists nobody rubber-stamps an AI suggestion. Practices are real and valuable, and a pharmacy full of good practices is a safer pharmacy than one without them. But a practice has three fatal weaknesses from an accreditation standpoint: it lives in people's heads rather than in writing, it varies from person to person and shift to shift, and it leaves no durable evidence that it happened. A practice cannot be shown to a reviewer, cannot be guaranteed to be consistent, and cannot survive the departure of the people who carry it.

A program fixes all three. A program is the same good behavior, but written down as policy, made consistent across people and sites through defined roles and standard workflows, and instrumented so that it produces evidence as a natural byproduct of the work. The behavior at the dispensing window may look identical, the pharmacist still verifies the criterion, still owns the clinical decision, but now that behavior is required by a documented standard rather than chosen by a conscientious individual, it is the same for every pharmacist rather than dependent on who happens to be working, and it generates a record a reviewer can examine. Operationalizing the user track is, at its heart, the act of converting the pharmacy's good AI practices into a program that has those three properties: it is written, it is consistent, and it is evidenced. Everything else in this lesson is detail about how to do that conversion well.

A practice lives in people's heads, varies by shift, and leaves no proof. A program is the same good behavior written down, made consistent, and instrumented to produce evidence. Operationalizing the user track is converting one into the other.

What the User Track Asks, Restated Operationally

The L1 awareness lesson on the URAC accreditation established the substance of what the user track wants: governance, verification practices, staff competency, and oversight and accountability. That framing is correct, but it is described from the outside, as categories of expectation. To operationalize it, a leader has to translate each category into a concrete thing that exists in the pharmacy and produces evidence. Governance, operationally, is a written policy plus a body that owns AI decisions plus a record of the decisions it made. Verification practices, operationally, is a defined verification standard built into the workflow plus the verification records the workflow produces. Staff competency, operationally, is a training curriculum plus a competency-evidence file showing who completed what and when. Oversight and accountability, operationally, is a named accountable owner plus monitoring of how the AI is performing plus a defined way to catch and correct problems, with records of all three.

Notice the pattern: every category resolves into a thing that exists (a policy, a body, a standard, a curriculum, an owner) paired with the evidence that thing produces (decisions logged, verification recorded, competency documented, monitoring captured). This pairing is the operational core of the user track. A reviewer does not credit the existence of a policy alone, because a policy nobody follows is theater; they credit a policy that exists and is followed, which means the policy plus the evidence of adherence. The leader's job in operationalizing the track is therefore not to write a binder of policies and call it done; it is to build the pairs: the practice and the proof, the standard and the record, the role and the evidence that the role is doing its work. A pharmacy that has policies without evidence will fail a review as surely as one with evidence but no policies, because the user track asks for the conjunction of both: deliberate, written intent and demonstrable, recorded execution.

The Scope Decision: Which AI Use Is In

Before a leader can operationalize anything, they have to answer a question that sounds simple and is not: which AI uses are in scope for the program? A modern pharmacy may touch AI in a dozen places, the PA platform, an order-verification clinical decision support (CDS) layer, a counseling-content drafter, an inventory forecaster, an ambient documentation tool, a chatbot on the patient portal. Treating all of them with the same heavyweight governance is wasteful and unsustainable; treating none of them seriously is the failure the user track exists to prevent. The scope decision is where a leader applies the program's calibration principle: the depth of governance and documentation for an AI use should be proportionate to the patient-safety and access stakes of that use.

This produces a tiered scope rather than a flat one. The high-stakes clinical uses, AI-assembled prior authorizations whose criteria affect whether a patient gets a therapy, AI-surfaced clinical signals that inform an order verification, anything where a fabricated dose, a missed interaction, or an invented coverage criterion can reach a patient, are squarely in scope for the full weight of the program: verification standard, audit trail, competency requirement, governance oversight. The low-stakes operational uses, an inventory forecast whose error is a recoverable business question, warrant a lighter touch: they should still be governed in the sense that the pharmacy knows they exist and has decided they are low-risk, but they do not need the same heavy verification-record and audit-trail apparatus. A leader who scopes well concentrates the program's effort where a patient is downstream of an error, which is both what keeps patients safe and what an accreditor will recognize as a thoughtful, defensible allocation of governance rather than either negligence or undifferentiated bureaucracy.

There is a discipline trap to name here. The temptation, when standing up a program under contract pressure, is to scope narrowly to make the work smaller, to declare that only the PA tool is "really" AI and quietly leave the CDS layer or the counseling drafter out of the program. This is a mistake, because the user track is about how the pharmacy uses AI, and a clinical AI use left out of the program is exactly the kind of ungoverned exposure the accreditation is designed to surface. The right scoping question is not "what can we leave out to save effort," it is "which uses put a patient downstream of an AI-touched decision," and every use that answers yes is in scope for real governance, regardless of how much work that implies. The honest map of where clinical AI touches the pharmacy is the foundation of a credible program, and a leader who draws that map accurately, including the uncomfortable entries, builds a program that will hold up rather than one that looks complete until a reviewer asks about the tool that was conveniently omitted.

Building the Evidence Engine, Not the Evidence

The most common way a pharmacy gets operationalizing wrong is to treat evidence as something staff produce by hand, on top of their real work. A leader who tells pharmacists "verify the AI output and also fill out this verification log every time" has built a program that will fail, not because the intent is wrong, but because a manual documentation burden layered onto a high-volume clinical workflow will be skipped under pressure, exactly when it matters most. The L1 documentation lesson made this point at the awareness level; at the strategist level it becomes a design mandate. The leader's job is not to produce evidence; it is to build the engine that produces evidence automatically as a byproduct of doing the work.

Concretely, this means the evidence requirements should be designed into the workflow and, wherever possible, into the system, rather than bolted onto the staff. When a pharmacist verifies an AI-assembled PA and approves it, the system should log who approved it, what the AI produced, and what data it drew on, without the pharmacist writing a separate narrative. When a tech submits through the AI-assisted workflow, the handoff to the pharmacist for clinical sign-off should be a structural step the system records, not an honor-system expectation. The verification standard should be embedded as a required step the workflow will not let a user skip, so that adherence is the path of least resistance rather than an extra duty. A program built this way produces a continuous, reliable stream of audit-grade evidence precisely because it does not depend on busy clinicians remembering to document; the documentation is the exhaust of a well-designed process. This is the difference between a program that generates a thick, consistent evidence record with little marginal effort and one that generates a thin, gap-riddled record that collapses under a reviewer's spot check, and the difference is almost entirely a matter of whether the leader built the evidence engine or asked people to be the engine.

The Named Owner and the Running Cadence

A program is not a document; it is something that runs, and something that runs needs an owner and a cadence. The user track's oversight-and-accountability expectation resolves, operationally, into two unglamorous but load-bearing things: a named person who owns the AI program and is accountable for it, and a regular rhythm at which the program is reviewed, monitored, and corrected. Without a named owner, accountability diffuses into nobody, and an accreditor's question "who is responsible for this" gets the worst possible answer, a pause and a shrug. The owner does not have to do all the work, and at scale should not; but there must be a single accountable person who can speak for the program, who knows its state, and who is the one a reviewer, a board, or an incident lands on. Naming that person, and writing the role down, is one of the cheapest and highest-value acts in operationalizing the track.

The cadence is the other half. A program that is set up once and never revisited rots, because the tools change, the staff turn over, the AI's performance drifts, and the workflow develops gaps that nobody is watching for. Operationalizing the user track means establishing a running cadence: a regular review of how the AI is performing against the metrics that matter, a periodic check that competency records are current and that new staff have been trained, a recurring look at whether any AI-related incidents or near-misses occurred and what they revealed, and a scheduled revisit of the policies as tools and risks evolve. This cadence is itself evidence: a reviewer who sees a program that is reviewed on a defined rhythm, with records of each review, sees a living program rather than a binder assembled the week before the audit. The named owner runs the cadence, the cadence keeps the program alive, and the records of the cadence are among the most persuasive evidence a pharmacy can show that its AI use is genuinely governed rather than nominally documented. A leader who installs both, an accountable owner and a running review rhythm, has converted a static set of policies into an operating program, which is what the user track is actually asking for.

Sequencing the Stand-Up Without Stalling the Work

A leader facing all of this at once can freeze, and the freeze is dangerous because the AI use does not pause while the program gets built; the pharmacy keeps running AI-assisted PAs whether or not the governance is ready. So the practical question is not whether to do everything at once, which is impossible, but how to sequence the stand-up so that the highest-risk exposures are governed first and the program builds outward from there. The sequencing principle is the same calibration that scoped the program: govern the patient-facing, clinical, high-stakes uses first, because that is where an ungoverned gap can hurt someone, and extend to the lower-stakes uses as the program matures.

A sensible sequence starts by getting the scope map right, so the leader knows what they are governing. It then secures the highest-stakes use, typically the AI-assisted PA and any clinical CDS, by ensuring a defined verification standard is in the workflow and producing records, because that closes the most dangerous exposure first. It names the accountable owner early, so there is someone driving the rest. It builds the competency program in parallel, because staff competency is both a user-track expectation and a precondition for the verification standard to actually work, an untrained pharmacist cannot verify well. It stands up the governance body and policy to give the whole thing deliberate ownership and a place where decisions are made. And it establishes the running cadence so the program stays alive. The point of sequencing is not perfection on day one; it is to ensure that at every stage the most dangerous gap is the one being closed next, so that even a half-built program is a safe program in its riskiest corners. A leader who sequences this way can tell a board, a reviewer, or a worried compliance officer something true and reassuring: the program is not finished, but the highest-stakes AI use is already governed and producing evidence, and the build-out is proceeding on a defined plan. That is a far stronger position than a pharmacy that froze waiting to launch everything perfectly and governed nothing in the meantime.

Key Takeaways

• Operationalizing the URAC (Utilization Review Accreditation Commission) AI user track is the move from a practice (good behavior in people's heads, varying by shift, leaving no proof) to a program (the same behavior written down, made consistent across people and sites, and instrumented to produce evidence).
• Each user-track category resolves into a concrete pair: governance becomes a policy plus a body plus logged decisions; verification becomes a standard plus records; competency becomes a curriculum plus an evidence file; oversight becomes a named owner plus monitoring plus a correction path. A reviewer credits the conjunction of intent and evidence, not policies alone.
• The scope decision is calibrated: the depth of governance for an AI use should be proportionate to its patient-safety and access stakes, so high-stakes clinical uses (AI-assembled prior authorizations, clinical decision support) get the full program while low-stakes operational uses get a lighter touch.
• The scoping trap is narrowing to save effort by quietly leaving a clinical AI use out; the right question is "which uses put a patient downstream of an AI-touched decision," and every yes is in scope for real governance.
• Build the evidence engine, not the evidence: design documentation into the workflow and the system so audit-grade records are produced automatically as a byproduct of the work, rather than as a manual log that busy clinicians will skip under pressure exactly when it matters.
• A program needs a single named accountable owner (so an accreditor's "who is responsible" never gets a shrug) and a running cadence of review, monitoring, competency checks, and incident review (so the program stays alive and the cadence records prove it is governed, not just documented).
• Sequence the stand-up so the highest-stakes exposure is always the next gap closed: get the scope map right, secure the high-stakes clinical use first, name the owner early, build competency in parallel, stand up governance, then establish the cadence, so even a half-built program is safe in its riskiest corners.
• The goal is a program that is written, consistent, and evidenced, the conjunction of good practice and the durable proof of it, because that conjunction is exactly what the user track asks a pharmacy to demonstrate and what a contract, a board, or a reviewer will one day require.