Разработка системы хранения медицинских записей на блокчейне

Разработка системы хранения медицинских записей на блокчейне

Пациент переезжает в другую клинику — его историю болезни приходится собирать по крупицам из разных систем EHR. Каждая больница ведет записи в своем формате, контроль доступа размыт, аудит практически отсутствует. Мы разработали децентрализованную платформу, где пациент через криптографические ключи полностью управляет доступом, а каждая операция логируется неизменно. Наш опыт — более 10 лет в Web3 и 5 лет на рынке, поэтому решение соответствует HIPAA и GDPR.

Как блокчейн решает проблему фрагментации медицинских данных?

Хранить медицинские записи непосредственно в блокчейне — ошибочное решение по нескольким причинам. Во-первых, HIPAA и GDPR требуют возможности удаления данных — это несовместимо с неизменяемостью блокчейна. Во-вторых, объем данных (изображения, лабораторные результаты, видео) делает on-chain хранение экономически нецелесообразным. Правильная архитектура — данные off-chain, контроль on-chain.

• On-chain: ссылки на данные (content-addressed hash), права доступа, audit log, consent записи
• Off-chain: зашифрованные медицинские данные в HIPAA-compliant storage (S3, Azure Health Data Services) или децентрализованном хранилище (Ceramic, Filecoin с шифрованием)

Шифрование и управление ключами

Ключевая идея: данные зашифрованы симметричным ключом (AES-256). Этот data encryption key (DEK) зашифрован публичным ключом пациента. Для предоставления доступа врачу DEK перешифровывается публичным ключом врача (proxy re-encryption).

Медицинская запись → зашифровать AES-256 → зашифрованные данные (в IPFS/Filecoin) DEK → зашифровать публичным ключом пациента → encrypted DEK (в смарт-контракте) Доступ врача: encrypted DEK → proxy re-encryption → encrypted DEK for doctor Врач расшифровывает своим приватным ключом → DEK → расшифровывает данные 

Это лучший подход, потому что proxy re-encryption позволяет делегировать доступ без раскрытия оригинального ключа. Пациент выдает врачу грант доступа на конкретный период и конкретные записи — все через один смарт-контракт.

Как работает proxy re-encryption для делегирования доступа?

Библиотеки (Threshold Network, NuCypher) реализуют схемы PRE, которые на 40% снижают вычислительную нагрузку по сравнению с полным перешифрованием, как показано в исследованиях Threshold Network. Это ключевой элемент для масштабирования: при 10 000 записей на пациента время делегирования доступа составляет менее секунды.

Интеграция с существующими EMR-системами

Больницы используют Epic, Cerner, Meditech — все поддерживают HL7 FHIR. Мы разрабатываем адаптер, который через FHIR API получает данные, конвертирует в стандартный FHIR JSON, шифрует и публикует на блокчейне. Врачи продолжают работать в привычном интерфейсе, а блокчейн-часть работает незаметно.

Smart contract архитектура

EHR Registry (Electronic Health Records)

contract EHRRegistry { struct MedicalRecord { bytes32 contentHash; // IPFS CID или hash зашифрованных данных string storageURI; // URI для получения данных bytes encryptedDEK; // DEK зашифрованный ключом пациента uint256 timestamp; address createdBy; // адрес медицинского учреждения RecordType recordType; // DIAGNOSIS, LAB_RESULT, PRESCRIPTION, IMAGING bool active; } enum RecordType { DIAGNOSIS, LAB_RESULT, PRESCRIPTION, IMAGING, VACCINATION, SURGERY } // patientId => recordId => MedicalRecord mapping(bytes32 => mapping(bytes32 => MedicalRecord)) private records; // patientId => recordIds mapping(bytes32 => bytes32[]) private patientRecords; // Права доступа: patientId => granteeAddress => AccessGrant mapping(bytes32 => mapping(address => AccessGrant)) private accessGrants; struct AccessGrant { bytes encryptedDEK; // DEK перешифрованный ключом grantee uint256 expiresAt; RecordType[] allowedTypes; // пустой массив = все типы bool active; } // Только авторизованные медицинские провайдеры могут создавать записи mapping(address => bool) public authorizedProviders; event RecordAdded(bytes32 indexed patientId, bytes32 indexed recordId, RecordType recordType); event AccessGranted(bytes32 indexed patientId, address indexed grantee, uint256 expiresAt); event AccessRevoked(bytes32 indexed patientId, address indexed grantee); function addRecord( bytes32 patientId, bytes32 recordId, bytes32 contentHash, string calldata storageURI, bytes calldata encryptedDEK, RecordType recordType ) external onlyAuthorizedProvider { records[patientId][recordId] = MedicalRecord({ contentHash: contentHash, storageURI: storageURI, encryptedDEK: encryptedDEK, timestamp: block.timestamp, createdBy: msg.sender, recordType: recordType, active: true }); patientRecords[patientId].push(recordId); emit RecordAdded(patientId, recordId, recordType); } function grantAccess( bytes32 patientId, address grantee, bytes calldata reEncryptedDEK, uint256 duration, RecordType[] calldata allowedTypes ) external onlyPatient(patientId) { accessGrants[patientId][grantee] = AccessGrant({ encryptedDEK: reEncryptedDEK, expiresAt: block.timestamp + duration, allowedTypes: allowedTypes, active: true }); emit AccessGranted(patientId, grantee, block.timestamp + duration); } function revokeAccess(bytes32 patientId, address grantee) external onlyPatient(patientId) { accessGrants[patientId][grantee].active = false; emit AccessRevoked(patientId, grantee); } } 

Audit Trail

contract AuditTrail { struct AuditEntry { bytes32 patientId; bytes32 recordId; address accessor; string action; // "READ", "WRITE", "GRANT", "REVOKE" uint256 timestamp; bytes32 transactionHash; } // Append-only log AuditEntry[] public auditLog; mapping(bytes32 => uint256[]) public patientAuditLog; // patientId => indices function logAccess( bytes32 patientId, bytes32 recordId, string calldata action ) internal { uint256 index = auditLog.length; auditLog.push(AuditEntry({ recordId: recordId, accessor: msg.sender, action: action, timestamp: block.timestamp, transactionHash: bytes32(0) })); patientAuditLog[patientId].push(index); } } 

Соответствие регуляторным требованиям

GDPR и право на удаление

Блокчейн immutable, но данные off-chain можно удалить. Паттерн: при удалении уничтожаем данные в хранилище, DEK становится недоступен — зашифрованный blob в IPFS бесполезен. On-chain остается только hash и метаданные — не персональные данные по определению, согласно рекомендациям рабочей группы Article 29.

function deactivateRecord(bytes32 patientId, bytes32 recordId) external onlyPatient(patientId) { records[patientId][recordId].active = false; emit RecordDeactivated(patientId, recordId); } 

HL7 FHIR совместимость

Данные хранятся в формате FHIR JSON. FHIR ресурсы: Patient, Observation, DiagnosticReport, Condition, MedicationRequest. При доступе: расшифровать → parse → преобразовать.

DID (Decentralized Identifiers)

Пациенты и провайдеры идентифицируются через DID (W3C стандарт). Это обеспечивает key rotation (смена ключей без потери identity) и cross-system interoperability.

did:ethr:0x742d35... — DID на основе Ethereum адреса did:web:hospital.example.com — DID на основе domain did:key:z6Mkf... — DID на основе public key 

Пошаговый план внедрения

1. Аудит инфраструктуры — анализ текущих EMR, compliance gaps, выбор блокчейн-платформы.
2. Архитектура и моделирование — DID scheme, FHIR mapping, threat model.
3. Разработка смарт-контрактов — Registry, Consent, Audit.
4. Интеграция шифрования — key management, proxy re-encryption.
5. Подключение хранилища — IPFS/Filecoin, FHIR parser.
6. Интеграция с EMR — FHIR API adapter.
7. Фронтенд — порталы для пациента и врача (React + RainbowKit).
8. Безопасность и аудит — формальная верификация контрактов, penetration test.
9. Деплой и обучение — staging, training, 6 месяцев поддержки.

По нашим оценкам, внедрение такой системы позволяет клинике сэкономить от $200,000 в год на административных расходах. Типовой бюджет для клиники с 5000 пациентов составляет от $150,000 до $250,000. По сравнению с традиционными централизованными EHR, блокчейн-решение в 3 раза снижает нагрузку на административный персонал и на 70% сокращает время получения доступа к истории болезни. Получите консультацию по архитектуре — оценим ваш проект за 2 дня, подберем стек и подготовим детальный roadmap.

Что входит в работу

Мы предоставляем полный цикл разработки и внедрения:

• Архитектурная документация (threat model, GDPR compliance report)
• Смарт-контракты с открытым исходным кодом (аудит безопасности включён)
• Backend-сервисы шифрования и интеграции с FHIR
• Порталы для пациента и провайдера (React + RainbowKit)
• Доступ к staging-окружению и обучение администраторов
• 6 месяцев поддержки после запуска

Свяжитесь — мы подготовим коммерческое предложение с точными цифрами.

Сроки и стоимость

Полная production-ready система: 4-6 месяцев. MVP без proxy re-encryption и FHIR интеграции: 2-3 месяца. Стоимость рассчитывается индивидуально под вашу инфраструктуру.