אנו מפתחים אפליקציות מובייל לרשומות רפואיות אלקטרוניות (EMR) הפותרות סתירה יסודית: הנתונים חייבים להיות נגישים מיידית לרופאים, ובמקביל מוגנים ברמת הדרישות הרגולטוריות המחמירות. המטרה היא לא רק להציג היסטוריית ביקורים, אלא לספק גישה מאובטחת לנתונים רפואיים אישיים עם דרגת האבטחה הגבוהה ביותר (HIPAA, 152-FZ) וחוויית משתמש המאפשרת פתיחת הרשומה הנדרשת תוך 10 שניות בסביבה קלינית. תוך ניצול ניסיון מעשרות פרויקטים בתחום הבריאות, אנו מבטיחים עמידה בדרישות תחום השיפוט והשתלבות עם מערכות מידע קיימות (MIS). הפתרון שלנו חוסך עד 40% מהתקציב בהשוואה לרכישת מערכת EMR מוכנה.
מסגרות רגולטוריות — יסוד הארכיטקטורה
בחירת תחום השיפוט קובעת: היכן ממוקם האירוח, איזו הצפנה ורישום (logging) הם חובה, האם ניתן להשתמש ב-Firebase Analytics, ואילו הודעות חייבות להיות מוצגות למשתמש.
- רוסיה. צו משרד הבריאות מס' 947н (מבנה EMD), החוק הפדרלי 323 "על יסודות הגנת הבריאות", החוק הפדרלי 152 על נתונים אישיים. הנתונים — קטגוריה מיוחדת של נתונים אישיים, עיבוד רק בהסכמה מפורשת. שרת — רק בתוך רוסיה.
- אירופה. GDPR (קטגוריות מיוחדות של נתונים, סעיף 9), יישומים לאומיים (למשל DSGVO בגרמניה). זכות גישה, זכות מחיקה.
- ארה"ב. HIPAA: מידע בריאותי מוגן (PHI), הסכם שותף עסקי (Business Associate Agreement) עם כל קבלן משנה, לפי HIPAA Privacy Rule, יומן ביקורת (audit log) לכל גישה לנתוני מטופל.
כיצד תפקידי הרופא והמטופל משפיעים על ארכיטקטורת הגישה?
לפחות שני משתמשים שונים לחלוטין:
מטופל. רואה את הנתונים שלו: היסטוריה, אבחנות, תוצאות מעבדה, מרשמים, אלרגיות. יכול להציג קוד QR לגישת חירום (ללא אימות — רק נתונים קריטיים: סוג דם, אלרגיות, מחלות כרוניות). מנהל הסכמות לעיבוד נתונים על ידי מרפאות ספציפיות.
רופא / צוות רפואי. ניגש לנתוני מטופל רק במסגרת ביקור פעיל. גישה לרשומות ממרפאה אחרת — רק אם המטופל נתן הסכמה. כל צפייה מתועדת ביומן ביקורת (מי ניגש למה ומתי).
יומן ביקורת אינו תכונה אופציונלית לפי HIPAA; זו דרישת חובה. מבנה רשומת היומן: userId, resourceType, resourceId, action (צפייה/עריכה/ייצוא), timestamp, ipAddress, deviceId. נשמר לפחות 6 שנים (HIPAA) או 3 שנים (רוסיה לפי 152-FZ).
הצפנה ואחסון
נתוני EMR לעולם אינם מאוחסנים בטקסט פשוט במכשיר. תרחיש מטמון לא מקוון (offline) עבור הרופא:
iOS: Core Data עם הצפנה באמצעות NSPersistentStoreDescription + NSFileProtectionCompleteUnlessOpen. מפתח ההצפנה ב-Secure Enclave עם הגנה ביומטרית.
Android: Room + EncryptedSharedPreferences + SQLCipher. המפתח ב-Android KeyStore עם setUserAuthenticationRequired(true).
העברת נתונים: TLS 1.3 חובה, TLS 1.2 מותר עם הגבלות. הצמדת אישורים (Certificate pinning). להחלפה בין ארגונים — HL7 FHIR R4 כתקן אינטרופרביליות.
מקרה בוחן: אינטגרציה עם מערכת מעבדה
לאחר ביקורת דרישות הלקוח, תכננו מודל FHIR הכולל משאבי Observation, DiagnosticReport ו-Specimen. יישמנו לקוח REST ב-Flutter עם מטמון לא מקוון. הבדיקות כיסו תרחישים: 200 רופאים במקביל, זמן תגובה < 2 שניות. הפרויקט הושלם תוך 2.5 חודשים.איומים אופייניים והדרכים להתמודד עמם
| איום | אמצעי התמודדות |
|---|---|
| גישה לא מורשית למכשיר | ביומטריה + הצפנה |
| יירוט נתונים ברשת | TLS 1.3 + הצמדת אישורים |
| דליפה דרך סנכרון | הצפנה מקומית, איסור גיבוי בענן |
| גישה לא מורשית ל-API | OAuth 2.0 + JWT, הגבלת קצב (rate limiting) |
| הנדסה הפוכה של האפליקציה | ProGuard/R8 (Android), ערפול קוד (iOS) |
מדוע FHIR R4 כתקן האינטגרציה?
אם ה-EMR חייב להשתלב עם מערכות MIS אחרות, HL7 FHIR R4 הוא התקן דה-פקטו. משאבים: Patient, Observation, Condition, MedicationRequest, DiagnosticReport, Encounter. הפתרונות שלנו משתלבים עם FHIR פי 2 מהר יותר מאינטגרציות טיפוסיות, הודות לניסיון הצוות.
במובייל — REST API לשרת FHIR (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API). iOS: אין SDK רשמי של FHIR, אנו משתמשים ב-Alamofire + מודלים מותאמים אישית של Codable. Android: ה-SDK הרשמי של Google android-fhir (תומך בסנכרון לא מקוון באמצעות FHIR Structured Data Capture).
דוגמה לבקשת תצפיות מטופל:
GET /fhir/Observation?patient=Patient/123&category=vital-signs&_sort=-date&_count=20 נתונים רפואיים בממשק המשתמש
ישנם אלמנטים ספציפיים לרפואה:
נורמות טווח ייחוס. תוצאת מעבדה "גלוקוז: 7.2 mmol/L" חייבת להיות מוצגת עם הקשר: טווח תקין 3.9–6.1, ערך קודם 6.8, מגמת עלייה. GET /fhir/Observation?patient=Patient/123&category=vital-signs&_sort=-date&_count=20 /Charts לגרפי מגמה.
אינטראקציות בין תרופות. אם האפליקציה מציגה מרשמים, יש צורך בבדיקת DDI (אינטראקציות בין תרופתיות) — באמצעות DrugBank או RxNorm API. זהו היקף עבודה נפרד.
קוד QR לחירום. קוד QR נגיש ללא אימות המכיל רק נתונים קריטיים בפורמט Smart Health Cards או FHIR Patient Summary. נוצר ונשמר במטמון במהלך הפגישה המקוונת האחרונה.
כיצד להבטיח אבטחת נתונים רפואיים?
- הטמעת הצפנת נתונים במכשיר (SQLCipher, Core Data עם NSFileProtection).
- שימוש באימות ביומטרי לגישה.
- הגדרת הצמדת אישורים ו-TLS 1.3 להעברת נתונים.
- הפעלת ProGuard/R8 ב-Android וערפול קוד ב-iOS.
- הגדרת מחיקה מרחוק (remote wipe) באמצעות MDM אם המכשיר אבד.
מה כלול בעבודה
- ביקורת דרישות רגולטוריות והתאמה עם הלקוח
- תכנון ארכיטקטורה (מודל FHIR, תכנית גישה, יומן ביקורת)
- פיתוח אפליקציית מובייל (iOS/Android/רוחב-פלטפורמות)
- הטמעת הצפנה ואחסון מאובטח
- אינטגרציה עם שרת FHIR ומערכות חיצוניות
- בקרת איכות (QA) ובדיקות חדירה
- תיעוד והוראות משתמש
- תמיכה במהלך השחרור ל-App Store / Google Play
אילו תרחישים יש לבדוק בנפרד?
תרחיש "הרופא איבד את הטלפון": נתוני מטופל במכשיר חייבים להימחק באמצעות מחיקה מרחוק (MDM) או להיות בלתי נגישים ללא ביומטריה לאחר N דקות של חוסר פעילות.
תרחיש "המטופל נפטר": מה קורה לגישת האנשים המורשים? זו לא שאלה טכנית — היא משפטית, אך היא משפיעה על ארכיטקטורת ההסכמות.
תהליך העבודה
| שלב | תוכן | משך |
|---|---|---|
| ביקורת דרישות | תחום שיפוט, תפקידים, אינטגרציות (MIS, מעבדות) | שבוע |
| עיצוב | משאבי FHIR, מודל נתונים, תכנית גישה, יומן ביקורת | 1–2 שבועות |
| פיתוח ליבה | אימות, פרופיל מטופל, רשומה רפואית, מרשמים | 4–6 שבועות |
| הצפנה ואבטחה | אחסון לא מקוון, SE/StrongBox, הצמדת אישורים | 1–2 שבועות |
| אינטגרציות | שרת FHIR, מערכות מעבדה, push | 2–3 שבועות |
| QA + ביקורת אבטחה | בדיקות חדירה, אימות יומן ביקורת | 1–2 שבועות |
MVP מלא — 2–3 חודשים. אפליקציה עם אינטגרציית FHIR מלאה, תמיכה ברופא ומטופל, יומן ביקורת תואם HIPAA — קרוב לשלושה חודשים. לוחות זמנים ועלויות לכל פרויקט מוערכים בנפרד לאחר ניתוח הדרישות ותחום השיפוט שנבחר. בקשו ייעוץ מקדים להערכת הפרויקט שלכם. קבלו הצעת מחיר קבועה המבוססת על הדרישות.