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

Пацієнт переїжджає до іншої клініки — його історію хвороби доводиться збирати по крихтах з різних систем 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 (Wikipedia) дозволяє делегувати доступ без розкриття оригінального ключа. Пацієнт видає лікарю грант доступу на конкретний період і конкретні записи — все через один смарт-контракт.

Як працює 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. Блокчейн-рішення у 3 рази краще за централізовані EHR за швидкістю доступу до історії хвороби та на 70% знижує навантаження на адміністративний персонал. Ми гарантуємо відповідність HIPAA та GDPR, а наші сертифіковані аудитори перевіряють код. Компанія має 10+ років досвіду в Web3 та реалізувала понад 50 успішних проєктів. Отримайте консультацію з архітектури — оцінимо ваш проєкт за 2 дні, підберемо стек і підготуємо детальний roadmap.

Що входить у роботу

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

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

Зв'яжіться — ми підготуємо комерційну пропозицію з точними цифрами.

Терміни та вартість

Повна production-ready система: 4-6 місяців. MVP без proxy re-encryption та FHIR інтеграції: 2-3 місяці. Вартість розраховується індивідуально під вашу інфраструктуру. Середній бюджет MVP — від $50,000. Компанія надає 6 місяців безкоштовної підтримки після запуску.