פקדים למוסדות רפואיים: ציפיות ומציאות

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

תוֹכֶן

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

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

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

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

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

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

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

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

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

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

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

החלטות כאלה יכולות להיות מוצדקות על ידי העובדה כי הרופאים יצטרכו לבלות יותר זמן כדי לקבל את המטופל אם הם מאפשרים נתונים לתוך המערכת. בפועל מראה כי בשלבים הראשונים, עיכובים קטנים באמת יכול להתקיים - אנשים לומדים, להתרגל, הורים הזדמנויות חדשות. אבל אז, כמו המערכת היא שולטת, הפרודוקטיביות של הרופאים גדל לעומת «עיתון» טֶכנוֹלוֹגִיָה.

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

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

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

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

גם אם אתה מזהה שבמקרים מסוימים, שיקולים אלה עשויים להיות מוצדקים, חשוב להבין את המגבלות הקשורות, והכי חשוב, המחיר הסופי של ההחלטה. אוטומציה של יתרונות תחרותיים, כמובן, משימה ראויה. אבל איזה יחס עושה תהליכים עסקיים ספציפיים בסך נפח של מוסד רפואי פונקציות? ייתכנו 5, 10, במקרים קיצוניים 20%, כמעט לא יותר. בינתיים, אם הוא החליט לעשות את 80-95% הנותרים בבית, אז כל התכונות של הפיתוח הפנימי יחולו עליהם.

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

האם כדאי להסביר את מה שהוא מסתובב כאשר דרישות חדשות עבור המערכת והצורך לבצע שינויים! מערכות תוצרת בית אוניברסלית גם לחוות קשיים חמורים עם חיבור ציוד רפואי מורכב. כתוצאה מכך, לא מובטחת מהירות, אבל אשליה של מהירות הפיתוח. מאחר שהצלחות מקוטעת צריכות, ככלל, בתקופה של ביצועים שליליים בפועל בפיתוח. בהשאלה «לְהִשְׁתוֹלֵל». בשפה של פרויקט ניהול הפרויקט, מצב זה מתואר כצירוף של סיכונים גבוהים ועלות גבוהה של בעלות על המערכת.

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

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

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

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

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