מרכז האמון
שקיפות עבור מטפלים, בעלי קליניקות ורוכשים מוסדיים. העמוד הזה מסכם איך Hanah מטפלת במידע רפואי, אילו ספקי שירות נכללים בפריסת הייצור ב, ואיך כל בקרת אבטחה מתייחסת לכללי האבטחה, הפרטיות והדיווח על דליפות של HIPAA. סימוני הסטטוס הם כלי עריכה זמני, והם יוסרו כשכל פריט יאומת בסביבת הייצור.
למי העמוד מיועד: קליניקות, רשתות בריאות, ממונים על הגנת הפרטיות וצוותי אבטחת מידע שמבצעים בדיקת נאותות ל-Hanah. במבט מהיר: מרכז האמון מסכם את בקרות האבטחה של Hanah ואת ספקי השירות שנכללים בפריסת הייצור ב. הרשומות הקליניות נשמרות ב. זיהוי הדיבור פועל אצל ספק מתמחה בארצות הברית, וניסוח ה-AI אצל ספקים בארצות הברית ובמדינות אחרות שבהן יש להם מתקנים, לפי תנאים שאוסרים אימון על התוכן שלכם. ראיות מפורטות יותר נמצאות במדריך האבטחה והתפעול שלנו, ולשונית בקרות מתארת איך כל בקרה מיושמת.
מתודולוגיית אימות
איך אנחנו מודדים את דיוק התמלול ואת ההזיות בתיעוד: מערך בדיקה אחד, קורפוס אחד, שתי שכבות הערכה (WER + פאנל שופטים של מודלי שפה). אלה הכללים שלפיהם מוערך כל מספר שאנחנו מפרסמים.
לקריאת המתודולוגיה ←שקיפות האימות
תמלילים לכל הקלטה, המסמכים שנוצרו, וההכרעה של כל שופט מודל שפה, מול קורפוס ייחוס מוסמך. הנתונים המלאים, לא רק מספרי הכותרת.
לדוח ←תוצאות קודמות
כל מבחן השוואתי שפרסמנו, עם השינוי לעומת ההרצה שלפניו. המספרים נשארים בדיוק כפי שנמדדו באותו יום, גם במקרים שבהם פאנל ההערכה עצמו השתנה מאז.
להשוואת הרצות ←כל שורה היא בקרה במובן המקובל ב-ISO: מדיניות (ממשל ונהלים מתועדים), טכנית (נאכפת על ידי מערכות ותצורה) או ספקים (הבטחה חוזית ושל מעבדי משנה). התגיות מציגות את סוג הראיה העיקרי, ושורות רבות משלבות יותר מסוג אחד. הפירוט נשען על מדריך האבטחה והתפעול הפנימי שלנו. השורה שמתחת לכל שורה מציינת את הוראות HIPAA (45 CFR) שהבקרה מקבילה להן. זו אינדיקציה בלבד, והיא אינה תחליף לייעוץ משפטי.
מקור הסמכות: HIPAA Administrative Simplification regulations, 45 CFR Part 164: Subpart C (Security Rule), Subpart D (Breach Notification Rule) ו-Subpart E (Privacy Rule).
תשתית ופלטפורמה
אבטחת תשתית
החלק הזה מגדיר היכן Hanah פועלת בפריסה האזורית, איך סביבת הייצור מופרדת מהתפעול, ואיך הצפנה מגינה על נתוני הלקוחות בין המטפלים, המערכת שלנו ומעבדי המשנה של AI. אלה בעיקר בקרות טכניות, עם גיבוי מנהלי במדריך האבטחה והתפעול (Security & Operations Handbook).
-
✅
טכנית מדיניותעומסי ייצור שמתארחים באזור
שרתי האפליקציה הראשיים, מסדי הנתונים, אחסון האובייקטים והגיבויים של הפריסה באזור נמצאים באותו אזור. רשומות מנהליות מתעדות את האזורים ואת אישור השינויים, והפריסה הטכנית מקבעת את המשאבים לפרויקט האזורי.
התאמה ל-HIPAA: §164.308(a)(1)(ii)(A)–(B) ניתוח סיכונים וניהול סיכונים; §164.310(a)(1) בקרות גישה למתקנים, בידי ספק האירוח. הרשומות נשמרות בארצות הברית; העיבוד אצל ספקים מפורט תחת ספקי שירות.
-
✅
טכניתהצפנה בתעבורה
תעבורה נכנסת מהאינטרנט משתמשת ב-TLS מודרני. התעבורה לספקי זיהוי הדיבור ולספקי מודלי ה-AI משתמשת ב-TLS אל נקודות הקצה שהוגדרו לכל ספק. זו בקרה טכנית שמאומתת בסקירות ארכיטקטורה ובתצורת הפריסה.
התאמה ל-HIPAA: §164.312(e)(1) אבטחת תעבורה; §164.312(e)(2)(ii) הצפנה.
-
✅
טכנית מדיניותהצפנה באחסון
מסדי נתונים, אחסון אובייקטים ואובייקטי גיבוי משתמשים באלגוריתמים מקובלים בתעשייה (למשל AES-256-GCM), עם מפתחות שמנוהלים לפי מדיניות הקריפטוגרפיה שלנו. גיבויי WAL-G מוסיפים הצפנה בצד הלקוח לפני האחסון מחוץ לאתר.
התאמה ל-HIPAA: §164.312(a)(2)(iv) הצפנה ופענוח; §164.308(a)(7)(ii)(A) תוכנית גיבוי נתונים.
-
✅
טכנית ספקיםהגנת DDoS ו-WAF בקצה הרשת
שכבת קצה מנוהלת עומדת לפני שמות המארחים הציבוריים, סופגת מתקפות נפח ומפעילה חוקי WAF נגד שימוש לרעה נפוץ ברשת. ההגנות ברמת הספק ומדיניות חומת אש הדוקה נשארות בתוקף מאחורי שכבת הקצה.
התאמה ל-HIPAA: §164.306(a)(1) זמינות של מידע רפואי מוגן אלקטרוני; §164.308(a)(7) תוכנית מגירה.
-
✅
טכנית מדיניותזיהוי חדירות
זיהוי בכמה שכבות: פלטפורמת האירוח מספקת IDS ברמת הרשת, וכל מכונה וירטואלית (VM) מריצה fail2ban (מניעת מתקפות brute-force על SSH), UFW עם מדיניות ברירת מחדל של חסימה, ועדכוני אבטחה אוטומטיים. אירועי אימות וגישה מה-auth-proxy נשלחים למערך Loki/Grafana מרכזי, כך שדפוסי התחברות חריגים מופיעים בלוחות הבקרה ובהתראות. המדיניות מגדירה מי אחראי לטיפול ראשוני כשהתראה מופעלת. IDS בזמן ריצה ברמת הקרנל לקונטיינרים הוא שיפור מתוכנן מעל הבסיס הזה.
התאמה ל-HIPAA: §164.308(a)(1)(ii)(D) סקירת פעילות מערכות המידע; §164.308(a)(6) נהלים לאירועי אבטחה; §164.312(b) בקרות ביקורת.
מוצר ואפליקציה
אבטחת המוצר
איך משתמשים מזדהים, איך ההרשאות נאכפות במוצר ובשכבת ה-API, ואיך אנחנו בונים ומשחררים תוכנה. שילוב של אכיפה טכנית (JWT, RBAC) עם דרישות מנהליות למחזור פיתוח מאובטח (SDLC) ולסקירה.
-
✅
טכנית ספקיםאימות וסשנים
מטפלים מזדהים דרך ספק זהויות מנוהל (תהליכים בסגנון OIDC/OAuth), וכל נתיב API מאמת את הזהות. משך הסשן והתנהגות הנעילה תואמים את מדיניות בקרת הגישה שלנו.
התאמה ל-HIPAA: §164.312(d) אימות של אדם או גוף; §164.312(a)(2)(iii) ניתוק אוטומטי.
-
✅
טכנית מדיניותבקרת גישה מבוססת תפקידים
היכולות של מטפלים, של מטופלים ושל מנהלי מערכת מופרדות במודל הנתונים ובשכבת ה-GraphQL, כך שהרשאה מינימלית היא ברירת המחדל. הגדרות התפקידים ותדירות הסקירה שלהן מתועדות ברמה המנהלית.
התאמה ל-HIPAA: §164.312(a)(1) בקרת גישה; §164.308(a)(4) ניהול גישה למידע; §164.502(b) המינימום הנדרש.
-
✅
טכנית מדיניותחובת MFA בנתיבים בעלי הרשאות מוגברות
חובת MFA נאכפת, דרך ספק הזהויות שלנו, בחשבונות שיכולים לשנות הגדרות רגישות לאבטחה או לגשת לנתונים בסיכון גבוה.
התאמה ל-HIPAA: §164.312(d) אימות של אדם או גוף.
-
✅
טכנית מדיניותמחזור פיתוח מאובטח
שינויים עוברים דרך ניהול קוד מקור, סקירה ותלויות מקובעות. השפעת האבטחה נשקלת בפיצ׳רים מהותיים כשער מנהלי, וכלים טכניים (Dependabot ועוד) תומכים בהיגיינה שוטפת.
התאמה ל-HIPAA: §164.308(a)(1)(ii)(B) ניהול סיכונים; §164.308(a)(8) הערכה.
-
✅
טכנית מדיניותרשימת רכיבי תוכנה (SBOM)
כל גרסה כוללת רשימת מלאי של התלויות בפורמט קריא למכונה, לצורך תגובה לפגיעויות. ייצוא ה-SBOM משולב ב-CI כחלק מתוכנית הבטחת שרשרת האספקה שלנו.
התאמה ל-HIPAA: §164.308(a)(1)(ii)(B) ניהול סיכונים; §164.308(a)(5)(ii)(B) הגנה מפני תוכנה זדונית.
נתונים ופרטיות
נתונים ופרטיות
שמירה, מחיקה, זכויות נושאי המידע ושקיפות לגבי אירועים רלוונטיים לאבטחה. הבקרות האלה משלבות אכיפה אוטומטית במוצר ובמסד הנתונים עם נהלים מנהליים (טיפול בבקשות DSAR לגישה למידע, הודעה על אירועי דליפת מידע, דיווח רבעוני).
-
✅
טכנית מדיניותשמירה ומחיקה של תוצרי ההקלטה ברקע
חומרי אודיו ותמליל נשמרים כברירת מחדל לתקופה קצרה ונמחקים אוטומטית. רשומות קליניות נשמרות לפי מדיניות השמירה של כל ארגון. אחרי שילוב עם מערכת הרשומות שלכם, הרשומה הקלינית המחייבת נשארת שלכם.
התאמה ל-HIPAA: §164.310(d)(2)(i) סילוק; §164.502(b) המינימום הנדרש.
-
✅
טכנית מדיניותיומן מחיקות חסין שינויים ודוחות רבעוניים
מחיקות שנובעות ממדיניות השמירה נרשמות ב-
deletion_log, טבלת Postgres שמאפשרת הוספה בלבד, בלי הרשאותUPDATEאוDELETEלאף תפקיד. כל שורה מקושרת לשורה שלפניה באמצעות שרשרת גיבוב SHA-256 (row_hash = sha256(prev_hash ‖ canonical(metadata))), כך ששינוי או הסרה של שורה מוקדמת כלשהי שוברים את כל הגיבובים שאחריה, והמאמת שבתוך מסד הנתונים,hanah_verify_deletion_chain(), מזהה זאת. גם טבלאות הביקורת הנלוות (ai_audit,secret_access_audit) מאפשרות הוספה בלבד. סיכומים רבעוניים ללקוחות מופקים באמצעותhanah_deletion_report_quarter(year, quarter).התאמה ל-HIPAA: §164.312(b) בקרות ביקורת; §164.312(c)(1) שלמות; §164.316(b) תיעוד.
-
✅
מדיניות טכניתזכות הגישה והתיקון של נושא המידע
אנשים יכולים לבקש גישה למידע האישי שלהם או את תיקונו. Hanah מתעדת לוחות זמנים, פורמטים (ייצוא JSON וייצוא קריא לבני אדם) ונתיבי הסלמה. הכלים תומכים בייצוא במקומות שבהם הנתונים נמצאים במערכות של Hanah.
התאמה ל-HIPAA: §164.524 זכות עיון; §164.526 תיקון. Hanah תומכת במענה של הקליניקה.
-
🔧
טכנית מדיניותשקיפות ביקורת מאוחדת
אירועים רלוונטיים לאבטחה (אימות, שימוש בהרשאות, שינויי תצורה) זמינים לשאילתה עבור לקוחות מוסדיים, ואפשר להעביר אותם ל-SIEM שלכם (למשל Microsoft Sentinel) כשהדבר סוכם בחוזה. מוגדר לכל לקוח בנפרד.
התאמה ל-HIPAA: §164.312(b) בקרות ביקורת; §164.308(a)(1)(ii)(D) סקירת פעילות מערכות המידע.
AI ובטיחות קלינית
אבטחה ותאימות של AI
בקרות ייחודיות ל-AI שמאזין ברקע: ללא שימוש משני במידע רפואי לאימון, בקרה אנושית לפני הסתמכות קלינית, מדידת איכות (WER) ופרומפטים עמידים לשימוש לרעה. משלב בקרות חוזיות על צדדים שלישיים עם תהליך העבודה במוצר ועם ממשל קליני.
-
✅
ספקים מדיניות טכניתללא שימוש משני לאימון מודלים
תנאי השימוש של ספקי זיהוי הדיבור ומודלי ה-AI שלנו אוסרים אימון על תוכן של לקוחות, והבקשות נשלחות כשהאחסון בצד הספק כבוי, בכל מקום שהספק מאפשר זאת. ל-Hanah אין תהליך אימון פנימי על המידע הרפואי שלכם. סקירות ספקים מנהליות תומכות בטענה הזו.
התאמה ל-HIPAA: §164.502(a) שימושים וגילויים, מוגבלים למטרה שלשמה הקליניקה התקשרה עם Hanah; הספקים מחויבים בחוזה לא לאמן מודלים על התוכן ולא לשמור אותו מעבר לתנאים שמוצגים תחת ספקי שירות.
-
✅
מדיניות טכניתבקרה אנושית לפני הסתמכות קלינית
רשומות שנוצרו מחייבות בדיקה ואישור סופי מפורשים של המטפל לפני שהן נחשבות לחלק מהרשומה הקלינית. זו גם בקרה במוצר (שערים בתהליך העבודה) וגם התחייבות מדיניות בתסקיר ההשפעה על הפרטיות (PIA).
התאמה ל-HIPAA: §164.312(c)(1) שלמות; §164.526 תיקון.
-
✅
מדיניות טכניתמתודולוגיית WER ותוצאות קבוצות הבדיקה שפורסמו
מערך בדיקה אחד ושתי שכבות הערכה, שרצים בכל סבב הערכה: שיעור שגיאות המילים מול תמלילי ייחוס מילה במילה (שכבה A), ופאנל שופטים של מודלי שפה שמודד גם כיסוי (האם הרשומה מכילה כל ציפייה שנרשמה מראש?) וגם הזיות (האם הרשומה מכילה טענות שהתמליל לא תומך בהן, כלומר תוכן שהמודל המציא?). המתודולוגיה המלאה מפורסמת, והתוצאות העדכניות מוצגות ישירות מהפלט המצרפי של מערך הבדיקה. הקורפוס ממשיך להתקדם בשלבים: v1 (סינתטי) ← v2 (משחקי תפקידים) ← v3 (אמיתי, מבוסס הסכמה) ← v4 (משותף עם שותפים ממערכות בריאות).
התאמה ל-HIPAA: §164.312(c)(1) שלמות; §164.308(a)(8) הערכה.
-
✅
טכנית מדיניותהזרקת פרומפט וניטור פלט לא בטוח
פרומפטי המערכת נשלטים בצד השרת, והקלט מוגבל על ידי תהליך העבודה הקליני (אין ממשק צ׳אט חופשי). מסווגי הבטיחות של הספק רצים על כל יצירה. כשהם מופעלים, הזרם מחזיר סיבת סיום של מסנן תוכן, שנרשמת בשורת
ai_auditשל אותה קריאה, יחד עם קוד שגיאה קנוניai.content_policy, זמן תגובה, טוקנים ומזהה Tempo trace. דפוסים חריגים מופיעים בלוחות בקרה שנבנים על טבלת הביקורת הזו. זיהוי חריגות התנהגותיות בין קריאות, לאיתור דפוסי שימוש לרעה, הוא שיפור מתוכנן מעל הבסיס הזה.התאמה ל-HIPAA: §164.308(a)(1)(ii)(D) סקירת פעילות מערכות המידע; §164.308(a)(5)(ii)(B) הגנה מפני תוכנה זדונית.
-
✅
טכנית מדיניותתיעוד הסכמה של כל המשתתפים בתוך המוצר
כשהמטפל לוחץ על הקלטה, המוצר פותח חלון הסכמה שמחייב אישור מפורש שהתקבלה הסכמה מהמטופל ומכל משתתף אחר במפגש. ההקלטה לא יכולה להתחיל לפני שהאישור הזה ניתן, והאישור נקשר למפגש יחד עם מדיניות הקליניקה שמוזכרת בתסקיר ההשפעה על הפרטיות.
התאמה ל-HIPAA: §164.506(b) הסכמה לשימושים לצורכי טיפול. גם חוקי הקלטה של המדינות חלים: כמה מדינות, ביניהן קליפורניה ופלורידה, מחייבות את הסכמת כל הצדדים להקלטה.
הארגון וצדדים שלישיים
אבטחה ארגונית
איך Hanah, החברה, מנהלת את האבטחה: אחריותיות, מדיניות, אימות בלתי תלוי ושילוב עם כלי האבטחה של הלקוחות. אלה בעיקר בקרות מנהליות, ולחלקן יש תוצרים טכניים (למשל מחברי SIEM).
-
✅
מדיניותממשל אבטחה ומרשם סיכונים
בכיר מוגדר בשמו אחראי לאבטחת המידע. סיכונים נרשמים עם בעלים ותאריכי יעד ונבדקים במועדים קבועים. זה תואם את מה שרוכשים מצפים לו בדרך כלל ממערכת ניהול בסגנון ISO, גם בהיקף הנוכחי שלנו.
התאמה ל-HIPAA: §164.308(a)(2) הגדרת אחריות לאבטחה; §164.308(a)(1) תהליך ניהול האבטחה.
-
✅
מדיניותחבילת מדיניות שאושרה בדירקטוריון
מדיניות פורמלית מכסה גישה, קריפטוגרפיה, תגובה לאירועים, ספקים וניהול שינויים. החבילה אושרה בדירקטוריון ומנוהלת בבקרת גרסאות. התוכן המלא זמין בכפוף להסכם סודיות (NDA).
התאמה ל-HIPAA: §164.316 מדיניות, נהלים ותיעוד.
-
🔧
מדיניות טכניתהעברה ל-SIEM של הלקוח (למשל Sentinel)
אירועי אבטחה ממערכות שבשליטת Hanah מועברים לסביבת ה-Sentinel שלכם (או למערכת מקבילה) לניטור משותף, כשהדבר סוכם בחוזה. מוגדר לכל לקוח מוסדי בנפרד.
התאמה ל-HIPAA: §164.308(a)(6) נהלים לאירועי אבטחה; §164.312(b) בקרות ביקורת; תומכת בהערכת הדליפה של הקליניקה לפי §164.402.
בארצות הברית, שאלוני בדיקת נאותות מגיעים בדרך כלל מנוסחים לפי HIPAA, ולפעמים לפי ISO/IEC 27001 או SOC 2. הטבלה הזו מתחילה מכל דרישת HIPAA, מציינת את ההוראה הקרובה ביותר בעקרונות הפרטיות האוסטרליים, ב-GDPR, בחוק הפרטיות של ניו זילנד, ב-ISO/IEC 27001 וב-SOC 2, ומציגה את בקרת Hanah שעונה עליה.
ההקבלות הן אינדיקטיביות בלבד ואינן ייעוץ משפטי.
| דרישת HIPAA | עקרונות הפרטיות האוסטרליים | GDPR / UK GDPR | NZ Privacy Act 2020 / HIPC 2020 | ISO/IEC 27001:2022 | SOC 2 (TSC 2017) | איך Hanah עומדת בזה |
|---|---|---|---|---|---|---|
| §164.530(a), (i) – ממונה פרטיות, מדיניות ונהלים | APP 1 ניהול פתוח ושקוף | סעיף 5(2) אחריותיות; סעיפים 24, 30 | סעיף 201 ממונה על הגנת הפרטיות | סעיף 5.2 מדיניות; A.5.1 | CC1.1–CC1.3; CC2.3 | בכיר אחראי מוגדר בשמו, מרשם סיכונים, חבילת מדיניות שאושרה בדירקטוריון, ומרכז האמון הזה. |
| §164.520 – הודעה על נוהלי פרטיות | APP 5 הודעה על איסוף | Art. 13–14 מידע שיש למסור | IPP 3; כלל HIPC 3 | A.5.34 | P1.1 הודעה | שלב הסכמה בתוך המוצר. מדיניות הפרטיות מציינת את המדינות שבהן הנתונים מעובדים. |
| §164.502(b), §164.514(d) – המינימום הנדרש | APP 3 איסוף מידע שהתבקש | סעיף 5(1)(b)–(c) צמצום מטרה ומזעור נתונים | IPP 1, 2, 4; כללי HIPC 1, 2, 4 | A.5.34 | P3.1–P3.2 איסוף | האיסוף מוגבל למפגש שהמטפל מתחיל, והסכמה מאושרת לפני כל הקלטה. |
| §164.502(a), §164.506 – שימושים וגילויים מותרים | APP 6 שימוש או גילוי | Art. 5(1)(b) הגבלת מטרה; Art. 28 תנאי מעבד | IPP 10, 11; כללי HIPC 10, 11 | A.5.34; A.5.10 שימוש מקובל | P4.1 שימוש; P6.1 מסירה לצדדים שלישיים | עיבוד רק לפי הוראות הקליניקה; ללא שימוש משני וללא אימון מודלים. |
| §164.508(a)(3) – הרשאה לשיווק | APP 7 שיווק ישיר | Art. 21(2)–(3) הזכות להתנגד לשיווק ישיר | אין מקבילה ישירה (Unsolicited Electronic Messages Act 2007) | אין מקבילה ישירה | P2.1 | מידע על מטופלים אף פעם לא משמש לשיווק; מטופלים שומעים מהקליניקה רק כשמטפל שולח להם משהו. |
| §164.502(e), §164.504(e), §164.308(b) – Business associates וקבלני משנה | APP 8 גילוי חוצה גבולות | סעיף 28 מעבדים; פרק V, סעיפים 44–49 העברות בינלאומיות | IPP 12; כלל HIPC 12 | A.5.19–A.5.22 קשרי ספקים | CC9.2 סיכוני ספקים; P6.4 | הרשומות נשמרות בארצות הברית. הספקים מפורטים לפי מדינה תחת ספקי שירות, עם התחייבות חוזית שלא לאמן מודלים ועם מגבלות שמירה. |
| §164.312(c) – שלמות | APP 10 איכות המידע האישי | Art. 5(1)(d) דיוק | IPP 8; כלל HIPC 8 | A.5.34 | P7.1 איכות | בדיקה של המטפל לפני שרשומה מאושרת סופית; מדידת דיוק והזיות שמתפרסמת. |
| §164.308, §164.310, §164.312 – אמצעי הגנה מנהליים, פיזיים וטכניים | APP 11.1 אבטחת מידע אישי | Art. 32 אבטחת העיבוד | IPP 5; כלל HIPC 5 | A.5.15, A.8.5 גישה ואימות; A.8.24 קריפטוגרפיה; A.8.13 גיבוי; A.8.15–A.8.16 רישום יומנים וניטור | CC6 גישה לוגית; CC7 תפעול מערכות; CC8 ניהול שינויים | הצפנה בתעבורה ובאחסון, גישה מבוססת תפקידים, MFA בנתיבים בעלי הרשאות מוגברות, זיהוי חדירות, גיבויים מוצפנים. |
| §164.310(d)(2)(i) – סילוק | APP 11.2 השמדה או התממה; APP 4 מידע שלא התבקש | Art. 5(1)(e) הגבלת אחסון; Art. 17 מחיקה | IPP 9; כלל HIPC 9 | A.8.10 מחיקת מידע | C1.2 השמדה; P4.3 | האודיו הגולמי נמחק ברגע שהתמליל מופק; אודיו ותמלילים נמחקים אוטומטית, והמחיקה נרשמת ביומן מחיקות חסין שינויים. |
| §164.524 – זכות עיון | APP 12 גישה | Art. 15 גישה; Art. 20 ניידות | IPP 6; כלל HIPC 6 | A.5.34 | P5.1 גישה | ייצוא ב-JSON ובפורמטים קריאים לאדם, כדי לתמוך במענה של הקליניקה. |
| §164.526 – תיקון | APP 13 תיקון | Art. 16 תיקון | IPP 7; כלל HIPC 7 | A.5.34 | P5.2 תיקון | המטפלים עורכים רשומות ומאשרים אותן סופית מחדש; בקשות תיקון מטופלות לפי נוהל מתועד. |
| §164.400–414 – Breach Notification Rule | חלק IIIC, Notifiable Data Breaches scheme | Art. 33–34 הודעה על דליפת מידע | Part 6 דליפות פרטיות החייבות בדיווח | A.5.24–A.5.27 ניהול אירועים | CC7.3–CC7.5 תגובה לאירועים | מדיניות תגובה לאירועים, רישום אבטחה מרכזי ותמיכה בהערכת הסיכון ובדיווח של הקליניקה. |
אלה קטגוריות ספקי השירות שעשויים לעבד או לאחסן נתוני לקוחות של Hanah בארכיטקטורת הייצור שלנו ב: מה כל אחד מטפל בו, מה הוא שומר והיכן הוא מעבד נתונים. כל ספק מחויב בחוזה להגן על נתוני הלקוחות, ואף אחד מהם אינו רשאי לאמן עליהם מודלים. הכניסה של המטפלים משתמשת בתשתית זהויות גלובלית שאינה מחזיקה מידע רפואי על מטופלים.
| סוג השירות | מטרה | הנתונים שמטופלים | שמירה | אזור העיבוד |
|---|
שקיפות תפעולית: דף סטטוס ציבורי (זמינות ואירועים) עומד לצד נקודת הקצה /healthz של סביבת הייצור, שמשמשת את הניטור שלנו.
PhysiPal Pty Ltd (פועלת בשם Hanah) – . מרכז האמון הזה הוא סיכום כללי. התחייבויות חוזיות ותנאי עיבוד הנתונים שבתוקף בעת החתימה גוברים על הדף הזה. סימוני האימוג׳י של הסטטוס (✅ 🔧) זמניים ויוסרו אחרי אימות בלתי תלוי של כל שורה.