פלטפורמת Health Connect מספקת מגוון של סוגי נתונים, בעיקר תרחישים לדוגמה של בריאות ואיכות חיים, שמאפשרים לאפליקציות בסביבת Android לשתף נתונים בלי צורך בשילובי API חד-ל-חד שעולים הרבה כסף. ביומן הבריאות האישי (PHR) היכולת הזו מורחבת כך שתכלול נתונים רפואיים בסיסיים בפורמט Fast Healthcare Interoperability Resources (FHIR®), כולל:
- ממשק API לאפליקציות שכותבות נתונים רפואיים.
- חוויית משתמש בדפדפן לנתונים רפואיים שמאוחסנים ב-Health Connect כסוגי נתונים רפואיים חדשים, יחד עם הרשאות מפורטות שמאפשרות קריאה במורד הזרם.
- ממשק API לאפליקציות שקוראות נתונים רפואיים על סמך ההרשאות שהמשתמשים העניקו.

ממשקי ה-API של PHR זמינים דרך Android 16 SDK. הוראות לתחילת העבודה מפורטות במאמר הגדרת Android SDK 16.
מגבלות
ממשקי ה-API האלה עדיין נמצאים בפיתוח, ולכן יש עדיין מגבלות מסוימות וחלק מהרכיבים לא זמינים במלואם.
- בדרך כלל משתמשים ב-Health Connect Jetpack SDK כדי לפשט את השילוב באמצעות גלישת ממשקי ה-API של Health Connect, אבל הם עדיין לא זמינים, ולכן צריך להשתמש בממשקי ה-API הבסיסיים של Android framework.
- מדיניות Play לגישה לתיעוד רפואי אישי עדיין בפיתוח, ויכול להיות שאפליקציות יצטרכו לעמוד בדרישות נוספות כדי שיהיה אפשר להשיק אותן בחנות Play.
- חלק מהתכונות, כמו ממשקי API שמבוססים על יומני שינויים, עדיין לא פותחו לממשקי API של מסמכי בריאות אישיים.
פורמט הנתונים של מסמך ה-PHR
נתוני ה-PHR מאוחסנים בפורמט HL7 FHIR, שתומך בשלב הראשון רק בגרסה R4.
אימות נתונים
ממשקי ה-API של PHR מקבלים משאבי R4 FHIR תקינים, ומערכת Health Connect תבצע בדיקות אימות מסוימות כדי לוודא שהם עומדים בדרישות של מפרט FHIR R4.
בדיקות האימות שמסומנות בתווית בקרוב עדיין לא נאכפות, אבל הן יהיו זמינות בגרסה עתידית. מומלץ לפתח תוך התמקדות בכל בדיקות האימות המפורטות כדי למנוע בעיות בגרסאות עתידיות.
רמה | בדיקת אימות | ||||||||
---|---|---|---|---|---|---|---|---|---|
JSON תקין | הנתונים תואמים לפורמט JSON. | ||||||||
פורמטים נתמכים של FHIR | יש תמיכה בגרסה של FHIR שהוגדרה על ידי אפליקציית הכתיבה. אלה הגרסאות של FHIR שנתמכות ב-Health Connect:
|
||||||||
פורמטים נתמכים של FHIR | סוג המשאב של FHIR שמופיע במופע המשאב נתמך. סוגי המשאבים הבאים של FHIR נתמכים ב-Health Connect:
|
||||||||
מזהה משאב ייחודי | למשאב יש שדה מזהה עם ערך שעומד בדרישות של ביטוי רגולרי. | ||||||||
מזהה משאב ייחודי | המשאב לא משתף מזהה עם משאב FHIR אחר מאותו סוג משאב מאותו MedicalDataSource . |
||||||||
כללי עסקים | לא מכיל משאב FHIR מוכלל. משאבים שמכילים משאבים אחרים הם משאבי FHIR שמוטמעים בתוך משאב 'הורה'. משתמשים בהם כשמשאב ההורה צריך להפנות למשאב אחר, אבל אין במערכת מספיק מידע כדי ליצור משאב עצמאי עם קיום עצמאי. |
||||||||
נתוני FHIR בסיסיים תקינים | שדות ברמה העליונה ב-JSON של FHIR קיימים במפרט FHIR של סוג המשאב הנתון. | ||||||||
נתוני FHIR בסיסיים תקינים | בשדות ברמה העליונה אין ערכים null של JSON. | ||||||||
נתוני FHIR בסיסיים תקינים | לשדות ברמה העליונה שמוגדרים בתור רכיבים חוזרים ב-FHIR יש את סוג הנתונים array של JSON. |
||||||||
נתוני FHIR בסיסיים תקינים | לשדות ברמה העליונה (כולל רכיבים ב-array של JSON) שמוגדרים בתור סוגי נתונים מורכבים ב-FHIR יש את סוג הנתונים object של JSON. |
||||||||
נתוני FHIR בסיסיים תקינים | לשדות ברמה העליונה (כולל רכיבים ב-array של JSON) שמוגדרים בתור טיפוסים פרימיטיביים ב-FHIR יש את סוג הנתונים הנכון ב-JSON.
|
||||||||
נתוני FHIR בסיסיים תקינים | שדות ברמה העליונה שמוגדרים בתור סוגים פרימיטיביים ב-FHIR עומדים בדרישות של ביטויים רגולריים. בקרוב |
||||||||
נתוני FHIR בסיסיים תקינים | תוספים לסוגי נתונים פרימיטיביים נמצאים במפרט FHIR, והם כוללים את סוג הנתונים object בפורמט JSON. |
||||||||
נתוני FHIR בסיסיים תקינים | לא מתועד יותר משדה אחד עבור שדות בחירה (fieldname[x] ).לדוגמה, לא יכולים להופיע גם effectiveDateTime וגם effectivePeriod באותו מופע של המשאב. |
||||||||
נתוני FHIR בסיסיים תקינים | סוגי נתונים מורכבים מכילים שדות וסוגים של נתונים שתואמים למפרט FHIR. בקרוב |
||||||||
נתוני FHIR בסיסיים תקינים | רכיבי השדרה (ורכיבים בתוך סוגים מורכבים) מכילים שדות וסוגים של נתונים שתואמים למפרט של FHIR. בקרוב |
||||||||
נתוני FHIR בסיסיים תקינים | השדות value[x] של רכיב התוספים הם מסוג תקין ומכילים תוכן בהתאם לסוג הנתונים הזה.אפשר לכלול רכיבי תוסף בכל משאב כדי לייצג מידע נוסף שלא נכלל במפרט הבסיסי. הם מכילים את השדה url שמקשר להגדרה של התוסף, ואת השדה
value[x] שמכיל את ערך התוסף.
value[x] חייב להיות מתוך רשימה מוגדרת של סוגי נתונים קבילים.
בקרוב |
||||||||
נתוני FHIR בסיסיים תקינים | כל שדות החובה ברמה העליונה נמצאים. |
קטגוריות של נתונים
הקבוצה הנתמכת של משאבי FHIR והקטגוריות התואמות מבוססות באופן כללי על הקטעים של הסיכום הבינלאומי של המטופל:
- קטגוריית רגישות לאלרגיה – מכילה משאבים מסוג AllergyIntolerance.
- קטגוריית התנאים – מכילה משאבי תנאים.
- קטגוריית ביקורים – מכילה משאבים מסוג Encounter, Location ו-Organization.
- קטגוריית חיסונים – מכילה משאבים בנושא חיסונים.
- קטגוריית פרטים אישיים – מכילה משאבים בנושא מטופלים.
- קטגוריית פרטי המטפל – מכילה את המשאבים Practitioner ו-PractitionerRole.
- קטגוריית 'נהלים' – מכילה משאבי 'נוהל'.
- קטגוריית תרופות – מכילה את המשאבים Medication, MedicationRequest ו-MedicationStatement.
משאבי התצפית מסווגים לפי התוכן שלהם:
- היריון – על סמך קודי LOINC של היריון.
- רקע אישי – על סמך קודי LOINC של רקע אישי או הקטגוריה 'רקע אישי' ב-FHIR.
- סימנים חיוניים – על סמך קודי LOINC של סימנים חיוניים או קטגוריית FHIR 'vital-signs'.
- מעבדה – על סמך קטגוריית FHIR 'מעבדה'.
תצפיות שלא שייכות לאף אחת מהקטגוריות האלה לא נכתבות ב-Health Connect.
משאבים למטופלים
בשלב זה, Health Connect מיועד לאחסון נתוני פרופיל בריאות אישי של אדם אחד בלבד. לכן, כל משאבי ה-FHIR שנכתבים צריכים להיות שייכים לאותו אדם.
לא נדיר שמערכות מכילות כמה משאבים של חולים ב-FHIR לגבי אדם אחד. אנחנו מעדיפים לכתוב אפליקציות כדי להתאים בין נתונים ולכתוב משאב יחיד של 'חולה' ב-Health Connect. עם זאת, המערכת לא אוכפת את הכלל הזה כדי להתאים את עצמה למבנים הארגוניים השונים שעשויים להתקיים.
נתוני FHIR שעברו טרנספורמציה
אפליקציות מסוימות משנות את נתוני ה-FHIR כדי לעמוד בדרישות שלהן. לדוגמה:
- מיזוג נתונים ממקורות שונים (בדרך כלל ממשקי API של FHIR).
- מיפוי קודים למונחולוגיות גלובליות (לדוגמה, SNOMED, LOINC, ICD) וייצור סטנדרטים ליחידות.
- איחוד נתונים והסרת כפילויות.
- תיקון בעיות בפורמט או בעיות אחרות באיכות הנתונים.
- סינון רשומות על סמך כללים עסקיים ספציפיים לאפליקציה.
אפשר לכתוב ב-Health Connect נתוני FHIR ללא טרנספורמציה ונתוני FHIR שעברו טרנספורמציה, בתנאי שהם עומדים במפרט FHIR R4. מומלץ לכתוב נתונים שעברו טרנספורמציה ככל האפשר. עם זאת, חשוב לזכור את הדברים הבאים:
- אפליקציות עם תרחישי שימוש צרים עשויות לסנן מספר משמעותי של רשומות, שעל סמךן אפליקציות אחרות בסביבה העסקית יכולות ליצור ערך למשתמש. במקרים כאלה, כדאי לכתוב את קובץ ה-FHIR ללא טרנספורמציה, שהוא מלא יותר. עם זאת, חשוב להודיע למשתמשים שהמערך הרחב יותר של הנתונים הזה משותף.
- אם משלבים נתונים שמקורם במקורות שונים, אפשר לכתוב נתונים ל-
MedicalDataSource
יחיד ב-Health Connect. בנוסף, צריך להקצות מזהה חדש לכל משאב כדי למנוע התנגשויות, ולעדכן את ההפניות למשאבים כך שיצביעו למזהים החדשים. - מיזוג נתונים ממקורות מרובים ל-
MedicalDataSource
יחיד עלול להסתיר את מקור הנתונים. לעתים קרובות צרכן הנתונים רוצה להבין את מקור הנתונים, ולכן מומלץ לאכלס את השדהmeta.source
של כל משאב במקור המקורי של הרשומה (בדרך כלל כתובת URL בסיסית של FHIR).
חוויית משתמש
בקטע הזה מוצג מידע כללי על חוויית המשתמש.
הרשאות
בקשת הרשאות קריאה או כתיבה של מסמכים רפואיים דומה למסכי ההרשאות הקיימים ב-Health Connect, אבל מוצג מסך נפרד של מסמכים רפואיים:
עיון בנתונים
ב-Health Connect יש גם תצוגה חזותית בסיסית של נתוני ה-PHR ששמורים, בדומה לסוגי הנתונים הקיימים ב-Health Connect.