Исправление ошибки подписки FHIR без операции $events
Согласно спецификациям FHIR, процесс устранения ошибок обычно
будет включать серию или пакет запросов, позволяющих клиенту узнать текущее состояние, или запрос к операции $events, если она доступна.
Меня бы заинтересовал первый упомянутый вариант: «серия или пакет запросов, которые позволяют клиенту узнать текущее состояние», в частности, о том, что сервер может сделать, чтобы предоставить клиентам способ восстановления после ошибок, отличных от $events операция.
Спецификации не содержат подробностей о том, какие типы запросов будут подходящими для восстановления после ошибок и, в частности, о том, как клиент может создать правильный запрос. В старой модели подписки на основе запросов клиент мог легко повторно использовать запрос подписки для устранения ошибок. Однако с новой моделью подписки на основе темы темы подписки имеют инкапсулированную логику запроса, которую клиентам не нужно знать (и которая в некоторых случаях может быть даже не выражена с помощью параметров поиска). Так как же клиенты могут составить запрос для восстановления?
У меня были следующие идеи для серверной поддержки запросов восстановления:
Может ли сервер каким-то образом предоставить запрос, эквивалентный подписке, который затем клиент может использовать для устранения ошибок?
Может ли сервер предоставить операцию, которая выполняет инкапсулированный запрос подписки?
К сожалению, я не нашел стандартного способа сделать это. Самое близкое, что я мог придумать, — это использовать именованные запросы, поскольку они также могут инкапсулировать логику скрытых запросов. Может быть именованный запрос для восстановления подписки (или, может быть, даже отдельные именованные запросы для разных тем подписки), поэтому клиент может использовать, например, http://fhir.example.com/?_query=subscriptionRecovery&subscriptionId=123&_since=:lastNotified) для восстановления после ошибки. Это может быть задокументировано в руководстве по внедрению для клиентов. Есть ли более стандартный способ?
Ответы 1
идея заключалась в том, что клиентское приложение, использующее подписку, должно иметь какой-то процесс для загрузки начального состояния, который обычно проще, чем выборка отдельных событий.
Например, если приложение используется для управления лекарствами пациента, уведомления полезны, чтобы знать, когда доступны новые записи о лекарствах, но начальное состояние можно найти, отправив прямой запрос на сервер FHIR и обработав результаты.
Это правда, что не все подписки будут иметь такие простые запросы. Если есть опасения, что любые пропущенные уведомления невозможно будет обнаружить, я бы рекомендовал включить эту информацию в то место, где определяется тема. И, если это руководство по реализации, я бы рекомендовал добавить требование для поддержки операции $events по этим темам.
Для тем, в которых можно загрузить текущее состояние с помощью запроса, рекомендуется также документировать эти запросы. Я не думаю, что у нас еще есть документ «Передовой опыт» для подписок, но я запишу его, когда/если он будет.
Поскольку эта концепция на самом деле не обсуждалась, для нее нет никакой стандартизации. Моим личным первым шагом было бы добавить дополнительную операцию на конечной точке подписки — что-то вроде $current-state, которую можно было бы использовать.
Если вы готовы отправить тикет Jira с этими запросами, мы можем обсудить их добавление в будущую версию спецификаций, которая обеспечивает конкретный путь для предварительного принятия. Если нет, я добавлю их в свой список в файл.
При всем при этом, если сервер обеспокоен возможностью восстановления клиента, самое простое решение сегодня — предложить операцию $events.
Надеюсь, это поможет — если вы хотите более активного обсуждения, я бы также предложил использовать поток Подписки в чате FHIR.
Ваше здоровье!
Мы рассмотрели операцию $events, но чтобы ее можно было использовать для устранения ошибок, серверу необходимо продолжать запись событий для подписок, находящихся в состоянии сбоя. Хотя это может быть осуществимо для коротких отключений, это не может поддерживаться бесконечно на сервере с большим трафиком. Но если срок действия истекает, а сохраненные события удаляются через некоторое время, то доступных событий может быть недостаточно для восстановления после более длительных простоев, и нам все равно необходимо предоставить другой механизм восстановления после ошибок.