Aursoft: Медицинский SaaS для стоматологических клиник

Клиника объединила расписание, лечение, документы и расчеты в одной системе, но не ценой общего доступа ко всем данным. Врачи, регистраторы и кассиры получили только необходимые им действия, параллельная запись на один слот была исключена, обращения к чувствительной карточке попадали в аудит, а напоминания не раскрывали содержание визита.

Паспорт медицинского продукта

• Направление: medical SaaS, CRM, расписание, документы.
• Задача: Собрать ключевые процессы стоматологической клиники в одной системе с понятным разграничением доступа.
• Продолжительность: 9 месяцев на основные модули, миграцию и пилот.
• Команда: PM, медицинский аналитик, архитектор, 4 backend-разработчика, 3 frontend-разработчика, 2 QA, UX, DevOps и security engineer. Всего 15 человек.
• Роль AIFlowPoint: Разработка модулей расписания, карточки пациента, документов и расчетов, ролевой модели, аудита, импорта и уведомлений.

Одна клиника, разные роли и классы данных

Врачи, регистраторы, кассиры и руководители работали с разными частями процесса: записью, лечением, документами и расчетами. В системе одновременно находились медицинские, контактные и финансовые данные, поэтому общий доступ для всех ролей был неприемлем.

Бизнес-задача состояла не просто в консолидации экранов. Система должна была удерживать границы между ролями, не раскрывать медицинскую информацию в маркетинговых коммуникациях и технической телеметрии, сохранять историю изменения плана лечения и показывать, кто обращался к чувствительной карточке. При миграции нельзя было молча загрузить некорректные данные, а резервную копию нельзя было считать рабочей без фактической проверки восстановления.

Объем работ охватил основные модули клиники, перенос данных и пилот. В него вошли расписание, карточка пациента, документы, расчеты, уведомления, отчеты, роли и аудит. Хранение, выгрузку, удаление и восстановление данных связали с утвержденной политикой клиники.

Проектирование от ролей и рисков

Сначала разобрали работу клиники по ролям и оставили каждой роли только необходимые данные и действия. Медицинскую информацию отделили от маркетинговых коммуникаций и финансовых отчетов. Чувствительные поля исключили из технических событий, отправляемых в Sentry. Хранение, выгрузку, удаление и восстановление данных связали с утвержденной политикой клиники.

Этот подход определил интерфейсы и backend одновременно. Регистратору нужен быстрый сценарий записи, но не полный медицинский контекст. Врачу нужна карточка, план лечения и история версий. Кассиру нужны расчеты и закрытие смены с отдельными правами. Руководителю нужны агрегированные отчеты, но не бесконтрольный доступ к каждой записи.

Реализованные процессы

В согласованный контур вошли:

1. Общее расписание врачей, кабинетов и оборудования.
2. Карточка пациента с планом лечения, визитами, исследованиями и историей изменений.
3. Шаблоны согласий, договоров, планов лечения и печатных форм.
4. Напоминания и подтверждение записи без медицинских подробностей в сообщении.
5. Оплата, задолженности, скидки и закрытие смены с раздельными правами.
6. Отчеты по загрузке врачей, повторным обращениям и незавершенным планам.
7. Контролируемый импорт с протоколом ошибок и сверкой итоговых количеств.
8. Аудит просмотра и изменения чувствительных данных.

Путь пациента начинался с записи на свободный слот. Во время подтверждения слот удерживался так, чтобы два параллельных запроса не создали две записи. Напоминание позволяло подтвердить визит, не раскрывая диагноз или содержание приема. Врач видел актуальный план лечения и предыдущие версии. Изменение плана не уничтожало историю, а открытие и редактирование карточки оставляло запись в аудите.

Архитектура, приватность и восстановление

ASP.NET Core обслуживает строгие бизнес-правила и ролевой доступ. React дает быстрый интерфейс расписания и карточки пациента. PostgreSQL хранит связанные медицинские и финансовые записи, Redis удерживает слот во время подтверждения, объектное хранилище используется для исследований и подписанных документов. Sentry сообщает о технических сбоях, но чувствительные поля удаляются до отправки события.

Хранение, выгрузка, удаление и восстановление данных связаны с утвержденной политикой клиники. Резервная копия считается рабочей только после проверки восстановления на отдельном контуре.

Технологический контур проекта: ASP.NET Core, C#, React, TypeScript, PostgreSQL, Redis, S3-совместимое хранилище, OpenAPI, SMTP, SMS API, OAuth 2.0, Role-based access control, Docker, Nginx, Sentry, xUnit и Playwright. Он охватывает роли, данные, уведомления, наблюдаемость и тестирование; юридические требования определяются политиками клиники и применимым регулированием.

Защитный контур проверял доступ к данным по роли, а не только наличие нужного пункта меню. Объектное хранилище использовалось для исследований и подписанных документов. Контролируемый импорт сначала показывал ошибки, затем позволял сверить итоговые количества. Техническая наблюдаемость не должна была превращаться в дополнительный канал утечки чувствительных полей.

Результат и измеримые изменения

Врачи, регистраторы и кассиры работают с расписанием, лечением, документами и расчетами в одной системе, но каждая роль видит только нужную часть данных. Слот защищен от параллельной записи, обращения к чувствительной карточке остаются в аудите, а напоминания не раскрывают содержание визита.

Измеримый результат: Время оформления записи сокращается на 25-40%; доля пропущенных визитов снижается на 10-20%; все обращения к чувствительным данным отражаются в аудите.

Эффект: Клиника объединила расписание, лечение, документы и расчеты, сохранив строгие границы доступа между ролями.

Приемка и проверка результата

Критерии приемки включали позитивные и негативные сценарии:

• Один временной слот нельзя занять двумя параллельными записями.
• Сотрудник не видит данные, которые не нужны ему по роли.
• Изменение плана лечения не уничтожает предыдущую версию.
• Импорт показывает ошибки до окончательной загрузки.
• Напоминание не раскрывает диагноз или содержание визита.
• В аудите видно, кто открывал и менял карточку пациента.

Проверку результата фиксируют dashboard записей и no-show, RBAC-тесты, журнал аудита, протокол миграции и отчет восстановления. Для метрик использовались согласованные определения времени оформления и пропущенного визита, сопоставимые периоды и проверка полноты аудита. Материалы с данными пациентов не публикуются.

Что передали клинике

• SaaS-модули и схема данных.
• Миграции и инструкция импорта.
• Схема ролей и доступов.
• Шаблоны документов.
• Модель угроз и журнал аудита.
• Тесты критических сценариев.
• План восстановления.

Передача охватывала эксплуатационные знания, которые особенно важны для чувствительных данных: правила ролей, порядок импорта, тесты критических сценариев, модель угроз и проверяемый план восстановления.

Кому подходит такой опыт

Кейс релевантен продуктам, где несколько ролей работают с общей сущностью, но имеют разные основания для доступа. Это медицинские и другие чувствительные процессы, в которых объединение данных должно сопровождаться RBAC, аудитом, безопасными уведомлениями, контролируемой миграцией и восстановлением.

Если нужно собрать разрозненные процессы в одном продукте без размывания доступа, начнем с карты ролей, данных и одного безопасного пользовательского пути.