Insights · Approach
Use the interface that already exists. Automate only the leftover circuit.
If a portal, clearinghouse, or vendor already writes into the system you use, buy that. Custom collection is for the remaining case: documents you are allowed to retrieve, no usable interface, and a destination your team already works from. This note is written from a daily healthcare collection job, not as a claim that every healthcare buyer has the same leftover work.
Start with whether an interface exists
Walk the job as it runs today: which portals, what is downloaded, which fields are copied, where the file lands, who is accountable when a row is wrong. Then ask, for each source, whether a documented API, SFTP drop, or vendor connector already covers that step.
If it does, stop. A custom job on top of a working integration is usually wasted spend, and you inherit two things that can break instead of one. The leftover work — if there is any — is the portal that has no interface, the document that does not map cleanly, or the check nobody runs before the file is sent.
Four ways the leftover work gets done
Native integration
The vendor already pushes or pulls into your destination. Fit when the fields you need are in that connector and the failure modes are ones you can live with. Do not rebuild it.
API or file drop
A supported interface exists but nobody wired it to your spreadsheet, queue, or operations file. Fit when the contract allows it, the payload is stable, and you can schedule the pull. This is ordinary integration, not a model problem.
Browser automation
There is no interface. A person is logging in, clicking, and downloading. Fit when access is legitimate, the portal is the only source, and you can stand the maintenance: logins, MFA, layout changes, and terms of use. This is the brittle path. Someone has to own the breakage.
Mixed job
Collection may be any of the above. Extraction from messy documents is the AI step. Deterministic automation then checks required fields, types, counts, and cross-source agreement before delivery. That is the pattern we used on a daily healthcare portal collection: the model reads; traditional automation verifies; failures are held, not sent.
Access and failure
The job fails at the portal more often than at the model.
Credentials expire. Multifactor prompts appear on a machine that is not a person. A vendor redesigns a table. A source publishes a PDF whose fields moved. Any of those will stop a daily run. If you do not have an operator who notices, the team goes back to opening portals by hand — which is the original cost — plus a silent gap for the days nobody noticed.
Write down who is allowed to hold the login, what happens when a check fails, and whether a missed day is worse than a delayed file. Those decisions belong in the engagement, not in a slide about accuracy.
What this note is not
It is not a recommendation to automate every healthcare document flow, and it does not name a buyer subtype. Clinics, networks, and service organizations run different leftover work. Product companies already sell referral intake into an EHR, capture, and revenue-cycle automation. If that is your job, evaluate those products first.
It is also not a claim that browser automation is always permitted. Access has to be legitimate. How we handle client credentials and data is on the security page. What the work costs to keep alive is in the companion note on economics.
Contact
Describe the circuit, not the technology.
Portals, destination, frequency, and what you already bought. We will say if a custom job is the wrong spend.
Start a conversation