FHIR מוסבר: תקן נתוני בריאות המותאם לזמננו

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

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

במאמר זה, שהוכן בשיתוף עם Łukasz Śliwowski, אנליסט עסקי ראשי, נסביר מהו תקן FHIR ונדון בארכיטקטורה וביישום שלו.

מהו FHIR במונחים פשוטים?

FHIR (Fast Healthcare Interoperability Resources) הוא תקן עולמי שפותח על ידי ארגון HL7, המתאר את פורמט הנתונים הרפואיים להחלפת רשומות בריאות אלקטרוניות בין מערכות רפואיות שונות באופן אחיד.

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

עם זאת, הגרסאות הראשונות של התקן, HL7 v.2 שפותח בשנות ה-90 ו-HL7 v.3 מתחילת שנות ה-2000, היו קשות למדי מבחינת יישום ולא עמדו בכל הדרישות. בתגובה לכך, בשנת 2012 החלו מפתחי תוכנה לעבוד על האיטרציה הראשונה של FHIR.

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

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

FHIR הוא תקן ידידותי למפתחים מכיוון שהוא משתמש ב-JSON (XML ו-Turtle הן גם אפשרות), המוכר כמעט לכל מהנדס תוכנה. הנתונים ב-JSON אחידים, ומעניקים מושג כיצד צריך להיראות מודל נתונים וכיצד יש ליישם את הממשקים. יישום הממשקים מבוסס על קונספט הידוע כמשאבים (resources).

הבטחת עמידה בתקן FHIR

גלו כיצד נוכל לסייע

גלו כיצד נוכל לסייע

ארכיטקטורת FHIR: משאבים, הפניות ופרופילים

מהם משאבים ב-FHIR?

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

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

משאבי FHIR מבוססים על כלל 80/20 – ה-FHIR הבסיסי אמור לחול על 80% מהמקרים, וה-20% הנותרים מוקדשים למקרים מיוחדים ונדירים. כדי לאפשר את הטיפול במקרים האחרונים, הציג FHIR את ההרחבות, שהן דרך מתוקננת להוספת נתונים נוספים למשאב.

מהם פרופילים ב-FHIR?

פרופילים ב-FHIR משמשים להתאמת משאבים למקרי שימוש ספציפיים. ארגוני בריאות יכולים לציין אילו משאבים הם רוצים להשתמש בהם.

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

במילים אחרות, באמצעות פרופילים, FHIR מאפשר יצירה של הגדרת משאב מותאמת אישית וספציפית יותר על ידי ציון סט של אילוצים והרחבות על משאב הבסיס. הודות לקהילת FHIR איתנה, ניתן גם לבחור בחינם מתוך רשימות רבות של פרופילים מוכנים מראש ונפוצים ביותר. ניתן למצוא אותם במדריכי היישום של FHIR (IG), לדוגמה, US Core.

מהן הפניות ב-FHIR?

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

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

מהם האתגרים ביישום FHIR?

נכון להיום, הקושי הגדול ביותר באימוץ FHIR הוא איכות הנתונים across מערכות שונות. לדוגמה, מחקר מראה כי קיים שוני רב במוסכמות שמות המעבדה בתוך רשומות רפואיות אלקטרוניות (EHR) בין בתי חולים שונים ובכל בית חולים בארה"ב. הנתונים הם לרוב טקסט לא מובנה או נרשמים באופן לא עקבי, מה שמקשה על ניהולם.

האם כדאי לאמץ את FHIR?

במרץ 2020, המרכזים האמריקאיים לשירותי Medicare ו-Medicaid (CMS) פרסמו את כלל יכולת הפעולה ההדדית והגישה למטופלים (Interoperability & Patient Access Rule) כדי לשפר עוד יותר את חילופי הנתונים הרפואיים האלקטרוניים – שיתוף מידע עם מטופלים או בין משלם לספק או בין שני משלמים. תאריך האכיפה של הכלל הוא 1 בינואר 2023.

כדי לאפשר שיטה חלקה יותר להחלפת מידע, תקנות ה-CMS כוללות מדיניות שמחייבת או מעודדת יישום של APIs שיכולים להתחבר לאפליקציות מובייל או לספק EHR או למערכת לניהול מרפאה. ה-CMS ממליץ לארגונים להשתמש ב-FHIR לצורך יישום ה-APIs כדי לעמוד בדרישות החדשות. לכן, זהו הזמן הנכון לאמץ את התקן, שכן הוא יהפוך בקרוב להכרח ולא לאופציה.

הצוות שלנו יכול לסייע לכם לבנות תוכנה המשולבת בתקן FHIR אשר תעמוד בכל דרישות תקנת CMS וכן תשלב את התוכנה הנוכחית שלכם עם מערכת אחרת המשתמשת ב-FHIR. צרו קשר למידע נוסף.