ABT-M — Medical Records Authorization

Department-scoped bubble keys with cross-bubble re-authorization. A patient whose oncologist can't read the cardiology notes — minimum-necessary enforced by cryptographic structure, not policy.

Protocol overview  ·  Whitepaper  ·  Counsel version  ·  Filed · Patent pending  ·  US Prov. 64/056,353
ABT-M
Medical
Provider-patient bubble architecture with cross-bubble re-authorization. Patient retains key custody across care transitions.
Filed · Patent pending
The scenario

What ABT-M does

Yusuf is diagnosed with both a cardiac condition and cancer in the same year. His oncologist can read his oncology records. His cardiologist can read his cardiology records. Neither can read the other department's notes, even though both treat the same patient at the same institution.

Cross-department re-authorization requires Yusuf's explicit participation — it does not flow automatically through the hospital's administrative access tier. The hospital administrator, the billing department, and the insurance processor each receive only the fields their role requires.

Research aggregations see anonymized summaries. Never identified records. The anonymization is a structural property of the research tier key — not a de-identification process applied after the fact.

How it works

Three structural properties

01
Department-scoped bubble keys
Each care department receives a bubble key scoped to their portion of the patient record. Departments at the same institution cannot read each other's records without explicit patient authorization.
02
Patient-held master key
The patient's device holds the master key from which all department bubble keys are derived. Cross-department re-authorization flows through the patient's device, not through administrative channels.
03
Minimum-necessary by structure
Each role — treating physician, billing, insurance, researcher — receives a tier key scoped to exactly the fields their role requires. Structural scoping, not access control policy, enforces minimum-necessary.
Applications

Where ABT-M applies

Hospital EHR systems, specialist referral networks, insurance claim processing, clinical research aggregation, telehealth platforms — wherever HIPAA's minimum-necessary principle needs structural enforcement rather than policy enforcement.

Hospital EHRInsurance claimsClinical researchSpecialist referrals

Technical primitives

ABT-M uses Ed25519 digital signatures for authentication of every event at every party. Per-event symmetric keys are derived via HKDF with the event identifier as salt and held in hardware-backed secure storage (Apple iOS Keychain, Android Keystore, or equivalent platform secure-storage). Envelope encryption is performed at the first-party endpoint before any ciphertext leaves the device or origin. Each tier authority’s ciphertext contains only that tier’s authored projection — information not relevant to a tier authority is authored out before encryption, not redacted after. The registry maintains a hash-chained log where each entry’s hash includes the prior entry’s hash, providing tamper-evident integrity across the chain. Forward-only tier activation: registration of a new tier authority causes inclusion of an active tier layer in subsequent envelopes only. Existing envelopes are not retroactively modified. Cryptographic boundary at the first party. Plaintext never moves. Per-tier projection authored at envelope construction. Registry-routed restoration requires structural participation by all three parties.

Who this is for

Cryptography researchers studying envelope encryption, tier-bounded ciphertext, deterministic key derivation, and signed receipt chains in healthcare patient data management.

Privacy researchers studying architectural privacy enforcement, unlinkability, purpose limitation, retention through cessation, and consumer-controlled key custody.

Consumer protection advocates seeking architectural alternatives to policy-based privacy enforcement. Cryptographic structural enforcement, not vendor trust.

Policy researchers examining cryptographic enforcement of storage limitation (GDPR Article 5(1)(e)), data minimization (GDPR Article 5(1)(c)), and consumer protection requirements.

Health informatics researchers studying patient privacy, electronic health records, HIPAA compliance, HL7 FHIR interoperability, provider-patient consent architectures, care coordination across providers, public health surveillance without patient identification, research access vs identified access separation, and cross-bubble re-authorization at care relationship boundaries.

Read the full walkthrough → Counsel version Protocol overview