Skip to main content

Multi-Party Data Sharing in Healthcare: A Consortium Blockchain Approach

· 10 min read
Prasad Kumkar
Prasad Kumkar
Founder & CEO, ChainScore Labs

Healthcare data sharing is the classic enterprise blockchain use case that's been promised for a decade and delivered almost nowhere. The problem isn't technology — it's that the technology was too complex for the organizations that needed it.

A regional healthcare network typically involves: 3-8 hospitals, 2-4 insurance carriers, dozens of specialty clinics, pharmaceutical companies running clinical trials, and public health agencies. Each operates its own EHR system. Each has different data formats, privacy policies, and access control rules. Each is legally prohibited from sharing certain data without explicit patient consent.

A permissioned blockchain with per-record encryption and consent management solves the coordination problem without requiring any single organization to centralize control of the data.

The Healthcare Data Sharing Problem​

Why Health Information Exchanges (HIEs) Struggle​

Traditional HIEs work like this: every provider sends patient data to a central repository. The central HIE operator manages access control. When Provider B needs data from Provider A's patient, they query the HIE.

This model has three fundamental problems:

  1. Centralization risk: The HIE becomes a single point of failure and a massive target for data breaches. A single breach exposes records from every participating organization.

  2. Governance disputes: Who controls the HIE? The largest hospital? The state government? A third-party vendor? Every participant wants access but no one wants to cede control.

  3. Data timeliness: Providers push data to the HIE on a schedule (nightly, weekly). The data Provider B queries might be days stale — dangerous for emergency care.

How a Consortium Blockchain Changes the Model​

Instead of a central repository, each organization runs a blockchain node. Patient data stays distributed — each provider holds their own patients' records. The blockchain provides:

  • A unified patient identity layer — which providers hold records for which patients
  • Consent management — patients control who can access which records
  • Access audit trail — every data access is logged immutably
  • Per-record encryption — sensitive data is encrypted at the field level, visible only to authorized parties
  • Real-time data availability — the ledger is always up to date across all nodes

No central repository. No single point of failure. No organization controls the entire network.

Architecture​

┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
│  General Hospital│   │  City Medical     │   │  Regional Clinic │
│  (Node 1, Raft)  │   │  (Node 2, Raft)   │   │  (Node 3, Raft)  │
│                  │   │                   │   │                  │
│ ┌──────────────┐ │   │ ┌───────────────┐ │   │ ┌──────────────┐ │
│ │EHR System    │ │   │ │EHR System     │ │   │ │EHR System    │ │
│ │(Epic/Cerner) │ │   │ │(Epic/Cerner)  │ │   │ │(athenahealth)│ │
│ └──────┬───────┘ │   │ └──────┬────────┘ │   │ └──────┬───────┘ │
│        │         │   │        │          │   │        │         │
│ ┌──────┴───────┐ │   │ ┌──────┴────────┐ │   │ ┌──────┴───────┐ │
│ │MiniLedger    │◄┼───┼─┤MiniLedger     │◄┼───┼─┤MiniLedger    │ │
│ │Node          │ │   │ │Node           │ │   │ │Node          │ │
│ └──────────────┘ │   │ └───────────────┘ │   │ └──────────────┘ │
│                  │   │                   │   │                  │
│ Patient Records  │   │ Patient Records   │   │ Patient Records  │
│ (local DB)       │   │ (local DB)        │   │ (local DB)       │
└──────────────────┘   └───────────────────┘   └──────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                    ┌────────────┴────────────┐
                    │     Raft Consensus       │
                    │  (Crash Fault Tolerant)  │
                    └─────────────────────────┘
                                 │
          ┌──────────────────────┼──────────────────────┐
          │                      │                      │
┌─────────┴────────┐  ┌─────────┴────────┐  ┌─────────┴────────┐
│  HealthInsure    │  │  PharmaCorp      │  │  Public Health   │
│  (Node 4, Raft)  │  │  (Node 5, Raft)  │  │  (Node 6, Audit) │
│                  │  │                  │  │                  │
│ Claims Processing│  │ Clinical Trials  │  │ Epidemiology     │
│ Fraud Detection  │  │ Recruitment      │  │ Reporting        │
└──────────────────┘  └──────────────────┘  └──────────────────┘

Implementation​

Step 1: Patient Identity and Record Index​

Patients are identified by a consortium-wide ID linked to a hash of their government ID. The actual government ID is never stored on-chain:

import { createHash } from 'crypto';

function createPatientIdentity(patientData) {
  const nationalIdHash = createHash('sha256')
    .update(patientData.nationalId + process.env.ID_SALT)
    .digest('hex');

  return {
    patient_id: `PAT-${nationalIdHash.slice(0, 12)}`,
    demographic_hash: createHash('sha256')
      .update(`${patientData.firstName}|${patientData.lastName}|${patientData.dob}`)
      .digest('hex'),
    record_locations: [] // Which hospitals have records for this patient
  };
}

When a patient visits General Hospital, the hospital creates or updates the patient index entry:

await consortiumNode.submit({
  key: `patient:${patientId}`,
  value: {
    consent_version: 1,
    consent_date: '2026-03-15T09:00:00Z',
    consent_scope: ['treatment', 'payment', 'operations'],
    record_locations: [
      { provider: 'general-hospital', record_count: 12, last_updated: '2026-05-20' },
      { provider: 'city-medical', record_count: 5, last_updated: '2024-11-03' }
    ],
    active_consents: {
      'pharmacorp-trial-2026': {
        granted: true,
        scope: 'research',
        granted_at: '2026-04-01',
        expires: '2027-04-01'
      }
    }
  }
});

Step 2: Per-Record Encryption with Granular Access​

When a physician creates a clinical note, it's encrypted so only authorized parties can read it:

async function createClinicalNote(patientId, noteData, authorizingProviders) {
  const noteKey = `record:${patientId}:note:${Date.now()}`;

  await consortiumNode.submit({
    key: noteKey,
    value: {
      record_type: 'clinical_note',
      patient_id: patientId,
      author: {
        provider_id: 'general-hospital',
        physician_id: 'dr-smith-4421',
        specialty: 'cardiology',
        timestamp: new Date().toISOString()
      },
      content: {
        chief_complaint: noteData.complaint,
        assessment: noteData.assessment,
        plan: noteData.plan,
        diagnosis_codes: noteData.icd10Codes,
        medications_prescribed: noteData.medications
      }
    },
    privacy: {
      readers: [
        'pk_general-hospital',
        'pk_city-medical',       // Referring physician needs access
        'pk_patient-portal',      // Patient access
        'pk_healthinsure-claims'  // Insurance needs to verify
      ],
      writers: ['pk_general-hospital'],
      public: false
    }
  });
}

A radiology lab at a different hospital can't read this note unless they're explicitly added to the readers list. The note exists, its existence is provable, but its contents are ciphertext to unauthorized nodes.

Patient consent isn't binary — it's granular, time-bound, and revocable. A smart contract manages this:

const consentManager = {
  grantConsent(ctx, patientId, granteeProviderId, scope, expirationDate) {
    const patientKey = `patient:${patientId}`;
    const patient = ctx.get(patientKey);

    if (!patient) throw new Error('Patient not found');

    const consentId = `consent-${Date.now()}`;

    patient.active_consents[consentId] = {
      grantee: granteeProviderId,
      scope,
      granted_at: new Date().toISOString(),
      expires: expirationDate,
      status: 'active'
    };

    ctx.set(patientKey, patient);
    ctx.log(`Consent granted: ${patientId} → ${granteeProviderId} (${scope})`);
  },

  revokeConsent(ctx, patientId, consentId) {
    const patientKey = `patient:${patientId}`;
    const patient = ctx.get(patientKey);

    if (!patient.active_consents[consentId]) {
      throw new Error('Consent not found');
    }

    patient.active_consents[consentId].status = 'revoked';
    patient.active_consents[consentId].revoked_at = new Date().toISOString();

    ctx.set(patientKey, patient);
    ctx.log(`Consent revoked: ${patientId} → ${consentId}`);
  },

  verifyAccess(ctx, patientId, providerId, requestedScope) {
    const patient = ctx.get(`patient:${patientId}`);

    if (!patient) return { allowed: false, reason: 'patient_not_found' };

    // Emergency access override
    if (requestedScope === 'emergency') {
      return { allowed: true, reason: 'emergency_override', requires_review: true };
    }

    const activeConsents = Object.entries(patient.active_consents)
      .filter(([_, c]) =>
        c.status === 'active' &&
        c.grantee === providerId &&
        new Date(c.expires) > new Date() &&
        (c.scope === requestedScope || c.scope === 'all')
      );

    if (activeConsents.length === 0) {
      return { allowed: false, reason: 'no_active_consent' };
    }

    return { allowed: true, consent_id: activeConsents[0][0] };
  }
};

export default consentManager;

Emergency access is handled with an override — "break glass" access is allowed but flagged for mandatory post-hoc review, which satisfies both clinical needs and compliance requirements.

Step 4: Clinical Data Queries for Research​

PharmaCorp is running a clinical trial and needs to find eligible patients across the consortium. Instead of asking each hospital to run a query and return results (HIPAA compliance nightmare), they submit a de-identified query:

-- Find patients eligible for a cardiovascular trial
-- Criteria: age 45-75, diagnosed with hypertension, not currently on beta blockers
SELECT
  s1.key as patient_key,
  json_extract(s1.value, '$.age') as age,
  json_extract(s1.value, '$.gender') as gender,
  json_extract(s1.value, '$.diagnosis_codes') as diagnoses,
  json_extract(s1.value, '$.medications') as medications
FROM world_state s1
WHERE s1.key LIKE 'patient:%'
  AND CAST(json_extract(s1.value, '$.age') AS INTEGER) BETWEEN 45 AND 75
  AND json_extract(s1.value, '$.diagnosis_codes') LIKE '%I10%'
  AND json_extract(s1.value, '$.medications') NOT LIKE '%beta_blocker%'
  AND json_extract(s1.value, '$.active_consents.pharmacorp-trial-2026.granted') = 'true'

The query returns de-identified counts and demographic summaries — not individual patient records. Each hospital's node processes the query locally and returns aggregated results. Individual identities are protected by the per-record encryption model.

Step 5: Claims Processing and Fraud Detection​

HealthInsure receives a claim from General Hospital. Before paying, they verify against the blockchain:

async function verifyClaim(claimData) {
  const { patientId, providerId, procedureCode, serviceDate, amount } = claimData;

  // 1. Verify the patient had a visit at this provider on this date
  const encounters = await consortiumNode.query(`
    SELECT key FROM world_state
    WHERE key LIKE 'record:${patientId}:encounter:%'
      AND json_extract(value, '$.provider_id') = ?
      AND json_extract(value, '$.service_date') = ?
  `, [providerId, serviceDate]);

  if (encounters.length === 0) {
    return { status: 'denied', reason: 'No matching encounter found on ledger' };
  }

  // 2. Check for duplicate claims (fraud detection)
  const duplicates = await consortiumNode.query(`
    SELECT key, json_extract(value, '$.claim_id') as claim_id
    FROM world_state
    WHERE key LIKE 'claim:%'
      AND json_extract(value, '$.patient_id') = ?
      AND json_extract(value, '$.procedure_code') = ?
      AND json_extract(value, '$.service_date') = ?
      AND json_extract(value, '$.provider_id') != ?
  `, [patientId, procedureCode, serviceDate, providerId]);

  if (duplicates.length > 0) {
    return {
      status: 'flagged',
      reason: `Duplicate claim detected from ${duplicates.length} other provider(s)`,
      duplicate_claims: duplicates
    };
  }

  // 3. Verify the provider is authorized to perform this procedure
  const providerAuth = await consortiumNode.query(`
    SELECT json_extract(value, '$.authorized_procedures') as procedures
    FROM world_state
    WHERE key = 'provider:${providerId}'
  `);

  return { status: 'approved' };
}

The blockchain provides a single source of truth. The insurer doesn't need to call the hospital to verify the encounter — it's on the shared ledger with cryptographic proof. Duplicate claims across different providers are detected automatically.

Step 6: Public Health Reporting​

The Public Health Agency needs real-time epidemiological data. They run queries across the consortium:

-- Influenza-like illness surveillance: daily case counts by region
SELECT
  json_extract(value, '$.region') as region,
  DATE(json_extract(value, '$.service_date')) as date,
  COUNT(*) as ili_cases
FROM world_state
WHERE key LIKE 'record:%:encounter:%'
  AND json_extract(value, '$.diagnosis_codes') LIKE '%J11%'
  AND json_extract(value, '$.service_date') > datetime('now', '-7 days')
GROUP BY region, date
ORDER BY date DESC, ili_cases DESC;

No patient identifiers are exposed. The agency sees counts by region and date — exactly what they need for early warning systems, without any PHI.

HIPAA Compliance Mapping​

HIPAA RuleHow the Blockchain Approach Satisfies It
Privacy Rule — Minimum NecessaryPer-record encryption ensures only authorized providers see specific records
Privacy Rule — Patient Right of AccessPatient portal node decrypts records; patient can query their complete history
Security Rule — Access ControlsPer-record ACLs define exactly which provider keys can read each record
Security Rule — Audit ControlsEvery access, consent grant/revoke, and data modification is immutably logged
Security Rule — IntegrityBlockchain immutability prevents record tampering; hash verification detects any attempt
Security Rule — Transmission SecurityAll inter-node communication over WebSocket with cryptographic signing
Breach Notification RuleComplete audit trail enables rapid determination of what (if anything) was exposed
Omnibus Rule — Business AssociatesBAs run their own nodes; same per-record encryption and audit controls apply

Why This Beats Centralized HIEs​

DimensionCentralized HIEConsortium Blockchain
Single point of failureYes — the HIE databaseNo — 5+ independent nodes
Data breach surfaceMassive — all records in one placeDistributed — breach one node, get one hospital's records
GovernanceContentious — who controls the HIE?Distributed — on-chain governance with voting
Data timelinessBatched — nightly/weekly syncReal-time — all nodes sync continuously
Consent managementCentralized — HIE operator managesPatient-controlled — consent recorded on-chain
Audit trail integrityOperator can modifyCryptographically immutable
Infrastructure costEnterprise database cluster5 modest VPS instances

Key Takeaways​

  1. Healthcare blockchain isn't about storing PHI on-chain. It's about a shared identity, consent, and access control layer that coordinates independent EHR systems without centralizing data.

  2. Per-record encryption replaces the centralized access control model. Each clinical record defines its own authorized readers — no central authorization server needed.

  3. Consent management is the killer feature. Patients control who can access which records. Consent grants and revocations are recorded immutably — auditors can verify the consent state at the time of any access.

  4. Fraud detection happens at the protocol level. Duplicate claims across providers are detected automatically because all claims are on the same ledger.

  5. Public health reporting becomes real-time. Epidemiological queries return live data, not weeks-old batch uploads.

Read the privacy and encryption guide for implementation details on per-record encryption, or the governance guide for consortium membership management.

About the Author

Prasad Kumkar is the Founder & CEO of ChainScore Labs. Over the last 5+ years, he has worked with teams building exchanges, DeFi infrastructure, smart contracts, tokenization systems, and protocol-level blockchain products, helping founders make architecture, security, and go-live decisions for production Web3 systems.