Приложения и веб-кабинеты
Разрабатываем отдельные интерфейсы для повторяющихся административных задач пациентов и сотрудников. Помогаем выбрать формат и состав первой версии — от веб-кабинета до мобильного приложения.
Обсудить приложениеКлиники / Стоматологии / Косметологии
Работа по всей России
Приложение имеет смысл, когда человеку нужно регулярно выполнять действия, для которых обычной страницы или формы недостаточно. Начнём с того, кто будет пользоваться продуктом, как часто и с какого устройства.
Сначала рассмотрим, можно ли использовать существующий инструмент. Если достаточно сайта, диалога с ботом или готового продукта, отдельная разработка может не понадобиться.
Сайт — чтобы представить услуги и принять простое обращение.
Бот — чтобы решить задачу в выбранном диалоговом канале.
Веб-кабинет — чтобы выполнять повторяющиеся действия в браузере с нужными правами доступа.
Мобильное приложение — отдельный формат, если его возможности и способ распространения соответствуют задачам пользователей.
Кабинет пациента, рабочий интерфейс администратора и внутренний сервис для врача решают разные задачи. Для каждой выбранной роли определим необходимые действия, информацию на экране и результат операции. Например, это может быть обращение, его статус или административное уведомление — состав выбирается под процесс клиники.
В первую версию включаем то, что нужно для согласованных задач. Дополнительные функции выделяем в дальнейшее развитие: большой перечень возможностей сам по себе не означает, что все они нужны к запуску.
Рабочие прототипы помогают согласовать действия и переходы до разработки. Результат проекта — первая работающая версия выбранного продукта. Создание собственной МИС и диагностические функции в эту услугу не входят.
До разработки выясним, какие данные нужны продукту, где они находятся и какие операции разрешены. Проверим документацию API действующих систем, условия доступа, идентификацию пользователей, роли и синхронизацию. Подключение конкретной МИС оценивается после этой проверки.
Если продукт работает с расписанием, различаем приём заявки и подтверждение записи в исходной системе. При недоступном подключении пользователь должен понимать, что произошло и какое действие возможно дальше.
Работа с медицинскими данными требует отдельного определения состава, правил доступа и архитектуры. Она не добавляется автоматически вместе с кабинетом. Для приёмки согласуем проверки ролей, запрета чужого доступа, ошибок и сбоев обмена.
До начала разработки определим платформы, состав первой версии и критерии её готовности. Клиника назначает ответственного за рабочие требования и предоставляет сведения об источниках данных, ограничениях и необходимых подключениях.
Уточняем пользователей, повторяющиеся задачи и приоритетные функции. Фиксируем, что входит в первую версию.
Прорабатываем действия, роли и состояния экранов. Клиника проверяет соответствие своему процессу до реализации.
Реализуем согласованные функции и интеграции. Проверяем пользовательские потоки, пустые состояния, ошибки и доступ.
Выполняем согласованный запуск или подачу на публикацию. Передаём исходники, необходимые сборки и инструкции.
Стоимость зависит от платформ, числа ролей и функций, авторизации, синхронизации и требований к данным. На объём влияют также набор устройств для проверки, интеграции и способ распространения. Для оценки важны задачи и сложность первой версии, а не только количество экранов.
В предложении разделяем разработку, инфраструктуру, внешние сервисы и дальнейшие обновления. Состав передаваемых материалов, права на созданный результат и ограничения сторонних лицензий закрепляем в договоре. Исправление несоответствий заданию, новые функции и эксплуатационная поддержка имеют разные условия.
Использование приложения пациентами и окупаемость нельзя гарантировать фактом разработки. Первая версия позволяет проверить согласованные действия и получить основание для решения о дальнейшем развитии.
Это зависит от действий пользователей, частоты обращений к продукту, устройств и нужных подключений. Сначала сравним эти требования с возможностями форматов. Иногда для задачи достаточно сайта или бота — отдельное приложение не является обязательным решением.
Те, без которых не выполняются выбранные задачи конкретных пользователей. Определим нужные роли, операции и данные, затем зафиксируем состав и исключения. Остальные пожелания можно планировать отдельно, не превращая первую версию в разработку сразу всех возможностей.
Возможность и объём подключения оцениваются после проверки API, доступных данных, разрешённых операций и инфраструктуры. При необходимости уточняем ограничения у владельца системы. Упоминание МИС в задаче ещё не подтверждает готовую совместимость.
Способ распространения и действия каждой стороны определяются до запуска. В согласованном объёме выполняется запуск или подача на публикацию и передаётся комплект продукта. Внешняя модерация не гарантируется; обновления и сопровождение оформляются отдельно от разработки первой версии.
Начать разговор
Для первого обсуждения достаточно описать пользователя, повторяющуюся задачу и желаемый результат. Если есть действующий сайт или система — можно назвать их, не передавая пароли, документы и данные пациентов.
Выберите удобный контакт: email или Telegram. Уточним необходимые функции и исходные данные, затем обсудим формат, объём и оценку разработки.