Описание эпизода

В новом эпизоде разобрана работа механизма вебхуков на примере интеграции между медицинской и страховой системой.

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

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

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

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

Актуально для опытных системных и бизнес-аналитиков, кто только знакомится с интеграциями систем или уже давно работает с ними, но еще ни разу не работал с вебхуками.

1:50 - Обсуждение возможных вариантов решения задачи, если вы не знакомы с механизмом вебхуков (Webhooks). Polling и Long Polling и почему.
08:53 - Что такое вебхуки - разбор на примере интеграции медицинской и страховой систем.
10:42 - Как технически реализуется вебхук в рамках интеграции систем, когда в нашу систему-подписчика надо получать уведомления из внешней. 
14:54 - Почему механизм Webhooks лучше механизма Polling и других подобных способов опроса внешней системы по таймерам, по расписанию.
20:30 - Как обеспечить работу вебхуков: реализация на стороне системы, которая оповещает о событиях.
26:23 - Почему рекомендуется использовать очереди сообщений (RabbitMQ / Kafka) для рассылки уведомлений о произошедших событиях при реализации вебхуков. Алгоритм реализации обработки сообщений из очереди.
28:47 - Механизм подписки на вебхуки для потребителей уведомлений.
31:05 - Прием вебхуков на стороне системы-подписчика в очередь и последующая их обработка.
32:27 - Про реализацию метода POST для вебхука на стороне системы-подписчика.
36:08 - Больше примеров задач и бизнес-процессов, где нужны вебхуки.
39:49 - Подведение итогов и рекомендации.

Вариант задачи для собеседования на системного аналитика по вебхукам

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

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

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

---------------------------------

Альтернативные условия могут быть связаны с платежными системами, системами ЭДО (электронного документооборота), торговыми и другими, где при интеграции важно отслеживать события на стороне внешней системы.

Возможные варианты решения задачи

Вариант 1. Обновление статуса заявки с использованием Polling - НЕ ЭФФЕКТИВНЫЙ.

1. Первые 30 секунд пытаться получить статус сразу, выполняя запрос на обновление статуса каждые 2 секунды.
Это можно заменить на разовую попытку обновления статуса сразу, что будет лучше.

2. Если сразу получить статус не удалось, то по расписанию, раз в сутки (например, в 3 часа ночи), проверять все заявки в системе, у которых статус pending, обновлен у них статус в страховой или нет.

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

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

Вариант 2. Обновление статуса заявки с использованием Long Polling + Polling - НЕ ЭФФЕКТИВНЫЙ и потенциально нереализуемый из-за отсутствия Long Polling в страховой системе.

1. Выполнение запроса с заданным таймаутом ожидания обновления статуса (например, 30 сек) - это использование Long Polling.
Не факт, что страховая система такой механизм вообще поддерживает.
По сути, это улучшает предыдущее решение, но открытое в течение 30 секунд соединение занимает ресурсы сервера.

2. Если сразу получить статус не удалось, то по расписанию, раз в сутки (например, в 3 часа ночи), проверять все заявки в системе, у которых статус pending, обновлен у них статус в страховой или нет. Это polling, как и в варианте 1.

По сути этот вариант ничем не лучше предыдущего, а Long Polling скорее ухудшает ситуацию, т.к. удерживает сервер страховой системы дольше.

Вариант 3. Обновление статуса заявки при её просмотре + автоматический запрос по таймеру, после истечения периода ожидания в 28-40 календарных дней - ОПТИМАЛЬНОЕ, но не лучшее решение.

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

1. Обновление статуса при просмотре заявки

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

Техническая реализация:

2. Автоматическое обновление по таймеру после 28-40 календарных дней

Для заявок, статус которых не был обновлен вручную через просмотр, система устанавливает таймер для автоматической проверки статуса по истечении предполагаемого максимального срока рассмотрения заявки (28 или 40 дней). Это гарантирует, что даже если заявка не просматривалась, её статус будет обновлён, и система сможет адекватно реагировать на исход рассмотрения заявки.

Техническая реализация:

Преимущества подхода:

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

Вариант 4. Автоматическое обновление статуса заявки с использованием механизма Webhooks - ИДЕАЛЬНОЕ РЕШЕНИЕ, если в страховой этот механизм реализован, иначе вариант 3.

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

Вот как можно реализовать это решение шаг за шагом:

Шаг 1: Реализация Webhooks в страховой компании

Страховая компания должна настроить свою систему так, чтобы она могла отправлять HTTP POST запросы на заранее определенный URL (endpoint) медицинской информационной системы каждый раз, когда статус заявки изменяется. Требования как должен выглядить этот HTTP POST запрос предъявляет страховая компания, т.к. медицинских систем к ней может быть подключено много.

Шаг 2: Обработка и верификация Webhooks

При получении Webhook от страховой компании, медицинская информационная система должна корректно его обработать:

Шаг 3: Мониторинг и логирование

Для обеспечения надежности и отказоустойчивости процесса важно настроить мониторинг и логирование всех входящих Webhooks:

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

Ссылки на API-документацию систем с вебхуками

Примеры систем, которые используют вебхуки, в популярных приложениях и сервисах.

Shopify
Интеграция с внешними приложениями для управления инвентарем и заказами.
https://shopify.dev/docs/apps/webhooks (ENG)

Stripe
Реализация уведомлений об изменениях статусов платежей.
https://docs.stripe.com/api/webhook_endpoints (ENG)

ЮКасса
Реализация уведомлений об изменениях статусов платежей.
https://yookassa.ru/developers/using-api/webhooks (РУ)

Райф Пэй
Реализация уведомлений об изменениях статусов платежей. 
https://pay.raif.ru/doc/ecom.html#tag/Callback (РУ)

МойСклад
Уведомление отправляется при наступлении в системе изменения, которое отслеживает вебхук. Например, если подключить вебхук на товары, при изменении наименования товара, вы получаете уведомление со ссылкой на измененный товар. Подробнее о работе с вебхуками читайте Вебхуки.
https://dev.moysklad.ru/doc/api/remap/1.2/dictionaries/#suschnosti-vebhuki 
https://dev.moysklad.ru/doc/api/remap/1.2/workbook/#workbook-vebhuki

Битрикс24
https://helpdesk.bitrix24.ru/open/20886106/