Record partial

A record a model can read and a person can trust.

Legible data is structured data with its story attached: what it says in words, what it said before, and who changed it.

Plain language on the record. Records written through the platform carry a readable version generated from their structured content, so a model and a clinician read the same statement of the same fact.

History is kept, not overwritten. Every version of every record is retained. Ask what the record said at any past moment. The second storage engine also answers what was believed to be true for a period, which is the question a retrospective review or a corrected result actually asks.

Every change is attributed. A change on the clinical interface must name the clinician responsible for it. A device or service credential without one is refused; a patient's own session is the one exception. That rule is what makes acting on someone's behalf meaningful when agents arrive.

The trace below is the shape the accountability work is building toward: one line per read, draft, proposal, approval and applied change, each naming who or what acted and for whom.

timeactionwhatwho, on behalf of
09:14:02readthe patient's problems, medications and two years of historyassistant, for Dr. Okafor
09:14:05draftassessment section of the visit noteassistant, for Dr. Okafor
09:15:40proposecardiology referral, as a draftassistant, pending review
09:17:10approvethe referral, now activeDr. Okafor
09:17:10applyreferral updated; follow-up task createdplatform, for Dr. Okafor
09:17:11notifythe assistant's task list updatedplatform
illustrative trace; the uniform audit that would record it is direction
Structured and readable

Structured and readable at once.

Every record on the platform is structured: codes carry the system they come from, quantities carry their units, references point at the records they mean. The plain-language version is generated from that structure, not written separately, so it cannot say something the structured record does not. A model reading the narrative, a clinician reading the screen and a query over the structured fields are reading one fact three ways.

Two questions about time

Two questions about time.

What did the record say on a given day? Every version of every record is kept, so the answer is exact. A corrected result shows both what was first recorded and the correction, each with its moment.

What was believed to be true for a period? A retrospective review or a corrected result asks this second question, which is different from the first: a fact can be recorded on Tuesday about Monday. The second storage engine answers both questions; the current one answers the first. A store asked for an axis it does not support refuses rather than approximating.

Attribution

Who did this.

A change on the clinical interface must name the clinician responsible for it. A device or a service credential without one is refused. A patient acting on their own record through the portal is the one exception, and their changes to identity details are staged for staff review rather than applied. When agents arrive, this is the hook that makes acting on someone's behalf meaningful: the person is already named on every change, and the agent is recorded as acting for them.

Vocabulary

Codes with meaning.

Codes on the record are checked against the loaded code systems and value sets, and each carries its display text. Picklists a practice curates are normalized as a whole whenever they change. A model that reads the record therefore sees a consistent vocabulary with meanings attached, and a rule that asks whether a diagnosis is in a value set gets a definite answer.

Toward one trace

Toward one trace.

Version history says what changed and attribution says who; together they are accountability for changes. The uniform trace the platform is building toward also records reads, with the purpose they were made for, and agent actions, with what the agent was given and what it relied on, all in one attachable service with pluggable destinations. Some parts of the platform already emit such records; the single uniform service is direction. The example trace at the top of this page shows its intended shape.

Build with us

Bring a workflow that needs deeper integration.

If your product needs to read a record, contribute to it, act on it and follow what happens next, we would like to hear what that workflow is. Tell us the steps, and we will tell you which parts exist today and which are still direction.

Breeze Health Platform is built by Breeze EHR, the clinical application at breezeehr.com. Breeze is also on LinkedIn.