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

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

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

Що насправді повинно бути на блокчейні

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

На блокчейні повинні бути:

• Записи контролю доступу — хто має право читати які дані, у якому періоді
• Audit trail згоди — коли, ким та на яку обробку була дана згода
• Хеші документів — криптографічне підтвердження цілісності документа
• Event log — факт створення, зміни, переглядання медичного запису (без вмісту)

Самі медичні дані — в зашифрованому вигляді в off-chain сховищі (IPFS з шифруванням, або приватна хмара з E2E encryption).

Архітектура: модель орієнтована на згоду

Ідентичність та ключі

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

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;         // часовий лімітcyBf на доступ
        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);
}

Управління згодою

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);
    }
}

Важливо: відзив не видаляє запис про видану згоду — це порушить audit trail. Він лише додає позначку про відзив з timestamp.

Взаємодія: HL7 FHIR + блокчейн

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

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

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

Пацієнт/лікар читає дані:
    1. Перевіряє права доступу в контракті
    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 для інтеграції блокчейну.

Вибір сети: публічний блокчейн або приватний?

Для healthcare два табори і кожен має аргументи:

Приватний/Consortium blockchain (Hyperledger Fabric, Quorum):

• Дані не потрапляють у публічний блокчейн (навіть у вигляді хешів)
• Регулятори комфортніше з відомим набором учасників
• Permissioned — тільки авторизовані ноди
• Мінус: централізоване управління, vendor lock-in, менша censorship resistance

Публічний блокчейн (Ethereum, Polygon):

• Максимальна прозорість та аудитабельність для пацієнтів
• Composability з DeFi (health insurance через DeFi — реальний use case)
• Мінус: навіть хеші даних публічні, нормативний дискомфорт

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

Управління ключами пацієнтів

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

Social recovery (EIP-4337 + Account Abstraction) — пацієнт заздалегідь вказує 3–5 адреси «guardian» (родичі, лікар). При втраті ключа вони спільно можуть восстановити доступ.

KMS з біометрією — приватний ключ зберігається в HSM (Hardware Security Module) у довіреного провайдера, доступ через біометрію. Менш децентралізовано, але реалістично для літніх пацієнтів.

Recovery при підтримці установи — клініка є guardian'ом останньої надії. Компромис з повною децентралізацією, але клініка вже має документи пацієнта.

Нормативний контекст

GDPR стаття 9 відносить медичні дані до "спеціальних категорій" — підвищені вимоги до обробки. Конкретно для блокчейну:

• Право на видалення (GDPR Art. 17): immutability блокчейну конфліктує з цим. Рішення — дані завжди off-chain, on-chain зберігається тільки хеш. При видаленні off-chain даних хеш стає «указівником в нікуди». Сам хеш може не бути персональними даними (EU CJEU рішення 2024 за справою C-413/22 поки не фінальне, але загальний напрямок — хеші ПД у публічному блокчейні залишаються зоною ризику).
• Data minimization: в блокчейн потрапляє тільки те, що необхідно для audit trail
• Cross-border transfer: якщо вузол блокчейну знаходиться поза EU — виникають вимоги SCCs (Standard Contractual Clauses)

Для HIPAA: технічно правильна реалізація (шифрування, access controls, audit log) відповідає вимогам. Business Associate Agreement потрібен з провайдерами вузлів.

Етапи проекту

Реалістичний термін до production з реальними пацієнтами: 12–18 місяців. Більшість часу — не розробка, а нормативне узгодження, робота з юристами та адаптація під конкретні вимоги клініки/країни.