Stand-alone launch - context sync simplification

[mbellehumeur]

To facilitate applications joining an on-going workflow independently, we propose to have the subscription process provide the last event.
There are two opportunities in the current protocol to provide that information: in the body of the subscription response itself which is currently empty or as an additional field in the subscription confirmation message.

This would also mitigate the need for a get-context query which was pushed out in the last ballot:
#143

[isaacvetter]

Hey @mbellehumeur ,

Wouldn't it make more sense for the hub to follow up a successful subscription with a normal event notification, sent to the new subscriber?

The selection of what events to send, to different subscribers with different subscriptions is tricky. We wouldn't want to send a -close event, for example. Nor an -open for which a -close had occurred.

It does seem that capabilities of Hubs will differ, the amount of time which a Hub caches/remembers these events will naturally vary, therefore this should be an optional feature of a Hub.

What do you think, Martin?

Isaac

Related: https://jira.hl7.org/browse/FHIR-25877

[mbellehumeur]

Thanks @isaacvetter !
I’m fine with the mechanism but it needs to be in the standard.
I think just sending the last event will cover >80% use cases.
An app should know that if the last event was a “close” then it should do nothing.
It should be an additional parameter of the subscription so that only client that want to receive this “last event” do. Can we have this added?

[isaacvetter]

Eric Martin made the point during our II call this afternoon, that an event notification communicating current context following a successful subscription also persists the problem of potentially stale information. There's will also be timing issues unless the subscription is atomic.

[gkustas]

This question of "how to replace get context" doesn't want to go away. My take on it, FWIW, is that we really shouldn't create a Hub standard for getting current context, until we standardize events/workflows and clearly define just "what context is" for any event/workflow. I don't know if that is possible or not, but consider the following:

1. A Hub can optionally choose to provide context and versioning (standard FHIR version numbers for resources).
2. The context is defined as the FHIR resource(s) identified by the event(s) sent in the topic session. Events would have to follow the spec definition [FHIR Resource]-[open|close|...|...|...]. NOTE: a FHIR Resource may contain one or more other FHIR Resources. In our implementation, a DiagnosticReport is the "context" and it contains ImagingStudy resource(s) and optionally Observation resources. Question: do we need to support multiple top-level resources in a single session (for example ImagingStudy-open and DiagnosticReport-open)?
3. Whenever a [FHIR Resource]-open event is received, the Hub stores the resource and versions it. Likewise, when a [FHIR Resource]-update is received, the Hub applies the changes and increments the version number prior to broadcasting the update message. THIS IS THE IMPORTANT PART: Nuance currently uses a Bundle of transactions for the DiagnosticReport-update. We, as in FHIRCast, would have to define this or some other message structure as a standard for ALL EVENTS if we want to implement a "smart Hub" that can provide the current context.
4. When a [FHIR Resource-close is received, the Hub can clear the context. There are probably other implementation details to consider here to ensure that old, unused topic sessions are cleaned up before a new session is started again.
5. When a client determines it needs to get the current context, it could hit an endpoint on the Hub which would return a context array of every open FHIR Resource, complete with a version number.

There are probably other issues to consider, but by far the biggest would be standardizing the event message structure, especially for updates.

@isaacvetter @mbellehumeur ???