CRM для клиники и МИС: что выбрать под 152-ФЗ

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

CRM управляет отношениями с клиентом. Она знает, откуда человек пришёл, кто ему звонил, что предложили, записался ли он, дошёл ли до приёма и вернулся ли потом. Внутрь кабинета CRM не заглядывает — и не должна: диагноз и план лечения не её зона ответственности.

МИС ведёт лечебный процесс. Это медицинская карта с анамнезом и назначениями, расписание врачей и кабинетов, специализированные формы приёма, роли персонала и юридический след: согласия, кто и когда открывал карту, сколько хранятся данные. Здесь система работает со сведениями о здоровье, а это специальная категория персональных данных с более строгими требованиями, чем к обычному контакту с телефоном.

Практический тест занимает одну минуту. Если ваш главный вопрос звучит как «почему пациенты не доходят до приёма и не возвращаются» — вам нужна CRM. Если он звучит как «как врачу вести карту, регистратуре — расписание, и чтобы это было законно» — вам нужна МИС. Если оба вопроса болят одинаково, речь о связке двух систем, а не о выборе одной.

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

CRM в клинике решает задачу потока пациентов: чтобы обращение не потерялось, запись состоялась, а человек вернулся. Это коммерческий и административный контур, и в нём готовая платформа с настройкой обычно окупается быстрее, чем разработка с нуля.

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

Ниже — признаки того, что вы вышли за пределы CRM. Как только два-три пункта из этого списка становятся для вас обязательными, вопрос «CRM или МИС» уже решён, и дальше выбор идёт между готовой медицинской системой и отраслевой разработкой под ваши процессы.

Фраза «наша система соответствует 152-ФЗ» часто продаётся как галочка в презентации. На практике это не наклейка, а набор архитектурных решений, которые видно в базе данных и в коде — и которые либо есть, либо их нет.

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

Разница между косметикой и архитектурой лучше всего видна на изоляции данных между клиниками. Её можно сделать условием в коде приложения: к каждому запросу добавляется фильтр «только моя организация». Работает это ровно до первой ошибки разработчика — один забытый фильтр в одном запросе, и сотрудник одной клиники видит пациентов другой. А можно перенести изоляцию на уровень самой базы данных: в нашей МИС мультитенантность реализована через PostgreSQL RLS — row-level security, то есть правила, по которым СУБД сама отдаёт строки только «своему» арендатору. Тогда даже ошибка в прикладном коде не откроет чужие данные: запрос просто не получит лишних строк.

Тот же принцип работает и с остальными требованиями. Журнал доступа, который система пишет сама при каждом открытии карты, — это архитектура. Файл, куда администратор вручную вносит, кто чем пользовался, — это косметика, которая рассыплется при первой же проверке или при разборе реального инцидента.

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

Что стоит проверить у подрядчика, когда он говорит «у нас всё по 152-ФЗ»:

Мы говорим о медицинских системах не со стороны: у DigitalOffice24 есть собственная МИС. Честно про статус — это MVP, рабочий прототип, который развивается дальше, а не коробочный релиз, который можно завтра поставить в клинику одним кликом.

Чтобы не изобретать предметную область заново, мы начали с разбора зрелого работающего аналога: провели реверс-инжиниринг его базы данных на 1613 таблиц и 1029 роботов, а затем собрали техническое задание воспроизведения на 1619 требований — функциональных и нефункциональных. Эти цифры полезны не сами по себе: они показывают реальный масштаб медицинской предметной области. Она на порядок сложнее, чем «карточка пациента и календарь записи», и именно поэтому попытка собрать МИС на конструкторе обычно заканчивается полумерой.

В MVP собраны ключевые рабочие места по принципу «роль → свой стартовый маршрут»: расписание регистратуры, медкарта врача с зубной формулой и дашборд управляющего. Мультитенантность через PostgreSQL RLS и контур 152-ФЗ — согласия, аудит доступа, сроки хранения персональных данных пациентов — заложены сразу, а не отложены на потом. Это осознанное решение: в медицинской системе именно эти вещи переделываются тяжелее всего, потому что затрагивают каждую таблицу и каждый экран.

Стек — Next.js, TypeScript, Prisma и PostgreSQL в Docker. Это управляемый современный набор, который мы контролируем сами, а не адаптация чужой коробки под задачи, для которых она не проектировалась.

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

Самая частая ошибка при такой связке — тащить медицинские подробности в маркетинговую систему. Если в карточку клиента в CRM начинают дописывать диагнозы и назначения «чтобы было удобнее», вы фактически заводите медицинскую базу в системе, которая под специальную категорию персональных данных не проектировалась: права доступа там устроены под коммерческие процессы, а не под врачебную тайну. В CRM должно оставаться только то, что нужно для записи и коммуникации.

Отдельный слой, полезный в обоих контурах, — приём звонков. Типовые входящие можно снять с администратора: голосовой робот принимает звонок, отвечает на вопросы о графике и услугах, записывает на приём, а сложный или эмоциональный разговор передаёт человеку вместе с контекстом. Записи и расшифровки при этом хранятся на серверах в РФ. Администратор остаётся в контуре — робот забирает у него рутину, а не решения.

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

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

Для такого разбора у нас есть бесплатный экспресс-аудит на 30 минут. Мы смотрим на ваши процессы: сколько врачей и кабинетов, как сейчас ведутся записи и карты, откуда приходят пациенты, какие требования к данным реально применимы к вашему профилю. По итогам говорим прямо — включая вариант «вам достаточно настроить CRM, разработка отраслевой системы сейчас не окупится». Это часть принципа честной оценки: сказать правду важнее, чем продать более крупный проект.

Стоимость называем после аудита, когда понятен объём: число рабочих мест, интеграции, требования к хранению и разграничению доступа. Весь стек при этом идёт одним договором — CRM, отраслевая система и AI-слой поверх них, — поэтому не придётся собирать трёх подрядчиков и разбираться, кто из них отвечает за стык между системами.