עבדנו עם מרכזים רפואיים שבהם טפסי הסכמה מנייר אבדו ורשומות זויפו בדיעבד. GDPR דורש הסכמה מפורשת ומדעת; HIPAA מחייב הרשאה לכל חשיפה של מידע בריאותי מוגן. מערכת ניהול ההסכמות שלנו מבוססת בלוקצ'יין משתמשת בחוזים חכמים לניהול הסכמת מטופלים לנתוני בריאות. הבלוקצ'יין הופך הסכמה לרשומה ניתנת לאימות וביקורת שניתן לבטל באופן מיידי. בפרויקט אחד, מטופל ביטל הסכמה בזמן שבית החולים המשיך להשתמש בנתונים — הבלוקצ'יין תיעד את ההפרה, ועזר להימנע מקנס.
למה בלוקצ'יין לניהול הסכמות?
ארכיוני נייר ומאגרי מידע מרכזיים לא נותנים למטופלים שליטה אמיתית. הם ניתנים לזיוף או לשינוי רטרואקטיבי. מערכת בלוקצ'יין אמינה פי 5: כל עסקה היא בלתי הפיכה, זמן החתימה קבוע, והגישות מתועדות. יישמנו חוזים עם הסכמה גרעינית: לא "כן/לא" בינארי אלא בחירה של 8 קטגוריות נתונים (אבחנות, תוצאות מעבדה, דימות, גנטיקה, בריאות נפשית, סטטוס HIV, שימוש בחומרים, מרשמים) ו-6 מטרות (טיפול, תשלום, פעולות בריאות, מחקר, שיפור איכות, תיאום טיפול). הניסיון של הצוות שלנו: 5+ שנים בפיתוח בלוקצ'יין לפרויקטים רפואיים, מהנדסים מוסמכים, 30+ יישומים מוצלחים. אנו מבטיחים תוקף משפטי ועמידה ב-GDPR/HIPAA.
| קריטריון | ארכיון נייר | מאגר מרכזי | הפתרון הבלוקצ'יין שלנו |
|---|---|---|---|
| שלמות רשומה | פגיע לזיוף | מנהל יכול לשנות | בלתי ניתן לשינוי |
| שקיפות גישה | אין | יומנים ניתנים למחיקה | מסלול ביקורת מלא על השרשרת |
| שליטת מטופל | אפס | תלוי בספק | המטופל חותם ומבטל בעצמו |
| זמן עיבוד | ימים | שעות | שניות |
| עמידה ב-GDPR/HIPAA | קשה | דורש התאמות | מובנה בארכיטקטורה |
יישום טכני
עיצוב חוזה חכם
חוזה Solidity (הרחב)
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 ליישומים מוכחים. החוזים מכוסים בבדיקות יחידה (Foundry) ובדיקות פאזינג (Echidna).
תוקף משפטי עם EIP-712
הסכמה חייבת להיות ניתנת להוכחה בבית משפט. EIP-712 — תקן לחתימה על נתונים מובנים — פותר זאת. המטופל חותם על אובייקט מובנה; החתימה מאומתת בחוזה. מסמך PDF נוצר אוטומטית, וה-hash שלו מסוג SHA-256 נשמר על השרשרת. המטופל מקבל עותק PDF ויכול להשוות את ה-hash עם רשומת הבלוקצ'יין. זה מספק הוכחה בלתי ניתנת לערעור להסכמה.
דוגמת חתימת EIP-712 (הרחב)
// Пациент подписывает 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.
מנגנון 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);
}
}אינטגרציה ותאימות
אינטגרציה עם מערכות לאומיות
למדינות שונות יש דרישות הסכמה שונות: האיחוד האירופי (GDPR + eHealth) דורש הסכמה מפורשת וגרעינית; ארה"ב (HIPAA) — טופס הרשאה ומינימום הכרחי; תחומי שיפוט אחרים — חוקי נתוני בריאות לאומיים. אנו מתאימים תבניות הסכמה לכל מדינה וטוענים אוטומטית את הטופס הנכון לפי מיקום גיאוגרפי.
הודעות
לאחר כל גישה לנתונים, המטופל מקבל הודעה: אימייל או push עם פרטים — מי, מתי ולמה ניגש לרשומות. פורטל מטופלים מציג את כל ההסכמות הפעילות, היסטוריית גישות (מסלול ביקורת), ומאפשר ביטול בלחיצה אחת.
תוצאות ועלות
חיסכון והשפעה
יישום מערכת ניהול הסכמות מבוססת בלוקצ'יין מניב תוצאות מדידות. זמן עיבוד ההסכמה יורד מיומיים ל-15 דקות. שגיאות מילוי טפסים יורדות ב-90%. חיסכון בארכיוני נייר, עלויות אדמיניסטרטיביות וקנסות עמידה יכול להגיע ל-70% — עבור בית חולים בינוני, זה שווה ערך ל-$50,000–$100,000 בשנה. הפרויקט הממוצע מחזיר את עצמו תוך 6–9 חודשים.
לוחות זמנים ועלות פרויקט
מערכת turnkey טיפוסית עולה $60,000–$90,000 בהתאם למורכבות. הפיתוח אורך 2 עד 3 חודשים ל-MVP עם תחום שיפוט אחד. העלות מחושבת באופן אישי לפי מספר תחומי השיפוט, עומק האינטגרציה והביצועים הנדרשים.
המסירה והמומחיות שלנו
מה אנו מספקים
| רכיב | טכנולוגיה |
|---|---|
| חוזים חכמים | Solidity + OpenZeppelin |
| חתימות EIP-712 | viem / ethers.js |
| יצירת PDF | PDFKit / WeasyPrint |
| פורטל מטופלים | React + wagmi |
| הודעות | אימייל (SendGrid) + Push (Web Push API) |
| אינדוקס | The Graph |
כלול בכל פרויקט:
- ביקורת על תהליכי ניהול ההסכמות הקיימים
- פיתוח חוזים חכמים (ERC-1155 לטוקניזציה של הסכמה)
- הגדרת תבניות הסכמה לפי תחום שיפוט (עד 3)
- אינטגרציה עם EMR קיים באמצעות REST API
- פורטל מטופלים (אינטרנט + ידידותי למובייל)
- תיעוד מקיף והדרכת צוות
- 3 חודשי תמיכה לאחר השקה
למה לעבוד איתנו
5+ שנות ניסיון בבלוקצ'יין לבריאות, 30+ יישומים מוצלחים ב-10 מדינות, 15 מהנדסים המתמחים ב-Solidity, אבטחה ו-IT בריאות. הסמכות: GDPR, HIPAA, ISO 27001. חוזים מבוקרים: למעלה מ-50 ביקורות אבטחה שבוצעו.
תהליך
- אנליטיקה — לימוד דרישות משפטיות (GDPR/HIPAA/מקומי), זרימת עבודת ההסכמה הנוכחית, נקודות אינטגרציה.
- עיצוב — ארכיטקטורת חוזה, עיצוב פורטל, בחירת רשת (Ethereum/Polygon/פרטית).
- פיתוח — חוזים, חתימות EIP-712, יצירת PDF, פורטל, הודעות.
- בדיקות — בדיקות יחידה (Foundry), פאזינג (Echidna), ביקורת אבטחה (Slither), בדיקת תרחישים משפטיים.
- פריסה — פרסום חוזה, הגדרת The Graph, פריסת פורטל, העברת נתונים (אם נדרש).
קבלו ייעוץ מפתח למערכת ניהול ההסכמות הבלוקצ'יין שלכם. צרו קשר להערכה חינם.