drchrono_push_eligibility_results, the DrChrono eligibility write-back tool exposed through the Agents Platform.
DrChrono has no note field on a patient chart, so a verification of benefits is filed as a document. The tool renders the note as a one-page-or-more PDF and uploads it to the chart.
Authentication
Uses the DrChrono OAuth connector. The platform injectsaccess_token; the agent never supplies it. When DrChrono is not connected, the tool returns reason: "drchrono_not_connected" rather than an error, so the agent can ask the user to connect it.
Safety
This is a mutating tool. Each successful call adds one document to a patient chart. It will not write in any of these cases:- No DrChrono patient matches the name and date of birth given.
- The name search examined more charts than its cap and matched none of them. Correctness does not rely on DrChrono’s
date_of_birthquery filter — candidates are re-checked in full — so a cut-short search is reported as cut short rather than as a miss. - More than one patient matches. The error lists the candidate ids; re-run with
patient_idto pick one. patient_idwas supplied but its chart carries a different date of birth.- The chart has no primary doctor. The documents API requires one as the filing provider.
- A live (non-archived) document with the same title is already on the chart.
patient_id is supplied. A benefits note filed on the wrong chart is a PHI disclosure, so the tool refuses rather than guesses.
The tool does not change the insurance record on file. The AthenaHealth tool of the same name offers that as an action; this one does not, because an eligibility check verifies coverage rather than correcting it.
Inputs
Required:date_of_birth:YYYY-MM-DDorMM/DD/YYYY. Always required — it confirms the chart before the write.benefits_note: the finished note, filed verbatim.
patient_id: the DrChrono patient ID. Never an ID from another EHR.first_nameandlast_name.
date_of_service:YYYY-MM-DDorMM/DD/YYYY. Sets the document date and title. Defaults to today.
What lands on the chart
These match what the Nanonets Health EBV agent writes, so a VOB filed by an agent and one filed by that pipeline look the same in the chart and answer the same filters.
Output
written is false, skipped is true, and reason is document_already_exists. document_id points at the existing document, and is omitted when DrChrono did not return an id for it — an absent id is reported as absent rather than as a placeholder. Treat this outcome as success — do not retry it.
Failure outcomes
Every failure carries areason and a retryable flag, so a caller can tell a deterministic refusal from a call worth retrying. A refusal will refuse again on identical input; retrying it only wastes a call.
Each failure also carries
suggested_actions — the same shape the not-connected result uses.
Limits
- Up to three upstream DrChrono operations per invocation: the patient lookup, the document list, and the upload.
- A name search examines at most 500 charts, paged 250 at a time. Beyond that it reports
patient_search_truncatedinstead of a result. - The duplicate check pages the chart’s documents 250 at a time, up to the client’s 20-page ceiling.
- The PDF uses the base-14 Helvetica face, which is Latin-1. Characters outside it (an em dash, a curly quote) are replaced with
?.
Human-readable text
The tool emits a markdown field table for the feed —Written to DrChrono or Already on file — carrying the patient id, the filing doctor, the document title and id, the file name and the metatag. The full payload stays in structuredContent.
Agent Instruction Guidance
Pass the note exactly as the previous step produced it. Do not shorten or reformat it. Push one document per patient. When several patients were processed, make one call each, with that patient’s own note. Retry only when the result saysretryable: true, and then at most once. Each successful call adds another document, so a blind retry loop stacks duplicates on the chart — the duplicate check only catches a repeat of the same title.
On a refusal, report the message and the suggested_actions to the user rather than working around it. patient_ambiguous is resolved by re-running with patient_id, not by picking one.