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

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