מודל נתונים ומערכת בקרה לגישה לנתוני FHIR

בדף הזה מוסבר איך להשתמש במערכת בקרת הגישה של Cloud Healthcare API FHIR כדי לנהל ולאבטח את נתוני הבריאות. אתם יכולים להשתמש בבקרת גישה ל-FHIR כדי להגדיר מדיניות הסכמה, לשלוט בגישה לנתונים על סמך תפקידים והקשר של המשתמשים ולאכוף את המדיניות הזו במאגר FHIR.

סקירה כללית על מודל הנתונים

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

כללי הגישה מבוטאים באמצעות משאבי FHIR Consent. ‫FHIR Consent הוא סוג של FHIR Resource שמתעד את הבחירות של צרכני שירותי בריאות. היא מאפשרת או אוסרת על קבוצה של גורמים לבצע פעולות שמשפיעות על הצרכן למען מטרה ספציפית מסביבה מוגדרת למשך תקופה מסוימת. לדוגמה, צרכן יכול להיות מטופל במערכת הבריאות, כל אדם שפועל בשם מטופל במערכת הבריאות או אדם אחר שחותם על הסכם הסכמה.

הפעולות שמתועדות בהסכמה בפורמט FHIR עשויות להיות רחבות ולהתייחס ליותר מנתוני סיכום מצב בריאותי אלקטרוני (EHR) של הצרכן. עם זאת, לצורך הסכמה ב-Cloud Healthcare API, הדגש הוא על פעולות שקשורות לגישה לנתונים, והאכיפה של הפעולות האלה מוגבלת לקריאת נתוני FHIR ממאגר FHIR.

למשאב Consent יש סטטוס שמציין את המצב הנוכחי של ההסכמה. למרות שמאגר FHIR יכול להכיל הרבה הסכמות במצבים שונים, Cloud Healthcare API אוכף רק הסכמות שנמצאות במצב active. הסכמות בכל מצב אחר לא משפיעות על האכיפה. אם ההסכמה ניתנת בשם מטופל, היא מתועדת כהסכמה שניתנה על ידי מבצע.

סוג המדיניות

‫Cloud Healthcare API תומך בסוגי מדיניות ההסכמה הבאים:

  • הסכמת מטופל: משויכת למטופל באמצעות Consent.patient (STU3, R4) ומאגדת כמה שיותר נתונים כפי שהוגדר על ידי תא המטופל (STU3, R4).

  • מדיניות האדמין: לא משויכת לאף מטופל וחייבת לכלול כתובת URL של תוסף https://g.co/fhir/medicalrecords/ConsentAdminPolicy. סוג המדיניות הזה יכול להיות קשור לקבוצת משנה או לכל המשאבים בחנות שצוינה בקריטריונים של משאבים. מדיניות האדמין מגדירה את מדיניות ברירת המחדל לכל המשאבים המקשרים בחנות.

  • מדיניות אדמין מדורגת: סוג של מדיניות אדמין שנדרשת בה כתובת ה-URL של התוסף https://g.co/fhir/medicalrecords/CascadingPolicy וכתובת ה-URL של תוסף מדיניות האדמין. אפשר לקשר את סוג המדיניות הזה לתא של משאבים שתואמים לקריטריונים של משאבים. יש לו את המגבלות הבאות:

    • תומך רק ב-Patient ‏ (STU3, ‏ R4) או ב-Encounter ‏ (STU3, ‏ R4) כבסיס לתא.
    • מאגר ה-FHIR שבו המדיניות נאכפת צריך להיות מוגדר עם disableReferentialIntegrity בערך false. כדי להשתמש בתכונה הזו במאגר FHIR ללא שלמות רפרנציאלית, צריך לפנות אל תמיכת Cloud.

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

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

  • סוג האכיפה: הוראה מסוג permit או deny.

  • פעולה: ההרשאות שחלות על ההנחיה הזו. יש תמיכה רק ב-access כדי לספק גישה לקריאה בלבד.

  • קריטריונים לגישה: קבוצה של מאפיינים שמזהים את מבקש ה-API שחל עליו כלל המדיניות.

  • קריטריונים של משאבים: קבוצה של מאפיינים שמזהים את המשאבים שההנחיה חלה עליהם.

קריטריונים של משתמשים עם גישה

‫Cloud Healthcare API תומך בשלושה מאפיינים של גורם ניגש לשימוש בהנחיית הסכמה ולהתאמה לגורם ניגש שמגיש בקשה לגישה לנתונים. כדי שההנחיה תיאכף על הפונקציה לקבלת גישה כחלק מהקביעה של הגישה שמוצעת על ידי שרת FHIR, צריך להיות התאמה מדויקת שרגישה לאותיות רישיות.

המאפיינים האלה מקודדים באופן הבא:

  • גורם מבצע: מייצג אדם, קבוצה או תפקיד גישה שמזהים את הגורם המקבל גישה או מאפיין שלו.

  • ‫Purpose: מייצג את מטרת השימוש בנתונים.

  • סביבה: מזהה מופשט שמתאר את הסביבה או את התנאים שבהם מתבצעת הגישה.

לדוגמה, אפשר לייצג מאפיין גישה באמצעות המאפיינים הבאים:

  • משתמש: Practitioner/123

  • המטרה: ETREAT או גישה למטרות טיפול חירום

  • סביבה: Application/abc

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

‫provision.actor ו-provision.purpose מוגדרים כחלק מתקן FHIR, ואילו Environment הוא https://g.co/fhir/medicalrecords/Environment. שימו לב שלא ניתן לפתוח את הקישור הזה.

בכל הוראות ההסכמה צריך לציין actor לאכיפה, אבל לא תמיד צריך לציין purpose או environment. לדוגמה, אם לא מציינים environment בהנחיית ההסכמה, ההנחיה תתאים לכל environment שלא נכלל כבר בהנחיות הסכמה אחרות.

קריטריונים של משאבים

‫Cloud Healthcare API תומך ברכיבים הבאים כחלק ממקור המידע של ההסכמה:

  • סוג המשאב (STU3, R4): מייצג את הסוג שמדיניות ההסכמה קשורה אליו, לדוגמה, Encounter,‏ Observation או Immunization.

  • ‫Resource ID (מזהה משאב) (STU3,‏ R4): המזהה שאליו משויכת מדיניות ההסכמה.

  • מקור נתונים: מייצג את המקור של המשאב כפי שמזוהה על ידי המשאב meta.source (זמין רק ב-R4).

  • תג נתונים: מייצג את התווית המותאמת אישית של המשאב, כפי שמתואר במשאב meta.tag (STU3,‏ R4).

  • תווית אבטחה: מייצגת תוויות אבטחה שמגדירות את המשאבים המושפעים כפי שזוהו בשדה meta.security (STU3,‏ R4). יש תמיכה במערכות הקוד הבאות:

    • סודיות: ערכים היררכיים שמדורגים מהערך הכי פחות מוגבל לערך הכי מוגבל: U, ‏ L, ‏ M, ‏ N, ‏ R, ‏ V. אם ההסכמה מאפשרת תווית אבטחה ברמה R, היא חלה על כל המשאבים שסומנו בתווית R או ברמה נמוכה יותר. אם המשתמש לא הסכים לשימוש בנתונים עם תווית אבטחה R, ההגדרה הזו תחול על כל המשאבים שרמת הרגישות שלהם היא לפחות כמו R.

    • ‫ActCode: התאמה מדויקת של מחרוזת לקוד האבטחה.

גישה לרצף הפעולות

authorization_flow

באיור הזה מוצג מסלול מלא של בקשה לחנות עם בקרת גישה ל-FHIR. אפליקציה (מס' 3) משתמשת באסימון חיצוני עם היקף הרשאות ההסכמה (מימין) כשהיא שולחת בקשה למאגר FHIR עם בקרת גישה מופעלת (משמאל).

כששולחים בקשת גישה לנתונים, המבקש פועל במסגרת היקף הסכמה מסוים שמייצג את המאפיינים actor, purpose ו-environment שקשורים לכל בקשת HTTP של FHIR. הערכים של המאפיינים האלה חייבים להיות זהים לאלה שצוינו בהסכמה, כולל אותיות רישיות, כדי שהם ישפיעו על קביעת הגישה לאכיפה.

לגורם שמבקש גישה יכולים להיות כמה מזהים actor שרלוונטיים לקביעת הגישה. באופן דומה, יכולים להיות כמה purposes או environments שרלוונטיים בהקשר מסוים של הסכמה. לכן, צריך לספק את כל מאפייני הגישה הרלוונטיים כחלק מבקשת FHIR HTTP כדי לייצג את הגישה הזו בצורה נכונה למטרות קבלת הסכמה.

לדוגמה, היקף ההסכמה לבקשת נתונים מסוימת יכול להיות:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

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

היקף ההסכמה מסופק כבקשה להיקף הסכמה כחלק מבקשת הנתונים של בעל הגישה.

בקשת היקף הרשאות להסכמה

בקשות FHIR משתמשות בכותרות של בקשות FHIR HTTP כדי לקבל את היקף ההסכמה של בעל הגישה. היקף ההסכמה הזה מכיל קבוצה של ערכים actor, purpose ו-environment שמשקפים את הזהות הנוכחית של המשתמש, את הכישורים שלו, את כוונת השימוש שלו ואת המגבלות הסביבתיות שחלות עליו. יכול להיות שבכל רגע נתון יהיו יותר ממופע אחד של כל אחד מהמאפיינים האלה שמייצגים את היקף ההסכמה של המשתמש שקיבל גישה.

ההגדרות של היקף ההסכמה מוגדרות כך:

  • ‫actor/{type}/{ID}: מאפיין actor שבו המשאב type מסופק יחד עם ID. דוגמאות לtype:

    • Practitioner
    • Group
    • Patient

    לדוגמה, אם חנות בפורמט projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID קוראת ל-API, הפניה מקומית לשחקן Practitioner/123 הופכת ל-projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • ‫purp/v3/{value}: מאפיין purpose שבו value הוא חבר בערכת הערכים FHIR Purpose of Use (v3) או בתוסף שלה. דוגמאות לvalue:

    • TREAT
    • ETREAT
    • HRESCH

  • ‫env/{type}/{value}: מאפיין environment שבו type ו-value הם מחרוזות מותאמות אישית ללא טקסונומיה מוגדרת מראש. דוגמאות לערכים של type ו-value:

    • App/my_app_1
    • Net/VPN

בנוסף, כותרות של בקשות HTTP ב-FHIR יכולות לקבל גם היקפי הרשאות מיוחדים, כמו btg ו-bypass, שמוגדרים באופן הבא:

  • ‫btg: Break the glass (או BTG) מאפשר לכם, כמשתמשים אנושיים, לדלג על בדיקות ההסכמה במקרה חירום. השימוש בה מיועד למקרי חירום בלבד, והיא כפופה לבדיקה לאחר הביקורת. לכן, btg צריך לפחות actor אחד.
  • ‫bypass: מאפשר למשתמשים מהימנים (כמו אדמין) או לאפליקציות מהימנות (כמו צינור להדרכת ML) לפעול במאגר FHIR ללא אישור הסכמה. לכן, bypass צריך לפחות actor וגם env.

אכיפת גישה וקביעת גישה

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

לצרכן שירותי בריאות, כמו מטופל או אדמין, יכולות להיות כמה הנחיות הסכמה שכלולות במשאב הסכמה יחיד. יכול להיות שמשאבי ההסכמה יכילו שילוב של הנחיות permit ו-deny provision.type. כברירת מחדל, למשתמש יכולים להיות כל מספר של משאבי הסכמה, אבל בכל פעם נאכפים עד 200 משאבי הסכמה מסוג active. פרטים נוספים זמינים במאמר אילוצים ומגבלות.

כל הוראות ההסכמה מחולצות מactive משאבי ההסכמה של משתמש מסוים כדי ליצור קבוצה של כללי הסכמה מצטברים.

אפשר להגדיר אכיפת הסכמה לכל היותר למטרה אחת ולכל היותר לסביבה אחת לכל רשומה של הקצאת הרשאות.

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

  • אם אין הנחיה תואמת, הגישה לכל המשאבים נחסמת כברירת מחדל.

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

    • אם סוג המשאב שייך ל-patient-compartment או ל-encounter-compartment: הגישה נדחית.

    • אחרת:

      • אם יש מדיניות אדמין שדוחה את קריטריוני הגישה בלי קשר לקריטריונים האחרים של המשאב, הגישה נדחית.

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

      • בכל המקרים האחרים, הגישה נדחית.

  • מדיניות האדמין היא מדיניות ברירת המחדל שמשמשת להתאמת משאבים בחנות.

  • המשאבים שלא שייכים לאף מטופל נקבעים רק על ידי כללי המדיניות של האדמין.

  • למשאבים שנמצאים בתא המטופל (STU3,‏ R4) או בתא המפגש (STU3,‏ R4) צריך להיות לפחות אישור אחד להוראת הסכמה לכל מטופל או מדיניות אדמין או מדיניות אדמין מדורגת, ולא יכולה להיות הוראת הסכמה מסוג 'דחייה' מהמטופל וגם ממדיניות האדמין וגם ממדיניות האדמין המדורגת. התנאי הזה נדרש מכל המטופלים ששמותיהם מופיעים במשאבים שהמבקש רוצה לגשת אליהם.

    • יכול להיות שחלק מהמשאבים יתמכו בכמה משתתפים שהם מטופלים. לדוגמה, Appointment מספק רשימה של participants, שיכולים להיות מטופלים. כל המטופלים שמופיעים במשאבים כאלה צריכים לאשר את הגישה למשתמש באמצעות הוראות הסכמה, אחרת המשאבים לא יוחזרו. אם למשאב יש הרשאה ממדיניות מדורגת של מפגש, שבה המפגש מפנה למטופל דרך השדה subject (STU3,‏ R4), אז המשאב נחשב כמאושר על ידי המטופל.

הקוד המדומה הבא מסכם את הכללים שמתוארים למעלה:

בקרת גישה משותפת

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

מאגר FHIR בודק את הרשאת ההסכמה ברמת כל משאב. כל הפניה במשאב לא מפוענחת ולא מועברת לבדיקת גישה לצורך קבלת הסכמה. לדוגמה, נניח שיש מטופל שמזוהה על ידי Patient/f001 שמאפשר לרופא גישה לכל משאב MedicationRequest שלו, אבל לא למשאב Patient/f001 עצמו בגלל פרטיות המטופל. בתרחיש הזה, איש המקצוע יכול לראות את כל המשאב MedicationRequest, כולל השדה subject שמתייחס למשאב Patient/f001, אבל הוא לא יכול לראות את התוכן של המשאב Patient/f001, גם אם הוא מבצע חיפוש FHIR באמצעות _include.

פתרון התנגשויות

יכולות להיות התנגשויות בין הנחיות שונות של permit ו-deny. אם שתי הנחיות סותרות תואמות למשאב, הסתירה נפתרת באמצעות המודל deny עדיף על permit.

רק הסכמות מסוג active נכללות באכיפת ההסכמה.

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

כששולחים בקשה ל-FHIR store עם תמיכה מובנית בסטטוס הסכמה, בקרת הגישה מתבצעת בסדר הבא:

  1. ‫Cloud Healthcare API בודק את ההרשאות ב Google Cloud חשבון השירות (או בפרינציפל) שהוגדר בפרוקסי. אם לחשבון השירות יש את הרשאות ה-IAM הנכונות לביצוע ה-method המבוקש של FHIR במאגר FHIR, הבקשה תאושר.

  2. אם אכיפת ההסכמה מופעלת בהגדרות של מאגר FHIR וכותרות ה-HTTP עם תמיכה מובנית בסטטוס הסכמה קיימות, אז Cloud Healthcare API אוכף מדיניות גישה להסכמה למשאבי Patient Compartment. האכיפה של מדיניות הגישה להסכמה מבוססת על היקפי ההסכמה שצוינו בבקשה, בהתאם להנחיות ההסכמה שנרשמו בביצוע האחרון של ApplyConsents ושל ApplyAdminConsents.

הכללים הבאים חלים כששולחים בקשה ל-FHIR Store עם תמיכה מובנית בסטטוס הסכמה:

  • צריך לציין לפחות actor היקף הרשאות שרלוונטי לפעולות שבוצעו בהסכמה.

  • כאן אפשר לציין היקפי הרשאות נוספים של purpose ושל environment שרלוונטיים לפעולות שבוצעו בהסכמה.

  • אם מספר הרשומות של היקף ההסכמה חורג מהמגבלות הנתמכות, מוחזרת שגיאה.

  • אם קוראים לשיטה שמקבלת גישה למספר משאבים (לדוגמה, השיטה fhir.Patient-everything,‏ fhir.Encounter-everything,‏ fhir.executeBundle או fhir.search), אכיפת ההסכמה חלה על כל משאב בנפרד. עם זאת, יש הבדל קטן בין שיטות הגישה האלה למספר משאבים:

    • fhir.executeBundle קריאת כמה משאבים מקבלת את השגיאה Consent access denied or the resource being accessed does not exist (הגישה נדחתה או שהמשאב שאליו מנסים לגשת לא קיים) למשאב בודד ללא הרשאות הסכמה (ראו דוגמאות במאמר קבלת משאבי FHIR עם היקף הסכמה).

    • ‫fhir.search מדלג על משאבים ללא הרשאות הסכמה ולא מחזיר שגיאה על דחיית גישה להסכמה, גם כשמבצעים חיפוש לפי _id (ראו דוגמאות במאמר חיפוש משאבי FHIR עם היקף הרשאות הסכמה).

    • הפרמטרים fhir.Patient-everything ו-fhir.Encounter-everything פועלים באופן דומה לפרמטר fhir.search, אלא שהם מחזירים את השגיאה Consent access denied or the resource being accessed does not exist (הגישה בהסכמה נדחתה או שהמשאב שאליו מתבצעת הגישה לא קיים) אם למתקשר אין הרשאת הסכמה למשאב המטופל או למפגש המבוקש, בהתאמה.

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

אם היקף ההסכמה של בקשה כולל שתי רשומות או יותר מאותו סוג של היקף הסכמה (actor,‏ purpose או environment), יכול להיות שהיקף ההסכמה תואם לכמה הנחיות הסכמה. חלק מההנחיות לבקשת הסכמה לא מציינות purpose או environment. לכן, היקף ההסכמה צריך להתאים גם להנחיות בנושא הסכמה שלא מציינות את סוגי ההיקף האלה.

לדוגמה, הגדרת היקף ההסכמה ל-actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc תואמת לכל אחת מההנחיות הבאות להסכמה: permit או deny:

  • actor/Practitioner/123 purp/v3/TREAT env/App/abc
  • actor/Practitioner/123 purp/v3/TREAT
  • actor/Practitioner/123 env/App/abc
  • actor/Practitioner/123
  • actor/Group/999 purp/v3/TREAT env/App/abc
  • actor/Group/999 purp/v3/TREAT
  • actor/Group/999 env/App/abc
  • actor/Group/999

המאמרים הבאים