HATSHIPAA Authenticated Transfer Space Spec · draft

1.1 What is HATS?

HATS is a proposed protocol layer on atproto spaces, the permissioned-data layer of the AT Protocol, that maps HIPAA's patient-data-sovereignty philosophy onto spaces. Instead of health records living in hospital-owned silos, they live in spaces the patient controls: the patient is the space authority, every author writes only to their own space repo, and providers read with short-lived, scoped credentials.

The name is doubly nested by design: HIPAA (Health Insurance Portability and Accountability Act) Authenticated Transfer Space Specification = HATS. "Authenticated Transfer" is the AT in atproto (Authenticated Transfer Protocol); "Space" is the atproto spaces primitive HATS is built on.

1.2 Origin

Started as a brainstorm from a real problem: modern hospitals go fully analog during cyberattacks because their systems (Epic, Cerner, etc.) are cloud-hosted with no meaningful LAN fallback. HIPAA compliance paradoxically centralizes data rather than distributing it safely. The fix: patient-sovereign records on an open protocol.

Daniel Holmgren (Bluesky protocol engineer) designed atproto's permissioned-data layer in a public design diary, which is essentially the infrastructure HATS needs. Most of this spec was drafted in July 2026 against those posts. The atproto spaces alpha shipped on August 20, 2026 (proposal 0016), and changed enough that the spec is being realigned doc by doc. Upstream: atproto Spaces Alpha tracks what changed, which docs are still stale, and where HATS needs something upstream doesn't provide.

1.3 Structure

One daemon, three modes. HATS is a standalone daemon — personal, institution, or coordinator mode — that other software reaches through standard FHIR APIs. An EHR is just another client. See Architecture.

Records are FHIR resources in spaces typed by IPS section and keyed by HL7 confidentiality code, under the hats.health domain (health.hats.* NSIDs). See Lexicon Namespaces.

HATS splits into two layers:

HATS.user — the patient-sovereign layer. The patient is the authority over their spaces; providers read with short-lived scoped credentials and write into their own repos. The Roles, Lexicon Namespaces, Access Flows, ATProto Mapping, and Open Questions docs below all describe this layer.

HATS.hospital — the institutional layer. Inter-hospital sharing (.public) and internal operational messaging (.pneumatic), both institution-to-institution and authorized under HIPAA's TPO exception.

Foundational primitives — metamorphic bilateral records, the accountability thesis, the binary audit ceiling — live one level up in the parent ATS umbrella and are inherited here rather than restated. See ATS Foundations.

1.4 Docs

• User Stories — patient, clinician, engineer: what each needs, what's covered, what's a gap
• Architecture — standalone daemon in three modes, standard APIs, offline-first sync
• Roles — Patient, Provider, Backup Provider, Guardian, Validator, Quorum Shareholder
  • Identity & Circles — one person, many DIDs; trusted circles replace the guardian model
• Lexicon Namespaces — IPS-section spaces, confidentiality keys, FHIR records
  • Record Integrity — pluggable signatures, amendment chains, the Mina-style ZTK
• Access Flows — routine care, admission/backup, notarized consent, break-glass
  • ER: Unresponsive Patient — tiered, reason-required break-glass on atproto spaces
• ATProto Spaces Mapping
  • Upstream: atproto Spaces Alpha — what changed since the June drafts, what's stale, feedback for the spaces team
• Open Questions
• HATS.hospital
  • HATS.hospital.public
  • HATS.hospital.pneumatic
• Autonomy Spectrum
• Progressive Onboarding
• Threshold Authority & Notarized Consent
• ATS Foundations — shared primitives inherited from the parent ATS umbrella

2.1 Personas

Sub-personas worth keeping in mind: the caregiver (a circle member acting for a parent or child), the privacy officer (reviews break-glass), and the high-infra patient (self-hosts). The person who is all three corners at once has their own section below.

2.2 Patient

• P1 — As a patient, I want an account created for me at my first visit, so that I never have to "sign up" for anything. Covered: Progressive Onboarding
• P2 — As a patient, I want to give a new doctor access with one tap of my card, so that check-in is no slower than today. Covered: Access Flows
• P3 — As a patient, I want to see every time anyone read my records and the coded reason why, so that access is never invisible. Covered: ER flow
• P4 — As a patient, I want to be told immediately when someone breaks the glass on my records, so that I can contest it while it's fresh. Covered: ER flow
• P5 — As a patient, I want my therapy notes kept out of routine access, so that seeing a new doctor doesn't expose my whole history. Covered: ER flow
• P6 — As a patient, I want to lose my card or phone without losing my records, so that a lost wallet isn't a medical event. Covered: Threshold Authority
• P7 — As a patient, I want to name my spouse as guardian, so that someone I trust decides when I can't. Covered: Roles
• P8 — As a patient, I want to read the note the ER wrote about me, so that I know what happened while I was out. Covered: ER flow
• P9 — As a patient, I want my records to follow me when I switch hosting providers, so that I'm never locked in. Gap: migration of space repos is upstream (listSpaces), but HATS doesn't spec what a patient sees
• P10 — As a patient, I want to let my sister see my medications and my partner act for me, without the system assuming what my family looks like, so that the people I actually trust are the ones involved. Covered: Identity & Circles

2.3 Clinician

• C1 — As an ER physician, I want allergies, medications, and advance directives for an unconscious patient within a minute, so that I don't treat blind. Covered: ER flow; latency target is a Gap
• C2 — As an ER physician, I want to break the glass when routine access isn't enough, so that I can act on my judgment and answer for it afterwards. Covered: ER flow
• C3 — As a clinician, I want HATS data to appear inside my existing EHR, so that I don't learn a new tool mid-shift. Covered: Architecture — not embedded; the EHR is a client of the institution node over FHIR R4
• C4 — As a clinician, I want to know who wrote a record and that it hasn't been altered, so that I can trust it clinically. Covered: Record Integrity (space commits are deniable, so integrity lives in the record)
• C5 — As a clinician, I want my notes to stay in my institution's custody for the retention period, so that I meet my legal obligations even if the patient revokes access. Covered: ER flow; conflicts with upstream space-deletion semantics (Gap)
• C6 — As an imaging technologist, I want exactly allergies and prior results, so that I can check contrast safety without seeing anything else. Covered: ER flow
• C7 — As a clinician, I want to sign in once through my hospital, so that HATS doesn't add another password. Covered: ER flow (hospital-hosted staff accounts)

2.4 Engineer

• E1 — As a hospital integrator, I want HATS exposed as standard FHIR R4 resources, so that our EHR consumes it like any other source. Covered: Architecture
• E2 — As an app developer, I want standard atproto OAuth with space: scopes and a published permission set, so that my consent screen is legible without custom work. Covered: ATProto Mapping
• E3 — As an app developer, I want a documented path to get my app onto the accredited allowlist, so that I know what passing looks like before I build. Gap: client attestation exists upstream; the HATS accreditation process does not
• E4 — As an operator, I want to run the HATS service with high availability, so that it isn't a single point of failure in an ER. Gap: open question in the ER flow
• E5 — As a self-hoster, I want my own PDS to work with any hospital, so that self-hosting is never a second-class choice. Covered: Autonomy Spectrum
• E6 — As an engineer, I want realistic test patients with no real PHI, so that I can develop against HATS without a BAA. Gap: no sandbox; Synthea is the standard source of synthetic FHIR patients
• E7 — As an engineer, I want every policy label to be a published code (HL7, NUCC, LOINC), so that I can map HATS onto systems I already have. Covered: ER flow

2.5 Center of the triangle

One person can be all three: a physician who builds software and is also a patient — often at the hospital they work for. Clinical informatics is a board-certified subspecialty, and many hospitals have a CMIO. This person is HATS's most likely early adopter and its classic insider risk.

• X1 — As a physician-informaticist, I want to wire HATS into my own department's EHR, so that I can show it working before asking anyone to fund it. Covered by design: Architecture — run an institution node and point the EHR at it
• X2 — As a physician-informaticist, I want synthetic patients to test against, never my own chart or a colleague's, so that piloting never touches real PHI. Gap: same as E6
• X3 — As a clinician who is also a patient, I want to choose which identity I'm using in each system, and have the system offer to switch when I'm clearly in the other role, so that I'm never locked out of either. Covered: Identity & Circles
• X4 — As a clinician treating my own family in an emergency, I want access to work and be reviewed afterwards, not blocked, so that the rules never cost a life. Covered: Identity & Circles

2.6 Triangle edges

Each pair of corners meets at one main interaction. Each needs to work for both sides at once.

2.7 Acceptance: the ER visit

One scenario that crosses all three corners.

2.8 Gaps

• Build the institution node (C3, E1, X1) — designed in Architecture; nothing exists yet, and it's what clinicians and integrators actually touch
• Record integrity minimums (C4) — the socket is designed in Record Integrity; which providers each collection requires is still open
• Retention vs. deletion (C5) — upstream says syncers delete on space deletion; HIPAA retention says they can't
• ER latency target (C1) — define "within a minute" end to end, card tap to rendered allergies
• Accreditation process (E3) — who accredits apps and institutions, and how an app gets onto the allowlist
• HATS service availability (E4)
• Synthetic-data sandbox (E6) — Synthea patients loaded into test PDSes
• Patient-facing migration (P9)

3.1 One daemon, three modes

The same software runs everywhere; only its role changes.

The coordinator plays the part of Tailscale's coordination server: control plane only, never data. As Headscale is to Tailscale, a self-hostable coordinator lets an institution run its own, which addresses the coordinator-availability question in the ER flow.

3.2 API

Every surface is an existing standard, so anything that already speaks healthcare integrates without learning HATS.

The EHR integrates as a client of the institution node — the same way for Epic, Cerner, or anything homegrown.

3.3 Storage

• Records carry FHIR resources inside atproto records
• Decimals are strings. The atproto data model disallows floats, and FHIR treats decimal precision as significant (7.250 is not 7.25). A string preserves both
• Encrypted at rest on every node. Personal mode on a phone uses the platform keystore

3.4 Offline operation

A node operates indefinitely without a connection. This is the origin problem: hospitals go fully analog during cyberattacks because their systems are cloud-only. An institution node keeps serving its LAN from its local copy no matter how long it is cut off.

• Reads come from the local copy. Space credentials are only needed to pull from other hosts, not to serve what a node already holds
• Writes go to the node's own repo and queue for upstream; repo hosts already retry write notifications until they land
• Accountability fills the gap. Every local read is logged against the reader and reconciled on reconnect (below)

3.5 Sync and reconciliation

Most of the merge problem never arises, because of two properties already in place:

• Single-writer repos — every account writes only to its own space repo, so two parties never write the same record
• Additive amendments — an amendment is a new record (Record Integrity), so nothing is overwritten

Together, reconciling two copies is a set union — a grow-only set, the simplest conflict-free replicated data type. The upstream sync path already does this: compare LtHash digests, list the difference, fetch what's missing.

Two cases need rules:

The amendment chain is a Merkle DAG — the same structure as git history and IPFS. History is recomputable from the records alone.

3.6 LAN peer fetch

Ideas taken from IPFS, without the public network:

• Content addressing — atproto CIDs are a blessed subset of the IPFS CID format, and DRISL is the successor to DAG-CBOR. A record or blob verifies against its CID and attestation signatures wherever it came from, so the source doesn't matter
• Local discovery — nodes on the same LAN find each other via mDNS (as kubo does) and fetch from whichever peer has the data. Institution nodes in one hospital serve each other while the internet is down. This fills in the federated replica mesh left as a stub in Autonomy Spectrum
• Large blobs — imaging is content-addressed and fetched from the nearest node, which answers much of the DICOM question in Open Questions

What not to take:

• The public DHT — it announces who holds which CID, a metadata leak for health data. If HATS uses libp2p, it is a private swarm with a shared key. Kubo describes its private networks as "stable but not quite ready for prime-time"
• Content addressing as access control — it isn't. Data in the swarm is encrypted, and a peer only serves what the requester is authorized for

3.7 Open Questions

• Offline clocks — "reads after the revocation" depends on an offline node's clock. How much drift is tolerated, and what is trusted for ordering?
• Peer authorization while offline — inside one institution, nodes share its authorization. Should peers from different institutions ever serve each other offline?
• Personal mode on iOS — iOS does not allow persistent background daemons. Personal mode there is probably push-driven, backed by a hosted node
• Local socket auth — which local apps may connect, and how they prove it
• SSE — offer it as a custom Subscriptions channel, or websocket only?
• Coordinator in the same binary — or a separate deployable?

4.1 Patient

The space authority: every health.hats.records.* space and the health.hats.audit.log space sit under the patient's DID. The patient controls access — by card + PIN, or through an act circle member — and every grant lands in their audit log.

Controlling a space is not hosting everything in it. Records a provider authors live in the provider's own repo inside the patient's space; the patient's repo holds only what the patient authored.

No one reads the patient's spaces or writes into them without a grant from the patient or an act member, or an audited emergency grant (ER flow).

4.2 Provider (Consumer)

A hospital, clinic, or practitioner granted read access to named IPS-section spaces during an active care relationship.

• Reads the granted spaces with 10-minute space credentials, renewed while the grant is active — n confidentiality only unless the patient grants r
• Writes encounter notes into its own repo inside the patient's health.hats.records.encounters space, never into the patient's repo. The patient controls the space; the provider holds custody of what it authored
• Loses live access when the grant expires or is revoked: the coordinator stops answering checkUserAccess, and outstanding credentials die within 10 minutes
• Does not keep syncing after discharge

4.3 Backup Provider

A provider whose institution node keeps syncing the patient's spaces while authorized. Upstream has no replica credential — space credentials are always read-only and last at most 60 minutes — so a backup provider is simply a syncer that keeps renewing.

• Authorized by an ordinary health.hats.provider.grant whose window outlasts the visit; there is no separate replica request
• Its local copy serves the institution's LAN through outages (Offline operation)
• When the grant ends, renewals stop and nothing new syncs
• Keeps custody of what it authored, in its own repo
• Post-care retention is unresolved. Upstream expects syncers to delete on space or account deletion; jurisdiction retention rules (e.g. 7 years in the US) forbid it. See Retention vs. deletion
• The patient sees the grant and its window in health.hats.audit.log

4.4 Guardian

HIPAA's personal representative — for minors, incapacitated patients, and designated healthcare proxies.

Precedence for an incapacitated patient: Guardian → Threshold quorum → Break-glass. A valid guardian delegation governs and the quorum never activates; the quorum is the fallback when no guardian exists or is reachable.

One exception: an unresponsive ER patient can't wait on a reply, so the ER flow notifies the guardian rather than blocking on them. The guardian can end emergency access at any time by granting or revoking.

4.5 Validator

A licensed, accredited healthcare institution that countersigns notarized-consent attestations — vouching for the existence and timing of a provider's consent assertion, not its truth. Eligibility piggybacks on institutional accreditation (NPI, Joint Commission); selection must be non-collusive (open problem). See Threshold Authority & Notarized Consent.

4.6 Quorum Shareholder

A holder of one share of the patient's threshold authority (TSS partial-signing key). Plausible shareholders: the patient's phone/card, authorized providers, a public-benefit "PDS of last resort." K-of-N partial signatures authorize authority-level operations (root rotation, card reissue) — only when the patient cannot will their own signature and no guardian governs. Composition is an open problem.

5.1 A person is a set of DIDs

Identity stays the DID. A person may use one DID for everything, or keep separate DIDs for personal and work life. HATS supports both, and runs policy over the set, so the two models behave the same.

One DID is just a set of size one.

5.2 Linking DIDs

• Mutual — each DID signs a statement naming the other, using the same attestation mechanism as Record Integrity. Neither side can link or unlink alone
• Private — the link is held in the HATS service's provider registry, never in a DID document or a public repo. A public work ↔ personal link is a harassment risk for some clinicians (abortion providers are the obvious case)
• Declared — for clinicians, declaring a linked personal DID is a credentialing obligation, like a conflict-of-interest disclosure
• Audited — unlinking is recorded and reviewed. Quietly dropping a link is exactly what someone planning to snoop would do

5.3 Choosing which identity to act as

The person chooses; the system helps; nobody gets locked out.

• The person picks which identity to use with any given system, and the system honors it
• The system suggests — if a patient DID linked to a clinician who works here starts doing clinician things, the system asks "Continue as Dr. X?" and switches to the clinician DID on confirmation. The same works in reverse
• Attribution follows the identity actually used. This is the one hard invariant: every action is recorded against the DID that performed it, which is what keeps access accountable

5.4 Self and circle access

A clinician acting on their own record, or on someone in their own circle, is allowed and flagged — never blocked. Clinicians do treat family in emergencies.

Reading one's own chart is harmless through either identity; the risk is in writes and orders.

5.5 Circles

A circle is a set of DIDs around a patient, each with its own delegation. No family structure is assumed: circles can overlap, and chosen family is as valid as any other.

Delegations, from least to most authority:

A guardian is a circle member with an act delegation. Precedence for an incapacitated patient is unchanged: Guardian → Threshold → Break-glass, with the ER exception that guardians are notified rather than waited on (see ER flow).

Everything here is an existing part:

5.6 Circles as conflict detection

A clinician's own declared circle doubles as their close relations for conflict checks. Clinical access to a circle member through the clinician role follows the self-access table above.

The honest limit: circles are self-declared, so a clinician can leave out an ex — the classic snooping target. HATS can't prevent that. It catches it afterwards: every access is attributed and reasoned, so review can find it. This is access is accountability doing its job.

5.7 Open Questions

• Re-delegation — can a view member pass access on? Probably not; act only
• Minors — state-specific independent rights for some record types (see Open Questions)
• Circle visibility — does a member see who else is in the circle?
• Undeclared relations — inferring relations beyond declarations (shared address, shared insurance) would catch more but is invasive. Leaning no
• Link registry — where exactly the private link lives, and who besides the HATS service may read it
• Groups spec — track the atmosphere groups working group and adopt rather than define

6.1 Shape

A record's address puts all of it together:

• Read access is per space, so the IPS section × confidentiality pair is the unit a grant opens. This is what lets the ER flow grant by LOINC section
• Every author writes to their own repo. Patient-authored and clinician-authored records share a space; each sits in its author's space repo
• Decimals are strings — atproto disallows floats; see Architecture

6.2 IPS section spaces

One space type per section of IPS 2.0.1 (FHIR 4.0.1). Collections are the resource types IPS allows in that section; every section also allows DocumentReference.

Collection NSIDs are the FHIR type in camel case under health.hats.fhir: Condition → health.hats.fhir.condition, AllergyIntolerance → health.hats.fhir.allergyIntolerance.

6.3 Other spaces

Records outside the IPS summary, and the access ledger.

6.4 Space type declaration

Each space type is a lexicon with "type": "space", per proposal 0016. The name is what a consent screen shows.

key is any because 0016 has no key type for a fixed set; HATS restricts the skey to n, r, v.

6.5 Confidentiality: the skey

A patient has at most one space per (section, confidentiality) pair, created when the first record needs it.

6.6 Removed

6.7 Open Questions

• Publishing account — which DID publishes the schemas (the did= value in each _lexicon record)
• DocumentReference everywhere — IPS allows it in every section, which makes it an escape hatch for putting anything anywhere. Restrict it?
• Raising confidentiality — moving a record from n to r means a new record in the r space, but the n copy still leaks unless it's removed. That collides with additive-only amendments; restricting is the one case that may need a real deletion
• Grant record body — health.hats.provider.grant has no defined shape yet. FHIR R4 Consent already models grantee, action (including write), period, and data class; reuse it rather than define one
• Patient story — IPS allows any resource; restrict to narrative?
• FHIR version — IPS 2.0.1 is on R4 (4.0.1). Migration path to R5/R6 profiles

7.1 The socket: atproto attestations

HATS uses the community atproto attestation spec (Rust implementation: atproto-attestation) rather than defining a signature format.

• A record carries a signatures array — an open union, so each entry declares its own scheme with $type
• Inline entries carry a signature and key
• Remote entries are strong references to a proof record in the attester's own repo
• The signed content is the record's CID, computed with a $sig object that names the repository DID, so a signed record cannot be cloned into another repo and replayed

7.2 Amendment chain

HIPAA's right to amend means correction is additive, never destructive.

• Each version carries prev: an array of com.atproto.repo.strongRef (URI + CID) naming the version it amends. The first version has none; a merge of two offline forks names both (see Architecture)
• An amendment is a new record with a new rkey. The old version stays as its own record. Space repos are a set with no history (LtHash, droppable oplog), so overwriting in place would make prev point at nothing
• The latest version is the chain head; the full history is recomputable by walking prev

7.3 Providers

Each scheme is just another $type in the union. A record can carry several; a verifier checks the ones it understands.

These map onto the cryptographic tiers in ATS Foundations: signatures settle authorship, the chain and receipts settle integrity. Semantic disputes still need a human.

7.4 Deniable vs. transferable

A signed record is transferable: if it leaks, it is provably authentic. That is right for clinical records — signed charts work this way today — and wrong for a patient's personal notes. Signing is opt-in per collection.

7.5 ZTK: the Mina idea

The "zero trust token" this doc grew from turned out to be Mina: a blockchain that stays a 22 KB fixed size by recursive zero-knowledge proofs, each proof verifying the previous one, so one small proof stands for the entire history.

HATS takes the technique, not the chain:

• Use — a constant-size proof per record that its amendment chain is intact and every amendment was signed by an authorized author, revealing no content. A court, insurer, or privacy officer gets "never altered after T" without seeing PHI
• Don't use — Mina's public chain, its accounts, or any global ledger. Identity stays the DID, and proofs of health records on a public chain are a metadata leak
• Cost — proving is heavy (minutes of CPU per proof): a job for the institution's server writing the record, not a patient's phone. Verifying is cheap
• Maturity — Mina's mainnet launched in 2021 with modest adoption. o1js is a prototyping candidate, not a commitment

7.6 Upstream feedback

• Bind the space, not just the repository. In spaces a record lives at (space, author). The attestation $sig names only the repository DID, so a signed record could be replayed into a different space by the same author. $sig should carry the space URI for space records

7.7 Open Questions

• Minimum per collection — is an author signature the only hard requirement for clinical records, with everything else optional?
• Key rotation — verifying an old signature needs the author's key as of signing time. PLC's audit log provides history for did:plc; what about did:web?
• Spec stability — the attestation spec is a community draft; pin a version
• What the ZK proof proves — chain validity only, or properties too ("no amendment after T", "authored by a clinician licensed at the time")?
• Transparency service metadata — a log entry reveals that something was recorded at T. Submit opaque hashes only, and decide who runs the log

8.1 Routine Care

1. Patient arrives at clinic; the card's DID (readable without the PIN) says whose spaces to ask about
2. Clinic requests the IPS-section spaces it needs (e.g. health.hats.records.problems, health.hats.records.medications, health.hats.records.allergies), plus write to health.hats.records.encounters
3. Patient (or an act circle member) authorizes via card + PIN; a health.hats.provider.grant — provider DID, sections, confidentiality, expiry — is written to the patient's health.hats.audit.log
4. The coordinator syncs the audit log and answers checkUserAccess from the grant
5. The clinic's EHR gets 10-minute credentials per granted space, as in the ER flow — n confidentiality only unless the grant names r
6. The clinic's institution node syncs those spaces, renewing credentials while the grant is active
7. Visit notes go into the clinic's own repo inside the patient's health.hats.records.encounters space
8. The grant expires on discharge or at its TTL, or the patient revokes it. The coordinator stops answering yes; outstanding credentials die within 10 minutes

8.2 Admission + Backup

1. Hospital requests access as above. To stay a Backup Provider, it asks for a window that outlasts the stay
2. Patient (or an act circle member) signs one health.hats.provider.grant. There is no separate replica request — upstream has no replica credential
3. The hospital's institution node syncs the granted spaces and keeps renewing; its local copy serves the ward through outages (Offline operation)
4. Inpatient notes and the discharge summary go into the hospital's own repo in health.hats.records.encounters
5. Discharge is grant expiry or revocation — nothing to downgrade, since credentials were always read-only. Renewals stop and syncing ends
6. The hospital keeps custody of what it authored. Whether it may keep its synced copy of everything else is the open retention vs. deletion conflict

8.3 Notarized Consent (conscious, can't sign)

For a patient who can verbally consent but cannot digitally sign (card lost, PIN forgotten, card in a property bag):

1. Treating provider asserts patient consent
2. A Validator (licensed institution, non-collusively selected) countersigns the existence and timing of the assertion — not its truth
3. The coordinator checks the Validator's countersignature, then writes a temporary health.hats.provider.grant carrying the attestation into health.hats.audit.log (no authority-level changes)
4. Patient reissues card later via quorum; attested grant surfaces for review on reclaim

8.4 Break-Glass (Emergency Access)

For unconscious or incapacitated patients with no guardian available (Guardian → Threshold → Break-glass precedence):

1. Provider invokes break-glass access
2. Provider gains temporary read access to a defined emergency subset of records
3. An immutable health.hats.audit.breakGlass record is written to the patient's PDS
4. On patient recovery/guardian availability, full grant flow resumes normally
5. Patient (or guardian) can review all break-glass events in audit log

9.1 Shape

Three separate problems, solved by three separate pieces:

The HATS service is a policy decision point plus a provider registry. It never stores or serves records.

9.2 Identify

The patient's NFC card (see Threshold Authority) carries their DID in a field readable without the PIN, plus a printed QR fallback. Reading the DID grants nothing; it only says whose spaces to ask about.

DID → PDS resolution is ordinary atproto identity resolution. No HATS directory is involved.

No card on them: register as a Doe patient, exactly as today. Link the Doe chart to the DID once the patient is identified. HATS does not maintain a central demographic or biometric index — that index would be the highest-value breach target in the system and recreates the silo HATS exists to remove.

9.3 Request emergency access

Every emergency request carries a reason. Routine emergency access is scoped by tiers; break the glass is a recorded override of them. There is no reasonless path.

Reason

A required code from HL7 v3 PurposeOfUse. There is no free-text reason.

• code — one of ERTREAT (emergency room treatment), ETREAT (emergency treatment, e.g. EMS in the field), or BTG (break the glass)
• description — clinical context. Optional for ERTREAT / ETREAT; required for BTG, because it is what an after-the-fact review weighs. Never a substitute for code

The reason is committed to the audit record before any credential is issued.

There are two levels of emergency access:

ERTREAT covers most ER visits without anyone having to break anything. BTG is for when the clinician judges they need more.

Label convention

HATS invents no vocabulary for policy. Every label is a code from an external, battle-tested standard; HATS only packages them.

• Stored lowercase: ertreat, 207p00000x, r
• Rendered in the standard's own case: ERTREAT, 207P00000X, R

Comparison happens on the stored form, so case can never split one code into two.

Record categories: IPS sections

The HL7 FHIR International Patient Summary (IPS) already defines "what a clinician needs about an unknown patient," as LOINC-coded sections. HATS uses one space type per IPS section, so space boundaries — the unit of read access — line up with the standard. Realigning Lexicon Namespaces to this is pending.

Tiers

For ERTREAT / ETREAT, access is decided from two inputs:

1. Clinician role — NUCC taxonomy code from the clinician DID's provider credential, via the same accreditation-VC machinery as Validators
2. Institution standing — from the EHR's attested client_id, mapped to an accredited institution

The role table is HATS policy; every entry in it is a standard code.

The radiologic technologist row is the RBAC point in miniature: allergies (contrast reactions) and prior results, nothing else.

Renewal past the window requires a new request with a new reason.

Sensitivity

Sensitive data is labeled with HL7's own scheme rather than a HATS one, and kept in separate spaces so labels apply at the space boundary:

• Confidentiality — N (normal), R (restricted), V (very restricted)
• Sensitivity — records tagged ETH, SUD, BH, MH, PSY, HIV, STD, SEX, SDV, or GDIS live in their own spaces labeled R. Psychotherapy notes (PSYTHPN) are labeled V

Break the glass

BTG trusts the clinician's judgment in a life-threatening situation and settles it afterwards. It does not prevent access; it makes access deliberate, attributable, and reviewed. This is the ATS accountability thesis applied directly: lying (or snooping) isn't made impossible, it's made expensive and permanently visible.

• Who — any verified clinician at an accredited institution. Role does not cap BTG; accountability requires a known, accountable party, so an unknown institution cannot BTG
• Opens — every section, including R spaces. V stays closed: psychotherapy notes need the patient's specific authorization under HIPAA (45 CFR 164.508(a)(2)) even for treatment, so no override can lawfully open them
• Window — 4h, renewable only by a new BTG with a new description
• Notifies — patient and guardian immediately, not on recovery
• Review — every BTG lands in the institution's privacy-officer review queue. HIPAA already requires access audits; HATS hands them a signed record instead of a log export

R sensitivity categories line up with existing law: 42 CFR Part 2 permits disclosure of substance-use records in a bona fide medical emergency, which is the BTG case.

Request

The clinician's EHR calls the HATS service:

Authenticated as the clinician (service auth) and the EHR (client attestation). The HATS service:

1. Verifies the clinician's provider credential and the EHR's attested client_id
2. Checks the reason code, then resolves role × institution to a set of IPS sections and a window
3. Notifies the patient's guardian, if one is designated (see Guardian below)
4. Writes a health.hats.audit.breakGlass record — clinician DID, institution, reason, sections, window — into its own repo in the patient's health.hats.audit.log space
5. Records an active grant (clinician DID, patient DID, sections, expiry) and returns the sections

Audit precedes access: if step 4 fails, no grant exists.

9.4 Read

Standard atproto spaces credential flow, per space in the granted sections:

1. EHR gets a delegation token from the clinician's PDS (com.atproto.space.getDelegationToken)
2. EHR calls com.atproto.space.getSpaceCredential on the patient's PDS with the delegation token and its client attestation
3. The patient's spaces run readPolicy: managing-app with the HATS service as managingApp, so the PDS calls com.atproto.simplespace.checkUserAccess on the HATS service
4. The HATS service answers yes only if an active grant covers this clinician and this section
5. The PDS applies appAccess: #allowList (accredited EHRs only) and mints a 10-minute credential
6. EHR syncs the space and renews credentials until the grant window closes

When the window closes, the HATS service starts answering no. Outstanding credentials die within 10 minutes; for faster cutoff the patient's PDS can send notifyCredentialRevoked.

9.5 Write back

The ER note does not go into the patient's repo — under atproto spaces, every account writes only to its own space repo. The hospital writes the encounter into its own repo inside the patient's health.hats.records.encounters space. writePolicy: managing-app means the HATS service also gates which writers the patient's space tracks.

The patient controls the space; the hospital holds custody of what it authored. ATS Foundations carries the same custody-vs-authorship model.

9.6 Close out

• Grant window closes; no further credentials
• Patient (on recovery) or guardian reviews every health.hats.audit.breakGlass record in their audit space
• Normal grant flow resumes via card + PIN, or guardian

9.7 Setup prerequisites

Done at onboarding (or by the first provider, per Progressive Onboarding):

• Each health.hats.records.* space created via com.atproto.simplespace.createSpace with:
  • readPolicy: managing-app, writePolicy: managing-app
  • managingApp: the HATS service's service identifier
  • appAccess: #allowList of accredited EHR client IDs
• A health.hats.audit.log space whose tracked writers are the patient, their act circle members (grants), and the HATS service (break-glass records)
• DID written to the card

Clinicians need an atproto DID and an OAuth session through their EHR. In practice, hospitals host staff accounts on their own PDS.

9.8 Guardian

Existing precedence is Guardian → Threshold → Break-glass. An unresponsive ER patient cannot wait on a guardian's reply, so this flow notifies the guardian in parallel rather than blocking on them. The guardian can end break-glass at any time by issuing a normal grant (or revoking). This is a deliberate softening of the precedence rule for the emergency case and should be reflected in Roles.

9.9 Open Questions

• HATS service availability — it is in the critical path of every ER read. managingApp is a single service identifier. What happens when it is down? Replicated instances behind one DID, or a cached fail-open grant of the IPS required sections on the patient's PDS?
• No reason in checkUserAccess — the upstream method carries space, user, access, and client, but no purpose. HATS works around this by pre-registering the grant. Worth raising with the spaces team as a purpose field.
• BTG review outcomes — the record settles what happened; who decides whether it was justified, and what follows, is external (privacy officer, licensing board, courts). Does HATS define a review-outcome record, or stay out of it?
• Role credentials — NUCC taxonomy codes are self-reported in NPPES and coarse. Is that enough to tell an attending from a resident, or does the institution attest roles for its own staff?
• Abuse detection — rate limits and anomaly review (an imaging tech requesting break-glass on many patients). Post-hoc review only, or real-time throttling?
• Patient PDS unreachable — this flow assumes the patient's PDS is up. Without its space host no new credentials are issued, so the floor is whatever an institution node already holds locally (Offline operation, LAN peer fetch).
• IPS section ↔ NSID mapping — space types are NSIDs; the LOINC code needs a home (a HATS-published mapping table, or a field on the space type declaration if upstream allows extra fields).

10.1 Concept Mapping

10.2 URI Structure

Spaces reuse at:// with a literal space segment:

Segment by segment in Lexicon Namespaces.

The space alone — at://did:plc:patient/space/health.hats.records.allergies/n — is the sub of the delegation token and the space credential. The delegation token and client attestation are addressed to the space host, did:plc:patient#atproto_space_host.

The HATS-specific point: the space type is the HIPAA compliance boundary and the OAuth consent boundary. Read access is all-or-nothing per space, so per-modality space types are required, not just preferred — one universal health.hats.space would be illegible and ungrantable. Each space type declaration carries a name for consent screens, so the screen reads "give this app access to your Allergies and intolerances" rather than "access to your health records."

10.3 HATS-Specific Gaps

The full list lives on Open Questions; what HATS is raising upstream is in Upstream.

Resolved

• App allowlists — simplespace appAccess: #allowList plus client attestation: only accredited EHRs get a credential. HATS's job is the allowlist and the permission set, not a mechanism
• HIPAA amendment — space repos are a set with no history, so the repo gives neither tamper evidence nor an amendment trail. Correction is an additive amendment chain carried in the records, and integrity comes from record signatures, not commits (Record Integrity)

Still open

• Retention vs. deletion — syncers are expected to delete their copy when a space is deleted; HIPAA retention forbids that for a hospital
• No purpose in checkUserAccess — the call carries space, user, access, and client, but no purpose of use. HATS pre-registers grants instead (ER flow)
• Space binding for record signatures — the attestation $sig names the repo DID only, not the space URI (Record Integrity)

11.1 What changed

11.2 Already realigned

• ER: Unresponsive Patient — written against the alpha: managing app, client attestation allowlist, author-custody write-back, IPS sections
• Record Integrity — answers deniable commits
• Identity & Circles — replaces the Guardian model
• Lexicon Namespaces — one space type per IPS section, confidentiality as the space key, FHIR resources as records
• ATProto Mapping — concept table rebuilt on 0016
• Roles, Access Flows — backup provider as syncer, flows rebuilt on managing-app policy
• ATS Foundations — custody vs. authorship, record-level evidence, addressing, sync, credentials, default-deny
• Autonomy Spectrum, Progressive Onboarding — hosts and syncers instead of replicas; claiming the DID via PLC
• HATS.hospital, .public, .pneumatic — institution-authored spaces, FHIR workflow resources, Subscriptions for delivery

11.3 Pending realignment

Nothing pending — every doc has been reviewed against the alpha. New gaps live in each doc's open questions.

11.4 Feedback for the spaces team

For the spaces office hours and the WG Private Data forum:

• Purpose in checkUserAccess — the method carries space, user, access, and client, but no purpose of use. HATS works around it by pre-registering grants; a purpose field would let managing apps decide inline
• Space binding for record signatures — the community attestation spec's $sig names the repository DID only; space records should bind the space URI (see Record Integrity)
• Transferable proofs, when wanted — deniable commits are right for social data. Regulated data wants transferable proof for some records. A standard way for a record to carry its own signature would beat every app inventing one
• Retention vs. deletion — "syncers delete on space deletion" is unlawful for a hospital under retention rules. Regulated syncers need a defined exception, or at least an acknowledged one

12.1 Protocol

• How does an institution node's retained copy interact with jurisdiction-specific retention law? Does the protocol encode retention periods, or is that app-layer config?
• Circle act scope: can an act member grant an institution long-lived (backup) access, or only visit-scoped access?
• Amendment flow: if a patient amends a record, how does that propagate to synced copies held by former providers?

12.2 Infrastructure

• DICOM / large imaging blobs: separate blob CDN with credentialed access, or out of scope entirely? Partly answered by content-addressed LAN peer fetch in Architecture
• PDS hosting for patients: who runs patient PDSes in practice? Hospitals (reintroduces custody problem), co-ops, insurance companies, personal hosting?
• Offline/emergency access: if no copy is reachable at all (patient's PDS down and no institution node holding their spaces), what's the floor? Partly answered by offline operation — an institution node serves its LAN from its local copy indefinitely, and LAN peer fetch reaches other nodes in the same hospital. The floor is a patient no reachable node has synced, since new space credentials need the patient's space host.

12.3 Legal / Compliance

• BAA coverage: which nodes in the atproto relay network need BAAs?
• Right to deletion vs. atproto's append-only architecture: how do we handle HIPAA's right to request amendment/deletion?
• GINA implications: genetic data (now health.hats.records.results records tagged GDIS, held in the r space — see Lexicon) has additional protections.
• Minor records: HIPAA gives minors independent rights in some states for certain record types (mental health, reproductive). Guardian delegation needs to handle this.

12.4 Raised since July

Newer questions live with the docs that raised them:

• Retention vs. deletion — upstream expects syncers to delete on space deletion; HIPAA retention forbids it. See Upstream
• HATS service availability — in the critical path of every ER read. See ER flow
• Record integrity minimums, key rotation, ZK proof scope — see Record Integrity
• Circles: re-delegation, visibility, minors — see Identity & Circles
• Institution node, accreditation, sandbox — the biggest adoption gaps. See User Stories
• Offline clocks, peer authorization, iOS background limits — see Architecture

12.5 Resolved

• PDS hosting for patients → it's a spectrum, not a choice. See Autonomy Spectrum: phone-only users get threshold-split authority + provider-hosted replicas; median users get hosted PDS; high-infra users self-host. Control plane (card/phone) never requires hosting.
• Guardian vs. Threshold Authority precedence → Guardian precedes. Guardian is the pre-designated incapacity path; threshold quorum is the fallback when no guardian exists or is reachable. Order: Guardian → Threshold → Break-glass.
• Generic vs. per-modality space type → per-modality. Daniel's June 2 "particular spaces, universal communities" argument settles it: one universal health.hats.space is illegible at consent and breaks the access boundary. HATS uses per-modality types (health.hats.records.labs, etc.), with the "whole patient record" assembled at the app layer by grouping spaces under the patient DID.
• Re-tiering: can a patient change a record's access tier after a provider has already read it? → Superseded by amendment flow; re-tiering is not a protocol operation.

13.1 Subspaces

HATS.hospital.public

The institutional face to the patient and to other institutions. What the patient's grant actually covers. Referrals, transfers, inter-hospital record sharing, specialist consults. The workflow runs in a space between two institutions; the clinical records stay in the patient's spaces, read under a health.hats.provider.grant.

HATS.hospital.pneumatic

Operational messaging within and between institutions. Bed availability, transfer coordination, lab routing, incident messaging, on-call handoffs. Low-latency and kept out of the patient's spaces, but every message is a signed record in an institution's space repo.

13.2 Spaces

Institutional spaces are authored by institutions, not patients. Each institution writes only to its own space repo; the patient's spaces are touched only through the ordinary grant flow.

• Authority is the institution's DID, not a dedicated space DID. simplespace anchors spaces on the caller's own DID, and a relationship between two hospitals has no reason to outlive either of them
• member-list, not managing-app, between institutions — the partner set is small and changes by agreement, not per request. It also keeps the HATS coordinator out of the path of institution-to-institution traffic
• Deterministic addresses — at://did:plc:swedish/space/health.hats.hospital.public/did:plc:uwmedicine is the space for Swedish's requests to UW Medicine. UW Medicine's requests to Swedish go in UW Medicine's space for Swedish
• appAccess: #allowList of accredited EHR and institution-node client IDs, as on patient spaces
• No PHI beyond references. Institutional records point into the patient's spaces by strongRef; reading what they point at still takes a grant

13.3 Trust Model

Inter-hospital interactions are institution-to-institution bilateral records — the same double-entry primitive as HATS.user (ATS Foundations), but both sides are institutional DIDs rather than patient + provider. Both sides sit in the same space, each in its author's repo.

Same audit guarantees: both records carry their author's signature (Record Integrity), both name the same strongRef (URI + CID), and alteration is detectable. Space commits are deniable, so the signatures are what make the trail evidence. External arbiter (accreditation bodies, CMS, malpractice law) consumes the trail as needed.

13.4 HIPAA TPO Coverage

Neither subspace requires explicit per-event patient authorization because both fall under HIPAA's Treatment, Payment, and Operations exception — internal and inter-institutional uses of PHI inherent to receiving care. The patient's sharing grant (health.hats.hospital.sharingGrant) is the authorization surface. Pneumatic inherits it.

Pneumatic never widens access. A message that references a lab result is readable by anyone in the space; the result itself is readable only under the recipient institution's own grant.

13.5 Open Questions

• skey convention — patient spaces key on HL7 confidentiality (n, r, v); institutional spaces key on the partner or unit instead. Does a referral for a restricted category (e.g. 42 CFR Part 2 substance use) need an r split as well?
• Retention vs. deletion — if an institution deletes a space, upstream expects the partner, as a syncer, to delete its copy. Both are covered entities with retention duties. The partner's own records survive in its repo; the copy of the other side does not
• Space discovery — readers are never enumerated upstream, so a partner learns a space exists out of band. The deterministic address helps; first contact still needs a notice

14.1 Scope

• Patient-facing records: visit notes, labs, imaging metadata, medications, discharge summaries — in the patient's health.hats.records.* spaces, each institution writing into its own repo there
• Inter-hospital sharing: referrals, specialist consults, transfer records, imaging handoffs — workflow in an institution-to-institution space (Spaces), records read from the patient's spaces under a grant
• Pre-authorized sharing classes (patient sets policy, not per-event consent)

14.2 Pre-Authorization Model

Rather than signing off on each inter-hospital data share, the patient pre-authorizes a sharing class at grant time. Each class is a FHIR R4 Consent (scope patient-privacy), built from codes that already exist:

The grant record lives in the patient's own repo in their health.hats.audit.log space, signed by the patient, beside the health.hats.provider.grant records it gives rise to. Institutions honor it without further patient interaction. Every grant issued under it cites it by strongRef, so the patient's audit log shows each institution it was used for.

v (psychotherapy notes) is outside any sharing class: HIPAA requires the patient's specific authorization even for treatment (Lexicon Namespaces).

14.3 Lexicon Namespaces

Inherits all health.hats.records.* namespaces from HATS.user. Adds one space type and the sharing grant. Referrals, transfers, and consults are not HATS records: each is a FHIR ServiceRequest from the requesting institution plus a Task from the receiving one, in the requester's space for that partner.

Task follows the FHIR workflow pattern with one change forced by single-writer repos: the receiver writes its own Task naming the requester's ServiceRequest in focus, rather than updating a Task the requester created. Status changes are amendments (Record Integrity).

Referral

ServiceRequest — requester: referring institution, performer: receiving institution, subject: the patient, reasonCode: SNOMED CT or ICD-10, supportingInfo: strongRefs into the patient's spaces. The receiving institution answers with a Task (accepted, rejected, completed).

Transfer

Transfer record — same structure as referral but marks a care handoff. Triggers a health.hats.provider.grant for the receiving institution.

The grant is written by the coordinator into its own repo in the patient's health.hats.audit.log, citing the sharing grant that allows it — the same move as the notarized-consent grant in Access Flows. The care handoff itself is recorded in the patient's health.hats.records.encounters space: the sender's Encounter names the receiver in hospitalization.destination, the receiver's names the sender in hospitalization.origin.

Consult

ServiceRequest for a specialist opinion. Access is an ordinary health.hats.provider.grant for the IPS-section spaces the consult needs — credentials are always read-only, whole-space, and short-lived, so "scoped" means which sections, not which records. The consultant's note goes into its own repo in the patient's health.hats.records.encounters space; its Task closes as completed.

health.hats.hospital.sharingGrant

Patient-signed pre-authorization of a sharing class. The record body is a FHIR Consent (above). Stored in the patient's health.hats.audit.log space. Referenced by institutions when initiating inter-hospital access, and read by the coordinator when it answers checkUserAccess.

14.4 Inter-Hospital Bilateral Record

UW Medicine then reads the patient's health.hats.records.results space like any provider: delegation token, 10-minute space credential, renewed while the grant lasts.

14.5 Open Questions

• Requesting the derived grant — the sending institution has to ask the coordinator for the receiver's grant. No request method is defined (the ER flow has health.hats.requestBreakGlass), and the coordinator cannot read the institution space to check the ServiceRequest it is cited for
• Grant home — Lexicon Namespaces lists health.hats.records.consent for "treatment and sharing consents" but puts policy inputs in health.hats.audit.log. This page puts the sharing grant in the audit log, where the coordinator already syncs
• One grant shape — health.hats.provider.grant and health.hats.hospital.sharingGrant would both be FHIR Consent. Merge them into one collection distinguished by provision?
• Network-wide class — "any HATS-compliant institution" needs an accreditation source the coordinator can check, the same question as Validator eligibility

15.1 Scope

• Bed availability and capacity coordination
• Transfer requests and logistics
• Lab specimen routing and result alerts
• Incident and emergency coordination
• On-call handoffs and staffing
• Internal clinical alerts (not patient-facing)

15.2 Design Principles

Ephemeral but auditable — messages don't live in the patient's spaces, but every exchange leaves a signed record on each side. Fast in transit, permanent in log.

Low-latency — spaces are a sync layer, not a message bus: write notifications are best-effort, and syncers pull. Delivery rides on FHIR Subscriptions between institution nodes (websocket or rest-hook). The record is written before the push, not after — a write to one's own repo is local and instant, so audit precedes delivery, as in the ER flow.

Institution-scoped — spaces are authored by institutions (Spaces). Within one institution, the institution's own node is the managingApp and answers from its staff directory; between two, the partner is on a member-list. The HATS coordinator is in neither path. No patient DID is a writer, and nothing is written to the patient's spaces.

TPO-covered — no patient authorization required per-message. Covered under the patient's sharing grant via HIPAA's Operations exception. Pneumatic never widens access: a message carries strongRefs into the patient's spaces, and the recipient reads them only under its institution's own grant.

15.3 Lexicon Namespaces

Each health.hats.pneumatic.* NSID is a space type, separated by audience since read access is all-or-nothing per space. Records are FHIR R4 resources, as everywhere in HATS.

health.hats.pneumatic.alert

Clinical alert routed between departments or institutions. A FHIR Communication: priority (routine, urgent, asap, stat), subject: the patient, about: strongRef to the source record (e.g. a DiagnosticReport in the patient's health.hats.records.results space). Bilateral: sender writes, receiver acknowledges with its own Communication whose inResponseTo names the alert.

health.hats.pneumatic.bedRequest

Capacity/transfer coordination. Institution A asks Institution B for bed availability. No PHI: bed status is FHIR Location.operationalStatus (HL7 v2 table 0116), aggregate capacity a MeasureReport, the ask a Task. Once a specific patient is named, the request becomes a transfer in .public — PHI stays out of the capacity space.

health.hats.pneumatic.handoff

On-call or care handoff. The outgoing clinician writes a Communication naming the incoming clinician as recipient and the patients' Encounters in about; the incoming clinician accepts with a Communication in response. Each signs its own record — there is no co-signed single record in spaces. Clinician DIDs are staff accounts on the institution's PDS.

health.hats.pneumatic.incident

Incident or emergency coordination. Institution-scoped, or bilateral between participating institutions. Existing standards per kind:

15.4 Audit Trail

Each pneumatic message produces a bilateral record — both sides in the same space, each in its author's repo:

Neither party can later claim the alert was not sent or, once acknowledged, not received: both records carry author signatures (Record Integrity), since space commits alone prove nothing to a third party. An alert with no acknowledgment is visible as exactly that. External arbiters (accreditation bodies, incident review boards, malpractice proceedings) can request the bilateral log.

15.5 Relationship to HATS.hospital.public

Pneumatic is the internal plumbing. Public is the external face. A lab result flows:

1. Lab produces result → Observation / DiagnosticReport in the lab's own repo in the patient's health.hats.records.results space (under the institution's grant)
2. Alert fired internally → Communication in a health.hats.pneumatic.alert space, pushed to the treating physician by FHIR Subscription
3. Physician acts → encounter note in the institution's own repo in the patient's health.hats.records.encounters space

Pneumatic sits in step 2 — invisible to the patient, auditable by institutions.

15.6 Open Questions

• Delivery guarantee — FHIR Subscriptions deliver at most as reliably as their channel. Critical results need a closed loop (read-back, escalation on no acknowledgment); is that HATS's job or the receiving EHR's?
• Internal space granularity — read is all-or-nothing, so one alert space per unit means every member of the unit can read every alert. Per care team is tighter but means many more spaces
• Handoff responsibility — the Communication pair records that a handoff happened, not who is responsible now. FHIR CareTeam (participant period) models that, but has no IPS space to live in
• Emergency standards — CAP and EDXL-HAVE are XML and predate FHIR. Carry them as Communication payloads, or map capacity onto MeasureReport throughout?
• Offline — internal pneumatic survives an internet outage only if the institution hosts its PDS (the space host) on site, not just its node

16.1 Control plane vs. data plane

The split that makes the spectrum work:

• Control plane — seeing who has access, granting, revoking, approving break-glass. This is a signing operation: every grant and revocation is a record in the patient's health.hats.audit.log, which the coordinator reads to answer checkUserAccess. It lives on the patient's phone (secure enclave), works offline, and propagates when connectivity returns.
• Data plane — hosting and serving the actual record bytes. Handled by repo hosts and syncers: the patient's PDS (hosted, or their own node) for what the patient authored, and providers' institution nodes for what they authored and what they're authorized to sync.

The key consequence: revocation and authority don't require hosting. Every patient space runs readPolicy / writePolicy: managing-app, so you're editing the access policy — not running a server. So every user — regardless of resources — gets the two things that actually constitute sovereignty: visibility (who can see my data) and veto (cut them off).

16.2 The spectrum

Same UX, same protocol, same ten-second revoke at every tier. A phone-only user can revoke a provider just as easily as someone running their own node — they simply don't host the bytes themselves.

16.3 Why this matters

Sovereignty that requires a homelab isn't sovereignty — it's a hobby for the already-resourced. The people a portable health record helps most (unhoused, chronically ill, transient) are the least able to run infrastructure. The autonomy spectrum ensures the protocol degrades gracefully toward zero personal infrastructure without ever collapsing back into "the hospital owns everything."

The phone is the floor: control without hosting. Everything above it is optional self-hosting.

16.4 Related & still-open threads

• Progressive Onboarding — see Progressive Onboarding (intake → claim → distribute, first-contact custody problem).
• Threshold / Shamir authority split — see Threshold Authority & Notarized Consent: card-as-master-key, notarized consent, TSS over Shamir.
• Federated replica mesh — superseded. Upstream has no replica credential and spaces have no relays: institution nodes are syncers that keep renewing while authorized, pulling directly from repo hosts, with write notifications sequenced by the space host. Peer-to-peer serving is LAN peer fetch; outages are covered by offline operation.

17.1 Core idea: first contact is invisible

The first provider creates the patient's account as a normal part of intake — they're creating a chart anyway. It registers the patient's DID, hosts their PDS custodially (repo host and space host for the patient's spaces, each set to managing-app policy), and its institution node becomes the first authorized syncer. The patient does nothing. Later, the patient "claims" the DID by pairing a phone: PLC key rotation moves control of the DID to keys the patient holds, and authority over the spaces comes with it — the space authority is the DID.

Onboarding becomes a progression, not a wall:

1. Intake — provider creates the DID and a custodial hosted PDS; its institution node is the first authorized syncer. Patient unaware. Custody sits with one provider.
2. Claim — patient pairs a phone and takes over the DID's rotation keys; gains visibility + veto (control plane). The PDS can stay where it is or migrate.
3. Distribute — second provider seen; authority rotates to a threshold split; single-provider custody dissolves.

17.2 The open problem: first-contact custody

Between step 1 and step 3 there is a window where a single provider holds the patient's DID rotation keys and runs their space host custodially. This is the one genuinely vulnerable moment — it briefly looks like "square one" (institution controls the record).

Mitigations to explore:

• Rotate to threshold as early as possible (second provider, or a public-benefit "PDS of last resort" as an automatic second shareholder)
• Constrain what a custodial first-provider can do (host, serve, and sync yes; change the spaces' managing-app policy settings or grant itself further access, no)
• Audit trail on the authority itself so any custodial action is visible once the patient claims control — the PLC operation log is public, and every grant is a record in health.hats.audit.log

17.3 Questions to resolve

• What can a custodial first-provider do vs. not do — and who enforces it? It hosts the patient's repo, including their audit log, so the constraint can't rest on keys alone; presumably the coordinator refuses grants the custodian issues to itself
• Claim mechanics: adding the patient's rotation key takes a PLC operation the custodian signs, and a higher-priority rotation key can undo later operations within PLC's 72-hour recovery window. Does the claim need the custodian's cooperation, and is it final only once the custodian's key is gone?
• Who is the "PDS of last resort" / health-data credit union, and who funds it?
• How does a patient with no ID and no device get re-identified across providers to avoid duplicate DIDs?
• Claiming UX: how does a patient prove they're the subject of an account created on their behalf?

Related: Autonomy Spectrum (control plane / data plane split), LAN peer fetch (what the federated replica mesh became), and Threshold Authority.

18.1 The card is the master key

The authority key lives in a PIN-gated NFC smartcard (secure element), not the phone. The card is the key; the phone is just one possible reader. Tap any NFC phone, clinic kiosk, or pharmacy terminal — it becomes a dumb terminal with no app-side key custody and no enrollment.

This is the sovereignty floor: it works on a borrowed device, costs little to produce, and can be issued / tracked / revoked by the governance layer. Separating the key (card) from the interface (phone) is what lets a phone-only or no-phone user still hold genuine control.

18.2 Situational authorization

18.3 Card vs. quorum: reversible vs. irreversible

The card can do everything reversible — grant, revoke, approve day-to-day access. It cannot do irreversible authority-level operations alone: rotating the authority root, reissuing cards. Those require the quorum.

The payoff is theft-resilience: a stolen card + observed PIN lets an attacker read records and grant access (bad, but recoverable), but they cannot rotate the root or lock the patient out permanently, because that needs the quorum. Theft stays recoverable.

18.4 Notarized consent

For the hardest middle case — patient is physically able to consent but cannot digitally sign (card lost, PIN forgotten, card in a property bag three floors down). The patient can say yes; they just can't sign.

Nobody remote can validate that the patient actually consented — they weren't there. So we don't ask them to. The treating provider asserts consent; a second trusted party co-signs the existence and timing of that assertion, not its truth.

This is a notary, not a witness: a notary doesn't vouch that your contract is fair, only that you signed it. Here the validator countersigns "Foo asserted patient consent at time T" — making that claim non-repudiable and frozen. Foo can still lie about having consent, but the lie is now cryptographically committed and contestable. If an audit shows no consent occurred, Foo is caught having signed a false attestation. Cost of lying rises; the record stays honest about its own limits.

The value of a party over a mere timestamp authority is exactly three things: it's a known accountable entity, it can apply minimal policy (is the asserting provider accredited?), and it raises collusion cost by requiring a second complicit party. If those three aren't needed, a transparency log is cheaper.

18.5 Threshold authority

For durable incapacity — the patient cannot manage their access policy at all. A defined quorum manages it on their behalf.

Mechanism should be threshold signatures (TSS / FROST), not Shamir reconstruction. The key is never reassembled in one place; each shareholder produces a partial signature and K partials combine into a valid signature without the full key ever existing. Shamir's reconstruction moment is a single point of compromise — unacceptable in a trust-minimized health context.

Quorum only ever activates when the patient cannot will their own signature and no guardian governs. Precedence for incapacity: Guardian → Threshold quorum → Break-glass. A valid guardian delegation always precedes the quorum; threshold authority is the fallback when no guardian exists or is reachable. A conscious patient with their card is always unilateral — neither guardian nor quorum can override a competent patient.

Quorum composition — who holds shares (patient phone, providers, public-benefit "PDS of last resort") and what K-of-N — remains open below.

18.6 Validator / shareholder eligibility

Same problem as social-media identity validation: who is allowed to vouch? Answer: licensed healthcare entities, piggybacking on existing medical licensing and accreditation. This inherits a vetted, revocable, publicly-checkable trust root instead of building one. But it's narrower than it first looks, and four distinctions matter:

Institutional accreditation, not individual licenses. Prefer the institution as validator (NPI, CMS certification, Joint Commission accreditation) over the individual physician's personal license. Institutions are more stable, persist across staff turnover, have legal departments, and already hold BAAs. Individual licenses are a secondary signal, not the anchor.

Inherited revocation. Lose accreditation → lose validator standing. No need to invent disbarment; the boards already run it. Revocation latency varies by board, though — a real consideration.

Eligibility ≠ selection. This is the load-bearing separation. Licensing answers "are you allowed in the validator pool" (eligibility). It does not answer "which pool member validates this specific event" (selection). A licensed hospital rubber-stamping a friend's attestation is still licensed — so licensing does nothing for collusion. These are two separate locks; do not let eligibility masquerade as solving selection (see Open Problems).

Jurisdiction fragmentation. There is no global medical license — 50 US state boards, then every country's own system, each with different APIs, formats, and revocation latencies. A licensing-grounded validator pool is really 50+ disjoint pools. Scope the first version to one jurisdiction (e.g. Washington State) explicitly; treat cross-jurisdiction federation as a later, hard problem.

atproto bridge — verifiable credentials. Model a validator as a DID holding a currently-valid accreditation VC issued by a recognized board. Pragmatically at first, an oracle scrapes the public board registry and attests to status (board-issued VCs are the ideal end state). This is the same VC machinery you'd want for credentialing providers generally, not just validators — so it's reusable infrastructure, not a one-off.

18.7 Open problems

• Validator selection — if the treating provider picks the validator, they pick a friend (collusion). Selection probably can't be the provider's choice: randomized draw from the licensed-validator pool, or reputation-staked validators who lose standing if caught rubber-stamping. This is the lever that makes attestation worth more than a timestamp.
• Duress PIN — a coerced patient (abusive guardian, trafficking — real risks in the population this serves) needs a PIN that signs a grant while silently flagging the audit log.
• Quorum composition — who holds shares (patient phone, providers, public-benefit "PDS of last resort")? What K-of-N?
• Reclaim & dispute — when the patient recovers their card, all on-their-behalf actions (notarized grants, quorum changes) surface for review and contest. Same retroactive-audit loop as Progressive Onboarding.

19.1 Design Ceiling

The protocol is intentionally a binary audit mechanism, not a trust provider or governance layer. Trust is a byproduct of accountability. Governance is external and pluggable.

The protocol only needs to guarantee:

• Both records exist
• Both are signed
• Both reference the same CID
• Neither has been altered

"Signed" means a signature in the record itself (Record Integrity), not the repo commit — upstream commits are deniable by design. atproto spaces supply the first and third guarantees; HATS's record attestations and amendment chain supply the second and fourth.

Everything above that line — arbitration, dispute resolution, fraud investigation, regulatory compliance, membership governance — is out of scope by design. Courts, regulators, hospital boards, payment processors: they all consume the audit trail as input. The protocol doesn't need to know they exist.

Why this is a feature, not a limitation

Social spaces need designed-in governance because there's no external legal framework to fall back on — hence the arbiter, cross-modal scope, and community-DID ownership questions in Daniel's design diary. Commerce and health already have legal frameworks. The law is already the trust layer. The protocol's job is just to make evidence cheap to produce and expensive to dispute.

A triangular trust formula (two parties + protocol arbiter) is unnecessary complexity. The binary model — two signed, CID-linked records — is sufficient. If there's a disparity, the parties submit their records to whichever external arbiter is appropriate. The protocol doesn't need to know which one.

Jurisdiction-agnostic by design

The same bilateral record works whether the arbiter is:

• A US federal court
• An EU GDPR authority
• A hospital ethics board
• A Stripe dispute team
• Two people settling over coffee

The audit trail is the constant. The governance layer is pluggable, external, and not the protocol's problem.

19.2 Metamorphic Bilateral Records

A core ATS primitive. The same event exists as two records — one in each party's own space repo — each shaped by their perspective, linked by a shared reference: a com.atproto.repo.strongRef (URI + CID).

Under atproto spaces, every account writes only to its own space repo, and a space is the aggregation of those per-author repos. So both sides of a bilateral record sit in the same space, in different repos:

Neither party owns "the truth" — the truth is the intersection. Disputes are resolved by comparing both records against the shared reference. No central ledger required.

This is double-entry bookkeeping applied to sovereign data. Double-entry bookkeeping has been the foundation of accountable commerce since the 15th century — every transaction recorded as both a debit and a credit, owned by different parties, reconcilable by auditors. ATS generalizes this:

Authorship and custody

Each party writes its own side, and only its own side. The patient controls the space — as space authority, they decide who reads and whose writes are tracked. The author holds custody of what they wrote: a hospital's note lives in the hospital's repo inside the patient's space (ER write-back). The patient cannot edit the hospital's record, and the hospital cannot write into the patient's repo.

Non-repudiation does not come from the repo. Upstream commits are deniable by design: a commit proves integrity to a syncer in the sync flow, and nothing to a third party. A record that must be provable carries its own signature — the community atproto attestation spec, opt-in per collection (Record Integrity). A clinician signs their note with their DID key; neither party can alter the other's contribution without breaking the signature.

Co-signing is a countersignature, not a commit property. This is what payment processors already do — Stripe is the trusted co-signer, and both parties agree Stripe's receipt is ground truth. In HATS the co-signer is a remote attestation, such as the Validator.

Generalizes beyond commerce and health

Any bilateral relationship with ongoing state:

• Employment records
• Loan agreements
• Contracts and NDAs
• Tenancy / lease records
• Insurance claims

Lying at the moment of recording

• Unilateral false record — detectable: the counterparty's repo has no matching record, or the reference doesn't resolve to a record with a valid attestation
• Colluding on a false shared reference — cryptography can't help; this is fraud, same as today
• Retroactive alteration — detectable, not impossible. A signed record can't be changed without breaking its signature, and a correction is a new record naming the old one in prev (amendment chain). Space repos are a set with no history, so the repo itself won't reveal a silent deletion — every other syncer's signed copy will. Transparency receipts pin a record's existence at time T
• Deletion on request — upstream expects syncers to delete when a space or account is deleted, which collides with medical-record retention law (see Upstream)

19.3 Core Thesis

"Own your data" is a feature. Accountable by default is a value proposition.

The protocol doesn't establish trust between parties — it makes lying expensive and detectable. Trust emerges as a rational response to that. If every transaction, clinical note, or order record is signed by its author, held by every party it touches, and corrected only by adding to it, lying isn't impossible — it's just immediately and permanently visible. The audit trail is the deterrent.

This collapses the distinction between "did this happen" and "can I prove this happened." Right now those are two different questions with expensive infrastructure between them — lawyers, discovery, expert witnesses. A cryptographic audit trail makes them the same question. The receipt is the proof.

Arbitration tiers

Commerce lives almost entirely in the first two tiers — which is why it's automatable. Health bleeds into the bottom two — but the protocol still eliminates the vast majority of lower-tier disputes that currently get escalated unnecessarily because the audit infrastructure doesn't exist.

The hashing primitive

Cryptographic hashing gives proof of existence and integrity at a moment in time without any third party:

• A signed hash proves a document existed, unchanged, at T1
• Neither party can alter their record without breaking the signature
• Append-only amendment chains (each amendment references the prior version by CID) handle legitimate mutability
• A space repo's LtHash digest proves a syncer's copy matches the host — useful for sync, worthless as evidence, since commits are deniable. Evidence is the record signature
• Contradictory records can both have valid hashes — cryptography proves integrity, not truth. Semantic disputes still need human arbiters.

If something is as easy to prove as the sky is blue, trust is a given.

19.4 Shared Concepts

The Core Pattern

Every ATS project follows the same shape:

1. Owner holds a DID and is the space authority for their spaces; their PDS is both repo host and space host by default
2. Requester's app gets a delegation token from the requester's own PDS and exchanges it with the space authority for a space credential, adding a client attestation when the space gates on app identity
3. Space credential is read-only, short-lived (10 minutes default, 60 maximum), signed by the space authority, and bound to a key the app holds
4. Access revocation = the authority stops issuing; outstanding credentials expire, or are revoked early by jti
5. Audit = attested records in the owner's audit space, each written by its author into their own repo

Addressing

Spaces reuse at://. A literal space segment where a public collection NSID would sit marks the URI as a space address; resolution is credentialed, not public. The space authority comes first because the author's records are only reachable through the space.

HATS's types, keys, and collections are in Lexicon Namespaces.

Partitioned Data (not Colocated)

Each member stores their own records in their own space repo, on their own repo host. The space host is the coordination point (credentials, the writer set, write notifications), not the data host. Colocated hosting reintroduces the resource, moderation, and custody problems that atproto was built to avoid.

Space Credentials

Three tokens, all existing parts:

Key binding stops a repo host from replaying a credential it was shown against other hosts. Faster-than-expiry revocation is com.atproto.space.notifyCredentialRevoked, naming credentials by jti. There is no long-lived replica credential: a backup provider is a syncer that keeps renewing.

Sync Model

Pull-based. Each space repo commits to an LtHash set-hash digest over its current records — order-independent, updated incrementally, and history-free. A syncer keeps its own running digest; when it matches the host's, the copy is exact.

• Incremental — com.atproto.space.listRepoOps returns operations since a revision. The oplog is a transport optimization the host may compact or drop; a syncer that loses its place falls back to full-state recovery
• Notifications — repo hosts send notifyWrite to the space host, which sequences them across the whole space; syncers subscribe with registerNotify

Because the repo has no history, HATS keeps history in the records: the amendment chain.

Default-Deny & App Allowlists

Resolved upstream. com.atproto.simplespace spaces set appAccess: #allowList, checked against the attested client_id from the client attestation, so the list is enforced, not advisory. A credential is minted only if readPolicy authorizes the user and appAccess authorizes the app. appAccess does not gate writes; writePolicy does.

HATS records spaces allowlist accredited EHR client IDs and use readPolicy: managing-app with the HATS service as managingApp (see ER setup).