Healthcare services · Selected work
A daily collection job across portals, with the AI work checked before anything is sent.
A healthcare services organization was pulling documents from many external portals every day and combining the fields by hand into one spreadsheet. We built a scheduled job that collects those documents, extracts and combines the fields, and runs deterministic checks on the extraction before the file goes to the agents. The team no longer opens the portals by hand.
What the team was doing
The work was a daily circuit, not a one-time migration. Staff signed into each portal, downloaded what had arrived, and copied fields into a shared spreadsheet so agents had one file to work from. The destination was already that spreadsheet. The cost was the hours spent opening portals and reconciling fields, and the risk that a missed portal or a mistyped value would travel downstream.
This page does not name the organization, the portals, or the line of business. Those details are confidential. What follows is the shape of the job: recurring collection from systems the client already used, extraction into a format they already delivered, and an operator who owns the run.
What we built
Collection
A scheduled job signs into the portals the team already had access to and pulls the day's documents. We did not replace the portals or ask counterparties to change how they publish files.
Extraction
AI reads the pulled documents and maps fields into the columns the spreadsheet already used. The model is doing the messy part: layouts that are not identical, fields that sit in different places, values that have to be lined up across sources.
Verification
Traditional automation then checks the AI output. The checks are deterministic: required fields present, types and formats that the spreadsheet expects, row counts that match what was collected, values that can be compared across sources. Failures do not go out as if they were clean. They are held for review.
Delivery
The verified spreadsheet is written and sent to the agents on the same daily cadence as before. The output is the file they already knew how to use.
Operation
We run the job. Portal logins break, layouts change, and a collection that worked on Tuesday can fail on Wednesday. That is part of the engagement, not a handoff the client is left to debug alone. How we handle access and data in client work is on the security page.
Verification
The AI does not have the last word.
The published summary of this work is easy to misread as “a person spot-checks the model.” That is not what was built. Extraction is the AI step. Checking the extraction is ordinary automation: rules that pass or fail, the same way you would check a file that came from any other brittle source.
When a check fails, the row or the run is escalated instead of being sent. The exact rules are specific to this client’s columns and portals, so they are not listed here. The pattern is the part that transfers: do not ship an unchecked extraction into a file other people will act on.
Where it landed
The spreadsheets are produced and sent to the agents daily. Nobody on that team opens the portals by hand for this job. That is the outcome we can stand behind.
We are not publishing hours saved, error-rate percentages, or a cost comparison for this engagement. Those numbers were not part of the public case, and this page does not invent them. If you need a reference who can speak to the work, ask on a call and we will arrange it where permission allows.
System boundary
In: the portals and documents this team already collected. Out: a new system of record, a replacement for the spreadsheet, or a product the counterparties had to adopt.
What this is not
It is not a claim that every healthcare document problem looks like this, or that a spreadsheet destination is inherently better than writing into an EHR or another system. It is one recurring collection job, operated, with checks on the extraction.
If you are deciding whether to automate a job like this
Purchasing notesWhen native tools are enough
If the portals expose a working API, file drop, or vendor integration into the destination you already use, buy that. Building a collection job on top of a solved interface is usually the wrong spend.
What the work actually costs
The expensive parts are access, mapping, verification, and keeping the job alive when a portal changes — not the model. Some daily jobs are not worth automating.
Contact
Running a similar daily circuit?
Describe the portals, the destination, and how often it runs. We will tell you whether it is a fit.
Start a conversation