FHIR订阅错误恢复,不使用$events操作。

huangapple go评论96阅读模式
英文:

FHIR subscription error recovery without the $events operation

问题

根据FHIR规范,错误恢复过程通常包括一系列或批量请求,允许客户端了解当前状态或在可用时请求$events操作。

我对提到的第一个选项感兴趣,“一系列或批量请求,允许客户端了解当前状态”,具体涉及服务器可以采取哪些措施来为客户端提供从$events操作以外的方式来恢复错误。

规范没有详细说明哪种请求适合用于错误恢复,尤其是客户端如何构建正确的查询。在旧的基于查询的订阅模型中,客户端可以轻松重用订阅的查询以进行错误恢复。但是,在新的基于主题的订阅模型中,订阅主题具有封装的查询逻辑,客户端无需了解(在某些情况下甚至可能无法使用搜索参数表达)。那么客户端如何构建用于恢复的查询呢?

我对服务器端支持恢复查询有以下想法:

  • 服务器是否能够以某种方式提供与客户端可以用于错误恢复的订阅等效的查询?

  • 服务器是否能够提供执行订阅的封装查询的操作?

不幸的是,我没有找到标准的方法来执行上述操作之一。我能想到的最接近的方法是使用命名查询,因为它们也可以封装隐藏的查询逻辑。可以为订阅恢复(或甚至为不同的订阅主题单独创建命名查询),以便客户端可以用于错误恢复,例如http://fhir.example.com/?_query=subscriptionRecovery&subscriptionId=123&_since=:lastNotified)。这可以在客户端的实施指南中进行文档化。但是否有更标准的方法呢?

英文:

According to the FHIR specs, the error recovery process typically

> will include a series or batch of requests that allow a client to know the current state or a request to the $events operation when available.

I would be interested in the first option mentioned, "a series or batch of requests that allow a client to know the current state", specifically about what a server can do to provide a way for clients to recover from errors other than the $events operation.

The specs do not go into detail about what kind of requests would be adequate for error recovery and specifically about how a client can construct the correct query. With the old query-based subscription model, a client could easily reuse the subscription’s query for error recovery purposes. However, with the new topic-based subscription model, subscription topics have an encapsulated query logic that clients do not need to know (and that in some cases may not even be expressible with search parameters). So how can clients construct a query to use for recovery?

I had the following ideas for server-side support for the recovery queries:

  • Could the server somehow provide a query equivalent to the subscription that the client could then use for error recovery purposes?

  • Could the server provide an operation that executes a subscription’s encapsulated query?

Unfortunately, I did not find a standard way to do either of these. The closest thing I could come up with is to use named queries, since those can also encapsulate hidden query logic. There could be a named query for subscription recovery (or maybe even separate named queries for different subscription topics), so the client could use for example http://fhir.example.com/?_query=subscriptionRecovery&subscriptionId=123&_since=:lastNotified) for error recovery. This could be documented in the implementation guide for clients. Is there a more standard way though?

答案1

得分: 1

这个想法是,使用订阅的客户端应该有某种加载初始状态的过程,通常比获取单独事件更简单。

例如,如果一个应用程序用于管理患者的药物,通知在新药物记录可用时很有用,但可以通过向 FHIR 服务器发出直接查询并处理结果来找到初始状态。

确实,并非所有订阅都会有这样简单的查询。如果担心会漏掉任何通知会导致无法发现,我建议在定义主题时包含该信息。如果这是一个实施指南,我建议还添加对这些主题支持 $events 操作的要求。

对于可以通过查询加载当前状态的主题,将这些查询也记录下来是一个良好的做法。我认为我们还没有订阅的“最佳实践”文档,但如果有的话,我会在适当时候记录下来。

由于这个概念实际上尚未讨论,因此对它还没有任何标准化。我个人的第一反应是在订阅端点上添加额外的操作,类似 $current-state,可以使用它。

如果您对提交 Jira 票 有信心,我们可以讨论在未来版本的规范中添加它们,为采用前提供具体的路径。如果您不愿意,我会把它们添加到我的清单中。

总之,如果 服务器 担心客户端的恢复能力,今天最简单的解决方案就是提供 $events 操作。

希望这能有所帮助 - 如果您想进行更积极的讨论,我还建议使用 订阅流 上的 FHIR 聊天。

干杯!

英文:

the idea was that a client app using a subscription should have some sort of process to load an initial state that is generally simpler than fetching discrete events.

For example, if an application is being used to manage a patient's medications, the notifications are useful to know when new medication records are available, but the an initial state can be found by issuing a straightforward query into the FHIR server and processing the results.

It is true that not all subscriptions will have simple queries like that. If there are concerns that any missed notifications would be undiscoverable, I would recommend including that information where the topic is being defined. And, if that is an implementation guide, I would recommend adding a requirement to support the $events operation on those topics as well.

For topics that are possible to load the current state via a query, it would be good practice to document those queries as well. I do not think we have a 'Best Practices' document for subscriptions yet, but I will note this down when/if there is one.

Since the concept has not really been discussed, there is not any standardization for it. My personal first take would be to add an additional operation on the subscription endpoint - something like $current-state that could be used.

If you are comfortable filing a Jira ticket with those requests, we can discuss adding them in a future version of the specs, which provides a concrete path for pre-adoption. If you are not, I will add them to my list to file.

All of that said, if a server is concerned about a client's ability to recover, the simplest solution today is to offer the $events operation.

I hope this helps - if you want more active discussion, I would also suggest using the Subscriptions stream on FHIR chat.

Cheers!

huangapple
  • 本文由 发表于 2023年4月19日 21:54:18
  • 转载请务必保留本文链接:https://go.coder-hub.com/76055373.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定