Содержание 
- Отправка сообщений с учётом часового пояса пациента
- Отправка сообщений с учётом даты приёма
- Отправка сообщений в рабочее время и не отправка сообщений в ночное время, если этого не требует бизнес-логика
- Отправка сообщений с учётом продолжительности приёма
- Отправка сообщений с учётом статусов приёма вычисляемых МедФлекс
- Повторная отправка сообщений о создании/изменении приёма при отсутствии ответа
- Обработка кодов ответа API МедФлекс
Концепция API МедФлекса 
API МедФлекса стремится быть как можно более простым, имея на своей стороне минимально необходимую бизнес-логику в целях эффективной, своевременной и стабильной передачи информации между участниками интеграции.
Наиболее частые кейсы 
При авторизации указывайте префикс Token.

Отправка сообщений с учётом часового пояса пациента 
Учитывайте часовой пояс ЛПУ при отправке уведомлений.
Для этого воспользуйтесь полем lpu_id.
Чтобы запросить информацию о клинике, используйте хук /catalog/lpu.
Используя поле lpu_id, вы сможете получить данные town_id
Пример ответа:

После этого забрать данные из нашего справочника городов /catalog/town/, и используя любую подходящую вам библиотеку, определить часовой пояс ЛПУ.
Пример ответа:

Партнёрам по триггерному API (сервисы триггерных рассылок) недоступен метод /catalog/lpu. Для получения ЛПУ доступен /appointments/lpu, часовой пояс указан в поле time_offset.
Отправка сообщений с учётом даты приёма 
Партнёру рекомендуется учитывать статус и дату приёма. В некоторых случаях МедФлекс передаёт данные по уже завершённым приёмам.
Для обработки записи обратите внимание на хук /direct_appointment/history/.
Этот хук возвращает историю записей, в нём можно найти полную информацию о приёме. В том числе дату и время начала и конца приёма.
Пример ответа:

У партнёров по триггерному API (сервисы триггерных рассылок) нет доступа к методу /direct_appointments/history. Список приёмов клиники можно получить, используя метод /appointments/appointments/. При запросе отобразится параметр dt_start и duration.

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

Отправка сообщений с учётом продолжительности приёма 
Рекомендуется учитывать продолжительность приёма, а также корректно отрабатывать данные, когда продолжительность приёма не соответствует реальной (в силу особенностей процессов клиники).
Например, продолжительность приёма может быть указана 1 минута, но фактическая продолжительность другая.
Собрать данные вы сможете, используя хук /direct_appointment/history/.
У партнёров по триггерному API (сервисы триггерных рассылок) нет доступа к методу /direct_appointments/history. Список приёмов клиники можно получить, используя метод /appointments/appointments/. При запросе отобразится параметр duration.
Отправка сообщений с учётом статусов приёма вычисляемых МедФлекс 
Для упрощения работы со статусами МедФлекс отображает вычисляемые статусы на своей стороне.
Если сервису необходимо учитывать статусы из МИС, то эта информация содержится в полях status и original_status.
- Поле status отвечает за состояние записи, которое МедФлекс валидирует на своей стороне.
- Поле original_status — какая информация хранится в МИС клиники, в которой сделана запись. Чтобы воспользоваться этой информацией, достаточно сделать небольшую доработку на вашей стороне для обработки этого поля.
Пример ответа:

Повторная отправка сообщений о создании/изменении приёма при отсутствии ответа 
Если МедФлекс не получает ответ на отправленный запрос (например, уведомление о создании/изменении приёма), запрос будет отправлен снова. При этом, на стороне партнёра фактически изначальный запрос может быть успешно обработан, но ответ не будет отдан в пределах таймаутов.
Это может привести к повторным отправкам сообщений пациентам о создании/изменении приёма.
Чтобы этого избежать, рекомендуется для метода POST /appointments/webhooks использовать ключ идемпотентности в виде HTTP-заголовка Idempotency-Key
, который содержит в себе UUID запроса. Таким образом, можно настроить обработку запросов, чтобы учитывать этот ключ — если ранее был успешно получен и обработан запрос с Idempotency-Key
, то повторные запросы с этим же Idempotency-Key
необходимо игнорировать, не дублируя сообщения пациенту.
Обработка кодов ответа API МедФлекс 
Важно! При разработке интеграции, учитывайте, что API регулярно обновляется и дополняется новыми видами ошибок. Рекомендуем добавить дополнительные универсальные обработчики ошибок с кодом 4XX.