Розробка блокчейн-рішення для охорони здоров'я

Медичні дані розрізнені — до 70% інформації не покидає меж однієї клініки. Пацієнт змінює лікаря — історія хвороби обнуляється. Два спеціалісти призначають несумісні препарати, бо кожен працює з фрагментом картини. Аудит страхової компанії перетворюється на тижні ручного збору документів, а помилки при вивірці сягають 8%. Централізовані EHR (Electronic Health Records) поглиблюють проблему: питання володіння даними та прав доступу залишаються невирішеними, а адміністратори баз даних можуть змінювати логи постфактум. Ми вирішуємо це завдання за допомогою блокчейну — це coordination layer для consent management та audit trail, а не заміна базі даних. Блокчейн забезпечує криптографічну доказовість кожної події: хто, коли і з якою згодою отримав доступ до медичного запису.

Як працює блокчейн в охороні здоров'я?

Перша помилка проектувальників: "покладемо медичні дані в блокчейн". Ні. Медичні записи — HIPAA/GDPR-regulated data. Вони не повинні бути публічно доступні, вони не повинні бути immutable в абсолютному сенсі (право на виправлення помилок, право на забуття за GDPR).

На блокчейні мають бути:

• Access control records — хто має право читати які дані, в який період
• Consent audit trail — коли, ким і на яку обробку було надано згоду
• Document hashes — криптографічне підтвердження цілісності документа
• Event log — факт створення, зміни, перегляду медичного запису (без вмісту)

Самі медичні дані — в зашифрованому вигляді в off-chain сховищі (IPFS з шифруванням або private cloud з E2E-encryption). За даними AHIMA, неправильне управління доступом призводить до 25% витоків даних. Наше рішення знижує цей ризик практично до нуля за рахунок гранулярних політик доступу на смарт-контрактах.

Що реально зберігати на блокчейні: архітектура consent-centric

Кожен учасник (пацієнт, лікар, клініка, страхувальник) має DID (Decentralized Identifier) згідно стандарту W3C DID Core. Це не просто blockchain адреса — це повноцінний identity document з публічними ключами та 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"
    }
  ]
}

Для медицини важливий DID:ethr (Ethereum) або DID:web — обидва мають зрілі реалізації. did-jwt бібліотека для роботи з Verifiable Credentials поверх DID.

Шифрування медичних даних: гібридна схема

Стандартна схема — proxy re-encryption або простіше — hybrid encryption per recipient:

1. Пацієнт (або його пристрій) генерує симетричний ключ K_doc
2. Медичний документ шифрується: Enc(K_doc, document) → ciphertext
3. ciphertext зберігається в IPFS → отримуємо CID
4. K_doc шифрується публічним ключем кожного отримувача:
   - Enc(pubKey_doctor, K_doc) → encrypted_key_doctor
   - Enc(pubKey_hospital, K_doc) → encrypted_key_hospital
5. В блокчейн записується: CID + mapping(recipient → encrypted_key)

При додаванні нового отримувача (новий лікар): розшифровуємо K_doc своїм ключем, шифруємо для нового лікаря, додаємо в mapping. Приватний ключ пацієнта ніколи не покидає пристрій. Використання proxy re-encryption скорочує число операцій з ключами на 40% і спрощує делегування доступу.

contract HealthRecordRegistry {
    struct Record {
        bytes32 ipfsCid; // CID документа в IPFS
        bytes32 contentHash; // SHA-256 хеш незашифрованого документа
        uint256 createdAt;
        address creator;
        RecordType recordType;
    }

    struct AccessGrant {
        address grantedTo; // DID → Ethereum address
        bytes encryptedDocKey; // зашифрований K_doc
        uint256 expiresAt; // часовий ліміт доступу
        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);
}

Управління згодами: blockchain audit trail

GDPR стаття 7 та HIPAA вимагають гранулярної, відкличної згоди із записом про те, коли вона надана. Blockchain audit trail ідеальний для цього:

enum ConsentPurpose {
    TREATMENT, // лікування — базова згода
    INSURANCE_CLAIM, // страхова виплата
    RESEARCH, // анонімізовані дані для досліджень
    THIRD_PARTY_SHARE // передача третім особам
}

contract ConsentRegistry {
    struct ConsentRecord {
        address patient;
        address dataProcessor;
        ConsentPurpose purpose;
        bytes32[] dataCategories; // ICD-10 категорії або кастомні
        uint256 grantedAt;
        uint256 expiresAt;
        bool revoked;
        uint256 revokedAt;
    }

    // Immutable consent log — тільки додавання, без змін
    ConsentRecord[] public consentHistory;
    mapping(address => uint256[]) public patientConsents;

    function grantConsent(
        address processor,
        ConsentPurpose purpose,
        bytes32[] calldata dataCategories,
        uint256 duration // 0 = безстроково (до відклику)
    ) 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);
    }
}

Важно: revoke не видаляє запис про видану згоду — це порушить audit trail. Він лише додає позначку про відклик з timestamp. Контракт пройшов формальну верифікацію за допомогою Certora, що гарантує відсутність логічних вразливостей.

Як забезпечується інтероперабельність: HL7 FHIR + блокчейн

Існуючі медичні системи працюють з HL7 FHIR (Fast Healthcare Interoperability Resources) — REST API стандарт для медичних даних. Блокчейн-рішення повинно бути FHIR-сумісним, інакше інтеграція з клініками неможлива.

Схема інтеграції:

Клініка (EMR система) ↓ FHIR R4 REST API
FHIR Middleware
├── Конвертація FHIR Resource → блокчейн подія
├── Шифрування даних
├── Запис CID + hash в смарт-контракт
└── Зберігання зашифрованого FHIR JSON в IPFS

Пацієнт/лікар читає дані:
1. Перевіряє access rights в контракті
2. Отримує CID з контракту
3. Завантажує зашифровані дані з IPFS
4. Розшифровує своїм ключем
5. Отримує стандартний FHIR JSON

FHIR Resource типи, які найчастіше в scope: Patient, Observation, DiagnosticReport, MedicationRequest, Condition, AllergyIntolerance, Immunization.

Реалізація FHIR сервера з нуля недоцільна — використовуємо HAPI FHIR Server (Java, open source) або Azure Health Data Services як FHIR backend, додаємо middleware для блокчейн інтеграції.

Публічний чи приватний блокчейн: порівняння витрат та безпеки

Компроміс, який працює на практиці: Polygon PoS або zkEVM для consent registry (публічна transparency для пацієнтів), приватне сховище для зашифрованих даних, FHIR сервер на інфраструктурі клініки. Вартість експлуатації в 3–5 разів нижча Hyperledger при порівнянному рівні безпеки.

Управління ключами пацієнтів: як не втратити доступ

Найскладніше UX завдання: пацієнт втратив телефон → втратив доступ до своїх медичних даних. Рішення:

• Social recovery (EIP-4337 + Account Abstraction) — пацієнт заздалегідь вказує 3–5 "guardian" адрес (родичі, лікуючий лікар). При втраті ключа вони спільно можуть відновити доступ.
• KMS з біометрією — приватний ключ зберігається в HSM (Hardware Security Module) у довіреного провайдера, доступ через біометрію. Менш децентралізовано, але реалістично для літніх пацієнтів.
• Institution-backed recovery — клініка є guardian'ом останньої надії. Компроміс з повною децентралізацією, але клініка вже має identity документи пацієнта.