Proven, and not yet proven, at the same weight.

The layer in between

MedUnity is the trusted infrastructure between Canada’s health custodians and the patients whose records they hold. It is the Canadian-owned layer that lets a patient bring the fragments together and direct who sees what, for how long, and why.

Every access is refused unless the patient permitted it, and every access is recorded in a ledger nobody — including MedUnity — can alter.

Not a competing record. Not another silo. The rails, the consent, and the proof.

Who is accountable, and when

MedUnity is infrastructure for interoperability between health data custodians. It will not hold health information until there is a named, accountable custodian for it.

Custodianship is modelled as something that can be transferred, and it is recorded over time — so the question "who is accountable for this record, right now" always has an answer, and so does the same question asked about a date two years ago.

Whether MedUnity is itself classified as a custodian, an agent, or a network provider is an open legal question. We have scoped it and we are resolving it, and we built to the strictest reading in the meantime, because no answer to it makes that work wasted.

Where we actually are

A working proof-of-concept, built and running.

A signed letter of intent with a Toronto primary care and pain practice. The services agreement is still in negotiation, and until it is signed there are no patients on this system.

Engagement with Canada’s CHI HALO and CA+ Baseline interoperability working groups, which is where the standards this has to meet are being written.

Proven

Proven

Each of these can be shown to a reviewer in the code and in a test that runs on every build.

• Every read of a record is recorded, in the same transaction as the access. If the audit write fails, the read fails.
• The audit records are append-only, proved against a real database server — including that the table’s own owner cannot edit them.
• The consent engine and the custodianship gate carry 100% branch coverage, enforced on every build. The consent engine is a pure function, with no input or output of its own and no clock.
• An abuse-case suite covering eight classes of attack runs blocking in continuous integration. Each case asserts both that the breach fails and that it leaves an audit record.
• One path to clinical data, enforced structurally: reaching it requires a permission decision that cannot be constructed outside the consent engine.
• Canadian residency is enforced by an organisation-level policy that makes creating anything outside the Canadian regions mechanically impossible, rather than discouraged.
• Every clinical record is stored as FHIR R4 with mandatory provenance, in an append-only store whose immutability is enforced by the database itself.

Not yet proven

Not yet proven

Stated at the same weight as the list above, because saying these is what makes that list believable.

• CA Core+ and CA Baseline profile conformance. A target, not a result.
• The no-administrator-read property. Architecturally absent, pending independent verification in a threat and risk assessment and a third-party penetration test.
• SOC 2 Type II. The observation window has not started.
• Classification under PHIPA — custodian, agent, or network provider. An open legal question, scoped and being resolved.

Compliance activities

Most rows say planned. For a company at this stage that is the correct and the more persuasive thing to show.

Ask us for the detail

Every claim on this page has a file behind it, and we would rather walk a reviewer through the ones that are not finished than be asked about them later.