Open-source · peer-to-peer · vendor-independent

Verifiable identity and revocable consent across institutions.

Credara is shared infrastructure for two things US healthcare does badly: knowing that a patient seen at one institution is the same person seen at another, and keeping that patient's consent verifiable and revocable as their records move around. A peer-to-peer graph of signed events — with no central matcher and no node that ever sees cleartext PHI.

FHIR R4 integration surface Built for longitudinal research Apache 2.0 licensed
identity event authorization erasure
Assert Assert Link Link Grant Link Revoke Link Grant Tombstone earliest latest
Each event points back to its parents — a directed, acyclic chain that only grows forward. The DAG is the audit trail, tamper-evident by construction.
Verification, not mediation. Credara verifies identity and authorization claims — it does not sit in the data path or broker transactions. Complementary to MPIs, EHRs, and TEFCA exchange — not a replacement.
The problem

Two things US healthcare does badly.

US healthcare runs on patient records fragmented across institutions and on consent that is practically impossible to revoke. The rights to fix both already exist on paper — the infrastructure to enforce them does not.

Identity

Is this the same person?

Identity matching depends on probabilistic vendor algorithms run against opaque databases. The miss rates show up as duplicate care, missed allergies, contraindicated prescriptions, and avoidable readmissions.

Consent

Can the patient take it back?

A consent granted at one institution lives in that institution's database. When the patient revokes it, the revocation stays put — while copies of the records keep flowing elsewhere.

Why it exists

Built for research that runs for years.

Credara is built for longitudinal research, where both problems compound over the years a study runs. A study lives or dies on identity holding over the full course of care — confirming a participant seen at one institution this year is the same person seen at another five years later, and keeping their authorization verifiable and revocable the whole way through.

The Lyme cohort

A clear example of where it breaks today.

Lyme disease patients accumulate fragmented records across many providers and state lines over long, frequently disputed disease courses. When identity links break, the cohort fragments. When consent provenance gets murky, so does data governance — and the study's footing erodes year over year.

The payoff

Composed into a single longitudinal record

A clinician in a new city sees the cardiology workup from two years ago, the medications from pharmacies across state lines, and the allergy noted by a pediatrician who has since retired. Rare diseases become recognizable patterns, polypharmacy interactions get caught, and care continuity across transitions stops resetting the chart to zero.

How it works

Peers contribute signed events to a shared graph.

Each participating institution — hospitals, health systems, QHINs, HIEs, payers — runs a peer that contributes signed, immutable identity and authorization events to a shared distributed graph. No central matcher, no leader nodes, no privileged intermediaries. Patients are identified by the chain of provenance behind every assertion, not a master patient index; authorization is itself a signed event any institution can issue, verify, or revoke.

consent Patient HIE Clinic Hospital Payer Health system Research Lab Pharmacy QHIN origin peer ~1–2 s network-wide

When an institution creates an event, its peer pushes it to a handful of neighbors, who push it onward — the network converges in roughly log(N) rounds, about 1–2 seconds. Three distinct kinds of exchange flow between peers, and none of them ever carries cleartext PHI.

01 — THE MAIN FLOW

Event gossip

A new identity assertion, link, grant, revocation, or tombstone is gossiped peer-to-peer as a batch of signed CBOR event nodes inside an encrypted Noise channel.

Batches flush every 100 ms or at 64 events — cutting message count 10–50×. Receivers verify the signature, store, dedup by UUID, and re-gossip.
02 — THE BACKSTOP

Anti-entropy

Peers periodically reconcile by exchanging a Merkle root over their sorted set of event UUIDs. Roots match → in sync. Roots differ → swap UUID sets and transfer only the missing nodes.

Computed over UUIDs, not contents — so tombstoning (scrubbing PII) never makes two peers with the same event set diverge.
03 — DISCOVERY

DHT routing & pulls

A Kademlia DHT maps a tokenized subgraph key to the peer IDs that hold it; a peer then makes a targeted point-to-point request for the actual event nodes.

A Portable Authorization Artifact — a signed AuthorizationGrant in CBOR — can travel this way too, handed to a relying party to verify locally.

What never crosses the wire: cleartext PHI.

Only tokenized demographics and signed events move between peers. Demographics are tokenized before anything is gossiped, the DHT only ever sees tokenized keys, and clinical payloads never enter the trust graph — all inside encrypted, mutually-authenticated Noise channels.

What it buys you

Obligations enforced structurally, not by policy.

Because every assertion is a signed event in a shared graph, the rights that exist on paper become operations the network performs.

Identity

Verifiable, not probabilistic

Every assertion carries a chain back to the institution that observed it. Matching stops being a vendor's black box — confidence emerges from consensus across peers.

Consent

Consent that actually moves

A grant propagates network-wide within seconds; a revocation takes effect at every peer with bounded latency; an erasure request lands as a signed event the whole network must honor — under the patient's own key.

Audit

Accounting of disclosures by query

What is reconstructed today by hand from scattered audit logs becomes a single query against the patient's own provenance chain.

Durability

Beyond any one organization

Durability stops depending on any single institution. The right to access records does not expire when a clinic closes or merges.

Technology at a glance

Standards already in wide use — open to full review.

Credara aligns with the existing trust framework and is assembled from mature components. Only the healthcare-domain layer is new code. Its integration surface is HL7 FHIR R4 — a conformant interface served through HAPI FHIR, HL7's reference implementation — and institutional identity follows the UDAP profile of the HL7 FAST Security implementation guide, the standard US nationwide exchange adopted in 2026. So Credara speaks the same standards as the EHRs, HIEs, and QHINs it sits alongside. The cryptography is algorithm-agile and post-quantum ready.

Core / Export Gate / VerifierRust
FHIR BridgeJava / Kotlin — HAPI FHIR (HL7's reference server), Plain Server mode (not JPA)
FHIR conformanceHL7 FHIR R4 conformant interface, US Core–aligned · R5 deferred
Networkinglibp2p — gossipsub, Kademlia DHT, Noise transport
StorageRocksDB via a Store trait · substrate decided (§13.1.1)
SerializationCanonical CBOR (ciborium, RFC 8949 deterministic encoding)
HashingBlake3 content integrity & Merkle roots · SHA-512 DHT routing key, FIPS-validated
Demographic tokenizationSalted Blake3 256-bit network salt, rotated annually — deterministic across peers, resistant to rainbow-table attacks. Cleartext demographics never leave the originating institution.
Node IDsUUIDv7
SignaturesAlgorithm-agile — Ed25519 default; ML-DSA-65 (FIPS 204) & SLH-DSA (FIPS 205) for PQC; hybrid mode
Identity & trustHL7 FAST Security IG via UDAP (institutional) + SPIFFE / SPIRE (workload) · admission modeled on DirectTrust · aligns with TEFCA
DeploymentKubernetes-native — the Helm chart is the primary production target, with Ansible automating install onto an existing cluster (cert-manager + SPIRE + the Helm release). Local development runs under Podman or Docker Compose.
LicenseApache 2.0
Project status

Pre-launch. All milestones implemented. Open for testers.

The technical specification (Sections 1–13 + appendices, ~90 pages) is complete and authoritative. All ten build milestones are implemented and verified; the multi-peer testbed under kind passes its gossip-convergence and anti-entropy-repair scenarios end-to-end.

M0–M9
All build milestones implemented & verified
2 ms
First end-to-end gossip propagation, peer-a → peer-b
<10 ms
Typical convergence on a developer laptop
~90 pp
Complete, authoritative technical specification
M1 Event model — credara-events green
M2 Storage (RocksDB) green
M3 Graph / computation — link-chain defense green
M4 Networking — libp2p adapter green
M5 Core green
M6 Export Gate + Verifier green
M7 FHIR Bridge builds
M8 Deployment — verified on kind green
M9 Conformance + synthetic data green
DQ Multi-peer testbed — more scenarios in progress
Pre-launch software. Not yet deployed to a real network and not yet independently security-reviewed. Do not use it with real PHI. All testing uses the synthetic-data generator with test-data tagging, provably invisible to clinical FHIR queries.

Open source. Vendor independent. Open for testers.

Credara is Apache 2.0, so it can be reviewed in full rather than trusted as a black box — no central coordinator, no lock-in. Bring a laptop with Docker and stand up a real two-peer network in minutes.

New testers Prerequisites, the conformance suite, and the multi-peer testbed. make -C testbed up && make -C testbed smoke
New contributors Read docs/STATUS.md — the authoritative map of what's real vs. demo — before building on any surface.