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

Медичні дані розрізнені — до 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 документи пацієнта.