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

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

Медицинские данные — одна из немногих областей, где блокчейн решает реальную проблему, а не создаёт иллюзию её решения. Проблема конкретна: пациент меняет клинику, и его история болезни не следует за ним. Или: два независимых специалиста назначают несовместимые препараты, потому что видят разные части истории. Или: аудит страховой компании — недели ручного сбора документов. Централизованные 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).

Архитектура: consent-centric модель

Identity и ключи

Каждый участник (пациент, врач, клиника, страховщик) имеет 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. Приватный ключ пациента никогда не покидает устройство.

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

Consent management

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.

Интероперабельность: 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 для блокчейн интеграции.

Выбор сети: публичный блокчейн или private?

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

Private/Consortium blockchain (Hyperledger Fabric, Quorum):

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

Public blockchain (Ethereum, Polygon):

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

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

Управление ключами пациентов

Самая сложная UX задача: пациент потерял телефон → потерял доступ к своим медицинским данным. Решения:

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

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

Institution-backed recovery — клиника является guardian'ом последней надежды. Компромисс с полной децентрализацией, но клиника уже имеет identity документы пациента.

Регуляторный контекст

GDPR статья 9 относит медицинские данные к "special categories" — повышенные требования к обработке. Конкретно для блокчейн:

• Право на удаление (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 месяцев. Большая часть времени — не разработка, а регуляторное согласование, работа с юристами и адаптация под конкретные требования клиники/страны.