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

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