Разработка приложения для управления медицинскими приборами
Меня зовут Владислав Бирюков и в этой статье мы рассмотрим нашу командную разработку приложения, которое поможет управлять медицинскими приборами и вести историю пациента в электронном виде.
Если вам необходима разработка, вы можете связаться со мной в Telegram
Заказчик обратился с запросом разработать удобное приложение для врачей, которое позволит производить измерения с помощью медицинских приборов из смарт-чемодана и добавлять измерения в историю пациента, а также синхронизировать информацию о пациенте между планшетом и рабочим компьютером врача.
Что такое смарт-чемоданчик?
Чемоданчик представляет из себя, где находятся медицинские приборы и планшет
Дизайн-процесс
Этап 1 — стратегия продукта
Проведение серии интервью с заказчиком и врачами помогло понять стратегию применения и продвижения данного продукта, что сыграло ключевую роль в определении порядка рабочих задач на разработку приложения.
Гипотезы:
- Смарт-чемоданчик не закреплен за пользователем, могут быть разные каждый раз
- Будут использовать в каретах скорой медицинской помощи
- Текущий флоу по замерам требует воспроизведения 1 в 1
- Карты пациентов хранятся в планшете
Методы:
- Глубинное интервью с представителями заказчика с большим опытом работы в сфере экстренной медицины
- Изучение исходного АРК
- Изучение документации
Эффекты:
- Построена AS IS CJM процесса приема пациента фельдшером, выделены основные проблемы в пути
- Определены основные кейсы использования чемоданчика в рамках MVP продукта
Этап 2 — определение скоупа
На данном этапе мы детально изучали процесс работы каждого отдельного прибора в чемодане, а также в целом - медицинской информационной системы. Наша задача заключалась в понимании того, как именно данные будут синхронизироваться с МИС, и как будет производиться каждый отдельный замер.
Гипотезы:
- Для каждого прибора флоу измерения будет типовой
- Процесс регистрации только для тех, кто впервые подключается к планшету
- Всего 3 активности: авторизация, идентификация пациента, замер
Методы:
- user story mapping
- activity map
- to be cjm
- user flow
Эффекты:
- достигнуты договоренности с заказчиком по скоупу mvp
- процесс дополнен активностью открытие приема
- определен пул основных экранов для отрисовки
- определено количество необходимых сценариев для проработки
Этап 3 — юзабилити тест
На данном этапе требовалось собрать прототип и протестировать его на пользователях. В качестве тестировщиков были задействованы практикующие врачи и медсестры (10 человек). После проведения тестирования были внесены незначительные корректировки, связанные с улучшением визуального представления отдельных элементов, таких как иконки, контрастность цветов и размер текста. Главные проблемы, выявленные у пользователей, были связаны с трудностями в считывании информации: мелкий текст в лейблах полей, непонятная иконки. В целом все поставленные задачи пользователи смогли выполнить.
Гипотезы:
- Боковое меню должно быть на всех экранах
- Подсказки нужны только в момент обращения к функции, предварительный онбординг на старте не нужен
- На странице выбора приборов на каждом из приборов нужна функция(кнопка), при активации которой будет объясняться зачем прибор и как его подключить
- Переключение между приборами должно быть доступно во время паузы или во время измерения
- Смена типа приема должна быть доступна во время заполнения протокола приема
- Если пользователь начал прием, то на каждой странице (при заполнении протокола, при проведении исследования) должна висеть информация об этом пациенте, пока прием не будет завершен или отменен
- Должна быть возможность провести несколько измерений и добавить в протокол средний результат замера или любой из промежуточных
- Должна быть возможность предпросмотра протокола приема
- Должна быть возможность сформировать отчет по проведенным исследованиям (отдельно по пациенту или по периоду) Должна быть возможность гибкого поиска пациента по базе МИС
- Должна быть возможность добавить нового пациента без привязки к профилю в МИС
- Должна быть возможность проведения исследования без привязки к карте пациента
- Процесс приема должен начинаться с идентификации пациента
- Должна быть возможность установить время в течении которого будет делаться измерение кислорода в крови
- Должно быть уведомление, о том что кислород в крови замерен
- Должно быть автосохранение результата после остановки таймера
Методы:
- usability test
Результаты:
- создан прототип приложения
- протестирован прототип приложения
Эффекты и результаты:
Этот продукт повышает мобильность медицинского персонала и ускоряет обработку и сохранение информации о пациентах. Благодаря процессу синхронизации данных из чемоданчика с медицинской информационной системой больницы, врачи увидели выгоду от использования этого устройства в своей практике. Наличие наглядного прототипа позволило заказчику привлечь новых клиентов, которые хотят улучшать свой сервис для пациентов.
Самое смешное, что это нафиг никому не надо.
А можно по подробнее?)
Пытался лет 10 назад зайти в тему. Сертификация мед железа запредельно высоко планка стояла. Сейчас попроще ?
Вопросом сертификации, занималась другая команда, не могу вам ответить стало ли сейчас проще
Система разрабатывалась по заказу китайских партнеров
Вот пара комментариев если интересно:
1 отклонения от нормы как в большую сторону так и в меньшую являются одинаковыми по значимости. То есть это одинаково плохо. По этому пониженные показатели не должны краситься в зелёный цвет. Так как он символизирует что-то хорошее. А вот стрелку можно оставить.
2 не стоит делать такие серые/светлые элементы интерфейса. Для дрибла это норм, но не для реального продукта. В реальности придётся вглядываться в каждое слово чтоб прочитать. Плюс нужно учитывать что если основное устройство это планшет и его могут использовать на улице то при солнечном свете на экране будет сложно считывать элементы.
3 ну и результаты поиска странно что справа от поиска отображаются
ООо технологии идут в медицину полным ходом, и это радует!
В дополнение можно добавить поля: фото человека и, обязательные у нас, снилс и ОМС.