+1

Почему в МИС до сих пор нет External ID?

Ингвар 2 недели назад 0

Коллеги, приветствую! 


Сказать, что я удивлен — ничего не сказать. Пытаюсь настроить базовую, стандартную интеграцию: клиент создается во внешней CRM/учетной системе (получает там ID), и через входящий вебхук должен создаваться в МИС. Логичный и безопасный сценарий. 


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


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


  1. Если мы создаем пациента «сверху вниз», мы обязаны где-то хранить ключ-связку.
  2. Вариант «создать в МИС -> забрать ID МИС -> записать обратно во внешнюю систему» — это костыль и прямая дорога к дублям при первой же сетевой задержке или ошибке таймаута вебхука.
  3. Искать по ФИО + Телефону + Email? Серьезно? В 2026 году опираться на динамические персональные данные, которые клиенты меняют каждый день, для жесткого маппинга систем — это архитектурное преступление.

В итоге: входящий хук на создание есть, а возможности нормально, безопасно связать источник и приемник — нет. Запись в МИС улетает «в никуда», и при любом следующем апдейте мы эту карточку просто не найдем. Зачем тогда вообще нужен этот хук? Для галочки в маркетинговом буклете «У нас есть API»? Это очень странно, досадно и сильно бьет по возможностям автоматизации клиник.


Уважаемая команда разработки!
Пожалуйста, добавьте в сущность Клиента (и Приёма тоже) банальное, стандартное индексируемое поле External ID (Внешний код) и методы нормального быстрого поиска по нему в API. Без этого любая серьезная интеграция с вашей МИС превращается в ходьбу по минному полю. 


Кто сталкивался с этой болью, поддержите лайком или расскажите, какими костылями вы это обходили?

безопасность БД

Сервис поддержки клиентов работает на платформе UserEcho