Every action is named, written down and enforced.
A useful integration needs the rules of the workflow, not only the shape of the record. A caller says what it wants done; the platform applies the rules and makes the related changes together, so no caller has to reimplement them and no caller can skip them.
For example, creating a referral
The caller says who the patient is, which specialty they are being referred to, and why. The platform sets the category, the time and the requesting clinician, allows the referral to begin only as a draft or as active, and, if the same request arrives twice, returns the referral it already created instead of making a second one. The clinician sees one referral, with the reasoning attached, ready to approve.
Scheduling
- Book
- Cancel
- Check in
- Mark no-show
- Release a slot
- Copy a day's schedule
Tasks
- Start
- Complete
- Reassign
- Reject
- Reopen
Orders and referrals
- Create a referral
- Convert to an order
- Complete
- Reconcile results
Medications
- Replace
- Stop
- Cancel
- Approve a renewal
Notes
- Capture a section
- Attest
- Use structured sections
Visits and billing
- Open a visit
- Change status
- Change attending
- Move location
- Send a claim
- Withdraw a claim
Terminology
- Expand a value set
- Validate a code
- Look up a code
- Search concepts
People
- Register a patient
- Request a demographic change
- Update demographics
- Add a related person
Each action is declared once. The same declaration drives the platform, the clinical application and, in time, an agent's understanding of what it may do. What a particular deployment exposes to outside software is stated for that deployment, not assumed from the list.
What the platform owns in each action.
A caller says what it wants. The rules, the related changes and the timestamps are the platform's. Here is what that means area by area.
| Area | The caller says | The platform owns |
|---|---|---|
| Scheduling | Book, reschedule, check in, mark a no-show, release a slot, copy a day's schedule. | The appointment and its related updates committed together as one change, an attributed response written, stale messages cleaned up, time zones on copied schedules. |
| Tasks | Start, complete, reassign, reject, reopen. | Who may act (owner, requester), which transitions are allowed, the timestamps, and repeat calls that converge rather than duplicate. |
| Referrals and orders | Create a referral, convert to an order, complete, reconcile results. | The category, the intent, the authored time, the requesting clinician by default, and a retry key so a repeated request returns the same referral. |
| Medications | Replace, stop, cancel, approve a renewal, mark entered in error. | The allowed transitions and the list flags that keep the medication list consistent. |
| Notes | Capture a section, attest, opt a note into structured sections. | The exact point in the record's history the section was captured against, and attestation rules that depend on the role. |
| Visits and billing | Open a visit, change status, change attending, move location, send or withdraw a claim. | The filing state on the claim and, when asked, finishing the visit while keeping the visit and its note consistent. |
| People | Register a patient, request a demographic change, update demographics, add a related person. | Identity changes proposed from outside are staged as a review task rather than applied, so a portal request never silently rewrites who a patient is. |
| Terminology | Expand a value set, validate a code, look up a code, search concepts, edit a picklist. | Expansion and validation against the loaded code systems; a picklist normalized as a whole on every edit. |
Why the platform does not offer a general write.
When the clinical application's own writes were surveyed, most were fine-grained edits to drafts and fields, and only a few dozen were lifecycle verbs: book, start, complete, refer, send. Those verbs are where the rules live, and they map one to one onto named actions. Draft content stays a plain read and write; transitions with invariants are actions.
A general write would hand every caller the rules to reimplement, and let any caller skip them. For a person that is a bug; for an agent it is the failure mode to design against. A named, bounded, documented action is exactly what a safe tool should be, and a "do anything" capability is precisely what no caller receives.
Repeatable by design.
Networks fail mid-request. Actions that create something accept a retry key, and a repeated request with the same key returns what was already created instead of creating it twice. Actions that change several records do so as one transaction, so a failure leaves the record as it was rather than half-changed. Lifecycle actions are convergent: asking twice to complete a task leaves it completed once.
What a deployment exposes.
Every deployment publishes its own capability statement, the list of record types and actions it actually loaded and routed. That is the number a caller should read; the contract declares more than any one installation may enable. Actions with effects outside the platform depend on their connections: a claim marked sent is not proof the payer received it, and a medication change is not proof the pharmacy exchange completed, unless the corresponding connection is configured and live. Ask which release you would build on, and what it exposes.