Proposal for new "get current session context" REST method

[gkustas]

Without some sort session context provided by the hub, a client that subscribes to a topic AFTER context has been set will be unable to synchronize with the other clients. One such scenario would be an application that crashes and then is restarted, or it could be the radiologist just didn't launch an app until they already loaded images or a patient in the first app.

While we don't want to burden the hub by requiring it "maintain state", I suggest that we require it to keep a list of notifications events for each topic session. In order to do this, we need to define a session: Consider the existing events ImagingStudy-open and Patient-open (as well as the newly proposed DiagnosticReport-open) as the "triggers" that signal a new topic session.

Example: Radiologist PACS/Reporting workflow

1. Radiologist logs into a PACS client and a reporting client.
2. The radiologist selects a study from the PACS.
3. Radiologist signals the beginning of a new report at which time the PACS client posts a DiagnosticReport-open event containing the imaging study (or studies) the radiologist is reporting on.
4. The reporting application receives the event, and creates a new report (or potentially opens an existing report if one exists for the imaging study identified by accession number).
5. The radiologist decides to pull up an older study for comparison in the PACS. The PACS client then posts a DiagnosticReport-update, which includes the prior study (ImagingStudy resource with "PriorStudy" as the key).
6. The reporting application suddenly terminates abnormally. The radiologist restarts the application and logs back in. The reporting system subscribes to the existing topic, and then queries the hub for context.
7. The hub returns all event notifications sent for the topic that occurred in the current session, which includes the DiagnosticReport-open and the DiagnosticReport-update. The data payload returned will be a json array of events. The payload will be exact duplicates of the events as they were originally sent.
8. The reporting application then reconstructs the context by applying each event (in chronological order): (a) Obtains the accession number from the first event, and opens the existing report it previously created prior to the abnormal termination. (b) examines the second event - which it never received - and adds the prior comparison study to the existing report.

*This method was recently removed from the current STU FHIRCast spec. It may be proposed as a new replacement to the HL7 working group in STU2

**If we assume that all ImagingStudy, Patient and DiagnosticReport event payloads contain the entire current context (all imaging studies including priors, all observations, etc.), then the hub need only provide the last event that occurred in the topic session. If we decide to allow partial updates to the context, we will need to devise a consistent way (across all events) to post context updates, perhaps using HTTP method notations like PATCH and DELETE (for adding or deleting a resource to the current context).

[wayfarer3130]

Having full playback seems fairly expensive. It also depends on actually being able to re-open a particular session, and that might be difficult. Finally, some things might cause windows to open or things to appear, so one doesn't want a real playback. I'd like to suggest an alternative:

1. Playback must be requested on a given resource type, eg Patient or ImagingStudy or DiagnosticReport
2. A close (or delete) operation removes any storage on the given object, AND all nested objects. That is, ImagingStudy is nested in Patient, and DiagnosticReport nested in ImagingStudy.
3. A new open on a given object replaces the previous open, and removes prior history before that on said object and nested objects.
4. updates are cummulative since the last open
5. An update MAY refer to an earlier update to replace it - define how, eg hub.replaces= might work
6. New methods need to define whether they are update or replace operations, and what their nesting is.
7. Need another proposal for a standard method to re-connect to a particular session, perhaps by user name or group name?

[gkustas]

@wayfarer3130 : I think you misunderstood - My proposal is for the hub to begin recording events after receiving an open event for DiagnosticReport, ImagingStudy, or Patient. That would be the "session trigger". I would consider these objects "contextual" resources since would reference other objects pertaining to the current session. I don't envision there being many events that occur for one session. I wouldn't call syncing "playback" either. It's really just the process of adding or deleting resources to the session based on the events received during the session. I think we're saying the same thing actually Bill. The get-current-study in the example above is only going to return the events associated with the "current context" which is defined implicitly by the DiagnosticReport-open event occurring. Does that make sense?

Stand by for a larger issue about to be opened in a collaborative effort we are having with Siemens. It will supersede this this issue and the DiagnosticReport issue, as well as introduce the Bundle resource for updates. We certainly look forward to your review and feedback!

[wmaethner]

Hey @gkustas, thanks for putting this together. I put my initial thoughts below, but will continue to think about it. I think there is a lot to consider here so might be a good thing to talk about on a future HL7 WG call or to even setup an ad hoc call to talk through everything.

1. I had the same misunderstanding as Bill, so I am glad to hear that we aren't suggesting the event list be the full user session, which could obviously get quite large.
2. I am wondering how this would work with a system that allows multiple different contexts or tabs to be opened at once. For example, if a user opened study A, then opened study B in a new tab (study A is still open, just not currently in focus), then at this point an app subscribes and performs this get current context flow, what should be returned? You mention the resource opens as the beginnings of these mini-sessions, so would that contain all subsequent events up until its closure or does each open start a new mini-session?
3. I think it may be helpful (maybe only to me) to see some diagrams showing some of these workflows and what would be returned at certain points.
4. Similar to 3, having someone implement this in one of our sandboxes (even if it is very minimal and prototype-like) would make things more clear.

Thanks again and looking forward to working through this some more.

[gkustas]

Hey @wmaethner !!

Yes, I agree there is a lot to consider. Things have been moving rapidly as of late here in my company, as is often the case when RSNA gets closer :-)

I mentioned the recent discussions we're having with other vendors - all of which is exciting. As I said, Siemens (Web DI aka Eric Martin) and Nuance are working on a collaborative proposal for handing user context, and introducing DiagnosticReport as one of three "session trigger" or "contextual" resources, along with ImagingStudy-open and Patient-open. Eric's group will elaborate further, but regarding the "multiple case session" you describe:

We assume there will be only one "session" per topic active at any time, as far as FHIRCast context is concerned. It will be the responsibility of the client (if it chooses) to cache other "tabs", studies or other resources in the event of an interrupted workflow. So, the "current context" is reset every time one of the three "contextual resource" events occur.

Of course, all of this is work in progress and we're so glad to have anyone's feedback at this point. More soon!

[cindymjiang]

Hi @wmaethner , there was an interaction "Query for Current Context" in the May2019Ballot version of the FHIRcast spec however it was then removed from the current version. We have a scenario that an user who already has a session established in an EHR trying to launch another application in context through single-sign-on. Since the event notification has occurred in the past the only way to synchronize the context in the new application is to use the "Query for Current Context" interaction. The new application is not SMART-on-FHIR enabled so it won't be able to support the SMART launch parameters as suggested by the current version of the FHIRcast spec to establish the initial context. What was the rationale to remove the support for "Query for Current Context"? How could we support the need for establishing the initial context in a non-SMART-on-FHIR app?

[EricOnFHIR]

Incorporated in the STU3 version of the standard