Healthsplit: Patient-Controlled EHR Splitting

Executive Summary

Healthsplit gives healthcare systems a cryptographic way to protect patient data across multiple providers while maintaining full patient control through consent validation.

Healthcare data breaches expose the most intimate details of patients' lives — diagnoses, prescriptions, procedures, lab results, medical history. A single compromised provider database can affect millions. Healthsplit solves this by splitting electronic health records across multiple independent healthcare providers using XorIDA threshold sharing, so that no single provider holds a complete patient record.

Two functions cover the full workflow: splitHealthRecord() takes a patient's EHR, a list of providers, a threshold, and patient consent, then splits the data via XorIDA so any K-of-N providers can reconstruct. reconstructHealthRecord() takes the manifest and provider shares, validates integrity via HMAC-SHA256, and returns the original data. Patient consent is validated before any cryptographic operation — no record is split without explicit patient authorization.

When a record is split 2-of-3 across Hospital A, Lab B, and Pharmacy C, an attacker who compromises Hospital A learns zero information about the patient's medical data. They need shares from at least two providers. An information-theoretic guarantee: not computationally hard to break, but mathematically impossible.

Zero configuration. Zero npm runtime dependencies. Runs on Node.js 20+, Tauri, browsers with Web Crypto API. Dual ESM and CJS builds ship in a single package.

The Problem: Healthcare Breaches Are Inevitable

Healthcare organizations hold the most sensitive personal data. A single breach exposes medical histories, prescriptions, diagnoses, and financial information. Current approaches rely on perimeter security that fails.

Current Risk Models

Healthcare systems rely on centralized storage: a patient's entire medical record lives in a single hospital database. This creates a single point of failure. If that hospital's security is compromised — via ransomware, insider threat, or misconfiguration — the attacker gains access to the complete medical history.

Encryption at rest helps, but the encryption key is stored in the same system. When the system is breached, the key is typically compromised too. Backups are held in the same administrative environment, creating copies of the same risk.

Scale of the Problem

In 2023, healthcare was the most breached industry, with 725 breaches affecting 100+ million individuals. The 2023 Verizon DBIR found that healthcare breaches took an average of 236 days to detect. By then, data was already exfiltrated.

HIPAA fines average $140K per breach, but settlements with affected patients reach millions. Reputational damage often exceeds financial penalties. Patients lose trust in institutions.

Why Current Mitigations Fall Short

None of these approaches change the fundamental risk: a single compromised provider database exposes the entire record. Healthsplit changes this by splitting the record itself.

The Solution: Information-Theoretic Data Splitting

Healthsplit splits health records across independent providers using XorIDA threshold sharing, a cryptographic technique where no single share reveals any information about the original record.

What Is Threshold Sharing?

In threshold sharing, a secret (the EHR data) is split into N shares such that any K shares can reconstruct the secret, but any K-1 shares reveal nothing. This is information-theoretic security — true mathematical security, not computational hardness.

With a 2-of-3 split, you need at least 2 shares to reconstruct. If an attacker steals Share 1 from Hospital A, they still have zero information. They must also steal Share 2 from Lab B or Share 3 from Pharmacy C. Attacking multiple, independent providers is exponentially harder than attacking one.

How Healthsplit Works

1. Patient consents to split their record across 3 providers.
2. Hospital uploads the full EHR to a health records management system (HRMS).
3. Healthsplit validates the patient's consent: Is it signed? Has it expired? Are the providers in the grant list?
4. If valid: Healthsplit uses XorIDA to split the EHR into 3 shares.
5. Share 1 → Hospital, Share 2 → Lab, Share 3 → Pharmacy (each provider holds only their share).
6. When needed: Provider requests 2 of the 3 shares, Healthsplit reconstructs and validates integrity via HMAC + data hash.

Why XorIDA?

Healthsplit uses XorIDA over GF(2) — XOR-based Information Dispersal Algorithms. This is fast, deterministic, and information-theoretically secure:

• Fast: Sub-millisecond for typical EHR sizes (<10MB). XOR is a CPU primitive.
• Simple: No complex number theory, no cryptographic constants, no PRNG dependency.
• Unconditionally secure: An attacker with K-1 shares has zero bits of information about the plaintext, even with infinite computational power.

Consent-First Architecture

Patient consent is not a checkbox. Healthsplit makes it cryptographic: no record is split, no share is held, without explicit patient authorization that is checked before every operation.

Consent Validation Pipeline

Before any cryptographic operation, Healthsplit validates patient consent:

// 1. Check all required fields exist
if (!consent.patientId || !consent.purpose) {
  return err('CONSENT_INVALID');
}

// 2. Check consent has been granted at a known time
if (!consent.grantedAt) {
  return err('CONSENT_INVALID');
}

// 3. Check at least one provider is authorized
if (consent.grantedTo.length === 0) {
  return err('CONSENT_INVALID');
}

// 4. Check consent has not expired
if (consent.expiresAt && new Date(consent.expiresAt) < new Date()) {
  return err('CONSENT_EXPIRED');
}

// 5. Check all providers in config are in the consent grant list
const providerIds = config.providers.map(p => p.id);
const unauthorized = providerIds.filter(
  id => !consent.grantedTo.includes(id)
);
if (unauthorized.length > 0) {
  return err('PROVIDER_MISMATCH');
}

Consent Model

Consent in Healthsplit is structured:

Use Cases

Architecture

Healthsplit is built on five core components: XorIDA splitting, chunking for large records, HMAC integrity, SHA-256 verification, and manifest generation.

Split & Reconstruct

Splitting a record happens in two steps:

// Step 1: Chunk the EHR into manageable pieces (default 1MB)
const chunks = chunkData(record.data, 1024 * 1024);

// Step 2: For each chunk, split via XorIDA into N shares
for (const chunk of chunks) {
  const shares = splitXorIDA(chunk, config.threshold, config.providers.length);
  // shares[0], shares[1], shares[2] for 2-of-3 split
}

// Step 3: HMAC each share for integrity
for (const share of shares) {
  const hmac = generateHMAC(share.data);
  share.hmac = hmac; // Stored with share
}

// Step 4: Create manifest with SHA-256 of original data
const dataHash = await sha256Hex(record.data);
const manifest = {
  id: generateUUID(),
  recordId: record.recordId,
  dataHash, // End-to-end integrity proof
  config, consent, // Audit trail
};

Integrity Protection

Every share has an HMAC-SHA256 computed over the share data. When reconstructing:

// Step 1: Collect K-of-N shares from providers
const shares = await collectShares(manifest, K);

// Step 2: Verify HMAC of each share BEFORE reconstruction
for (const share of shares) {
  const computed = generateHMAC(share.data);
  if (computed !== share.hmac) {
    return err('HMAC_FAILED'); // Fail closed
  }
}

// Step 3: Reconstruct chunk via XorIDA
const chunk = reconstructXorIDA(shares);

// Step 4: Verify final data hash against manifest
const finalHash = await sha256Hex(assembledData);
if (finalHash !== manifest.dataHash) {
  return err('RECONSTRUCT_FAILED');
}

return ok(finalData);

Chunking Strategy

Large EHRs are split into chunks (default 1MB) for performance and memory efficiency:

• Chunk size: Configurable (default 1MB). Larger chunks = fewer chunks to manage. Smaller chunks = lower memory overhead per split operation.
• Per-chunk HMAC: Each chunk has its own HMAC, so corruption in one chunk is isolated. Reconstruction fails only for that chunk.
• Chunk indexing: Manifests store totalChunks. Shares reference chunkIndex, so providers know which chunk each share belongs to.
• Streaming reconstruction: Chunks can be reconstructed on-demand, without loading the entire record into memory.

Integration

Healthsplit is designed to integrate into health records management systems (HRMS), electronic health exchanges (EHX), and privacy-preserving research platforms.

HRMS Integration

A typical hospital HRMS integration:

import {
  splitHealthRecord,
  reconstructHealthRecord
} from '@private.me/healthsplit';

// Hospital uploads a record
app.post('/api/ehr/split', async (req, res) => {
  const { record, config, consent } = req.body;

  // Validate consent signed by patient on hospital portal
  if (!verifyConsent(consent)) {
    return res.status(403).json({ error: 'Consent invalid' });
  }

  // Split the record
  const result = await splitHealthRecord(record, config, consent);
  if (!result.ok) {
    return res.status(400).json({ error: result.error });
  }

  // Distribute shares to providers (Lab, Pharmacy, etc.)
  const { manifest, shares } = result.value;
  await distributeShares(manifest, shares);

  res.json({ manifest, sharesDistributed: shares.length });
});

// Provider requests to reconstruct
app.post('/api/ehr/reconstruct', async (req, res) => {
  const { manifest, shares } = req.body;

  // Reconstruct with HMAC validation
  const result = await reconstructHealthRecord(manifest, shares);
  if (!result.ok) {
    return res.status(400).json({ error: result.error });
  }

  res.json({ data: result.value });
});

Research Platform Integration

A research platform can use Healthsplit to enable threshold-based access to de-identified EHRs:

// Clinical trial platform
const researchConsent = {
  patientId: 'PAT-ANON-123',
  purpose: 'clinical_trial_ABC',
  grantedTo: ['RESEARCHER_1', 'RESEARCHER_2', 'RESEARCHER_3'],
  grantedAt: new Date().toISOString(),
  expiresAt: new Date(Date.now() + 365 * 24 * 60 * 60 * 1000).toISOString(),
};

// Split EHR 2-of-3 across researchers
const config = {
  providers: [
    { id: 'RESEARCHER_1', name: 'Dr. Smith', type: 'researcher' },
    { id: 'RESEARCHER_2', name: 'Dr. Jones', type: 'researcher' },
    { id: 'RESEARCHER_3', name: 'Dr. Brown', type: 'researcher' },
  ],
  threshold: 2, // Need 2-of-3 to see full record
};

const result = await splitHealthRecord(record, config, researchConsent);

Security Model

Healthsplit provides multiple layers of cryptographic and operational security.

Information-Theoretic Security

XorIDA splitting is information-theoretically secure. An attacker with K-1 shares has zero bits of information about the plaintext, regardless of computational power. This is not merely computationally hard to break — it is mathematically impossible to break with fewer than K shares.

Integrity Guarantees

• HMAC-SHA256 per share: Every share is signed with HMAC. If a share is modified in transit or at rest, the HMAC fails.
• SHA-256 end-to-end: The full assembled record is hashed. Bit-flips during reconstruction are detected.
• Fail-closed validation: HMAC is verified BEFORE reconstruction. If validation fails, no data is returned.

Consent-Driven Access Control

• Provider authorization: Only providers in consent.grantedTo may hold shares.
• Purpose binding: Consent includes a purpose field (treatment, research, billing). This enables auditing downstream use.
• Expiry enforcement: Consent can expire. Operations after expiry return CONSENT_EXPIRED error.

No Plaintext in Logs

Healthsplit never logs, prints, or exposes plaintext data. All logging is restricted to manifest metadata (provider IDs, chunk counts, timestamps).

API Surface

Healthsplit exports two main functions, comprehensive types, and a structured error model.

Core Functions

Type System

Error Handling

Healthsplit returns a Result<T, HealthError> type. Every error is a discriminated union with a code and message:

Benchmarks

Healthsplit is fast. XorIDA operates at CPU-core speeds, and consent validation is sub-millisecond.

Splitting Performance

Reconstruction Performance

Reconstruction is equally fast. Retrieving shares from distributed providers (network I/O) dominates the total time:

• Local shares (K-of-N stored locally): <5ms for 1MB record.
• Distributed shares (fetched from K providers over network): 200–500ms depending on network latency.
• HMAC validation: <1ms per chunk.

Limitations & Design Tradeoffs

Healthsplit is purpose-built for EHR splitting. It does not cover every healthcare data protection scenario.

What Healthsplit Does NOT Do

• Secure message transport. Use TLS for share transmission between systems. Healthsplit only protects data at rest.
• Authentication of providers. Healthsplit assumes providers are known and authenticated. Use mutual TLS or OAuth for provider auth.
• Key management. Healthsplit has no keys — the split IS the security. If you need encryption keys, use @private.me/crypto separately.
• Audit logging. Healthsplit is a library. Integrators must implement audit trails (what provider requested what record when).
• Consent management UI. Healthsplit validates consent; it does not generate it. Build a patient-facing portal to collect consent signatures.

Multi-Provider Coordination

Distributing and retrieving shares from K independent providers requires a coordination layer. Healthsplit does the math; you handle the logistics:

• Where is share 1 stored? (Hospital A's database, Healthsplit's own shard service, a decentralized store?)
• How does provider 2 request share 1? (HTTP, message queue, blockchain?)
• What if a provider goes offline? (Fallback to a different provider, wait for retry?)

Quantum Resistance

XorIDA is post-quantum resistant — there is no quantum algorithm known that breaks XOR-based threshold sharing. However, the consent validation uses timestamps (ISO 8601 strings), not post-quantum signatures. If consent signing is critical, integrate with @private.me/xid (Xid supports ML-DSA-65 signatures).

Codebase & Testing

Healthsplit is a compact, well-tested library built with TypeScript, zero npm dependencies, and comprehensive test coverage.

Core Modules

Test Coverage

Test Strategy

Tests cover all critical paths:

• Happy path: Valid config, valid consent, successful split/reconstruct.
• Consent validation: Missing fields, expired consent, provider mismatch.
• HMAC failures: Corrupted shares, modified HMAC values.
• Chunking: Small records (<1MB), large records (>10MB), custom chunk sizes.
• Error codes: All 8 error types tested with specific failure scenarios.
• Abuse cases: Out-of-range indices, threshold violations, empty provider lists.