4 Must-Have Primitives for Trustworthy Healthcare AI Governance

Healthcare AI is stuck. Despite billions invested, three critical failures keep recurring: fragmented data silos, patient consent buried in paperwork, and audit trails that can’t be trusted. The root cause isn’t technology—it’s the absence of a shared governance protocol that enforces consistent rules across systems that don’t trust each other.

A new framework proposes four primitives to solve this. Each one tackles a specific failure mode by defining strict data structures and algorithms, not just marketing slogans. Together, they form a working set that any honest governance protocol must include—whether for electronic health records, clinical research, or AI model training.

Why "Consent and Audit" Isn’t Enough

Most healthcare AI pitches start and end with the phrase "consent and audit." While technically correct, it’s also useless. Real governance requires specific data structures and algorithms that rule out failure modes—like signed consent forms that can’t be revoked or provenance records that can’t be verified.

A primitive, in this context, must:

• Address a failure mode that doesn’t disappear if you avoid defining it clearly. For example, "consent" isn’t the primitive; the data structure that records consent is.
• Eliminate lookalike alternatives that seem similar but lack the same guarantees. A signed consent form isn’t the same as a hash-chained consent record.
• Work alongside the other primitives without creating circular dependencies. Provenance can’t verify its own integrity.

The four primitives below meet these criteria. Each section explains the failure it addresses, the flawed alternative that doesn’t work, and what breaks if you remove it.

Content-Addressable Health Assets: Solving Data Fragmentation

Failure addressed: The healthcare industry’s data is scattered across electronic health records (EHRs), app databases, and research snapshots. No two systems agree on what constitutes the same patient record, making governance impossible.

A Health Asset solves this by assigning a unique identifier to every piece of clinical data based on its content—not its location. From the HAVEN whitepaper (§6.11):

HealthAsset := {
  asset_id: ContentHash       // SHA-256 hash of the data
  data_ref: SecureReference    // Link to the raw data
  substrate: Identifier        // Format (FHIR, OMOP, etc.)
  consent_ref: ConsentID       // Linked consent policy
  quality_class: {A, B, C, D}  // Data quality grade
  provenance_ref: ProvenanceID // Audit chain reference
  patient_ref: PatientID       // Patient owner
  created_at: Timestamp        // Creation time
}

The asset_id is derived from the content itself. Change even a single byte, and the hash changes—making it impossible for two systems to disagree about whether they’re referencing the same record.

The flawed alternative: Simply giving every record a UUID.

• UUIDs work fine within a single system but fail at boundaries. Two custodians can assign the same UUID to different records or different UUIDs to the same record.
• Reconciliation becomes a manual, custodian-by-custodian process.
• Content addressing dissolves this problem: same content, same hash, anywhere. No registry or reconciliation needed.

What happens if you remove this primitive?

• Every audit becomes a game of "trust me, this is the right record."
• Consent becomes ambiguous—it’s unclear which data it covers.
• The fragmentation failure remains unfixed.

This isn’t revolutionary. Git has used content addressing since 2005. IPFS applies it to general data. RFC 6920 standardizes it for URIs. The innovation here is applying it specifically to healthcare records in a way that’s substrate-neutral—whether the data is in FHIR, OMOP, or a raw document.

Programmable Consent: Putting Patients Back in Control

Failure addressed: Patients have no meaningful role in governance. Their data is shared, siloed, and revoked through phone calls to records departments. "Consent" is a paper artifact, not a machine-verifiable rule.

The Consent Protocol changes this by turning consent into a programmable, auditable contract. From the HAVEN whitepaper (§6.21):

ConsentAttestation := {
  consent_id: UUID
  grantor: PatientIdentity       // Who grants access
  grantee: AccessorIdentity      // Who receives access
  scope: DataScope               // What data is covered
  purpose: PurposeType           // Why access is granted
  conditions: Conditions[]       // Under what rules
  status: {active, revoked, expired}
  signature: CryptoSignature      // Cryptographic proof
}

Three properties set this apart from existing consent practices:

• Closed-world semantics: If consent isn’t explicitly granted, access is denied by default. Most systems default to permission unless explicitly forbidden—HAVEN inverts this.
• Deterministic verification: Same inputs always produce the same output. No ambiguity, no "it depends on the custodian." This makes consent machine-verifiable.
• Instant revocation: A revoke() call immediately invalidates access. No waiting periods or bureaucratic delays.

What happens if you remove this primitive?

• Governance has no foundation—patients become passive data sources.
• Without programmable consent, the other primitives (like provenance) lack a clear purpose.
• The "no role for the patient" failure remains unaddressed.

Hash-Chained Provenance: Building Unbreakable Audit Trails

Failure addressed: Audit trails in healthcare are unreliable. Records can be altered retroactively, and proving data integrity requires trusting the custodian—not the data itself.

Provenance ensures every change to a Health Asset is recorded in an immutable chain. Think of it as a Git commit log for clinical data. Each entry includes:

• A link to the previous entry (hash chaining)
• A cryptographic signature from the custodian who made the change
• A timestamp and description of the modification

This creates an auditable trail where:

• No entry can be altered without breaking the chain.
• Any custodian can verify the integrity of the data independently.
• Patients and regulators can inspect the full history of their records.

The flawed alternative: Centralized audit logs.

• Centralized systems are single points of failure. A compromised custodian can alter logs.
• Hash chaining distributes trust. Even if one custodian is untrustworthy, the integrity of the chain remains intact.

What happens if you remove this primitive?

• Data integrity becomes a matter of trust in custodians.
• Fraudulent alterations—like backdated records—go undetected.
• The governance protocol loses its ability to prove compliance.

Quality-Weighted Contribution: Ranking Data by Trustworthiness

Failure addressed: Not all clinical data is equally reliable. Some sources (like EHRs) are high-quality but siloed, while others (like patient-reported data) may be incomplete or inaccurate. Governance needs a way to weight contributions based on their credibility.

The quality-weighted contribution primitive assigns a grade to every Health Asset:

quality_class: {A, B, C, D}

• A: Highest quality (e.g., verified lab results from an EHR)
• B: Moderate quality (e.g., structured data from a wearable device)
• C: Low quality (e.g., patient-reported symptoms)
• D: Unreliable (e.g., data from an unverified source)

This grade influences:

• Consent scope: High-quality data may require stricter consent policies.
• Provenance verification: Lower-quality data may trigger additional audits.
• Model training: AI models can prioritize high-quality data for better predictions.

The flawed alternative: Treating all data equally.

• Unreliable data can contaminate research and AI training.
• Governance protocols can’t differentiate between trustworthy and questionable sources.

What happens if you remove this primitive?

• Governance loses a critical tool for managing data quality.
• AI models trained on mixed-quality data produce less reliable results.
• The "no role for data quality" failure persists.

The Path Forward: Governance That Works

These four primitives aren’t theoretical—they’re actionable. HAVEN’s whitepaper outlines how to implement them in real systems, from EHRs to research databases. The key insight is that governance isn’t about adding more regulations or platforms; it’s about defining the data structures and algorithms that enforce rules automatically.

For healthcare AI to move forward, custodians, regulators, and technologists must adopt these primitives. Fragmented data, patient disempowerment, and untrustworthy audits won’t fix themselves. The tools to solve them already exist—we just need the discipline to use them.