Dealer Workspace
Застосунки
КейсиШаблон кейсу · My Health
My HealthОхорона здоров’я · Цифровий продукт
Послуги
Інструменти
Стек технологій
Охорона здоров’я · Цифровий продукт
My Health
Концепція медичного застосунку, що допомагає пацієнтові відстежувати запит між кабінетом лікаря, страховою компанією та клінікою. My Health показує поточний етап, відповідальну організацію та доступну наступну дію, а також пов’язаний робочий процес лікаря.
Той самий запит із боку лікаря. Повідомлення пацієнта, важлива історія й рішення в очікуванні зібрані разом, щоб лікар міг вивчити контекст, вибрати наступний крок і продовжити роботу зі зверненням.
Навіщо цей досвід
Надсилання запиту не пояснює пацієнтові подальший шлях. Направлення може потребувати перевірки в офісі, схвалення страховою компанією й запису — у різних місцях. Ми зосередилися на зрозумілому прогресі та практичному способі подальших дій.
Навіщо цей досвід
Один пацієнт може чекати на лікаря, а інший запит — на страхову компанію. Лікареві потрібно розрізняти відповідальність, бачити контекст пацієнта й діяти, не відновлюючи всю історію з окремих екранів.
Наші продуктові рішення
Ми побудували досвід навколо запиту та його етапів. Замість загального статусу очікування пацієнт бачить, у кого перебуває запит, що далі та чи потрібно йому щось зробити.
Ми перенесли подальшу роботу в саме звернення, розмістивши потрібні контакти й довідкові відомості біля дії. Рецепти й підсумки візитів мають власні подання: отримання ліків і повернення до плану лікування — інші завдання, ніж відстеження погодження.
Наші продуктові рішення
Ми відокремили запити, що потребують рішення лікаря, від замовлень, які чекають на іншу організацію. Кожен запит показує свій контекст і відповідні варіанти: схвалити, спочатку запросити на прийом або відхилити.
Ми пов’язали підтримувані рішення із запитом пацієнта й залишили історію, результати, ліки та перебіг лікування поруч із розмовою. Зведення асистента допомагає перевірці, але рішення залишається за лікарем.
Наш внесок
Ми побудували досвід пацієнта й лікаря навколо одного запиту на допомогу: у кого він перебуває, чого чекає та яка дія наступна. Спроєктували етапи запитів, подальші дії, подання ліків і контекст пацієнта, а потім розробили фронтенд, щоб підтримувані рішення лікаря відображалися в пацієнта.
01 / Знайдіть те, що потребує уваги
Бачте запити, які потребують наступного кроку.
Огляд поєднує направлення, погодження й аналізи за людиною. Кожен запит має свої етапи та статус, тому пацієнт може перевірити кілька поточних питань, не відкриваючи кожне.
Список направлень розрізняє запити, готові до дії пацієнта, ті, що ще проходять етапи, і ті, що потребують нагадування. Прикладні дати й строки ілюструють ці стани, а не встановлюють універсального строку.
02 / Відстежити передавання
Знати, у якої організації перебуває запит.
Направлення може пройти через кілька організацій, перш ніж пацієнт зможе записатися. Ми зробили передачу видимою в межах одного запиту, послідовно показавши завершений етап, поточного відповідального й наступне місце призначення.
У прикладі МРТ запит перебуває у страхової компанії до передавання в діагностичний центр. Цей контекст допомагає зрозуміти, у кого дізнатися про статус, а не починати наново з кожною організацією.
03 / Продовжити роботу з контекстом
Зберегти контактні дані поруч із дією.
Коли запит потребує подальших дій, пацієнтові не потрібно збирати ідентифікатори в різних місцях. Панель об’єднує контакт страхової компанії, відомості учасника й запиту та запропоновані формулювання.
Підготовлений сценарій також показує способи залучити лікарський офіс чи дізнатися про перегляд. Це приклади спрощення підготовки подальших дій, а не твердження, що застосунок може прискорити погодження.
04 / Отримуйте ліки й керуйте ними
Дати рецептам подробиці, потрібні для їхнього завдання.
У рецепта наступний крок відрізняється від направлення. Його сторінка показує етап аптеки й відомості про отримання та зберігає разом зафіксовані інструкції, запас, решту повторних відпусків і вартість.
Ми виділили це подання окремо: пацієнт, якому потрібен статус отримання чи повторного відпуску, може відразу відкрити ліки, не проходячи трекер направлень.
05 / Зберегти план
Зробити візит корисним після завершення розмови.
Підсумки візиту зберігають зафіксовані висновки й план після прийому. Пацієнт може повернутися до них, щоб пригадати обговорене та наступні кроки, поруч із запитами й рецептами, створеними під час лікування.
01 / Знайти пацієнта, якому потрібна увага
Показати незавершену роботу поруч із пацієнтом.
Список пацієнтів містить сигнали пріоритетів: новий запит, нові результати чи план в очікуванні. Лікар може знайти потрібну людину й відкрити її контекст в одному місці.
02 / Розділити відповідальність
Відрізняйте рішення від подальшої дії.
Запити й призначення показують, яка робота чекає на лікаря, а яка вже передана страховій компанії. Тож незавершене погодження не виглядає як звернення пацієнта без відповіді.
Завдання містять пов’язану з пацієнтом роботу практики: наприклад, підписання нотатки чи нагадування страховій компанії. Два подання розділяють рух запиту й дії, які повинна виконати сама практика.
03 / Перевірити й відповісти
Перенести потрібну історію в розмову.
Приклад зведення асистента збирає історію, результати, ліки й перебіг лікування поруч із повідомленням пацієнта. До нього входять і відкриті запити, щоб відповідь ураховувала незавершені питання.
Підтримувані дії пов’язують обидва боки: схвалений запит просувається в трекері пацієнта, а новий рецепт з’являється в його ліках. Зведення використовує підготовлену демонстраційну логіку й не ухвалює клінічного рішення.
Результат
Запит, який можуть відстежувати обидва боки.
Результат пов’язує видимий пацієнтові прогрес із рішеннями й подальшою роботою лікаря. Дослідіть обидва інтерфейси та підтримувані спільні сценарії на вигаданих медичних даних. Організації не підключені, строки й зміст асистента ілюстративні.
