What runs today, and what is direction.
Three statements are kept distinct on this page: built, verified in a particular deployment, and available to outside developers. The table is the first. Which release you would build on, and what it exposes, is a conversation.
| Capability | Built | Direction |
|---|---|---|
| Clinical contract | The shape of the record and the actions allowed on it, declared in writing and loaded by the platform at startup. | Publishing the contract as a versioned package for outside developers. |
| Workflow actions | Booking, tasks, referrals, prescribing through the national network, medication changes, billing, note sections, demographic change review, terminology. A separate billing service adds eligibility checks, claim tracking, payment remittances, appeals and prior authorizations. | A review step for agent proposals; delegation of individual actions. |
| Decision support | An incremental rule engine that keeps thousands of rules evaluated as the record changes, serving suggestions to the clinical application with the previous engine as a fallback. A rule library with the sentence-style editor, modules a practice can fork, and releases deployed per practice. | Retiring the previous engine. |
| Live updates | Updates on a patient, task or appointment, delivered consistently. | Re-checking permissions on every update. |
| Collaborative notes | Shared editing with history and live updates; structured sections with a stated basis. | One permission path shared with the rest of the platform. |
| Permissions | Standard, scoped permissions on the clinical interface; a responsible clinician named on every non-patient change. A service acting for a person carries that person's identity and is held to their role, starting with billing. | Bounded delegation, so an agent's authority is a subset of its principal's. |
| Accountability | Every version kept; clinician attribution on changes; one audit path that every change, export and document read goes through. | An attachable service that stores and reports that record, including agent actions. |
| Delivery | A hosted, multi-tenant service operated by Breeze; each practice in its own realm with its own record, rules and permissions. | Independent operation of the platform by a practice or a partner. |
| Openness of the source | The core server is open source. Breeze's own clinical definitions are not yet released. | An explicit scope for wider release and for operating the platform independently. |
What changed since September.
The table above reflects these. Each entry says which of the three statements it has reached.
The rule library and editor built
The sentence-style rule editor described on the rules page is built: modules, forks and change requests, releases deployed per practice, and suggestions of text, paragraphs and clinical items, each of which can open the rule that produced it. It reaches each practice as the practice moves to the new version of the clinical application.
Prescribing on the platform built, rolling out
The platform sends prescriptions through the national e-prescribing network itself, with renewals, change requests, cancellations, pharmacy fill history taken with the patient's consent, prescription benefit checks, and a way to settle a send the network never answered. Practices move to it one at a time; controlled substances stay on the existing workflow.
A billing service beside the record built, in pilot
Revenue-cycle work runs as its own service with its own interface, reading the clinical record through the platform's standard interface rather than a private copy. Eligibility checks, claim filing and its full history, payer remittances matched to claims, denials, appeals, prior authorizations, and payments measured against contracted fee schedules are built. Payment posting and charge capture from signed visits are built and switched off until a practice chooses its cutover date, and a person approves each posting.
Acting for a person partial
When the billing service acts for a biller, its token names the biller, and the biller's role is checked on every posting action. This is the first use of the delegation the agents page describes; bounding an agent's authority to a subset of its principal's is still direction.
The record, exported with its format built
A patient's complete record, with documents and history, exports as one computable package for staff or for the patient, and the package format is published in full. Each export links to that format from its manifest.
Summary-of-care documents and quality measures direction
Incoming summary-of-care documents can be received, kept exactly as sent, matched to a patient and reconciled for allergies and problems, as a prototype that is not offered. Standard clinical quality measure definitions are being compiled to run directly against the record, and the reporting formats are validated against their published rules; reports are not yet produced.
What open means here.
Openness at three levels: documented access to data and workflow capabilities; the ability to extend or replace services and to choose who provides the AI; and inspectable software with a viable path to operating the platform independently. An interface alone does not fulfil that. What is released, under which terms, and what it takes to run are stated explicitly for each offering, and where they are not yet settled this page says so.
Three statements, kept apart.
Built means implemented in the platform's source and covered by its tests, and that is what the table on this page records. Verified in a deployment means exercised in a particular installation with its connections, credentials and configuration; a laboratory connection is built once but verified per practice. Available to outside developers means published with a contract, onboarding and terms, which no capability on this site is yet.
Numbers are handled the same way. The contract declares a certain number of record types and actions; a deployment publishes the number it actually loaded, which is what a caller should read. A count of declarations is never quoted here as a count of available endpoints.
What is not yet modular.
Three things the platform depends on are real but not yet cleanly separated. One policy path: permissions are enforced on the clinical interface, and collaborative notes have their own path; the direction is one policy for every surface, including delegation to agents. An attachable audit service: history and attribution exist, and changes, exports and document reads go through one audit path; the service that stores and reports that record does not exist yet. Declared packaging: a deployment is assembled by hand rather than described as a reviewable bill of services and modules.
Source and licensing today.
The FHIR server at the center of the platform is open source under a permissive licence. Breeze's own clinical definitions, the contract described on the architecture page, are proprietary at present. The complete platform is not yet offered as an independently deployable package, and publishing the contract as a versioned package for outside developers is direction. When those things change, this page will say so in the same terms.
How to read a demonstration.
Ask three questions. Which release is being shown? Which connections are live in it, and which are stubs? Which of the workflows you care about are built, and which are direction? The honest answers are the ones this site is written to give, and a demonstration should give them the same way.