Инфоклиника или IDENT: как выбрать МИС, если история пациентов уже внутри

• Опубликовано: 20 сентября 2026 г.

Выбор новой МИС часто выглядит как конкурс интерфейсов. Один поставщик показывает красивое расписание, другой — дашборд, третий обещает «перенести всё». Но утром после переключения клиника живёт не в презентации. Администратор ищет старый долг, врач открывает план лечения, кассир оформляет возврат, пациент звонит по записи, созданной ещё в прежней системе.

Именно поэтому вопрос «Инфоклиника или IDENT — что лучше?» почти всегда задан слишком рано. Обе системы развиваются, набор модулей и условия меняются, а публичное описание не заменяет договор и тест. Решение зависит от профиля клиники, существующих процессов, интеграций и того, что уже накоплено в базе.

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

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

Начните с причин перехода, которые можно проверить

«Старая МИС неудобная» — ощущение, а не требование. Разложите его на наблюдаемые проблемы:

• запись пациента требует двойного ввода;
• расписание не учитывает кабинет или оборудование;
• врачу трудно найти предыдущий документ;
• интеграция с сайтом создаёт дубли;
• статусы ЕГИСЗ не видны пользователю;
• отчёты нельзя сверить с первичными событиями;
• сеть филиалов работает нестабильно;
• поддержка не даёт трассировку ошибки;
• клиника не может получить полный экспорт;
• обновление мешает работе и не имеет отката.

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

Публичный список функций — только приглашение к тесту

Официальные сайты поставщиков описывают множество возможностей: расписание, медицинскую документацию, аналитику, интеграции, ЕГИСЗ, кассу, коммуникации. Но наличие слова на странице не отвечает на вопросы конкретной клиники:

• входит ли функция в выбранную редакцию и тариф;
• требуется ли отдельный модуль;
• работает ли она в вашей архитектуре;
• какие ограничения есть у мигрированных данных;
• кто внедряет и поддерживает интеграцию;
• что доступно через API или экспорт;
• как функция ведёт себя при ошибке.

Поэтому каждое важное обещание превращайте в строку приёмки: сценарий, тестовые данные, ожидаемый результат, версия продукта, ответственный и доказательство. Более короткая методика такого отбора есть в материале «Как не купить МИС по красивой презентации».

Профиль клиники влияет сильнее, чем красота интерфейса

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

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

Сначала опишите собственную модель. Иначе поставщик покажет сильнейший модуль продукта, а не вашу сложнейшую операцию.

История пациента — не одна таблица

Под словами «перенесём картотеку» могут иметься в виду только ФИО, телефон и дата рождения. Для клиники история шире:

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

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

Сделайте паспорт каждого набора данных

Паспорт не требует копировать содержимое медицинских документов в проектный файл. Он описывает структуру и контроль.

Самая дорогая часть миграции — карта соответствий

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

Карта соответствий содержит:

• исходное значение;
• целевое значение;
• правило преобразования;
• владельца решения;
• неоднозначные случаи;
• поведение при отсутствии аналога;
• тестовый пример;
• дату и версию.

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

Дубли пациентов нельзя «склеить по телефону» автоматически

Телефон меняется, используется семьёй, записан в разных форматах или отсутствует. Совпадение фамилии и даты рождения тоже не всегда достаточно. Автоматическое слияние может соединить истории разных людей — это серьёзнее, чем два дубля.

Разработайте уровни уверенности:

• однозначное техническое соответствие;
• вероятный дубль для ручной проверки;
• конфликт, который запрещено объединять автоматически;
• новая карточка с сохранением ссылки на исходную запись.

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

Электронный документ нельзя переносить как обычный текст

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

Для каждого типа определите:

• переносится оригинальный объект или представление;
• сохраняются автор, дата и версия;
• виден ли статус подписи;
• доступно ли исходное доказательство;
• можно ли редактировать импортированную историю;
• как различается архивная и новая запись;
• сохраняется ли связь с внешним идентификатором.

Юридический и медицинский статус конкретных документов подтверждают профильные специалисты. Миграционный скрипт не должен молча переопределять его.

Изображения и вложения требуют отдельного маршрута

Фотографии, сканы, DICOM-исследования и PDF могут храниться внутри МИС, на файловом сервере, в PACS или у внешнего поставщика. Экспорт базы без файлов оставит ссылки на пустоту. Копирование файлов без индекса создаст склад, в котором ничего не найти.

Для DICOM и PACS полезен отдельный разбор медицинского архива, облака и доступности снимков. В миграции МИС достаточно зафиксировать владельца, идентификатор связи, способ открытия, права и проверку после переключения.

Деньги требуют сверки до копейки, но не обязательно полного переноса операций

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

Сверяйте:

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

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

Расписание — живая система зависимостей

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

Тестируйте:

1. Одиночный визит.
2. Повторный визит.
3. Комплексный приём нескольких специалистов.
4. Ресурсный конфликт кабинета или аппарата.
5. Перенос и отмену.
6. Лист ожидания.
7. Онлайн-запись.
8. Будущие уведомления.
9. Расписание после смены должности или ставки.
10. Запись, созданную в старой системе и завершённую в новой.

Именно последний сценарий часто раскрывает скрытые зависимости.

Интеграции составляют отдельный реестр

Не пишите одной строкой «телефония, сайт, лаборатории». Для каждой интеграции укажите:

• поставщика;
• направление данных;
• источник истины;
• идентификаторы;
• частоту или событие обмена;
• механизм авторизации;
• очередь и повтор;
• журнал ошибок;
• владельца;
• тест;
• поведение при недоступности;
• план переключения.

Сюда входят ЕГИСЗ, лаборатории, PACS, телефония, сайт, агрегаторы, касса, бухгалтерия, SMS, email, BI и платёжные сервисы. Если интеграция не попала в реестр, о ней вспомнят после запуска. Аудит сайта клиники после долгой паузы пригодится как отдельный перечень внешних форм, доменов, аналитики и каналов, которые миграция МИС может незаметно затронуть.

Сравнивайте системы на одном сценарии и одной ошибке

Дайте каждому поставщику одинаковый сценарий на синтетических данных:

Новый пациент записывается через сайт на комплексный приём. Администратор исправляет номер телефона, переносит визит, добавляет ресурс кабинета. Врач создаёт план лечения, прикладывает тестовое изображение и назначает повтор. Пациент вносит частичную оплату. Затем одна интеграция временно недоступна.

Попросите показать:

• обычный путь;
• ошибку;
• исправление;
• аудит действий;
• экспорт результата;
• доступ второй роли;
• отчёт руководителя;
• поведение после восстановления интеграции.

Красивая демонстрация счастливого пути занимает десять минут. Качество системы проявляется в исключении.

Поставщик должен показать не только импорт, но и экспорт

До подписания договора запросите:

• перечень доступных выгрузок;
• формат;
• полноту вложений;
• сохранение идентификаторов и связей;
• ограничения API;
• сроки подготовки полного экспорта;
• стоимость;
• поведение при расторжении;
• способ проверить выгрузку независимо.

Фраза «данные ваши» без рабочего механизма экспорта недостаточна. Клиника должна иметь возможность выйти из системы без ручного переписывания истории.

Не превращайте архив старой МИС в вечный сервер под столом

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

• какие данные остаются;
• кто имеет доступ;
• как аутентифицируются пользователи;
• где работает приложение;
• кто поддерживает ОС и базу;
• как выполняется резервное копирование;
• что делать при отказе;
• когда архив можно вывести из эксплуатации;
• как найти запись из новой МИС;
• кто оплачивает лицензии.

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

Тестовая миграция должна быть повторяемой

Ручной «удачный импорт» одного файла не доказывает готовность. Миграционный конвейер должен повторяться на зафиксированной версии исходных данных и создавать отчёт:

• сколько записей прочитано;
• сколько преобразовано;
• сколько отклонено;
• какие значения не сопоставлены;
• какие связи потеряны;
• сколько дублей найдено;
• сколько файлов отсутствует;
• какие контрольные суммы или иные проверки не совпали;
• сколько времени занял процесс.

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

Синтетические данные — не пять пустых карточек

Хороший тестовый набор содержит сложность реальной клиники, но не реальных пациентов:

• одинаковые фамилии;
• разные форматы телефона;
• ребёнка и представителя;
• врача с несколькими ролями;
• услугу со старым и новым названием;
• отменённый и перенесённый визит;
• частичную оплату и возврат;
• вложение;
• неподдерживаемое значение;
• конфликт идентификаторов;
• закрытый и будущий период.

Набор версионируют. Он становится регрессией для каждого следующего импорта и обновления.

Параллельная работа создаёт раздвоение истины

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

Если параллельный период необходим, задайте правила:

• какая система является источником для каждого типа данных;
• какие операции запрещены в старой;
• как помечается дата отсечения;
• что синхронизируется автоматически;
• кто разбирает конфликт;
• когда прекращается двойная работа.

Двойной ввод допустим только как короткий контролируемый сценарий, а не как страховка на неопределённый срок.

Окно переключения начинается за несколько дней

Cutover-план включает:

• заморозку справочников;
• последнюю тестовую миграцию;
• резерв исходной системы;
• выгрузку изменений после теста;
• финальный импорт;
• сверку ключевых агрегатов;
• запуск интеграций;
• пользовательские тесты;
• решение go/no-go;
• поддержку первой смены;
• откат.

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

Откат — это не «включить старую МИС»

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

Стоп-условия устанавливают до переключения:

• критичный сценарий не проходит;
• расхождение финансов превышает согласованный порог;
• часть будущих записей отсутствует;
• подпись или обязательный обмен недоступны;
• поддержка не может классифицировать ошибку;
• резерв исходной системы не подтверждён.

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

Составной сценарий: все пациенты перенесены, а клиника потеряла планы лечения

Это иллюстративная реконструкция, не описание реальной организации.

Поставщик сообщает: импортировано 98% карточек. Команда радуется высокой цифре. Через несколько дней координаторы обнаруживают: карточки пациентов есть, визиты видны, но этапы долгих планов лечения остались в текстовых вложениях старой системы. Новая МИС не может строить по ним расписание и финансовый прогноз.

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

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

Обучение должно идти по ролям и исключениям

Общий вебинар «вот главное меню» не готовит команду к рабочему дню. Регистратуре нужны запись, перенос, конфликт, оплата и обращение. Врачу — поиск истории, протокол, план, подпись и исправление. Руководителю — проверяемые отчёты и очередь ошибок. IT — роли, журналы, интеграции и восстановление.

Для каждой роли:

• пять основных сценариев;
• три исключения;
• короткая инструкция;
• тест без подсказки;
• канал вопроса;
• критерий допуска;
• повторная проверка через неделю.

Ошибку пользователя не объявляют причиной, пока не проверили качество инструкции и интерфейса.

Первая неделя после запуска — отдельная фаза проекта

Нужна «комната управления», даже если она виртуальная:

• единый журнал проблем;
• классификация влияния;
• дежурные владельцы;
• ежедневная сверка финансов и расписания;
• контроль интеграций;
• список ручных обходов;
• решение по каждому неподдерживаемому случаю;
• обновление инструкций;
• запрет хаотичных доработок.

Поддержка не должна закрывать тикет словом «обучили». Пользовательский сценарий повторяется и подтверждается владельцем процесса.

Метрики перехода, которые трудно подделать

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

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

Красные флаги предложения

• поставщик обещает перенести «всё» без инвентаризации;
• объём оценивается только числом пациентов;
• нет карты соответствий;
• непонятно, что будет с подписями и версиями документов;
• изображения не включены в обследование;
• полный экспорт не демонстрируется;
• тест выполняется на данных пациента без согласованного контура;
• критичные интеграции «подключим после запуска»;
• параллельная работа не имеет даты окончания;
• архив старой системы не имеет поддержки;
• откат описан одной строкой;
• обучение состоит из записи вебинара;
• приёмка считается успешной после входа пользователей;
• коммерческое предложение не разделяет лицензии, внедрение, миграцию и доработки.

Чек-лист до договора

• [ ] Зафиксированы проверяемые причины перехода.
• [ ] Описан профиль клиники и критичные маршруты.
• [ ] Сделан паспорт наборов данных.
• [ ] Определена судьба каждого класса истории.
• [ ] Согласована карта справочников.
• [ ] Описаны правила работы с дублями.
• [ ] Отдельно разобраны документы и подписи.
• [ ] Отдельно разобраны изображения и вложения.
• [ ] Финансовые остатки имеют критерии сверки.
• [ ] Будущее расписание проверяется сценариями.
• [ ] Интеграции внесены в реестр.
• [ ] Оба поставщика показали одинаковый тест.
• [ ] Полный экспорт продемонстрирован.
• [ ] Архивный режим старой системы спроектирован.
• [ ] Миграция повторяема и создаёт отчёт.
• [ ] Есть синтетический регрессионный набор.
• [ ] Cutover и откат описаны.
• [ ] Первая неделя обеспечена поддержкой.
• [ ] Стоимость включает модули, миграцию, интеграции и выход.

FAQ

Что лучше — Инфоклиника или IDENT?

Без профиля клиники и одинакового теста честного универсального ответа нет. IDENT публично ориентирован на стоматологии; линейка Инфоклиники описывает более широкий набор медицинских организаций. Выбор подтверждают конкретными сценариями, модулями, интеграциями и миграцией.

Нужно ли переносить всю историю в рабочую базу?

Не всегда. Активные процессы обычно требуют структурированного переноса, а часть закрытой истории может остаться в защищённом архиве чтения. Решение зависит от типа данных, требований и стоимости поддержки архива.

Как проверить качество миграции?

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

Можно ли мигрировать без остановки клиники?

Часть подготовки и тестов — да. Финальная точка отсечения всё равно требует строгих правил изменений и источника истины. Иначе две базы расходятся.

Кто принимает миграцию?

Не только IT. Нужны владельцы регистратуры, медицинской документации, финансов, интеграций и руководитель проекта. Каждый подтверждает свой результат.

Что обязательно спросить про выход из новой МИС?

Формат и полноту экспорта, вложения, идентификаторы и связи, API, сроки, стоимость, доступ после расторжения и независимую проверку выгрузки.

Источники и границы сравнения

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

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

Что сделать завтра

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

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

Ответ на последний вопрос будет полезнее десятка красивых экранов. Хорошая МИС не обязана быть идеальной для всего. Но хороший проект выбора обязан заранее показать клинике, что она приобретает, что ей придётся изменить и какую часть прошлого нельзя потерять незаметно.