Розробка системи зберігання медичних записів на блокчейні
Пацієнт переїжджає до іншої клініки — його історію хвороби доводиться збирати по крихтах з різних систем 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 contracts | Solidity + OpenZeppelin |
| Шифрування | AES-256-GCM + RSA або ECIES |
| Proxy re-encryption | Threshold Network / NuCypher |
| DID | did:ethr + DID Resolver |
| Сховище | IPFS + Filecoin або AWS S3 HIPAA |
| FHIR | HAPI FHIR (Java) або medplum (TypeScript) |
| Indexing | The Graph |
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);
}
}
Деталі моделі згод (Consent Model)
Пацієнт може надавати інформовану згоду на конкретні типи записів і терміни. Смарт-контракт консиліуму перевіряє, що всі сторони схвалили доступ перед передачею ключа. Це забезпечує compliance з GDPR та HIPAA без централізованого сховища згод.Відповідність регуляторним вимогам
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
Поетапний план впровадження
- Аудит інфраструктури — аналіз поточних EMR, compliance gaps, вибір блокчейн-платформи.
- Архітектура та моделювання — DID scheme, FHIR mapping, threat model.
- Розробка смарт-контрактів — Registry, Consent, Audit.
- Інтеграція шифрування — key management, proxy re-encryption.
- Підключення сховища — IPFS/Filecoin, FHIR parser.
- Інтеграція з EMR — FHIR API adapter.
- Фронтенд — портали для пацієнта та лікаря (React + RainbowKit).
- Безпека та аудит — формальна верифікація контрактів, penetration test.
- Деплой та навчання — 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 місяців підтримки після запуску
Зв'яжіться — ми підготуємо комерційну пропозицію з точними цифрами.
Терміни та вартість
| Фаза | Зміст | Термін |
|---|---|---|
| Архітектура | DID scheme, FHIR mapping, threat model | 1-2 тиж |
| Core contracts | Registry, consent, audit | 3-4 тиж |
| Encryption layer | Key management, proxy re-encryption | 2-3 тиж |
| Storage integration | IPFS/Filecoin, FHIR parser | 2-3 тиж |
| Provider integration | FHIR API adapter | 2-4 тиж |
| Frontend | Patient portal, provider UI | 3-4 тиж |
| Security audit | Контракти + crypto implementation | 2-4 тиж |
Повна production-ready система: 4-6 місяців. MVP без proxy re-encryption та FHIR інтеграції: 2-3 місяці. Вартість розраховується індивідуально під вашу інфраструктуру. Середній бюджет MVP — від $50,000. Компанія надає 6 місяців безкоштовної підтримки після запуску.