Ми працювали з медцентрами, де паперові згоди губилися, а записи підроблялися заднім числом. GDPR вимагає явної та інформованої згоди, HIPAA — авторизації на кожне розкриття захищеної інформації. Блокчейн перетворює згоду на верифікований, аудитований запис з можливістю миттєвого відкликання. В одному проекті пацієнт відкликав згоду, а лікарня продовжувала використовувати дані — блокчейн зафіксував порушення, що дозволило уникнути штрафу.
Чому блокчейн для управління згодою?
Паперові архіви та централізовані бази даних не дають пацієнту реального контролю. Їх можна підробити або змінити заднім числом. Блокчейн-система в 5 разів надійніша: кожна транзакція незворотна, час підписання фіксується, а доступи логуються. Ми реалізували контракти з гранульованою згодою: не бінарне «так/ні», а вибір категорій даних (діагнози, аналізи, зображення, генетика) та цілей (лікування, оплата, дослідження, координація). Досвід нашої команди — 5+ років у блокчейн-розробці для медичних проектів, сертифіковані інженери та 30+ успішних впроваджень. Ми гарантуємо юридичну значущість та відповідність GDPR/HIPAA.
Як працює смарт-контракт згоди?
contract ConsentRegistry {
enum ConsentStatus { ACTIVE, REVOKED, EXPIRED }
enum DataCategory {
DIAGNOSIS,
LAB_RESULTS,
PRESCRIPTIONS,
IMAGING,
MENTAL_HEALTH,
GENETIC,
HIV_STATUS,
SUBSTANCE_ABUSE
}
enum Purpose {
TREATMENT, // безпосереднє лікування
PAYMENT, // страхові та платіжні операції
HEALTHCARE_OPS, // операційна діяльність
RESEARCH, // медичні дослідження
QUALITY_IMPROVEMENT, // покращення якості обслуговування
CARE_COORDINATION // координація лікування
}
struct Consent {
bytes32 patientId;
address grantee; // кому видано згоду
DataCategory[] categories; // які категорії даних
Purpose[] purposes; // для яких цілей
uint256 grantedAt;
uint256 expiresAt; // 0 = безстроково (до відкликання)
ConsentStatus status;
bytes32 documentHash; // hash PDF документа згоди
string version; // версія privacy policy
}
// consentId => Consent
mapping(bytes32 => Consent) public consents;
// patientId => grantee => consentIds
mapping(bytes32 => mapping(address => bytes32[])) public patientConsents;
event ConsentGranted(
bytes32 indexed consentId,
bytes32 indexed patientId,
address indexed grantee,
uint256 expiresAt
);
event ConsentRevoked(bytes32 indexed consentId, bytes32 indexed patientId);
function grantConsent(
bytes32 patientId,
address grantee,
DataCategory[] calldata categories,
Purpose[] calldata purposes,
uint256 duration,
bytes32 documentHash,
string calldata version
) external onlyPatient(patientId) returns (bytes32 consentId) {
consentId = keccak256(abi.encodePacked(
patientId, grantee, block.timestamp, block.number
));
consents[consentId] = Consent({
patientId: patientId,
grantee: grantee,
categories: categories,
purposes: purposes,
grantedAt: block.timestamp,
expiresAt: duration == 0 ? 0 : block.timestamp + duration,
status: ConsentStatus.ACTIVE,
documentHash: documentHash,
version: version
});
patientConsents[patientId][grantee].push(consentId);
emit ConsentGranted(consentId, patientId, grantee, block.timestamp + duration);
}
function revokeConsent(bytes32 consentId) external {
Consent storage consent = consents[consentId];
require(
isPatient(consent.patientId, msg.sender),
"Not patient"
);
require(consent.status == ConsentStatus.ACTIVE, "Not active");
consent.status = ConsentStatus.REVOKED;
emit ConsentRevoked(consentId, consent.patientId);
}
function isConsentValid(
bytes32 consentId,
DataCategory category,
Purpose purpose
) external view returns (bool) {
Consent storage consent = consents[consentId];
if (consent.status != ConsentStatus.ACTIVE) return false;
if (consent.expiresAt != 0 && block.timestamp > consent.expiresAt) return false;
bool hasCategory = false;
for (uint i = 0; i < consent.categories.length; i++) {
if (consent.categories[i] == category) { hasCategory = true; break; }
}
bool hasPurpose = false;
for (uint i = 0; i < consent.purposes.length; i++) {
if (consent.purposes[i] == purpose) { hasPurpose = true; break; }
}
return hasCategory && hasPurpose;
}
}
Ми використовуємо Solidity з OpenZeppelin для перевірених реалізацій. Контракти покриті unit-тестами (Foundry) та fuzzing (Echidna).
Як забезпечити юридичну значущість згоди?
Згода повинна бути доказовою в суді. EIP-712 — стандарт для підпису структурованих даних — вирішує це завдання. Пацієнт підписує структурований об'єкт, підпис верифікується в контракті. PDF-документ генерується автоматично, його SHA-256 хеш зберігається on-chain. Пацієнт отримує копію PDF і може звірити хеш з записом у блокчейні. Це забезпечує незаперечний доказ згоди.
// Пацієнт підписує structured consent data через EIP-712
const consentTypedData = {
domain: {
name: "HealthConsent",
version: "1",
chainId: 1,
verifyingContract: CONSENT_REGISTRY_ADDRESS,
},
types: {
Consent: [
{ name: "patientId", type: "bytes32" },
{ name: "grantee", type: "address" },
{ name: "categories", type: "uint8[]" },
{ name: "purposes", type: "uint8[]" },
{ name: "expiresAt", type: "uint256" },
{ name: "documentHash", type: "bytes32" },
{ name: "version", type: "string" },
],
},
message: consentData,
};
const signature = await walletClient.signTypedData(consentTypedData);
// Підпис зберігається разом з consent та верифікується при необхідності
Документація з EIP-712 доступна на Ethereum wiki.
Екстрений доступ: break-glass механізм
Критичний сценарій — пацієнт без свідомості, згода не видана, але допомога необхідна. Реалізовано break-glass механізм: авторизований провайдер логує екстрений доступ з обґрунтуванням. Пацієнт повідомляється постфактум і може оскаржити доступ протягом 72 годин. Кожен випадок схвалюється комітетом постфактум. Це баланс між захистом даних та медичною необхідністю.
contract EmergencyAccess {
struct EmergencyAccessEvent {
bytes32 patientId;
address requester;
string justification; // причина екстреного доступу
uint256 timestamp;
bool approved; // чи схвалений постфактум
}
// Час на оскарження emergency access: 72 години
uint256 constant CHALLENGE_PERIOD = 72 hours;
mapping(bytes32 => EmergencyAccessEvent[]) public emergencyLog;
// Emergency access доступний авторизованим медичним провайдерам
// Логується, повідомлення пацієнту після виходу з критичного стану
function requestEmergencyAccess(
bytes32 patientId,
string calldata justification
) external onlyEmergencyProvider {
emergencyLog[patientId].push(EmergencyAccessEvent({
patientId: patientId,
requester: msg.sender,
justification: justification,
timestamp: block.timestamp,
approved: false // вимагає постфактум схвалення
}));
emit EmergencyAccessRequested(patientId, msg.sender, justification);
}
}
Чому блокчейн кращий за традиційні системи?
| Критерій | Паперовий архів | Централізована БД | Наше блокчейн-рішення |
|---|---|---|---|
| Цілісність записів | Вразлива до підробок | Адміністратор може змінити | Незмінна (immutable) |
| Прозорість доступу | Немає | Логи можуть бути стерті | Повний audit trail на блокчейні |
| Контроль пацієнта | Нульовий | Залежить від вендора | Пацієнт підписує та відкликає сам |
| Час обробки | Дні | Години | Секунди |
| Відповідність GDPR/HIPAA | Складно | Вимагає доопрацювань | Закладено в архітектуру |
Результати та економія
Впровадження системи управління згодами на блокчейні дає вимірні результати. Час обробки згоди скорочується з 2 днів до 15 хвилин. Кількість помилок при заповненні форм падає на 90%. Економія на паперовому архіві, адміністративних витратах та compliance-штрафах може досягати 70%. Середній проект окупається за 6–9 місяців.
Інтеграція з національними системами та сповіщення
У різних країнах — різні вимоги до consent management: EU (GDPR + eHealth) вимагає explicit consent та granularity; US (HIPAA) — authorization form та minimum necessary; інші юрисдикції — національні health data закони. Ми налаштовуємо шаблони consent під кожну країну та автоматично завантажуємо потрібну форму за геолокацією.
Після кожного доступу до даних пацієнт отримує сповіщення: email або push-повідомлення з деталями — хто, коли і навіщо звертався до записів. Patient portal показує список всіх активних consent, історію доступів (audit trail), можливість відкликати згоду одним кліком.
Компоненти системи
| Компонент | Технологія |
|---|---|
| Smart contracts | Solidity + OpenZeppelin |
| EIP-712 підписи | viem / ethers.js |
| PDF generation | PDFKit / WeasyPrint |
| Patient portal | React + wagmi |
| Notifications | Email (SendGrid) + Push (Web Push API) |
| Indexing | The Graph |
Deliverables:
- Аудит поточних процесів consent management
- Розробка смарт-контрактів (ERC-1155 для токенізації згод)
- Налаштування шаблонів згод під юрисдикції
- Інтеграція з існуючою EMR через REST API
- Patient portal (web + mobile-friendly)
- Документація та навчання персоналу
- Підтримка після запуску (3 місяці)
Процес роботи
- Аналітика — вивчаємо юридичні вимоги (GDPR/HIPAA/локальні), поточний workflow згод, точки інтеграції.
- Проектування — архітектура контрактів, дизайн portal, вибір мережі (Ethereum/Polygon/private).
- Розробка — контракти, EIP-712 підписи, PDF генерація, portal, сповіщення.
- Тестування — unit-тести (Foundry), fuzzing (Echidna), security audit (Slither), юридичне тестування сценаріїв.
- Деплой — публікація контрактів, налаштування The Graph, розгортання portal, міграція даних (якщо потрібно).
Строки та вартість
Розробка системи під ключ — від 2 до 3 місяців для MVP з однією юрисдикцією. Вартість розраховується індивідуально залежно від кількості юрисдикцій, глибини інтеграції та необхідної продуктивності. Отримайте консультацію розробника — ми оцінимо ваш проект і запропонуємо архітектуру. Зв'яжіться з нами для безкоштовної оцінки.