Содержание 
- Отправка сообщений с учетом часового пояса пациента.
- Отправка сообщений с учетом даты приема.
- Отправка сообщений в рабочее время и не отправка сообщений в ночной время, если этого не требует бизнес-логика.
- Отправка сообщений с учетом продолжительности приема.
- Отправка сообщений с учетом статусов приема вычисляемых Медфлекс.
- Повторная отправка сообщений о создании/изменении приёма при отсутствии ответа.
- Обработка кодов ответа API МедФлекс
Концепция API МедФлекс
API МедФлекс стремится быть как можно более простым, имея на своей стороне минимально необходимую бизнес-логику в целях эффективной, своевременной и стабильной передачи информации между участниками интеграции.
Наиболее частые кейсы
Отправка сообщений с учетом часового пояса пациента.
Партнеру рекомендуется учитывать часовой пояс ЛПУ для отправки уведомлений. Для этого вам стоит обратить внимание на поле lpu_id. Воспользовавшись этим полем вы можете легко запросить у нас информацию, этой клиники используя хук /catalog/lpu.
Используя поле lpu_id, вы сможете получить данные town_id
Пример ответа:
После чего вам остается лишь забрать данные из нашего справочника городов /catalog/town/, и используя любую подходящую вам библиотеку, определить часовой пояс ЛПУ
Пример ответа:
Отправка сообщений с учетом даты приема.
Партнеру рекомендуется учитывать статус и дату приема. В некоторых случаях МедФлекс передает данные по уже завершенным приемам.
Для обработки записи обратите внимание на хук /direct_appointment/history/
Этот хук, возвращает историю записей, в нем можно найти полную информацию о приёме. В том числе дату и время начала и конца приема
Пример ответа:
Отправка сообщений в рабочее время и не отправка сообщений в ночной время, если этого не требует бизнес-логика.
При отправке мы рекомендуем учитывать дату и время создания записи, т.к. иногда прием может быть создан ночью, а иногда создан днем, но передан с временной задержкой.
Чтобы получить информацию о дате и времени создания записи вы можете воспользоваться хуком /appointments/appointments/
Пример ответа:
Отправка сообщений с учетом продолжительности приема.
Партнеру рекомендуется учитывать продолжительность приема, а также корректно отрабатывать данные, когда продолжительность приема не соответствует реальной (в силу особенностей процессов клиники).
Например продолжительность приема может быть указана 1 минута, но фактическая продолжительность другая.
Собрать данные вы сможете используя хук /direct_appointment/history/
Отправка сообщений с учетом статусов приема вычисляемых Медфлекс.
Для упрощения работы со статусами, Медфлекс отображает вычисляемые статусы на своей стороне.
Если сервису необходимо учитывать статусы из МИС, то эта информация содержится в полях status и original_status.
- Поле status отвечает за состояние записи, которое мы валидируем на нашей стороне
- Поле original_status - это то какая информация хранится в МИС клиники, в которой сделана запись. Для того чтобы воспользоваться этой информацией, вам достаточно, сделать небольшую доработку на своей стороне, для обработки данного поля
Пример ответа:
Повторная отправка сообщений о создании/изменении приёма при отсутствии ответа
Если МедФлекс не получает ответ на отправленный запрос (например, уведомление о создании/изменении приёма), запрос будет отправлен снова. При этом, на стороне партнёра фактически изначальный запрос может быть успешно обработан, но ответ не будет отдан в пределах таймаутов. Это может привести к повторным отправкам сообщений пациентам о создании/изменении приёма.
Чтобы этого избежать, рекомендуется для метода POST /appointments/webhooks использовать ключ идемпотентности в виде HTTP-заголовка Idempotency-Key
, который содержит в себе UUID запроса. Таким образом, можно настроить обработку запросов, чтобы учитывать этот ключ - если ранее был успешно получен и обработан запрос с Idempotency-Key
, то повторные запросы с этим же Idempotency-Key
необходимо игнорировать, не дублируя сообщения пациенту
Обработка кодов ответа API МедФлекс
Важно! Уважаемые Партнеры, при разработке интеграции, пожалуйста, учитывайте, что API регулярно обновляется и дополняется новыми видами ошибок. Поэтому рекомендуем добавить дополнительные универсальные обработчики ошибок с кодом 4XX.