Decoupled by design, bound by one contract.

One written contract, read by the platform at startup.

The contract is an implementation guide: a set of documents in the healthcare data standard that declares what the record looks like and which actions may be taken on it. It is the source everything else is built from.

Profiles describe the shape of each kind of record: which fields a patient, a visit, a referral or a note carries, which are required, and which vocabularies their codes come from. Extensions add the fields Breeze needs that the base standard does not define. Operation definitions describe each action: its name, the parameters it takes, what it returns, and a binding to the code that implements it. A capability statement lists the record types and actions a server offers.

The platform reads the contract when it starts. The record types it serves, how it checks and coerces incoming data, how it stores each field, and which action routes exist are all derived from the same declarations. An action that is declared but whose implementation cannot be loaded stops the platform from starting rather than failing a caller later. The description and the behavior cannot drift apart, because one is generated from the other.

The same contract drives the clinical application: its request and response types are generated from the definitions rather than written by hand. In time, an agent's description of what it may do is the same projection. See Agents.

A reusable server with interchangeable storage.

At the center is a FHIR server that is not specific to Breeze. It is open source. It composes its request handling from named pieces, so a host can insert its own identity handling, its own permission checks, or its own telemetry without forking the server. Storage sits behind a protocol, and two storage engines exist today. One keeps system-time history: what the record said at any past moment. The other keeps system time and valid time: also what was believed to be true for a period. A read that asks for an axis a store does not support is refused, not approximated.

Every version of every record is retained on both. That history is what makes the record legible over time, and it is the foundation the accountability work builds on. See Record.

Six services, each behind its own boundary.

The record. The clinical store itself: patients, visits, orders, results, medications, notes and the rest, with full history and the named actions on top of them.

Terminology. A separate store of code systems and value sets, with expansion, validation, concept lookup and search, and the picklists a practice curates. Every code on the record carries its meaning.

Notes. Collaborative editing of the visit note: several people, and in time agents, editing the same document at once, with snapshots, compaction and live updates, and structured sections captured with a stated basis in the record's history.

Rules. Deterministic decision support: thousands of rules compiled together, evaluated as the record changes, answering in milliseconds. See Decision support.

Connections. The edge: laboratories, pharmacies, hospital admission feeds, text and voice, and the pattern they share. A connection subscribes to a kind of record, translates it, speaks the foreign protocol, and translates the reply back into records. The lab loop is the model: an order goes out, a result comes back into the chart.

Search. People and concepts: finding a patient by a fragment of a name, a clinician, an organization, or a term in a code system.

What replacing a piece means.

Each dashed line in the diagram is a boundary where both sides speak the standard. That is what makes a piece replaceable rather than merely separate.

Choose the AI provider. A model or an agent is a caller of the same interface as everything else. Nothing on the platform is tied to one vendor's model, and a practice can change its choice without changing its record.

Choose the terminology source. The terminology service is data, a loader and an index. Load a different code system, or a practice's own value sets, without touching the record store.

Add a connection. A new laboratory, registry or messaging channel is a new connector following the same subscribe, translate, speak, translate-back shape; the record and the clinical application do not change.

Swap the storage. Two storage engines already run behind the same protocol. That seam is proven, not theoretical.

Bring your own application. The clinical application is one client. A partner application, a specialty tool or an agent enters at the same boundary with the same permissions.

What is not yet cleanly separated.

Three things are real but not yet modular, and they are the focus of the platform work. Authorization: permissions are enforced on the clinical interface today, but collaborative notes have a separate permission path; the direction is one policy path for every surface, including delegation to agents. Audit: version history and attribution exist, and some parts of the platform emit audit records, but there is no single attachable audit service covering every read and change. Packaging: a deployment is assembled by hand; the direction is to describe it as a declared bill of services and modules that can be reviewed and reproduced.

See Status for the table of what is built and what is direction.