Co-Clinician

Disclosure

Safety and data

A demonstration in a regulated field is only useful if it is clear about what is real and what is staged. This page is that accounting.

Every patient here is fiction

The three patients, their twelve documents, their identifiers, their laboratory values and their clinicians were all written for this demonstration. No real protected health information is stored, processed or transmitted by this system, and none ever has been. The hospitals and laboratories named do not exist.

What is genuinely running

The records are staged. The mechanisms are not.

What this is not

Not a medical device. It has no regulatory clearance of any kind and must not be used to make or inform a clinical decision about a real person.

Not HIPAA-compliant. No business associate agreement is in place with any model provider used here. The de-identification layer demonstrates where that boundary belongs in a production system and what it produces; it is not a certified de-identification implementation, and it has not been validated against Safe Harbor or Expert Determination.

Not an identity provider. Access is a shared passcode exchanged for an httpOnly session cookie. There are no accounts, no roles and no per-user audit. A real deployment would put SSO in front of this with per-clinician identity — the audit trail this system already writes is only worth as much as the identity attached to it.

Not evaluated. There is no eval suite behind this build. The guardrails are observable on every turn, which is a different and weaker claim than measured against a held-out set of adversarial flows. Standing that suite up is the first thing a production engagement should fund.

Known limitations

How data is handled here

Records live in a Postgres database with row-level security enabled on all fifteen tables. The browser-facing role has select access only; every write goes through a server route using a service role that never reaches the client.

The de-identification ledger is the one table with no browser-facing policy at all. It stores the type, placeholder and SHA-256 hash of each detected identifier, and never the identifier itself — so the audit trail can prove what was redacted without becoming a second copy of the thing it was protecting.

How it worksOpen the console