Медицинская информационная система — центр данных клиники и одновременно самая закрытая её часть. Расписание, карточки пациентов, услуги, оплаты и вся медицинская история лежат в ней, а телефонии, сайту, CRM и бухгалтерии из этого нужен небольшой, но постоянно обновляемый срез. Способов получить этот срез существует три, и выбор между ними определяет не бюджет клиники, а то, что готов отдать вендор МИС.
Разница в цене между способами — от 90 000 ₽ до 420 000 ₽ на одном и том же объёме данных, и объясняется она не сложностью задачи, а тем, сколько работы приходится делать в обход системы. Поэтому единственный документ, с которого начинается такой проект, — письменный ответ вендора о наличии программного интерфейса и его документации. Получить его надо до подписания договора с подрядчиком, а лучше — до покупки самой МИС.
Ниже — что именно нужно вытаскивать наружу, три способа это сделать с ценами и сроками, четыре типовые связки с эффектом в рублях, техническая сторона передачи сведений в ЕГИСЗ и разбор ситуации, когда обмена у системы нет вовсе. Сквозной пример тот же, что в остальных статьях кластера: клиника на восемь врачей, 1 400 записей и 1 250 входящих звонков в месяц.
Что лежит в МИС и что из этого нужно наружу
Полезно с самого начала разделить содержимое системы на две неравные части. Смежным системам нужна административная часть — она небольшая и меняется постоянно. Медицинская часть наружу не нужна почти никогда, и попытка её туда вывести создаёт риск, несопоставимый с пользой.
| Данные в МИС | Кому нужны наружу | Что именно передаётся | Пересекает границу контура |
|---|---|---|---|
| Расписание и свободные слоты | Сайт, бот, колл-центр | Врач, кабинет, время, длительность, признак «свободен» | Да |
| Карточка пациента | Телефония, CRM | Идентификатор, имя, телефон — без диагнозов и без специальности врача | Да, в минимальном объёме |
| Услуги и прайс | Сайт, CRM, касса | Код услуги, название, цена, длительность | Да |
| Оплаты и реестры | Бухгалтерия, касса, страховые | Сумма, дата, способ оплаты, номер реестра | Да |
| Статус визита | Все смежные системы | Записан, подтверждён, состоялся, неявка, отменён | Да |
| Жалобы, осмотр, диагноз, назначения, протоколы, результаты | Никому за пределами клиники | Ничего | Нет |
Последняя строка — не формальность и не осторожность юриста. Сведения о здоровье относятся к специальной категории персональных данных, а врачебной тайной является даже сам факт обращения к врачу определённой специальности. Отсюда следует конкретное инженерное правило: через границу проходят идентификатор, время и статус, но не содержание. Как это разделение устроено на уровне контуров и почему оно дешевле любых организационных мер, разобрано в статье про данные о здоровье как специальную категорию. Формулировки согласий, состав модели угроз и сроки хранения — вопрос к юристу и к специалисту по защите информации; наша зона ответственности заканчивается на архитектуре обмена.
Карта связей. В центре прямоугольник «МИС» с двумя внутренними зонами: «административная часть» (расписание, карточка, услуги, оплаты, статус) и заштрихованная «медицинская часть» (диагноз, назначения, протоколы). Наружу от административной зоны отходят четыре стрелки к узлам «Телефония» (подпись: номер → пациент и ближайшая запись), «Сайт и бот» (свободные слоты, создание записи), «CRM» (обращение, источник, воронка), «Бухгалтерия и касса» (реестр услуг, оплаты). Отдельная вертикальная стрелка вверх к узлу «РЭМД / ЕГИСЗ» с подписью «СЭМД, подписанный УКЭП». От заштрихованной зоны стрелок нет, рядом подпись «границу не пересекает». Чертёжный стиль, подписи по-русски.
Три способа обмена и цена каждого
Способы отличаются не качеством, а тем, что именно вендор МИС готов открыть. Первый требует его согласия и документации, второй — только доступа на чтение, третий строится тогда, когда первых двух не хватает или когда систем-потребителей больше двух.
| Способ | Что это технически | Срок | Разово | Поддержка | Главное ограничение |
|---|---|---|---|---|---|
| Документированный API вендора | Прямые вызовы методов: чтение слотов, создание записи, чтение статуса визита | 3–6 недель | 140 000–300 000 ₽ | 8 000–15 000 ₽/мес | Работает только в пределах методов, которые вендор реализовал; недостающий метод — его платная доработка |
| Регулярная выгрузка на чтение | Файл по расписанию или доступ к реплике базы только на чтение | 2–4 недели | 90 000–180 000 ₽ | 6 000–12 000 ₽/мес | Только чтение и задержка от 15 минут до суток; записать данные обратно в МИС нечем |
| Промежуточный слой | Свой обменный контур: очередь заданий, журнал операций, сверка и повтор при сбое | 5–8 недель | 220 000–420 000 ₽ | 15 000–22 000 ₽/мес | Дороже на старте и всё равно требует источника — API или реплики; сам по себе данные не добывает |
Практический критерий выбора простой. Одна система-потребитель и живой API — берите прямой обмен, это дешевле и быстрее всего. Нужно только читать (карточка звонящего, отчёт по загрузке, выгрузка в бухгалтерию) — хватит регулярной выгрузки, и это самый недооценённый вариант: он закрывает больше половины реальных задач за половину денег. Промежуточный слой оправдан, когда потребителей три и больше или когда МИС планируют менять: тогда переезд стоит переписывания одного адаптера, а не всех связок разом. Общая логика выбора между «связать напрямую» и «строить слой» — в статье про то, сколько стоит связать две системы.
Когда вендор не даёт ни API, ни реплики, подрядчики предлагают программного робота, кликающего по экранам МИС. Работает это до первого обновления интерфейса, а работает робот под учётной записью живого сотрудника — то есть под чужими правами доступа и без отдельного журнала. В медицинской системе это плохой обмен: следующее обновление вендора остановит его в рабочий день, а разбирательство, кто внёс изменение в карту, упрётся в общую учётную запись. Границу между RPA и интеграцией по API мы разбирали отдельно; для МИС ответ смещён в сторону API сильнее, чем для любой другой системы.
Сравнение в три колонки. «Документированный API»: 3–6 недель, 140 000–300 000 ₽, 8 000–15 000 ₽/мес, пометка «чтение и запись, нужен живой API вендора». «Регулярная выгрузка на чтение»: 2–4 недели, 90 000–180 000 ₽, 6 000–12 000 ₽/мес, пометка «только чтение, задержка до суток». «Промежуточный слой»: 5–8 недель, 220 000–420 000 ₽, 15 000–22 000 ₽/мес, пометка «от трёх потребителей или при планах сменить МИС». Под колонками общая полоса: «первый документ проекта — письменный ответ вендора про API и его документацию». Чертёжный стиль, подписи по-русски.
Четыре типовые связки и что они дают
Связок, которые действительно нужны частной клинике, четыре. Ниже — что в каждой передаётся и какой эффект она даёт на потоке 1 400 записей и 1 250 звонков в месяц.
| Связка | Что передаётся | Что даёт | Разово |
|---|---|---|---|
| МИС ↔ телефония | Номер звонящего → карточка пациента и его ближайшая запись; исход звонка → карточка обращения | Экономия 40 секунд на звонке: 1 250 звонков — это 13,9 часа, или 7 381 ₽ в месяц. Главное не деньги, а то, что обращение перестаёт теряться | 150 000 ₽ |
| МИС ↔ сайт и бот | Свободные слоты наружу, новая запись внутрь, отмена и перенос в обе стороны | Канал записи, не порождающий ручного переноса слотов администратором | 130 000 ₽ |
| МИС ↔ CRM | Первичное обращение, метка источника, движение по воронке «обращение → запись → визит → оплата» | При рекламном бюджете 120 000 ₽ и 96 записях с него одна запись стоит 1 250 ₽ при марже слота 1 400 ₽. Без связки этот вывод недоступен вообще | 90 000–160 000 ₽ |
| МИС ↔ бухгалтерия и касса | Реестр оказанных услуг, оплаты, реестры по договорам ДМС | Закрытие месяца без ручной сверки реестра с кассой; корректная выручка по услугам, а не по кассовым сменам | 80 000–140 000 ₽ |
Обратите внимание на первую строку. Экономия 7 381 ₽ в месяц не окупает связку за 150 000 ₽ никогда — окупаемость выходит за двадцать месяцев, и продавать её как экономию времени нечестно. Покупают эту связку ради другого: без неё звонок не превращается в карточку обращения, а значит, невозможно ни посчитать пропущенные, ни автоматически перезвонить. Именно это даёт 81 200 ₽ маржи в месяц в расчёте по работе регистратуры, и именно так связку и надо обосновывать.
Вторая строка подробно разобрана в статье про онлайн-запись к врачу — там же сравнение готового модуля отраслевого сервиса с собственной формой. Здесь важно одно требование: слот должен создаваться прямо в расписании МИС, а не в отдельной очереди на стороне сайта. Запись, которая живёт вне расписания, стоит клинике 23 часов ручного переноса в месяц и ломает всё, что построено поверх расписания, — от напоминаний до отчёта по загрузке.
Четвёртая связка выглядит скучной и потому откладывается дольше всех, а обходится клинике дороже, чем кажется. Пока реестр оказанных услуг переносится в учётную систему руками, закрытие месяца упирается в сверку кассовых смен с реестром — это два-три рабочих дня главного бухгалтера и постоянный спор о том, какая выручка правильная. Отдельная история — договоры добровольного медицинского страхования: реестр для страховой собирается по её правилам, ошибка возвращается через месяц отказом в оплате, и восстанавливать обстоятельства приёма приходится задним числом. Практический признак, что связку пора делать, простой: если в клинике живут две цифры выручки за один и тот же месяц и у каждой есть свой защитник, обмен нужен не ради экономии часов, а ради того, чтобы цифра стала одна.
ЕГИСЗ со стороны техники: как убедиться, что документы уходят
Сведения из частной клиники попадают в государственную систему не напрямую, а через МИС: система формирует структурированный электронный медицинский документ, он подписывается усиленной квалифицированной подписью врача и медицинской организации и уходит в реестр электронных медицинских документов в составе ЕГИСЗ. Для этого нужны подключение к защищённой сети передачи данных, действующие сертификаты подписи и корректно заполненные обязательные поля в карте пациента.
Состав передаваемых сведений, сроки, порядок подключения и ответственность клиники — это регуляторный вопрос, и решает его юрист вместе с ответственным за медицинскую часть. Обязанности частной клиники разбираются в отдельном материале журнала. Инженерная зона узкая и конкретная: сделать так, чтобы выгрузка не молчала, чтобы её отказ был виден в тот же день, а не через квартал, и чтобы каждый неотправленный документ имел причину в журнале.
Проверять выгрузку отчётом вендора бессмысленно: он показывает то, что система отправила, а не то, что было принято. Рабочая проверка — сверка двух чисел из разных источников. Ниже месяц модельной клиники.
Разбирать эти 116 надо по трём группам, и они очень разные по опасности. 66 документов отправлены, но не зарегистрированы — это обычные ошибки валидации: не заполнен обязательный идентификатор пациента, некорректный код услуги, просроченный сертификат подписи. Они видны в журнале и чинятся регламентом заполнения. 22 сформированы, но не подписаны — чаще всего врач не подписал документ до конца смены, и это вопрос дисциплины, а не техники. Самая опасная группа — 28 визитов, по которым документ не сформирован вообще: их нет ни в одном журнале ошибок, потому что ошибки не произошло, объекта просто не существует. Найти эту группу можно единственным способом — сверкой с числом состоявшихся визитов.
Практический вывод: сверку надо ставить на расписание — раз в неделю выгружать четыре числа и сравнивать с числом визитов, а расхождение больше 2 % превращать в задачу с ответственным. Это тот же принцип, что и в любой другой интеграции: проверять, что обмен работает, надо встречным счётом на стороне-получателе, а не логом на стороне-отправителе.
Горизонтальная схема из пяти блоков со стрелками: «Визит состоялся — 1 218» → «Документ сформирован — 1 190» → «Подписан УКЭП — 1 168» → «Отправлен по защищённому каналу» → «Зарегистрирован, квитанция — 1 102». Под каждым переходом вынесены потери с подписями: «−28 не сформирован: не виден в журнале ошибок», «−22 не подписан врачом», «−66 отклонён валидацией». Справа врезка «Правило: расхождение первого и последнего числа больше 2 % — задача с ответственным». Чертёжный стиль, подписи по-русски.
Пять вопросов вендору МИС до подписания договора
Эти вопросы стоят дешевле любой интеграции и задаются письмом. Ответ «да, конечно, у нас всё есть» ответом не является — нужны документы и доступы.
- 1Есть ли документированный программный интерфейс и можно ли получить документацию до покупки? Не «планируется» и не «по запросу после оплаты» — файл или ссылка сейчас. Отсутствие документации почти всегда означает, что интерфейс есть, но нестабильный.
- 2Кто платит за доработку, если нужного метода нет, и в какой срок она делается? Здесь важен не тариф, а срок и обязательность. Формулировка «включим в план развития продукта» означает «никогда».
- 3Что происходит с нашими доработками и обменами при обновлении версии? Самый дорогой вопрос из пяти. Нужны письменные гарантии обратной совместимости интерфейса и порядок уведомления о его изменениях хотя бы за месяц.
- 4Кому принадлежат данные и в каком формате мы можем выгрузить всё? Ответ должен быть в договоре, а не в переписке, и относиться он должен не только к базе, но и к доработкам, которые вендор делает за ваши деньги: право пользоваться ими после расторжения — отдельный пункт, а не подразумеваемое следствие оплаты.
- 5Есть ли тестовый контур и как получить к нему доступ? Без тестовой базы любая доработка проверяется на живых пациентах. Для медицинской системы это неприемлемо, и отсутствие тестового контура — сам по себе повод посмотреть на другого вендора.
Что делать, если обмена у МИС нет
Ситуация встречается регулярно, особенно у систем, установленных пять и более лет назад. Вариантов два, и оба дорогие. Ниже — честное сравнение на горизонте двух лет для нашей клиники на восемь врачей.
| Статья расходов | Смена МИС на систему с API | Промежуточный слой поверх закрытой МИС |
|---|---|---|
| Разовые работы | Миграция данных 180 000 ₽, настройка и обучение 120 000 ₽ | Слой обмена с журналом и сверкой — 300 000 ₽ |
| Переходный месяц: двойной ввод, сверхурочные | 60 000 ₽ | 0 ₽ |
| Связки поверх (телефония, сайт, CRM) | 160 000 ₽ по API новой системы | Входят в слой |
| Разница в лицензиях за 24 месяца | 57 600 ₽ (15 200 ₽ против 12 800 ₽ в месяц) | 0 ₽ |
| Поддержка обмена за 24 месяца | 288 000 ₽ (12 000 ₽ в месяц) | 432 000 ₽ (18 000 ₽ в месяц) |
| Итого за два года | 865 600 ₽ | 732 000 ₽ |
На двух годах слой дешевле на 133 600 ₽, и к деньгам добавляется важное нефинансовое преимущество: он не трогает лечебный процесс. Смена МИС — это переобучение всех врачей и администраторов, месяц двойного ввода и риск потерять часть истории при миграции; в клинике, где расписание не должно останавливаться ни на день, это отдельный проект с отдельными рисками.
Но у сравнения есть продолжение, о котором подрядчику выгодно молчать. После второго года смена МИС стоит 14 400 ₽ в месяц (поддержка обмена плюс разница лицензий), а слой — 18 000 ₽. Разница 3 600 ₽ в месяц закрывает разрыв в 133 600 ₽ за 37 месяцев, то есть примерно на пятом году владения смена системы становится дешевле. Отсюда практическое правило: слой оправдан, если МИС вас в целом устраивает и вы планируете её оставить. Если система и так вызывает вопросы у врачей, слой — это способ дорого продлить жизнь тому, что вы всё равно поменяете.
Двухосевой график накопленных расходов за 60 месяцев. Оси: месяцы и рубли. Сплошная линия «Промежуточный слой»: старт 300 000 ₽, наклон 18 000 ₽/мес, на 24-м месяце 732 000 ₽. Штриховая линия «Смена МИС»: старт 520 000 ₽, наклон 14 400 ₽/мес, на 24-м месяце 865 600 ₽. Точка пересечения около 61-го месяца выделена и подписана «примерно пятый год владения». Вертикальная пунктирная отметка на 24-м месяце с подписью «разница 133 600 ₽ в пользу слоя». Чертёжный стиль, подписи по-русски.
Что ломается при обновлении МИС и как это пережить
Обновление медицинской системы — плановое событие, которое ломает обмен чаще, чем что-либо ещё. Ломается обычно не сам вызов метода, а мелочи: изменился формат идентификатора, добавилось обязательное поле, поменялся справочник статусов визита. Симптом одинаковый — обмен молчит, а клиника узнаёт об этом от пациента, который не получил напоминание.
- Держите справочники на своей стороне. Коды услуг, статусы визита и специальности врачей должны сопоставляться таблицей соответствия в вашем контуре, а не быть зашиты в код. Изменение справочника у вендора тогда чинится правкой строки, а не релизом.
- Заведите встречный счётчик. Ежедневная проверка «сколько записей создано за сутки» и «сколько напоминаний отправлено» на стороне-получателе. Ноль вместо обычных сорока — сигнал раньше, чем звонок пациента.
- Требуйте уведомление об обновлении заранее. Месяц — разумный срок для проверки обмена на тестовом контуре. Если вендор обновляет продуктив без предупреждения, это надо закладывать в бюджет поддержки, а не в надежду.
- Не растворяйте связку в одном скрипте. Слой с очередью и повтором при сбое переживает получасовую недоступность МИС без потери записей; прямой вызов без очереди в такой ситуации теряет их молча.
Когда обмен строить не надо
Три ситуации, в которых деньги на интеграцию тратить рано, и одна, в которой это прямая ошибка.
- Клиника на 2–3 врача. Ручной перенос десятка записей в день дешевле любой связки, а поддержка обмена съест весь эффект. Разумнее взять отраслевой сервис записи с встроенным расписанием и вернуться к вопросу при росте.
- Расписание ведётся не в МИС. Пока смены и слоты живут в отдельной таблице, связывать нечего: обмен с системой, где нет источника правды, просто перенесёт беспорядок в другое место. Сначала одно расписание, потом обмен.
- Потребитель ровно один и ему нужно только читать. Тогда это не интеграция, а выгрузка по расписанию за 90 000–180 000 ₽. Слой за 300 000 ₽ здесь продают тем, кто не спросил про разницу.
- Наружу просят вывести медицинскую часть. Диагнозы и назначения в CRM, расшифровку приёма во внешний сервис, содержательный текст в маркетинговый сегмент — это не задача обмена, а перенос специальной категории данных за границу контура. Здесь правильный ответ — отказ и разговор о том, какая метрика на самом деле нужна.
Во всех остальных случаях порядок один: сначала письменный ответ вендора про интерфейс, потом выбор способа под число потребителей, потом связки по одной с проверкой встречным счётом. Порядок здесь важнее полноты: связка с телефонией, сделанная первой, окупается медленно, но без неё две следующие теряют половину смысла, а связка с бухгалтерией, сделанная первой, не даёт вообще ничего, пока статус визита в МИС не проставляется дисциплинированно.
