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?
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!