Building a Drug Tier Classification Engine in n8n
Most formulary teams are still doing a lot of this by hand. Someone pulls a list, cross-references a reference database, makes a judgment call on tier placement, pastes it into a spreadsheet, emails it to somebody else, and hopes the production system gets updated before the next adjudication cycle runs.
What I just described isn't really a process. It's a prayer.
Healthcare is one of those industries that is so crucial to the very fabric of our society but operates so inefficiently, it's almost criminal. So, I built a better version of this manual process using my current favorite AI orchestration tool n8n, Gemini, and a staged review pipeline that keeps a human in the loop without making the human do the grunt work. Here is how the whole thing hangs together.
At a Glance
Five Stages, One Clean Handoff Chain
The flow has five distinct stages and about a billion nodes, but here is the gist of it.
The Webhook Trigger
The whole thing kicks off from a webhook. In n8n, this is a Webhook node set to POST. Whatever upstream system is generating the drug list, a nightly batch job, a manual upload, or another workflow, sends a JSON payload to this endpoint.
The payload should be clean and consistent coming in. At minimum you want drug name, NDC code, current tier, and any relevant clinical flags. The cleaner the input, the less massaging the AI node has to do downstream.
Add a basic validation step right after the webhook before anything hits Gemini. A simple IF node that checks for required fields and routes malformed payloads to an error log. You will thank yourself for that later.
Gemini Classification
This is where the actual intelligence lives. The validated payload gets passed into an AI Agent node connected to Gemini. The prompt positions Gemini as a formulary expert and asks it to evaluate each drug across a few dimensions: cost tier placement, therapeutic alternatives, generic availability, and any clinical or formulary policy flags worth surfacing for the reviewer.
You are not asking Gemini to make the final call just asking it to do the analysis and surface a recommended classification with reasoning attached. That reasoning is what makes the human review stage actually useful rather than just a rubber stamp exercise. The reviewer is not staring at a tier number, rather, they are reading a short rationale for why the system landed where it did.
Keep the prompt directive and constrained and tell it exactly what fields to return and in what format. JSON output makes the downstream database write straightforward and removes ambiguity about what the node produces.
Now training and hosting an LLM requires tons of resources, additional infrastructure, monitoring, maintenance, and performance considerations, but for some organizations the added control may justify the complexity. Regardless of the model you choose, try and communicate the minimum amount of information necessary to get the job done.
Dev Database Write and Human Review
The classified results write to a dev database never directly to production. The dev database acts as a staging layer with every record that comes out of Gemini lands here first with a status of pending_review.
An n8n Form node or a notification to whatever review tool your team uses surfaces these records to the person responsible for approving changes. In a healthcare context that is usually a clinical pharmacist or a formulary committee lead.
Approved records flip to approved. Rejected ones get flagged for manual follow-up.
Nothing moves to production until that status changes!
Promotion to Production CRM
A second workflow, triggered either on a schedule or manually by the reviewer, queries the dev database for all records with an approved status and pushes them into the production database. The n8n HTTP Request node handles this portion of the flow.
Every record that promotes to production should write a timestamp, the reviewer's name, and the before/after tier values to an audit table. Formulary changes in a regulated environment need a paper trail, and this gives you one without anyone documenting anything manually.
RPA Handoff to the Adjudication Platform
Here is where it gets interesting. Most adjudication platforms in the pharmacy and home health space are legacy systems. No API. No webhook support. Nothing modern to hook into. You are looking at a desktop application that someone built in the early 2000s and nobody has touched since because it works and nobody wants to find out what happens if they break it.
The way you handle this is with an RPA desktop process. Once the CRM is updated, n8n kicks off the desktop automation by triggering a Power Automate Desktop flow or an equivalent RPA tool. That flow opens the adjudication platform, navigates to the right screen, and updates the tier information field by field based on the data passed from n8n.
It is not elegant under the hood but it works, and it works consistently. The adjudication platform never knows anything changed except that someone apparently typed really fast.
Why This Architecture Holds Up
Formulary management is not a space where you fire and forget. There are clinical implications, regulatory requirements, and downstream billing consequences attached to every tier change. A fully automated pipeline with no human checkpoint would be the wrong call here regardless of how good the AI classification is.
What this flow does instead is compress the manual work down to the only part that actually requires human judgment: the review. Everything before it and everything after it runs on its own. The human is not fetching data, not typing into the adjudication platform, not chasing down approvals over email. They are just deciding yes or no on a record that already has the analysis done for them.
Where to Start If You Want to Build This
Start with the webhook and the Gemini node in isolation. Get comfortable with what the AI returns before you build the database layer. Once the classification output is consistent and structured the way you want it, the rest of the pipeline is mostly plumbing.
The RPA stage is the one that will take the most time to tune, especially if the adjudication platform has any dynamic elements in the UI. Build that piece last and test it against a sandbox environment before you let it anywhere near production data.
