Connectivity

EHRs

Signed notes and their addenda are filed in the chart through the EHR's FHIR R4 interface, as a DocumentReference on the patient matched by medical record number, with a bearer token or OAuth 2.0 client credentials (a client secret). An administrator sets the connection up under Integrations; credentials are stored encrypted.

What is needed

A FHIR R4 endpoint that answers a Patient search by identifier and accepts a DocumentReference create, and credentials for it. There is no vendor-specific code: the same two calls go to the address an administrator enters.

Where that is found

Through the developer programmes of the certified systems, among them Epic, Oracle Health (Cerner), MEDITECH, athenahealth, eClinicalWorks, NextGen and Veradigm. Certification covers reading; writing a document is a separate permission a site may withhold, and some of these interfaces are read-only.

What is not built

No connection to a named vendor has been tested; treat each as work to scope on Contact us. HL7 v2 through an interface engine, and the JWT client assertion some vendors require, are not built.

Agents and applications

Language structure protocol

VisitRounds answers a language structure protocol over Streamable HTTP at /mcp, so an assistant calls its tools with a key. Tools: list_patients, get_patient, list_notes, get_note, list_templates, create_patient, update_patient, create_note_from_text, edit_note_draft, add_addendum and finalize_note.

Agent flows

Agents built on open-source and frontier LLM models, and any client that speaks it, connect with a key. LangChain and LangGraph reach the same tools through their protocol adapters, or the REST interface as plain tools. Multi-step flows run on events: a webhook fires, the agent reads what its key allows and writes back within its scopes.

SDK applications

No client library is needed: the REST interface is plain JSON over HTTPS with a bearer key, so any language's HTTP library is the SDK. An agent SDK reaches the same tools through the protocol endpoint. Worked examples for a given stack come under the enterprise agreement; ask on Contact us.

REST interface

/api/v1, for another website, a practice database or billing software: patients (list, add, read, update, import up to 500 rows by medical record number), notes (from text, read, draft, addenda, sign), templates, bills (read only), and a transcripts route that takes a recording from another system.

Webhooks and pipelines

Events: note.ready_for_review, note.finalized, note.addendum, coding.approved, bill.submitted, census.ready, patient.created. Signed with HMAC-SHA256. A delivery that fails on a network error, a timeout, 408, 409, 425, 429 or a 5xx is retried at 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours, six attempts in all. Any other 4xx is not retried. Managed under Integrations: add, test, retry, and a delivery log of record ids and status, never patient information.

Keys

Made by the physician in Settings and shown once; only a digest is stored. An optional expiry of 30, 90 or 365 days, and allowed addresses. A key reaches only its physician's patients, and every call is audited by tool or route name.

Other applications

Billing software and practice databases over REST (bearer token, API-key header, OAuth 2.0 client credentials or HMAC). Outside reference servers (guidelines, formularies, coding references) for the note. Web connectors for hosted assistants are not built today.

Permissions

A key carries only the permissions it is given. Anything outside them is refused.