---
title: "מרכז האמון – Hanah (אוסטרליה)"
description: "מרכז האמון של Hanah (אוסטרליה): רשומות המטופלים נשמרות באוסטרליה, עבור קליניקות באוסטרליה ובניו זילנד. בקרות אבטחה ופרטיות, וספקי השירות של הפריסה האוסטרלית."
source: https://hanah.health/he/au/trust/
---

# מרכז האמון

שקיפות עבור מטפלים, בעלי קליניקות ורוכשים מוסדיים. העמוד הזה מסכם איך Hanah מטפלת במידע רפואי, אילו ספקי שירות נכללים בפריסת הייצור ב, ואיך כל בקרת אבטחה מתייחסת ל-**Privacy Act 1988** (עקרונות הפרטיות האוסטרליים). סימוני הסטטוס הם כלי עריכה זמני, והם יוסרו כשכל פריט יאומת בסביבת הייצור.

✅ הושלם 🔧 מיושם בפתרון ייעודי

סקירה כללית בקרות מיפוי מסגרות תקינה ספקי שירות משאבים

**למי העמוד מיועד:** קליניקות, רשתות בריאות, ממונים על הגנת הפרטיות וצוותי אבטחת מידע שמבצעים בדיקת נאותות ל-Hanah. **במבט מהיר:** מרכז האמון מסכם את בקרות האבטחה של Hanah ואת ספקי השירות שנכללים בפריסת הייצור ב. הרשומות הקליניות נשמרות ב. זיהוי הדיבור וניסוח ה-AI פועלים אצל ספקים מתמחים מחוץ לאזור, בעיקר בארצות הברית, לפי תנאים שאוסרים אימון על התוכן שלכם. ראיות מפורטות יותר נמצאות במדריך האבטחה והתפעול שלנו, ולשונית **בקרות** מתארת איך כל בקרה מיושמת.

### בקרות אבטחה

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

לבקרות ←

### HIPAA, GDPR, ISO ו-SOC 2 ממופים לעקרונות ה-APP

כל עיקרון פרטיות אוסטרלי לצד המקבילים לו ב-HIPAA, ב-GDPR, בניו זילנד, ב-ISO/IEC 27001 וב-SOC 2, ולצד בקרת Hanah שעונה עליו.

למיפוי ←

### ספקי שירות

אילו סוגי ספקים מטפלים בנתונים, לאיזו מטרה, מה הם שומרים והיכן הם מעבדים אותם.

לספקי השירות ←

### משאבים והצעדים הבאים

סטטוס השירות, ואיך לבקש את חבילות המדיניות המלאות בכפוף להסכם סודיות (NDA).

למשאבים ←[

### מתודולוגיית אימות

איך אנחנו מודדים את דיוק התמלול ואת ההזיות בתיעוד: מערך בדיקה אחד, קורפוס אחד, שתי שכבות הערכה (WER + פאנל שופטים של מודלי שפה). אלה הכללים שלפיהם מוערך כל מספר שאנחנו מפרסמים.

לקריאת המתודולוגיה ←](https://hanah.health/he/au/trust/wer-methodology/)[

### שקיפות האימות

תמלילים לכל הקלטה, המסמכים שנוצרו, וההכרעה של כל שופט מודל שפה, מול קורפוס ייחוס מוסמך. הנתונים המלאים, לא רק מספרי הכותרת.

לדוח ←](https://hanah.health/he/au/trust/transparency/)[

### תוצאות קודמות

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

להשוואת הרצות ←](https://hanah.health/he/au/trust/benchmarks/)

כל שורה היא בקרה במובן המקובל ב-ISO: **מדיניות** (ממשל ונהלים מתועדים), **טכנית** (נאכפת על ידי מערכות ותצורה) או **ספקים** (הבטחה חוזית ושל מעבדי משנה). התגיות מציגות את סוג הראיה העיקרי, ושורות רבות משלבות יותר מסוג אחד. הפירוט נשען על **מדריך האבטחה והתפעול** הפנימי שלנו. השורה שמתחת לכל שורה מציינת את עקרונות הפרטיות האוסטרליים שהבקרה תומכת בהם. זו אינדיקציה בלבד, והיא אינה תחליף לייעוץ משפטי.

**מקור הסמכות:** [_Privacy Act 1988_ (Cth)](https://www.oaic.gov.au/privacy/australian-privacy-principles), תוספת 1 (עקרונות הפרטיות האוסטרליים) וחלק IIIC (Notifiable Data Breaches).

טכנית בקרות מערכת ופלטפורמה: תשתית, אפליקציה, קריפטוגרפיה, אוטומציה. מדיניות ממשל ברמת הארגון: אחריותיות, מדיניות חתומה, מרשם סיכונים, ראיות לנהלים. ספקים הסתמכות על צד שלישי: תנאי DPA, רשימת מעבדי משנה, הסמכות של ספקים.

## תשתית ופלטפורמה

אבטחת תשתית

החלק הזה מגדיר היכן Hanah פועלת בפריסה האזורית, איך סביבת הייצור מופרדת מהתפעול, ואיך הצפנה מגינה על נתוני הלקוחות בין המטפלים, המערכת שלנו ומעבדי המשנה של AI. אלה בעיקר בקרות טכניות, עם גיבוי מנהלי במדריך האבטחה והתפעול (Security & Operations Handbook).

-   ✅
    
    טכנית מדיניות
    
    **עומסי ייצור שמתארחים באזור**
    
    שרתי האפליקציה הראשיים, מסדי הנתונים, אחסון האובייקטים והגיבויים של הפריסה באזור נמצאים באותו אזור. רשומות מנהליות מתעדות את האזורים ואת אישור השינויים, והפריסה הטכנית מקבעת את המשאבים לפרויקט האזורי.
    
    **התאמה ל-APP:** APP 11.1 (אבטחת מידע אישי); APP 8 – שמירת הרשומות באוסטרליה מגבילה את הגילוי מעבר לים לעיבוד שמפורט תחת ספקי שירות.
    
-   ✅
    
    טכנית
    
    **הצפנה בתעבורה**
    
    תעבורה נכנסת מהאינטרנט משתמשת ב-TLS מודרני. התעבורה לספקי זיהוי הדיבור ולספקי מודלי ה-AI משתמשת ב-TLS אל נקודות הקצה שהוגדרו לכל ספק. זו בקרה טכנית שמאומתת בסקירות ארכיטקטורה ובתצורת הפריסה.
    
    **התאמה ל-APP:** APP 11.1 (הגנה מפני הפרעה, שימוש לרעה וגישה לא מורשית).
    
-   ✅
    
    טכנית מדיניות
    
    **הצפנה באחסון**
    
    מסדי נתונים, אחסון אובייקטים ואובייקטי גיבוי משתמשים באלגוריתמים מקובלים בתעשייה (למשל AES-256-GCM), עם מפתחות שמנוהלים לפי מדיניות הקריפטוגרפיה שלנו. גיבויי WAL-G מוסיפים הצפנה בצד הלקוח לפני האחסון מחוץ לאתר.
    
    **התאמה ל-APP:** APP 11.1; APP 11.2 – גיבויים מוצפנים נשארים מוגנים עד להשמדתם המתוזמנת.
    
-   ✅
    
    טכנית ספקים
    
    **הגנת DDoS ו-WAF בקצה הרשת**
    
    שכבת קצה מנוהלת עומדת לפני שמות המארחים הציבוריים, סופגת מתקפות נפח ומפעילה חוקי WAF נגד שימוש לרעה נפוץ ברשת. ההגנות ברמת הספק ומדיניות חומת אש הדוקה נשארות בתוקף מאחורי שכבת הקצה.
    
    **התאמה ל-APP:** APP 11.1 (הגנה מפני הפרעה ואובדן).
    
-   ✅
    
    טכנית מדיניות
    
    **זיהוי חדירות**
    
    זיהוי בכמה שכבות: פלטפורמת האירוח מספקת IDS ברמת הרשת, וכל מכונה וירטואלית (VM) מריצה fail2ban (מניעת מתקפות brute-force על SSH), UFW עם מדיניות ברירת מחדל של חסימה, ועדכוני אבטחה אוטומטיים. אירועי אימות וגישה מה-auth-proxy נשלחים למערך Loki/Grafana מרכזי, כך שדפוסי התחברות חריגים מופיעים בלוחות הבקרה ובהתראות. המדיניות מגדירה מי אחראי לטיפול ראשוני כשהתראה מופעלת. IDS בזמן ריצה ברמת הקרנל לקונטיינרים הוא שיפור מתוכנן מעל הבסיס הזה.
    
    **התאמה ל-APP:** APP 11.1; תומכת בהערכה בתוך 30 יום של חשד לדליפת מידע החייבת בדיווח במסגרת Notifiable Data Breaches (חלק IIIC).
    

## מוצר ואפליקציה

אבטחת המוצר

איך משתמשים מזדהים, איך ההרשאות נאכפות במוצר ובשכבת ה-API, ואיך אנחנו בונים ומשחררים תוכנה. שילוב של אכיפה טכנית (JWT, RBAC) עם דרישות מנהליות למחזור פיתוח מאובטח (SDLC) ולסקירה.

-   ✅
    
    טכנית ספקים
    
    **אימות וסשנים**
    
    מטפלים מזדהים דרך ספק זהויות מנוהל (תהליכים בסגנון OIDC/OAuth), וכל נתיב API מאמת את הזהות. משך הסשן והתנהגות הנעילה תואמים את מדיניות בקרת הגישה שלנו.
    
    **התאמה ל-APP:** APP 11.1 (הגנה מפני גישה לא מורשית).
    
-   ✅
    
    טכנית מדיניות
    
    **בקרת גישה מבוססת תפקידים**
    
    היכולות של מטפלים, של מטופלים ושל מנהלי מערכת מופרדות במודל הנתונים ובשכבת ה-GraphQL, כך שהרשאה מינימלית היא ברירת המחדל. הגדרות התפקידים ותדירות הסקירה שלהן מתועדות ברמה המנהלית.
    
    **התאמה ל-APP:** APP 11.1; APP 6 – הגישה מוגבלת לאנשים שמשתמשים במידע למטרה שלשמה נאסף.
    
-   ✅
    
    טכנית מדיניות
    
    **חובת MFA בנתיבים בעלי הרשאות מוגברות**
    
    חובת MFA נאכפת, דרך ספק הזהויות שלנו, בחשבונות שיכולים לשנות הגדרות רגישות לאבטחה או לגשת לנתונים בסיכון גבוה.
    
    **התאמה ל-APP:** APP 11.1 (הגנה מפני גישה לא מורשית).
    
-   ✅
    
    טכנית מדיניות
    
    **מחזור פיתוח מאובטח**
    
    שינויים עוברים דרך ניהול קוד מקור, סקירה ותלויות מקובעות. השפעת האבטחה נשקלת בפיצ׳רים מהותיים כשער מנהלי, וכלים טכניים (Dependabot ועוד) תומכים בהיגיינה שוטפת.
    
    **התאמה ל-APP:** APP 11.1; APP 1.2 (נהלים ומערכות שמבטיחים עמידה בדרישות).
    
-   ✅
    
    טכנית מדיניות
    
    **רשימת רכיבי תוכנה (SBOM)**
    
    כל גרסה כוללת רשימת מלאי של התלויות בפורמט קריא למכונה, לצורך תגובה לפגיעויות. ייצוא ה-SBOM משולב ב-CI כחלק מתוכנית הבטחת שרשרת האספקה שלנו.
    
    **התאמה ל-APP:** APP 11.1 (צעדים סבירים מפני הפרעה דרך קוד של צד שלישי).
    

## נתונים ופרטיות

נתונים ופרטיות

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

-   ✅
    
    טכנית מדיניות
    
    **שמירה ומחיקה של תוצרי ההקלטה ברקע**
    
    חומרי אודיו ותמליל נשמרים כברירת מחדל לתקופה קצרה ונמחקים אוטומטית. רשומות קליניות נשמרות לפי מדיניות השמירה של כל ארגון. אחרי שילוב עם מערכת הרשומות שלכם, הרשומה הקלינית המחייבת נשארת שלכם.
    
    **התאמה ל-APP:** APP 11.2 (השמדה או התממה של מידע שאינו נחוץ עוד לאף מטרה מותרת).
    
-   ✅
    
    טכנית מדיניות
    
    **יומן מחיקות חסין שינויים ודוחות רבעוניים**
    
    מחיקות שנובעות ממדיניות השמירה נרשמות ב-`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)`.
    
    **התאמה ל-APP:** APP 11.2; APP 1.2 – ראיה לכך שההשמדה בוצעה ולא שונתה.
    
-   ✅
    
    מדיניות טכנית
    
    **זכות הגישה והתיקון של נושא המידע**
    
    אנשים יכולים לבקש גישה למידע האישי שלהם או את תיקונו. Hanah מתעדת לוחות זמנים, פורמטים (ייצוא JSON וייצוא קריא לבני אדם) ונתיבי הסלמה. הכלים תומכים בייצוא במקומות שבהם הנתונים נמצאים במערכות של Hanah.
    
    **התאמה ל-APP:** APP 12 (גישה); APP 13 (תיקון).
    
-   🔧
    
    טכנית מדיניות
    
    **שקיפות ביקורת מאוחדת**
    
    אירועים רלוונטיים לאבטחה (אימות, שימוש בהרשאות, שינויי תצורה) זמינים לשאילתה עבור לקוחות מוסדיים, ואפשר להעביר אותם ל-SIEM שלכם (למשל Microsoft Sentinel) כשהדבר סוכם בחוזה. מוגדר לכל לקוח בנפרד.
    
    **התאמה ל-APP:** APP 11.1; תומכת בהערכה ובדיווח של דליפת מידע החייבת בדיווח לפי חלק IIIC.
    

## AI ובטיחות קלינית

אבטחה ותאימות של AI

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

-   ✅
    
    ספקים מדיניות טכנית
    
    **ללא שימוש משני לאימון מודלים**
    
    תנאי השימוש של ספקי זיהוי הדיבור ומודלי ה-AI שלנו אוסרים אימון על תוכן של לקוחות, והבקשות נשלחות כשהאחסון בצד הספק כבוי, בכל מקום שהספק מאפשר זאת. ל-Hanah אין תהליך אימון פנימי על המידע הרפואי שלכם. סקירות ספקים מנהליות תומכות בטענה הזו.
    
    **התאמה ל-APP:** APP 6 (שימוש וגילוי רק למטרה העיקרית); APP 8 – נמענים מעבר לים מחויבים בחוזה לא לאמן מודלים על התוכן ולא לשמור אותו מעבר לתנאים שמוצגים תחת ספקי שירות.
    
-   ✅
    
    מדיניות טכנית
    
    **בקרה אנושית לפני הסתמכות קלינית**
    
    רשומות שנוצרו מחייבות בדיקה ואישור סופי מפורשים של המטפל לפני שהן נחשבות לחלק מהרשומה הקלינית. זו גם בקרה במוצר (שערים בתהליך העבודה) וגם התחייבות מדיניות בתסקיר ההשפעה על הפרטיות (PIA).
    
    **התאמה ל-APP:** APP 10 (איכות המידע האישי: מדויק, עדכני, שלם ורלוונטי).
    
-   ✅
    
    מדיניות טכנית
    
    **מתודולוגיית WER ותוצאות קבוצות הבדיקה שפורסמו**
    
    מערך בדיקה אחד ושתי שכבות הערכה, שרצים בכל סבב הערכה: **שיעור שגיאות המילים** מול תמלילי ייחוס מילה במילה (שכבה A), **ופאנל שופטים של מודלי שפה** שמודד גם _כיסוי_ (האם הרשומה מכילה כל ציפייה שנרשמה מראש?) וגם _הזיות_ (האם הרשומה מכילה טענות שהתמליל לא תומך בהן, כלומר תוכן שהמודל המציא?). [המתודולוגיה המלאה](https://hanah.health/he/au/trust/wer-methodology/) מפורסמת, [והתוצאות העדכניות](https://hanah.health/he/au/trust/transparency/) מוצגות ישירות מהפלט המצרפי של מערך הבדיקה. הקורפוס ממשיך להתקדם בשלבים: v1 (סינתטי) ← v2 (משחקי תפקידים) ← v3 (אמיתי, מבוסס הסכמה) ← v4 (משותף עם שותפים ממערכות בריאות).
    
    **התאמה ל-APP:** APP 10; APP 1.2 (נהלים מוכחים לשמירה על דיוק).
    
-   ✅
    
    טכנית מדיניות
    
    **הזרקת פרומפט וניטור פלט לא בטוח**
    
    פרומפטי המערכת נשלטים בצד השרת, והקלט מוגבל על ידי תהליך העבודה הקליני (אין ממשק צ׳אט חופשי). מסווגי הבטיחות של הספק רצים על כל יצירה. כשהם מופעלים, הזרם מחזיר סיבת סיום של מסנן תוכן, שנרשמת בשורת `ai_audit` של אותה קריאה, יחד עם קוד שגיאה קנוני `ai.content_policy`, זמן תגובה, טוקנים ומזהה Tempo trace. דפוסים חריגים מופיעים בלוחות בקרה שנבנים על טבלת הביקורת הזו. זיהוי חריגות התנהגותיות בין קריאות, לאיתור דפוסי שימוש לרעה, הוא שיפור מתוכנן מעל הבסיס הזה.
    
    **התאמה ל-APP:** APP 11.1 (הגנה מפני שימוש לרעה והפרעה).
    
-   ✅
    
    טכנית מדיניות
    
    **תיעוד הסכמה של כל המשתתפים בתוך המוצר**
    
    כשהמטפל לוחץ על הקלטה, המוצר פותח חלון הסכמה שמחייב אישור מפורש שהתקבלה הסכמה מהמטופל ומכל משתתף אחר במפגש. ההקלטה לא יכולה להתחיל לפני שהאישור הזה ניתן, והאישור נקשר למפגש יחד עם מדיניות הקליניקה שמוזכרת בתסקיר ההשפעה על הפרטיות.
    
    **התאמה ל-APP:** APP 3.3 (הסכמה לאיסוף מידע רגיש); APP 5 (הודעה על איסוף).
    

## הארגון וצדדים שלישיים

אבטחה ארגונית

איך Hanah, החברה, מנהלת את האבטחה: אחריותיות, מדיניות, אימות בלתי תלוי ושילוב עם כלי האבטחה של הלקוחות. אלה בעיקר בקרות מנהליות, ולחלקן יש תוצרים טכניים (למשל מחברי SIEM).

-   ✅
    
    מדיניות
    
    **ממשל אבטחה ומרשם סיכונים**
    
    בכיר מוגדר בשמו אחראי לאבטחת המידע. סיכונים נרשמים עם בעלים ותאריכי יעד ונבדקים במועדים קבועים. זה תואם את מה שרוכשים מצפים לו בדרך כלל ממערכת ניהול בסגנון ISO, גם בהיקף הנוכחי שלנו.
    
    **התאמה ל-APP:** APP 1.2 (נהלים, הליכים ומערכות לעמידה בדרישות); APP 11.1.
    
-   ✅
    
    מדיניות
    
    **חבילת מדיניות שאושרה בדירקטוריון**
    
    מדיניות פורמלית מכסה גישה, קריפטוגרפיה, תגובה לאירועים, ספקים וניהול שינויים. החבילה אושרה בדירקטוריון ומנוהלת בבקרת גרסאות. התוכן המלא זמין בכפוף להסכם סודיות (NDA).
    
    **התאמה ל-APP:** APP 1.2; APP 11.1.
    
-   🔧
    
    מדיניות טכנית
    
    **העברה ל-SIEM של הלקוח (למשל Sentinel)**
    
    אירועי אבטחה ממערכות שבשליטת Hanah מועברים לסביבת ה-Sentinel שלכם (או למערכת מקבילה) לניטור משותף, כשהדבר סוכם בחוזה. מוגדר לכל לקוח מוסדי בנפרד.
    
    **התאמה ל-APP:** APP 11.1; תומכת בהערכה משותפת של דליפת מידע לפי חלק IIIC.
    

שאלוני בדיקת נאותות מגיעים לעיתים קרובות מנוסחים לפי HIPAA, GDPR, ISO/IEC 27001 או SOC 2. באוסטרליה, Hanah כפופה ל-Privacy Act 1988, ולכן הטבלה הזו מתחילה מכל אחד מעקרונות הפרטיות האוסטרליים, מציינת את ההוראה הקרובה ביותר בכל אחת מהמסגרות האלה ומציגה את בקרת Hanah שעונה עליו. השתמשו בה כדי לתרגם שאלה לעיקרון שחל כאן.

ההקבלות הן אינדיקטיביות בלבד ואינן ייעוץ משפטי.

| עיקרון פרטיות אוסטרלי | HIPAA (ארה״ב) | GDPR / UK GDPR | NZ Privacy Act 2020 / HIPC 2020 | ISO/IEC 27001:2022 | SOC 2 (TSC 2017) | איך Hanah עומדת בזה |
| --- | --- | --- | --- | --- | --- | --- |
| APP 1 – ניהול פתוח ושקוף | §164.520 הודעה על נוהלי פרטיות; §164.530(a), (i) ממונה פרטיות, מדיניות ונהלים | סעיף 5(2) אחריותיות; סעיפים 12–14 שקיפות; סעיפים 24, 30 | סעיף 201 ממונה על הגנת הפרטיות; הצהרת פרטיות מפורסמת | סעיף 5.2 מדיניות; A.5.1, A.5.34 | CC1.1–CC1.3; CC2.3; P1.1 | בכיר אחראי מוגדר בשמו, מרשם סיכונים, חבילת מדיניות שאושרה בדירקטוריון, ומרכז האמון הזה. |
| APP 2 – אנונימיות ושימוש בכינוי | אין מקבילה ישירה; תקן ההתממה ב-§164.514(a)–(b) | סעיף 25 הגנת מידע כבר בשלב התכנון; סעיף 4(5) פסאודונימיזציה | אין מקבילה ישירה | A.8.11 מיסוך נתונים | אין מקבילה ישירה | נקבע על ידי הקליניקה, שמחליטה אם מטופל יכול לפנות אליה באופן אנונימי או תחת כינוי. |
| APP 3 – איסוף מידע שהתבקש (מידע רגיש מחייב הסכמה) | §164.502(b) המינימום הנדרש | סעיף 5(1)(b)–(c) צמצום מטרה ומזעור נתונים; סעיפים 6, 9 בסיס חוקי לנתוני בריאות | IPP 1, 2, 4; כללי HIPC 1, 2, 4 | A.5.34 | P2.1 בחירה והסכמה; P3.1–P3.2 איסוף | אישור הסכמה לפני כל הקלטה; האיסוף מוגבל למפגש שהמטפל מתחיל. |
| APP 4 – מידע שלא התבקש | אין מקבילה ישירה | סעיף 5(1)(c) מזעור נתונים; סעיף 5(1)(e) הגבלת אחסון | אין מקבילה ישירה | A.5.34 | P3.1 | האודיו הגולמי נמחק ברגע שהתמליל מופק; התמלילים כפופים לתקופת השמירה הקצרה שמוגדרת כברירת מחדל. |
| APP 5 – הודעה על איסוף | §164.520 הודעה על נוהלי פרטיות | Art. 13–14 מידע שיש למסור | IPP 3; כלל HIPC 3 | A.5.34 | P1.1 הודעה | שלב הסכמה בתוך המוצר. מדיניות הפרטיות מציינת את המדינות שבהן הנתונים מעובדים. |
| APP 6 – שימוש או גילוי | §164.502(a), §164.506 שימושים מותרים; §164.502(e), §164.504(e) חוזי business associate | Art. 5(1)(b) הגבלת מטרה; Art. 28 תנאי מעבד | IPP 10, 11; כללי HIPC 10, 11 | A.5.34; A.5.10 שימוש מקובל | P4.1 שימוש; P6.1 מסירה לצדדים שלישיים | עיבוד רק לפי הוראות הקליניקה במסגרת הסכם עיבוד הנתונים (DPA); ללא שימוש משני וללא אימון מודלים. |
| APP 7 – שיווק ישיר | §164.508(a)(3) הרשאה לשיווק | Art. 21(2)–(3) הזכות להתנגד לשיווק ישיר | אין מקבילה ישירה (Unsolicited Electronic Messages Act 2007) | אין מקבילה ישירה | P2.1 | מידע על מטופלים אף פעם לא משמש לשיווק; מטופלים שומעים מהקליניקה רק כשמטפל שולח להם משהו. |
| APP 8 – גילוי חוצה גבולות | אין הגבלה גאוגרפית; הנמענים מחויבים באמצעות חוזי business associate | פרק V, סעיפים 44–49 העברות בינלאומיות (בריטניה: IDTA או UK Addendum) | IPP 12; כלל HIPC 12 | A.5.19–A.5.22 קשרי ספקים | CC9.2 סיכוני ספקים; P6.4 | הרשומות נשמרות באוסטרליה. עיבוד מעבר לים מפורט לפי מדינה תחת ספקי שירות, עם התחייבות חוזית שלא לאמן מודלים ועם מגבלות שמירה. |
| APP 9 – מזהים ממשלתיים | אין מקבילה ישירה | סעיף 87 מספרי זיהוי לאומיים | IPP 13; HIPC כלל 13 מזהים ייחודיים | אין מקבילה ישירה | אין מקבילה ישירה | Hanah אינה משתמשת במספרי Medicare או במזהים ממשלתיים אחרים כמזהים שלה. |
| APP 10 – איכות המידע האישי | §164.312(c) שלמות | Art. 5(1)(d) דיוק | IPP 8; כלל HIPC 8 | A.5.34 | P7.1 איכות | בדיקה של המטפל לפני שרשומה מאושרת סופית; מדידת דיוק והזיות שמתפרסמת. |
| APP 11.1 – אבטחת מידע אישי | Security Rule §164.308, §164.310, §164.312 אמצעי הגנה מנהליים, פיזיים וטכניים | 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 בנתיבים בעלי הרשאות מוגברות, זיהוי חדירות, גיבויים מוצפנים. |
| APP 11.2 – השמדה או התממה | §164.310(d)(2)(i) סילוק | Art. 5(1)(e) הגבלת אחסון; Art. 17 מחיקה | IPP 9; כלל HIPC 9 | A.8.10 מחיקת מידע | C1.2 השמדה; P4.3 | מחיקה אוטומטית של אודיו ותמלילים, שנרשמת ביומן מחיקות חסין שינויים. |
| APP 12 – גישה למידע אישי | §164.524 גישה | Art. 15 גישה; Art. 20 ניידות | IPP 6; כלל HIPC 6 | A.5.34 | P5.1 גישה | ייצוא ב-JSON ובפורמטים קריאים לאדם, כדי לתמוך במענה של הקליניקה. |
| APP 13 – תיקון מידע אישי | §164.526 תיקון | Art. 16 תיקון | IPP 7; כלל HIPC 7 | A.5.34 | P5.2 תיקון | המטפלים עורכים רשומות ומאשרים אותן סופית מחדש; בקשות תיקון מטופלות לפי נוהל מתועד. |
| חלק IIIC – Notifiable Data Breaches scheme | Breach Notification Rule §164.400–414 | Art. 33–34 הודעה על דליפת מידע | Part 6 דליפות פרטיות החייבות בדיווח | A.5.24–A.5.27 ניהול אירועים | CC7.3–CC7.5 תגובה לאירועים | מדיניות תגובה לאירועים, רישום אבטחה מרכזי ותמיכה בהערכה של הקליניקה בתוך 30 יום. |

אלה סוגי ספקי השירות שעשויים **לעבד או לאחסן נתוני לקוחות של Hanah** בארכיטקטורת הייצור שלנו באזור , מה כל אחד מהם מטפל בו, מה הוא שומר והיכן הוא מעבד נתונים. כל ספק מחויב בחוזה להגן על נתוני הלקוחות, ואף אחד מהם לא רשאי לאמן עליהם מודלים. כניסת המטפלים משתמשת בתשתית זהויות גלובלית שאינה מחזיקה **שום מידע רפואי של מטופלים**. אותם סוגים מופיעים בנספח C של [הסכם עיבוד הנתונים](https://hanah.health/dpa/#annex-c) שלנו.

| סוג השירות | מטרה | הנתונים שמטופלים | שמירה | אזור העיבוד |
| --- | --- | --- | --- | --- |

שקיפות תפעולית: דף **סטטוס** ציבורי (זמינות ואירועים) עומד לצד נקודת הקצה `/healthz` של סביבת הייצור, שמשמשת את הניטור שלנו.

[סטטוס השירות](https://hanah.health/he/au/trust/status/ "תקינות לפי רכיב, זמינות ב-90 הימים האחרונים והיסטוריית אירועים לפריסה האוסטרלית.") [לבקשת חבילת האבטחה המלאה בכפוף להסכם סודיות (NDA)](mailto:security@hanah.health?subject=Trust%20%2F%20security%20pack%20request) [חזרה ל-hanah.health](https://hanah.health/he/)

PhysiPal Pty Ltd (פועלת בשם Hanah) – . מרכז האמון הזה הוא סיכום כללי. התחייבויות חוזיות ותנאי עיבוד הנתונים שבתוקף בעת החתימה גוברים על הדף הזה. סימוני האימוג׳י של הסטטוס (✅ 🔧) זמניים ויוסרו אחרי אימות בלתי תלוי של כל שורה.