טוען ענפים…
נוכחות שמחזקת אמון. תהליכים שמפנים זמן.
המפגש עם המרפאה מתחיל לא פעם באתר. מידע ברור על הצוות, ההתמחויות והטיפולים מחזק את האמון ועוזר להבין לאן לפנות. כשהדרך לקביעת תור ולהכנה לביקור פשוטה יותר, גם הצוות וגם המטופלים יכולים להתנהל בנוחות.
אנחנו בונים אתרים לרופאים, מרפאות, מרכזים רפואיים וחברות HealthTech, ומפתחים מערכות לתהליכים שסביב הביקור: יומנים, זימון תורים, אישורי הגעה, רשימות המתנה וטפסי קליטה. החיבור למערכות הניהול והתשלומים נבחר לפי התשתית שהארגון מפעיל.
האפיון מגדיר מי משתמש במערכת, אילו נתונים נדרשים ומי רשאי לגשת אליהם. התהליך הדיגיטלי נבנה סביב הפעילות הקיימת, עם תשומת לב למידע הרגיש ולחלוקת האחריות, בלי להפוך את הטכנולוגיה לעוד משימה של הצוות.
7לקוחות בענף
חצי שעה לטיפול, שעה לפגישה, שעתיים לאבחון: יומן אחד שמחזיק את כולם. כשתור ארוך נקבע בשעה שבה יש משבצות קצרות, המשבצת הבאה נדרסת, ובלי חישוב נכון נוצרת התנגשות. ומה קורה כשמטופל מבטל ברגע האחרון או לא מגיע? כל קליניקה רוצה כלל אחר: התראה, חיוב או חסימה. ומה כששני מטופלים רוצים להחליף ביניהם תור בלי לראות זה את זה? באוברסייט אפיינו יומן אחד לכמה סוגי תורים, עם חלון ביטול ועריכה שהעסק מגדיר, והחלפת תור אנונימית שמסתיימת באישור או דחייה והתראה לבעל העסק. כל ביטול מחזיר את המשבצת לרשימת ההמתנה, כך שהיא לא נשארת ריקה.
אינטייק קליני אינו טופס. תשובה חיובית אחת פותחת שאלון שלם, חלק מהתשובות הן תסמינים מג'וריים או מינוריים ולא כן ולא, והערכת מסוכנות מחייבת חלוקה שמסתכמת ב-100 בדיוק. שדות הזיהוי נבחרים בכוונה: מספר סידורי פנימי במקום תעודת זהות ושם בדוי. וכשיש סיכון, תוכנית הביטחון צריכה להתמלא לבד עם פרטי קווי הסיוע. והלקח שגילינו כשבנינו את גרסת הפיילוט, המלאה והמקוצרת: הכלל חייב להיאכף בשני הכיוונים, גם מתחת ל-100 ולא רק מעליו. שאלונים מקובלים וטפסי קליטה נשלחים למטופל לפני הביקור, כך שהצוות פוגש מידע שלם ולא טפסים שמגיעים רק בדלפק.
"יש לכם את התרופה הזו במלאי?" מטופל מחפש תרופה לפי שם מסחרי, חומר פעיל או רק לפי תסמין, ובסוף רוצה לדעת דבר אחד: איפה היא במלאי. מאגר התרופות של משרד הבריאות מחזיק את הרישום, העלונים והמחירים, אבל המלאי חי במערכת של בית המרקחת, ולכן החיבור הוא לא חיפוש אחד אלא שניים שנפגשים. תרופה שיצאה משיווק או שם מסחרי אחר לאותו חומר פעיל צריכים להופיע כחלופה ולא כאפס תוצאות. באוברסייט בונים את זה כך: שכבה אחת, חיפוש מעל המאגר הממשלתי, חיבור לנתוני המלאי של הסניפים, ועלון שנמשך תמיד מהמקור ולא מועתק. המערכת מציגה מידע, ולא ממליצה על טיפול.
משימה אחת ביום, בשעה שהמשתמש בחר: כך נראית אפליקציית אימון קוגניטיבי לגיל השלישי כשהיא עובדת, והיא נכשלת ברגע שהיא מציפה. המשתמש בוחר אחת עד שלוש משימות ביום, מתחומים כמו זיכרון וחשיבה, וקובע בעצמו באילו שעות הן יגיעו. התראה שמגיעה בשעת ברירת מחדל ולא בשעה שנבחרה מספיקה כדי שהאפליקציה תימחק. פיתחנו הרשמה בצעדים קטנים עם כפתור שנשאר פעיל, בחירת שעה כפעולה נפרדת מסימון הבלוק, התראות שמכבדות את מה שנקבע, וקוד SMS בפורמט ש-iPhone ממלא לבד. מאגר המשימות מנוהל מפאנל ניהול, והצוות מוסיף ומעדכן בלי פיתוח. אפליקציה שמכבדת את השעה שנבחרה נשארת במכשיר.
בלי חיבור, פרטי מטופל מוקלדים פעם ביומן ופעם בכרטיס, ותשלום פעם בסליקה ופעם בחשבונית. עם חיבור, הצוות מתנהל במקום אחד. מערכת הניהול של הקליניקה, התשלומים וה-CRM כבר קיימים, וכל פתרון חדש שאינו מדבר איתם הופך להקלדה כפולה. בענף שבו המידע רגיש, השאלה מי רואה ומי עורך היא חלק מהאפיון ולא תוספת. באוברסייט מתחילים במיפוי הממשקים שהתשתית הקיימת חושפת, מגדירים אילו נתונים עוברים ולאן, ומקבעים הרשאות לפי תפקיד, כך שהמידע נשאר בידי מי שמורשה לראות אותו. חיבור נבחר לפי התשתית שהארגון מפעיל, ולא להפך.
7פרויקטים שהגשמנו בענףלכל הפרויקטיםהמרפאה שלכם יכולה להתנהל ברור יותר, גם בדיגיטל. בואו נדבר.
מציגים בבירור את הצוות, ההתמחויות, הפעילות ודרך הפנייה. התוכן המקצועי מגיע מהארגון ומקבל מבנה נוח לקריאה, גם בנייד, כדי שהמטופלים ימצאו את המידע הרלוונטי לפני יצירת הפנייה.
מגדירים יומנים, סוגי ביקורים וזמינות לפי אופן העבודה של המרפאה. כללי השיבוץ נבנים סביב המטפלים והסניפים, והחיבור למערכת קיימת נבדק כחלק מהאפיון.
מתכננים תהליך שמחבר בין התזכורת, תגובת המטופל ושינוי מצב התור. לפי כללי המרפאה, מקום שהתפנה יכול להמשיך לתהליך שיבוץ מרשימת ההמתנה, במקום להתחיל סבב תיאום ידני.
טפסי קליטה, שאלונים ומסמכים שהמרפאה מגדירה כחלק מההכנה. באפיון קובעים מה נאסף, איך מועבר המידע ומי מקבל גישה אליו, בהתאם לצורך ולרגישות הנתונים.
בודקים אילו ממשקים זמינים ואילו נתונים צריכים לעבור בין המערכות. החיבור מתוכנן לפי האפשרויות בפועל; כשיש מגבלה, מגדירים חלופה או גבול ברור במקום להבטיח שכל מערכת ניתנת לחיבור.
כבר באפיון מגדירים אילו נתונים נאספים, מי רשאי לראות אותם ומהן דרישות הארגון. היישום הטכני נקבע בהתאם, ודרישות משפטיות או מקצועיות נבדקות עם הגורמים המוסמכים של הארגון. אין התחייבות גורפת לציות מכוח עצם הפיתוח.
יש שאלות שעדיף לשאול ישירות. נשמח לענות על השאלה שלכם באופן אישי.
דברו איתנובואו נדבר · רפואה ובריאות
