Five things software needs to take part in care.
Health data standards give an application a way to ask for access to a patient's information, including permission to write. How deeply it can take part still depends on what the clinical system exposes. Access to records does not by itself provide access to the work happening around them.
Context
The relevant record, its history, and where each fact came from.
Today: read the record, search it, and see every earlier version of it.
Participation
Structured drafts and collaborative edits where clinicians already work.
Today: shared editing of the visit note, and structured note sections captured at a stated point in the record's history.
Action
Defined clinical and administrative actions with checks, bounded authority, and human review where required.
Today: named actions for booking, tasks, referrals, medications, billing and notes. The platform owns the rules and makes the related changes together.
Feedback
Events and outcomes that let a caller follow work through to completion.
Today: live updates on a patient, a task or an appointment, delivered so that a screen or an agent never sees a half-applied change.
Accountability
A trace of what was read, proposed, approved and changed, including who or what acted and on whose behalf.
Today: every change names the clinician responsible for it, and every version is kept. A uniform record of reads and of agent actions is designed and in progress.
Access to records is not access to the work.
A standards-based application can ask for permission to read and write a patient's information, and get it. That settles which records it may touch. It says nothing about the work happening around those records: who may move a task, in what order a referral is drafted and approved, what happens when a result arrives, and who is answerable for the change.
When a clinical system exposes only records, every integration has to carry that workflow knowledge itself. Each tool reimplements the rules, inconsistently, or skips them. An assistant that can write a resource but cannot ask the system to book, to refer, or to complete a task is left guessing at the system's own invariants, and the practice inherits the mistakes.
The five requirements below are what it takes to let software take part in the work rather than only read about it. They apply equally to a partner application and to an AI agent, which is the point: one interface, checked the same way for every caller.
What each requirement asks of the platform.
Context. Not only the current record but its history and where each fact came from. An assistant preparing for a visit reads two years of problems, medications and results, sees which of them changed since the last visit, and can say which source each came from. Today: read, search and version history on every record, through the same interface the clinical application uses.
Participation. A draft that lands where the clinician is already working, in the note they are already writing, marked as a proposal they can accept, edit or discard. Today: shared editing of the visit note with live updates, and structured note sections captured at a stated point in the record's history.
Action. A way to ask the system to do something with its own rules applied: book this appointment, start this task, create this referral as a draft. The caller says what; the platform checks who may, applies the rules, and makes the related changes together. Today: named actions for booking, tasks, referrals, medications, billing, notes and terminology.
Feedback. Once a caller has acted, it needs to know what happened next: the referral was accepted, the result came back, the task moved. Today: live updates on a patient, a task or an appointment, delivered as consistent frames so a screen or an agent never sees a half-applied change.
Accountability. A trace of what was read, proposed, approved and changed, naming who or what acted and on whose behalf. Today: every change on the clinical interface names the clinician responsible, and every version is kept. What is still being built is one uniform record of reads and of agent actions, with a declared purpose attached.
How claims are marked on this site.
Three statements are kept apart everywhere on these pages. Built means implemented in the platform's source and covered by its tests. Verified in a deployment means exercised in a particular installation with its connections, credentials and configuration. Available to outside developers means published with a contract, onboarding and terms. A capability can be the first without being the second or third, and this site says which.
Each section carries a marker. implemented means built. partial means part of it is built and the rest is designed. direction means designed, not built. When a number appears, the page says what was measured, where and when.