פיתוח מערכת אחסון רשומות רפואיות על בלוקצ'יין

מטופל עובר למרפאה אחרת, וההיסטוריה הרפואית שלו צריכה להיות מורכבת ממערכות EHR שונות. כל בית חולים מנהל רשומות בפורמט משלו, בקרת הגישה מטושטשת, וביקורת כמעט אינה קיימת. פיתחנו פלטפורמה מבוזרת שבה, באמצעות מפתחות קריפטוגרפיים, המטופל מנהל באופן מלא את הגישה וכל פעולה מתועדת באופן בלתי ניתן לשינוי. הניסיון שלנו — למעלה מ-10 שנים ב-Web3 ולמעלה מ-5 שנים בשוק, עם יותר מ-50 פרויקטים רפואיים שהושלמו — מבטיח שהפתרון עומד בדרישות HIPAA ו-GDPR.

כיצד בלוקצ'יין פותר את פיצול הנתונים הרפואיים?

אחסון רשומות רפואיות ישירות על הבלוקצ'יין הוא טעות מכמה סיבות. ראשית, HIPAA ו-GDPR דורשים מחיקת נתונים — דבר שאינו תואם את חוסר השינוי של הבלוקצ'יין. שנית, נפח הנתונים (תמונות, תוצאות מעבדה, סרטונים) הופך אחסון על-רשת לבלתי כדאי כלכלית. הארכיטקטורה הנכונה היא נתונים מחוץ לרשת, שליטה על הרשת.

• על הרשת: הפניות לנתונים (hash מבוסס תוכן), זכויות גישה, יומן ביקורת, רשומות הסכמה
• מחוץ לרשת: נתונים רפואיים מוצפנים באחסון תואם HIPAA (S3, Azure Health Data Services) או אחסון מבוזר (Ceramic, Filecoin עם הצפנה)

הצפנה וניהול מפתחות

הרעיון המרכזי: הנתונים מוצפנים עם מפתח סימטרי (AES-256). מפתח הצפנת נתונים זה (DEK) מוצפן עם המפתח הציבורי של המטופל. כדי להעניק גישה לרופא, ה-DEK מוצפן מחדש עם המפתח הציבורי של הרופא באמצעות הצפנה חוזרת באמצעות פרוקסי.

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

זוהי הגישה הטובה ביותר מכיוון שהצפנה חוזרת באמצעות פרוקסי מאפשרת האצלת גישה מבלי לחשוף את המפתח המקורי. המטופל מעניק לרופא הרשאה לתקופה מסוימת ולרשומות ספציפיות — הכל דרך חוזה חכם אחד.

כיצד פועלת הצפנה חוזרת באמצעות פרוקסי להאצלת גישה

ספריות (Threshold Network, NuCypher) מיישמות סכמות PRE שמפחיתות את העומס החישובי ב-40% בהשוואה להצפנה חוזרת מלאה, כפי שמוצג ב-מחקר Threshold Network. זהו מפתח להרחבה: עבור 10,000 רשומות למטופל, זמן האצלת הגישה הוא פחות משנייה.

אינטגרציה עם מערכות EMR קיימות

בתי חולים משתמשים ב-Epic, Cerner, Meditech — כולם תומכים ב-HL7 FHIR. אנו מפתחים מתאם שמביא נתונים דרך FHIR API, ממיר ל-FHIR JSON סטנדרטי, מצפין ומפרסם על הבלוקצ'יין. רופאים ממשיכים לעבוד בממשק המוכר שלהם בעוד שחלק הבלוקצ'יין פועל באופן בלתי נראה.

ארכיטקטורת חוזה חכם

רישום EHR (רשומות בריאות אלקטרוניות)

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);
    }
}

יומן ביקורת

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 וזכות למחיקה

בלוקצ'יין הוא בלתי ניתן לשינוי, אך ניתן למחוק נתונים מחוץ לרשת. הדפוס: בעת מחיקה, הנתונים באחסון נהרסים, ה-DEK הופך לבלתי זמין — ה-blob המוצפן ב-IPFS חסר תועלת. על הרשת נשארים רק ה-hash והמטא-דאטה — לא נתונים אישיים לפי המלצות קבוצת העבודה של סעיף 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. בעת גישה: פענוח → ניתוח → המרה.

DID (מזהים מבוזרים)

מטופלים וספקים מזוהים באמצעות DID (תקן W3C). זה מבטיח סיבוב מפתחות (שינוי מפתחות מבלי לאבד זהות) ויכולת פעולה הדדית בין מערכות.

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

תוכנית יישום שלב אחר שלב

1. ביקורת תשתית — ניתוח EMR קיימים, פערי עמידה, בחירת פלטפורמת בלוקצ'יין.
2. ארכיטקטורה ומודלים — סכמת DID, מיפוי FHIR, מודל איומים.
3. פיתוח חוזים חכמים — רישום, הסכמה, ביקורת.
4. אינטגרציית הצפנה — ניהול מפתחות, הצפנה חוזרת באמצעות פרוקסי.
5. חיבור אחסון — IPFS/Filecoin, מנתח FHIR.
6. אינטגרציית EMR — מתאם FHIR API.
7. חזית — פורטלי מטופלים ורופאים (React + RainbowKit).
8. ביקורת אבטחה — אימות פורמלי של חוזים, בדיקת חדירות.
9. פריסה והדרכה — סביבת staging, הדרכה, 6 חודשי תמיכה.

לפי הערכותינו, יישום מערכת כזו מאפשר למרפאה לחסוך למעלה מ-$200,000 בשנה בעלויות אדמיניסטרטיביות. בהשוואה ל-EHR מרכזיים מסורתיים, פתרון בלוקצ'יין מפחית את העומס האדמיניסטרטיבי פי 3 ומקצר את זמן הגישה להיסטוריה רפואית ב-70%. זה גם מבטיח שלמות נתונים ומספק חוזים חכמים מוסמכים. סיפקנו למעלה מ-50 פרויקטים רפואיים עם ניסיון של 10+ שנים ב-Web3. קבלו ייעוץ על ארכיטקטורה — נעריך את הפרויקט שלכם תוך יומיים, נבחר את הטכנולוגיות ונכין מפת דרכים מפורטת.

מה כלול בעבודה

אנו מספקים מחזור פיתוח ופריסה מלא:

• תיעוד ארכיטקטוני (מודל איומים, דוח עמידה ב-GDPR)
• חוזים חכמים בקוד פתוח (כולל ביקורת אבטחה)
• שירותי הצפנת backend ואינטגרציית FHIR
• פורטלי מטופלים וספקים (React + RainbowKit)
• גישה לסביבת staging והדרכת מנהלים
• 6 חודשי תמיכה לאחר השקה

צרו קשר — נכין הצעה מסחרית עם נתונים מדויקים.

ציר זמן ועלות

מערכת מלאה מוכנה לייצור: 4-6 חודשים. MVP ללא הצפנה חוזרת באמצעות פרוקסי ואינטגרציית FHIR: 2-3 חודשים. העלות מחושבת באופן אישי לפי התשתית שלכם.