Kin-mediated emergency access

Kin-mediated emergency access (KMEA) v0.1

A declaration mechanism for break-glass when the patient cannot consent and the requester is outside any facility.

Status: draft for comment. Author: Anand Rajan. Date: 2026-09-25. Deliberately short. If this grows past four pages before someone outside has commented on it, that is scope creep, not progress.

Keywords MUST, SHOULD and MAY are used as in RFC 2119.

1. Problem

Consent frameworks define what happens once break-glass is declared, but not how it is declared or by whom. IHE’s Privacy Consent on FHIR profile carries this as an open issue: break-glass provisions exist, and there is no clear way to declare break-glass. Every candidate mechanism in that discussion assumes the declaring party is the requesting user, inside an organisation whose authorization server can assert that they hold the privilege.

Outside a facility that assumption fails. At a roadside there is no prior relationship, no client registration, and in India no registry against which a first responder can be verified, although clinicians can be verified through the national professional registry.

2. Proposal in one paragraph

The patient names delegates in advance. A minimal public tier is always readable without anyone’s approval. Anything beyond it is released only when a delegate declares the emergency from their own authenticated device, which produces a short-lived signed grant that the requester presents. Every release is written to an append-only log the patient and delegates can read.

3. Scope

In scope: the declaration act, who may perform it, the evidence it produces, what must be logged, and the behaviour when nobody answers.

Out of scope: the record format (use IPS, and in India the Indian Patient Summary in the ABDM FHIR IG), transport, storage design (a separate note), responder identity proofing, and clinical decisions about what belongs in each tier.

4. Actors

5. Tiers

Tier Contents Release rule
T0 Public Name, blood group, allergies, current medication, emergency contacts Always readable. No approval, no network. Keep it small enough to hand to a stranger
T1 Responder Conditions, implants, recent events, insurance and policy identifiers One delegate approval
T2 Clinical History, documents, results One delegate approval and a Requester whose clinician identity is verifiable
T3 Full Everything, including family history Subject only, or a legally recognised representative

T0 MUST be minimal by construction. Its protection is editorial, not cryptographic: anything in T0 is visible to whoever holds the phone.

6. Pre-authorisation

The Subject MUST be able to:

  1. name one or more Delegates, each with a verification key;
  2. set, per Delegate, the highest tier that Delegate may release;
  3. set whether a single approval suffices or two are required for T2;
  4. revoke any Delegate at any time, effective immediately on the Holder;
  5. review the list on a schedule; the Holder SHOULD prompt at least annually.

Where a consent resource is used, Delegates SHOULD be expressed as consent actors with an appropriate role rather than as a new resource type.

7. Declaration flow

  1. The Requester reads T0 from the lock screen, tag or card.
  2. The Requester asks for a higher tier, identifying themselves by name, service or organisation, and any identifier they carry. This is a claim, not proof, and MUST be recorded as a claim.
  3. The Holder notifies every eligible Delegate with: who is asking, what they claim, the tier requested, the location if available, and the time.
  4. A Delegate approves or denies. Approval produces a grant (section 8).
  5. The grant is presented to the Enforcement point, which releases exactly the tier named in the grant, for the grant’s lifetime, and no more.
  6. The release is logged (section 9) and every Delegate is notified that it happened, including Delegates who did not approve it.

Step 6 is not optional. A Delegate who was asleep MUST be able to see in the morning what was released and by whom.

8. The grant

A grant is a signed object carrying at least:

Claim Meaning
sub the Subject
declared_by the Delegate’s identifier and key reference
requester_claim the identity the Requester asserted, verbatim
tier the tier authorised
purpose break-glass purpose of use
nbf / exp validity, in minutes, not hours. Default 30 minutes
jti unique identifier, for replay prevention and audit correlation
sig the Delegate’s signature

Constraints:

9. Audit obligations

Every release MUST write an entry containing: timestamp, tier, grant jti, the Delegate who declared, the Requester’s claimed identity, the enforcement point, and whether the release was completed or aborted.

The log MUST be append-only and tamper-evident. A hash chain, where each entry carries the hash of the previous one, is sufficient; a chain root MAY be published externally, and personal data MUST NOT be.

The Subject and every Delegate MUST be able to read the whole log.

10. When nobody answers

This is the case that decides whether the design is honest.

11. Threats

Threat Response
Fake responder requests T1 Delegate sees the claim and decides; T0 alone is exposed by default
Delegate is coerced by someone at the scene Every Delegate is notified of every release; a second approval MAY be required for T2
Compromised Delegate device Revocation is immediate on the Holder; grants are short-lived and single-use
Grant replayed later jti and exp enforced at the enforcement point
Holder lost or stolen Hardware-backed keys, released only after user authentication, with per-operation authorisation for bulk release
Subject wants it all erased No custodian holds records; deletion is local and key destruction is final

12. Conformance checklist

  1. T0 readable with no network and no approval.
  2. Delegates pre-authorised, per-tier, revocable immediately.
  3. Requester identity recorded as a claim, never as proof.
  4. Grants single-tier, single-use, minutes-long, signed by the Delegate.
  5. Releases logged append-only and tamper-evident, readable by Subject and all Delegates.
  6. All Delegates notified of every release.
  7. No automatic release above T0 without explicit clinical governance.
  8. No personal data published to any external ledger.

13. Open questions

  1. Is delegated declaration in scope for consent profiles at all, or is it local policy with only the audit obligations standardised?
  2. Responder identity: is there any national registry for ambulance crews or police in India? If not, is a recorded claim plus notification an acceptable substitute, or does T1 need a different gate?
  3. Should T2 verification consume a clinician registry directly, or accept an assertion from the clinician’s own system?
  4. Is there a defensible clinical case for timed auto-release, and if so, who signs off on it?

14. References

This site is open source. Improve this page.