Короткий ответ: безопасный MVP — это ограниченный пациентский сервис
Хорошее приложение клиники не переносит всю медицинскую систему в телефон. Оно сокращает один повторяющийся административный путь: пациент входит, видит актуальное расписание, записывается или переносит визит, получает понятный статус и открывает только те документы, к которым подтверждено право доступа. МИС, лабораторная система и другие внутренние сервисы остаются источниками истины.
Такая граница экономит не «экраны», а риск. Команда заранее знает, где создаётся запись, кто резервирует слот, откуда пришёл результат, что произойдёт при недоступности МИС и как расследовать действие. Если приложение само хранит копии расписания и документов без владельца, у клиники появляется ещё одна медицинская система — только менее управляемая.
Тезис для решения: сначала определите пациентский путь, роли, данные и источник каждого статуса. Экраны и оценка разработки появятся после этого.
Когда отдельное приложение клинике не нужно
Допустим, человек выбирает услугу раз в год, приходит из поиска и хочет только увидеть цену и записаться. Просить его установить приложение, создать аккаунт и выдать разрешения — лишняя ступень. Мобильный сайт с настоящими слотами из МИС или готовый кабинет поставщика может решить задачу быстрее и дешевле в сопровождении.
Не начинайте отдельную разработку, если расписание обновляется вручную, клиника не умеет разбирать дубли пациентов, никто не отвечает за ошибочную привязку документа, а поддержка узнаёт о сбоях из жалоб. Приложение поверх такого процесса не лечит его. Оно делает рассинхронизацию видимой пациенту и добавляет ещё один канал инцидента.
Устанавливаемый продукт стоит проверять, когда путь повторяется: регулярные визиты, подготовка к процедурам, документы, планы наблюдения, безопасные уведомления и следующий шаг после приёма. Это продуктовая гипотеза, а не обещание роста лояльности. До инвестиций полезно сравнить завершённые самостоятельные записи, обращения в поддержку, ошибки синхронизации и возвраты пользователей в существующем канале.
Запись, кабинет, телемедицина и медсистема — четыре разных контура
Фраза «медицинское приложение под ключ» скрывает четыре продукта. Запись работает со слотами, филиалами, специалистами и статусами визита. Личный кабинет добавляет идентификацию, историю, документы, представителей и удаление профиля. Телемедицина затрагивает дистанционное взаимодействие медицинского работника и пациента, идентификацию и документирование. Медицинская система поддерживает клинические процессы и может влиять на медицинские решения.
Расширение нельзя считать ещё одной вкладкой. Например, кнопка «связаться с поддержкой» и медицинская консультация по видео выглядят похоже, но имеют разную ответственность. Так же показ готового документа отличается от алгоритма, который оценивает риск, предлагает диагноз или рассчитывает дозировку.
Российский закон №323-ФЗ связывает телемедицинские технологии с дистанционным взаимодействием медицинских работников либо работника и пациента, а действующий порядок установлен приказом Минздрава №193н. Статья 38 закона №323-ФЗ допускает, что программное обеспечение с медицинским назначением может быть медицинским изделием. Но ни наличие видеосвязи, ни слово «клиника» не дают автоматического ответа. Назначение, функции, алгоритмы и маркетинговые утверждения конкретного продукта должен оценить профильный специалист до разработки и подачи в магазины.
Роли и карта данных: кому действительно нужен доступ
У роли должно быть не название, а разрешённое действие. Пациент видит собственную запись. Врач открывает данные назначенного пациента в пределах рабочего сценария. Администратор управляет расписанием, но не читает медицинское содержание «на всякий случай». Оператор поддержки восстанавливает административный путь по техническому идентификатору. IT расследует сбой по журналу, а не выгружает документы.
Отдельно проектируют доступ представителя или родственника. Семейный аккаунт нельзя строить на совпавшей фамилии или общем телефоне. Нужны основание полномочий, срок действия связи, понятный отзыв и проверка того, какой документ разрешено показать конкретному человеку.
Паспорт пациентского сценария
Действие.
Запись, перенос, оплата, документ или результат.
Роли.
Кто создаёт, читает, меняет и подтверждает.
Источник истины.
МИС, ЛИС, CRM или платёжная система.
Минимальные данные.
Поля, без которых действие не работает.
Основание.
Что подтверждают юрист и медицинская организация.
Ошибка.
Сбой обмена, дубль, чужая запись, неверный адресат.
Безопасное состояние.
Что увидит пациент и что сохранит сервер.
Проверка.
Журнал, отрицательный тест и владелец риска.
Пришлите такую матрицу команде, которая оценивает проект. Если в ответ обсуждают только количество экранов, оценка ещё не опирается на реальный объём. На техническом разборе 13FOX может заполнить паспорт для одного пути и показать, где административная функция начинает затрагивать медицинские данные.
152-ФЗ, врачебная тайна, согласия и хранение
Закон №152-ФЗ относит сведения о здоровье к специальным категориям персональных данных и требует конкретных целей, соразмерного состава данных и мер защиты. Закон №323-ФЗ отдельно охраняет врачебную тайну: факт обращения, состояние здоровья, диагноз и сведения обследования или лечения. Выполнение одного режима не означает автоматического выполнения другого.
Для проекта нужна таблица «цель → поле → основание → получатель → срок → удаление». Запись на приём не оправдывает передачу диагноза в продуктовую аналитику. Диагностика сбоя не требует текста документа в журнале. Push-сервису обычно не нужно знать, какой анализ готов. Клиника, разработчик, облако, лаборатория и сервис аналитики могут иметь разные роли и обязательства — их фиксируют в документах и архитектуре.
Согласие должно соответствовать конкретной цели, но один экран с галочкой не заменяет анализ правовых оснований. Также нельзя свести локализацию к лозунгу «всё только в России»: часть 5 статьи 18 закона №152-ФЗ задаёт требования к базам при сборе данных граждан РФ, а трансграничная передача регулируется отдельно. Проверять нужно основную базу, резервные копии, журналы, push, почту, аналитику, видеосвязь и аварийные отчёты.
Юридическая оговорка: эта статья помогает собрать вопросы, но не определяет правовое основание, уровень защищённости ИСПДн, статус медицинского изделия или допустимость конкретной телемедицинской функции. Выводы подтверждают профильный юрист и специалист по безопасности применительно к клинике и архитектуре.
МИС, ЛИС, оплата и CRM: один статус — один владелец
Представьте: два пациента одновременно выбрали последний слот. Приложение показало обоим свободное время, потому что раз в несколько минут копирует расписание. Правильный путь запрашивает доступность у сервера, а сервер резервирует слот в системе, которая владеет расписанием. При повторном запросе он не создаёт дубль и возвращает понятный итог.
МИС обычно отвечает за пациента, расписание и визит; ЛИС — за лабораторный результат; платёжный сервис — за подтверждённую транзакцию; CRM — за разрешённые коммуникации и административную работу. Это не универсальная схема: в конкретной клинике границы могут отличаться. Важно назначить источник каждого объекта, направление записи и безопасное поведение при недоступности.
Документ лучше получать по защищённой ссылке или через сервер после проверки полномочий, а не разносить копии по мобильному клиенту, CRM, аналитике и службе поддержки. Оплату связывают с внутренним номером заказа или услуги; клиентский экран «успешно» не заменяет серверного подтверждения. В журналах хранят технические события и идентификаторы, достаточные для расследования, без лишнего медицинского содержания.
Модель угроз простым языком
Модель угроз — не список страшных слов, а рабочая цепочка: ценный объект, возможный нарушитель, точка входа, нежелательное событие, последствие, защита, способ проверки и ответственный. Например: документ пациента → пользователь с другой учётной записью → прямой адрес файла → чужой просмотр → инцидент и потеря доверия → проверка права на каждый запрос → отрицательный тест и запись в журнале → владелец серверного контура.
Обязательные сценарии: потерянный телефон; перебор идентификаторов; сотрудник сохранил доступ после смены роли; тестовые данные попали в рабочую среду; сторонний SDK получил документ или голос; повтор запроса создал вторую запись или оплату; резервная копия пережила удаление профиля; журнал не отвечает, кто открыл результат.
Защита начинается до кода: минимальные права, разделение сред, короткие сессии по риску, повторная проверка перед чувствительным действием, шифрование транспорта и хранения, управление ключами, инвентаризация SDK, контроль административных действий и процесс инцидента. Статья 21 закона №152-ФЗ предусматривает сроки уведомления Роскомнадзора при определённых инцидентах — поэтому канал эскалации и владелец решения нужны не после первой утечки.
Безопасное уведомление ничего лишнего не рассказывает
Самая безобидная функция часто оказывается самой публичной. Экран заблокированного телефона видят коллеги, родственники или случайный человек. Сообщение «результат анализа на … готов» раскрывает больше, чем нужно для возвращения в защищённый кабинет.
Безопасный вариант сообщает о новом событии нейтрально: «В приложении клиники появилось обновление». После нажатия глубокая ссылка открывает нужный раздел только после проверки действующей сессии и прав. Настройки позволяют отключить категории уведомлений, а CRM не использует медицинское событие как рекламный сегмент без отдельно проверенного основания.
Проверяют не только текст: неправильный токен получателя, старое устройство, семейный аккаунт, превью вложения, журнал push-провайдера и повторную доставку. Успешная отправка сервисом ещё не означает безопасное и понятное получение пациентом.
Apple, Google Play, конфиденциальность и удаление аккаунта
Apple требует политику конфиденциальности, раскрытие практик сбора данных, учёт сторонних SDK и доступное удаление аккаунта внутри приложения. Медицинские функции, способные повлиять на диагностику или лечение, проверяются строже; заявления о точности должны иметь доказательства. Для проверки приложения с входом нужен рабочий демонстрационный аккаунт и доступный сервер — без данных реального пациента.
Google Play требует декларацию health-функций, раздел Data safety, публичную политику и раскрытие чувствительного сбора до запроса разрешения. Разработчик отвечает и за поведение встроенных библиотек. Для приложения с созданием аккаунта нужен путь удаления внутри приложения и отдельный веб-ресурс для запроса.
Удаление аккаунта не всегда равно уничтожению медицинской карты. Часть документации может храниться на отдельном законном основании. Поэтому интерфейс разделяет профиль приложения, токены, маркетинговые данные, технические идентификаторы и медицинскую документацию, а пользователь видит, что будет удалено, что сохранится и почему. Реализацию сверяют с действующим правом и актуальными правилами магазинов перед каждой подачей.
Доступность — часть безопасности, а не косметика
Пациент может быть старше, плохо видеть, пользоваться экранным диктором, держать телефон одной рукой или читать инструкцию в тревожной ситуации. Мелкий серый текст, код только цветом и короткий таймер входа превращают обычную запись в звонок оператору. Хуже, если человек случайно подтверждает не тот филиал или не понимает статус документа.
В MVP закладывают масштабирование текста, достаточный контраст, крупные зоны нажатия, видимый фокус, подписи элементов для экранного диктора, понятные ошибки и отсутствие критической информации только в цвете. Сценарий проверяют с увеличенным шрифтом, клавиатурой и ассистивными технологиями на реальных устройствах.
Простой язык не означает снисходительность. «Запись не создана: слот уже занят, выберите другое время» полезнее технического кода ошибки. Перед окончательным подтверждением показывают врача, услугу, филиал, дату и время, а после — однозначный статус и следующий шаг.
MVP, пилот и релизные ворота
Первая версия должна доказать один сквозной путь, а не вместить весь список желаний. Практичный состав: безопасный вход; получение слотов из МИС; запись, перенос и отмена; статус визита; нейтральные уведомления; поддержка; ограниченный документный сценарий, только если клиника готова к проверке личности, прав и хранения.
Телемедицину, клинические рекомендации, семейные профили, сложную лояльность и AI-анализ разумно выносить в отдельные решения. Каждый такой контур меняет модель данных и проверки. Пилот проводят на ограниченном процессе с синтетическими тестовыми данными, владельцами инцидентов и возможностью безопасно остановить функцию.
До выхода должны пройти проверки P0: чужой документ не открывается; роль не повышается; запись не дублируется; сбой МИС не превращается в ложное подтверждение; уведомление не раскрывает содержание; восстановление аккаунта не привязывает чужого пациента; удаление и хранение работают по утверждённому правилу. Затем проверяют плохую сеть, разные устройства, доступность, аналитику без лишних данных и полный повторный прогон критического пути.
Подробную общую процедуру можно продолжить в материале о проверке качества перед релизом, а назначение разных QA-контуров — в обзоре видов тестирования приложений. Здесь важна медицинская надстройка: отрицательные проверки доступа, безопасные уведомления, поведение интеграций и доказуемый журнал.
Честная граница опыта 13FOX: Psyheya и PsyAI — не clinic-case
В открытом портфолио 13FOX нет подтверждённого приложения клиники, и похожий интерфейс нельзя выдавать за медицинский кейс. Psyheya и PsyAI показывают ограниченно релевантный опыт: мобильные сценарии с персональным контекстом, заметками, голосом и обработкой ИИ. Это не медицинские информационные системы, не телемедицинские платформы, не клиническое доказательство и не подтверждение безопасности медицинских данных.
Полезный перенос — не готовые экраны, а проектные вопросы: какой контекст действительно нужен, куда уходят текст и голос, кто может читать и удалять историю, что получает внешний поставщик ИИ, как ведёт себя приложение при повторной отправке. Для клиники к ним добавляются МИС, врачебная тайна, правовые основания, роли и проверяемая модель угроз.
Поэтому доказательством перед оценкой служат рабочие артефакты: карта пути пациента, матрица ролей и данных, схема потоков, интеграционные контракты, модель угроз и список релизных блокеров. В портфолио 13FOX можно проверить опубликованные проекты и границы заявленного опыта, а не полагаться на неподтверждённую отраслевую историю.
Официальные источники и границы применимости
Источники проверены 30 июля 2026 года. Платформенные правила меняются, а нормативные требования зависят от архитектуры, ролей и функций. Перед проектным решением сверяйте действующие редакции и применимость с профильными специалистами.
- Федеральный закон №152-ФЗ «О персональных данных» — цели, специальные категории, согласия, локализация и меры защиты.
- Федеральный закон №323-ФЗ — врачебная тайна, телемедицина, информация пациента и медицинские изделия.
- Приказ Минздрава России №193н — порядок применения телемедицинских технологий.
- Постановление Правительства РФ №1119 и приказ ФСТЭК №21 — требования и меры защиты ИСПДн.
- Apple App Review Guidelines и App Privacy Details.
- Google Play Health Content and Services Policy, Data safety и account deletion.
FAQ
Чем приложение клиники отличается от медицинской информационной системы?
Приложение клиники обычно служит пациентским интерфейсом: помогает записаться, перенести визит, получить нейтральное уведомление или открыть разрешённый документ. МИС управляет медицинским и операционным контуром клиники. Приложение не должно создавать параллельную версию расписания, пациента или документа: источник истины и правила обмена фиксируют до разработки.
Когда клинике не нужно отдельное мобильное приложение?
Если пациент обращается редко, основной путь заканчивается одной записью, а мобильный сайт или кабинет поставщика МИС уже решает задачу, отдельная установка может не окупить усилия. Сначала стоит наладить актуальное расписание, уведомления и поддержку. Приложение поверх нестабильных процессов лишь добавит ещё один интерфейс ошибки.
Можно ли показывать результаты анализов в приложении?
Технически можно, но конкретный сценарий требует проверки личности, полномочий пациента или представителя, источника документа, правил доступа, хранения, журналирования и правового основания. Безопаснее получать документ из утверждённого контура и не копировать его во все сервисы. Решение должен проверить профильный юрист и специалист по информационной безопасности.
Является ли приложение клиники медицинским изделием?
Не обязательно. Статус зависит не от названия, а от назначения, функций, алгоритмов и заявлений: влияет ли программа на диагностику, лечение, дозировки, прогноз или клиническое решение. Запись и административный кабинет сами по себе не дают универсального ответа. Границу конкретного продукта нужно подтвердить у профильного регуляторного специалиста.
Что входит в безопасный MVP приложения клиники?
Разумная первая версия закрывает один повторяющийся путь: вход, получение актуальных слотов из МИС, запись или перенос, понятный статус, нейтральное уведомление и ограниченный документный сценарий при готовности клиники. До пилота нужны матрица ролей и данных, схема интеграций, модель угроз, журналирование, правила поддержки и отраслевые релизные проверки.
Удаление аккаунта означает удаление всей медицинской карты?
Не всегда. Apple и Google требуют доступного пути удаления аккаунта и связанных данных, но часть медицинской документации может храниться по отдельным законным основаниям. Поэтому нужно разделить профиль приложения, технические идентификаторы, маркетинговые данные и медицинскую документацию, а пользователю ясно объяснить, что удаляется, что сохраняется и почему.
Соберём границы безопасного MVP до сметы
Приходите с одним пациентским путём, перечнем ролей, текущей МИС, лабораторией, оплатой, документами и уведомлениями. На техническом разборе 13FOX составит начальную role/data map, схему движения данных, список интеграций, угроз и вопросов для профильного юриста и ответственного за безопасность. На выходе останется проектная карта для решения о MVP и оценке — не медицинское или юридическое заключение. Если задачу надёжнее закрывает мобильный сайт или готовый кабинет МИС, скажем об этом до большой разработки.