Blockchain Healthcare Solution Development

Development of Blockchain Solution for Healthcare

Medical data is one of the few areas where blockchain solves a real problem rather than creating an illusion of solving one. The problem is concrete: a patient changes clinics and their medical history doesn't follow them. Or: two independent specialists prescribe incompatible drugs because they see different parts of the history. Or: an insurance audit takes weeks of manual document collection. Centralized EHR (Electronic Health Records) solves part of this but creates a new problem — who owns the data and who has the right to read it. Blockchain here is not a database replacement — it's a coordination layer for consent management and audit trail.

What Should Actually Be on Blockchain

The first mistake designers make: "let's put medical data on blockchain". No. Medical records are HIPAA/GDPR-regulated data. They should not be publicly accessible, they should not be immutable in absolute terms (right to correct errors, right to be forgotten under GDPR).

On blockchain should be:

• Access control records — who has the right to read what data, in which period
• Consent audit trail — when, by whom and for what processing consent was given
• Document hashes — cryptographic proof of document integrity
• Event log — fact of creation, modification, viewing of medical record (without content)

Medical data itself — in encrypted form in off-chain storage (IPFS with encryption, or private cloud with E2E encryption).

Architecture: Consent-Centric Model

Identity and Keys

Each participant (patient, doctor, clinic, insurer) has a DID (Decentralized Identifier) according to W3C DID Core standard. This is not just a blockchain address — it's a full identity document with public keys and service endpoints.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:ethr:0x1234...abcd",
  "verificationMethod": [{
    "id": "did:ethr:0x1234...abcd#key-1",
    "type": "EcdsaSecp256k1RecoveryMethod2020",
    "controller": "did:ethr:0x1234...abcd",
    "blockchainAccountId": "eip155:1:0x1234...abcd"
  }],
  "service": [{
    "id": "did:ethr:0x1234...abcd#health-records",
    "type": "HealthRecordsEndpoint",
    "serviceEndpoint": "https://hospital.example.com/records"
  }]
}

For medicine, DID:ethr (Ethereum) or DID:web are important — both have mature implementations. did-jwt library for working with Verifiable Credentials on top of DID.

Medical Data Encryption

Standard scheme — proxy re-encryption or simpler — hybrid encryption per recipient:

1. Patient (or their device) generates symmetric key K_doc
2. Medical document is encrypted: Enc(K_doc, document) → ciphertext
3. ciphertext is stored in IPFS → get CID
4. K_doc is encrypted with public key of each recipient:
   - Enc(pubKey_doctor, K_doc) → encrypted_key_doctor
   - Enc(pubKey_hospital, K_doc) → encrypted_key_hospital
5. In blockchain is recorded: CID + mapping(recipient → encrypted_key)

When adding new recipient (new doctor): decrypt K_doc with your key, encrypt for new doctor, add to mapping. Patient's private key never leaves their device.

contract HealthRecordRegistry {
    struct Record {
        bytes32 ipfsCid;           // document CID in IPFS
        bytes32 contentHash;        // SHA-256 hash of unencrypted document
        uint256 createdAt;
        address creator;
        RecordType recordType;
    }
    
    struct AccessGrant {
        address grantedTo;         // DID → Ethereum address
        bytes encryptedDocKey;     // encrypted K_doc
        uint256 expiresAt;         // time limit on access
        bool isRevoked;
        ConsentPurpose purpose;    // TREATMENT, INSURANCE, RESEARCH
    }
    
    mapping(bytes32 => Record) public records;
    mapping(bytes32 => mapping(address => AccessGrant)) public accessGrants;
    
    event RecordCreated(bytes32 indexed recordId, address indexed patient, RecordType recordType);
    event AccessGranted(bytes32 indexed recordId, address indexed grantee, ConsentPurpose purpose);
    event AccessRevoked(bytes32 indexed recordId, address indexed grantee);
}

Consent Management

GDPR Article 7 and HIPAA require granular, revocable consent with record of when it was given. Blockchain audit trail is ideal for this:

enum ConsentPurpose {
    TREATMENT,        // treatment — basic consent
    INSURANCE_CLAIM,  // insurance payment
    RESEARCH,         // anonymized data for research
    THIRD_PARTY_SHARE // sharing with third parties
}

contract ConsentRegistry {
    struct ConsentRecord {
        address patient;
        address dataProcessor;
        ConsentPurpose purpose;
        bytes32[] dataCategories;   // ICD-10 categories or custom
        uint256 grantedAt;
        uint256 expiresAt;
        bool revoked;
        uint256 revokedAt;
    }
    
    // Immutable consent log — only additions, no changes
    ConsentRecord[] public consentHistory;
    mapping(address => uint256[]) public patientConsents;
    
    function grantConsent(
        address processor,
        ConsentPurpose purpose,
        bytes32[] calldata dataCategories,
        uint256 duration  // 0 = indefinite (until revoked)
    ) external {
        uint256 expiresAt = duration > 0 ? block.timestamp + duration : type(uint256).max;
        consentHistory.push(ConsentRecord({
            patient: msg.sender,
            dataProcessor: processor,
            purpose: purpose,
            dataCategories: dataCategories,
            grantedAt: block.timestamp,
            expiresAt: expiresAt,
            revoked: false,
            revokedAt: 0
        }));
        emit ConsentGranted(msg.sender, processor, purpose, uint256(consentHistory.length - 1));
    }
    
    function revokeConsent(uint256 consentId) external {
        ConsentRecord storage record = consentHistory[consentId];
        require(record.patient == msg.sender, "Not your consent");
        require(!record.revoked, "Already revoked");
        record.revoked = true;
        record.revokedAt = block.timestamp;
        emit ConsentRevoked(msg.sender, consentId);
    }
}

Important: revoke doesn't delete the record of given consent — this would break the audit trail. It only adds a revocation mark with timestamp.

Interoperability: HL7 FHIR + Blockchain

Existing medical systems work with HL7 FHIR (Fast Healthcare Interoperability Resources) — REST API standard for medical data. Blockchain solution must be FHIR-compatible, otherwise integration with clinics is impossible.

Integration scheme:

Clinic (EMR system)
    ↓ FHIR R4 REST API
FHIR Middleware
    ├── FHIR Resource → blockchain event conversion
    ├── Data encryption
    ├── Recording CID + hash to smart contract
    └── Storing encrypted FHIR JSON in IPFS

Patient/doctor reads data:
    1. Checks access rights in contract
    2. Gets CID from contract
    3. Downloads encrypted data from IPFS
    4. Decrypts with their key
    5. Gets standard FHIR JSON

FHIR Resource types most commonly in scope: Patient, Observation, DiagnosticReport, MedicationRequest, Condition, AllergyIntolerance, Immunization.

Building FHIR server from scratch is not practical — use HAPI FHIR Server (Java, open source) or Azure Health Data Services as FHIR backend, add middleware for blockchain integration.

Blockchain Choice: Public or Private?

For healthcare two camps and each has arguments:

Private/Consortium blockchain (Hyperledger Fabric, Quorum):

• Data doesn't fall into public blockchain (even as hashes)
• Regulators more comfortable with known set of participants
• Permissioned — only authorized nodes
• Minus: centralized management, vendor lock-in, less censorship resistance

Public blockchain (Ethereum, Polygon):

• Maximum transparency and auditability for patients
• Composability with DeFi (health insurance through DeFi — real use case)
• Minus: even data hashes are public, regulatory discomfort

Compromise that works in practice: Polygon PoS or zkEVM for consent registry (public transparency for patients), private storage for encrypted data, FHIR server on clinic infrastructure.

Patient Key Management

Most complex UX challenge: patient lost their phone → lost access to their medical data. Solutions:

Social recovery (EIP-4337 + Account Abstraction) — patient pre-designates 3–5 "guardian" addresses (family members, treating doctor). On key loss they can jointly recover access.

KMS with biometrics — private key stored in HSM (Hardware Security Module) with trusted provider, access through biometrics. Less decentralized but realistic for elderly patients.

Institution-backed recovery — clinic is guardian of last resort. Compromise with full decentralization but clinic already has patient identity documents.

Regulatory Context

GDPR Article 9 classifies medical data as "special categories" — heightened requirements for processing. Specifically for blockchain:

• Right to deletion (GDPR Art. 17): blockchain immutability conflicts with this. Solution — data always off-chain, only hash stored on-chain. When off-chain data is deleted, hash becomes "pointer to nowhere". The hash itself may not be personal data (EU CJEU decision 2024 on case C-413/22 not yet final, but general direction — hashes of PD in public blockchain remain risk zone).
• Data minimization: only what's necessary for audit trail goes to blockchain
• Cross-border transfer: if blockchain node is outside EU — SCCs (Standard Contractual Clauses) requirements apply

For HIPAA: technically correct implementation (encryption, access controls, audit log) complies with requirements. Business Associate Agreement needed with node providers.

Project Stages

Realistic timeline to production with real patients: 12–18 months. Most time is not development but regulatory coordination, work with lawyers and adaptation to specific clinic/country requirements.