Stream: FHIRcast
Topic: FHIRcast STU1 clarification
Cindy Jiang (Oct 24 2019 at 20:28):
We are implementing a context management service based on FHIRcast and have a few questions in regards to FHIRcast STU1.
Cindy Jiang (Oct 24 2019 at 20:29):
- Should the topic uuid be included in the POST URL for “Request Context Change” transaction? Our preference is no to avoid potential security exposure. Need to ask FHIRcast for their opinion.
- What is the expected use of timestamp in “Request Context Change”? Is it the subscriber that should set the timestamp, and what if the subscribers’ clocks are out of synch?
- We noticed the “Query for Current Context” transaction has been removed from FHIRcast STU1, however it was defined in the May2019Ballot version and is useful for our implementation, because our subscribers are not SMART-on-FHIR enabled at the moment. If we were to follow the “Query for Current Context” defined in the May2019 ballot version, what exactly should be included in the response?
a. The spec says “Note that no hub.event is present in the response.”, however the sample response message still includes an “event” block though there is no event returned. Is the “event” block necessary in this case?
b. What is the “timestamp” meant to be?
c. What is the “id” meant to be?
d. In the sandbox implementation the response only returns the context itself without “timestamp” and “id” though… - Our implementation expects that the hub will maintain the overall context that is accessible by all subscribers, and the subscribers may update all or a subset of the resources in the context based on the nature of the event. E.g. “patient-open” will trigger an update of the Patient resource, and “parameter-change” will trigger an update of the Parameters resource for information such as “DateFrom” and “DateTo”. Is this align with the approach of FHIRcast STU1? We noticed the FHIRcast STU1 says that “FHIRcast events are stateless. Context changes are a complete replacement of any previously communicated context, not "deltas". Understanding an event SHALL not require receiving a previous or future event.”, and this requirement seems to be newly added in FHIRcast STU1. Can you clarify the intent here? What would be in the context in the following example?
a. When “Patient-open” event occurred, Patient resource is added into the context;
b. Then “Parameter-change” event occurred, will the Patient resource be erased and only Parameters resource will exist in the context from this point on, or will both Patient and Parameters resources exist in the context?
Isaac Vetter (Oct 25 2019 at 19:03):
Hi Cindy!
Isaac Vetter (Oct 25 2019 at 19:03):
- Should the topic uuid be included in the POST URL for “Request Context Change” transaction? Our preference is no to avoid potential security exposure. Need to ask FHIRcast for their opinion.
Isaac Vetter (Oct 25 2019 at 19:03):
The examples in the spec are confusing. Ultimately, I think that the intent is that a subscriber requests context changes by POST'ing to the hub.url. Ultimately, the hub.url is whatever value the subscriber receives during the app launch.
Isaac Vetter (Oct 25 2019 at 19:04):
Note that the spec does clearly state this:
the subscriber MAY request context changes with an HTTP POST to the hub.url
Isaac Vetter (Oct 25 2019 at 19:13):
- What is the expected use of timestamp in “Request Context Change”? Is it the subscriber that should set the timestamp, and what if the subscribers’ clocks are out of synch?
Isaac Vetter (Oct 25 2019 at 19:14):
The intent of the timestamp is to allow systems receiving the event to appropriately order notifications. The "Request for Current Context" message is originating from the subscriber, presumably because the user took an action in that subscriber's system; therefore, I think that the subscriber is the only actor aware of the timestamp at which the user took the action.
Isaac Vetter (Oct 25 2019 at 19:14):
I agree with you that out of sync clocks between subscribers would cause an integration to fail. I'm not sure that the possibility of significant clock skew (at the speed of a user clicking around in applications) is actually a problem in prod environments. (Doesn't everyone simply use network time protocol nowadays)?
Isaac Vetter (Oct 25 2019 at 19:17):
- We noticed the “Query for Current Context” transaction has been removed from FHIRcast STU1, however it was defined in the May2019Ballot version and is useful for our implementation, because our subscribers are not SMART-on-FHIR enabled at the moment. If we were to follow the “Query for Current Context” defined in the May2019 ballot version, what exactly should be included in the response?
Isaac Vetter (Oct 25 2019 at 19:17):
The working group and implementer community is continuing to talk through this. In practice, my observation was that it was really hard to implement a Hub that supported this query across multiple subscribers with potentially different subscriptions. Have you perused the Synchronization Considerations page? The absence of SMART doesn't preclude a custom app launch mechanism, which commonly passes initial contextual data.
Isaac Vetter (Oct 25 2019 at 19:37):
4.Our implementation expects that the hub will maintain the overall context that is accessible by all subscribers, and the subscribers may update all or a subset of the resources in the context based on the nature of the event. E.g. “patient-open” will trigger an update of the Patient resource, and “parameter-change” will trigger an update of the Parameters resource for information such as “DateFrom” and “DateTo”.
Right. Making the Hub smart enough to handle this potentially significant complexity is exactly why the (controversial) ballot comment to remove the "Query for Current Context" passed. Again, especially consider multiple subscribers authorized / subscribed to varying events. If the hub is tracking the context of the session, it's likely that it would have to do so per subscriber.
Isaac Vetter (Oct 25 2019 at 19:37):
Can you clarify the intent here? What would be in the context in the following example?
Ultimately, the intent is to allow the Hub to be simple and to not require it to track/remember the content of a session.
Isaac Vetter (Oct 25 2019 at 19:37):
4a. When “Patient-open” event occurred, Patient resource is added into the context;
4b. Then “Parameter-change” event occurred, will the Patient resource be erased and only Parameters resource will exist in the context from this point on, or will both Patient and Parameters resources exist in the context?
Isaac Vetter (Oct 25 2019 at 19:37):
Do note that there's not a "change" verb defined in the spec. The documented events (somewhat arbitrarily) explicitly call out the resources that are required or possible to belong in the context. For example: imagingstudy-open requires a patient resource in addition to an imagingstudy resource. Practically, this really makes sense; however, there's not currently a rule that helps authors of new events to determine what resources belong in context.
Isaac Vetter (Oct 25 2019 at 19:37):
Does a parameter-change event have a patient resource in its context? I worry that the Parameter resource and a parameter-change event don't have much intrinsic meaning in a workflow.
Cindy Jiang (Oct 30 2019 at 20:31):
Hi @Isaac Vetter ,
The "parameter-change" event is just an example for the discussion and we haven't fleshed out the actual event names yet. Since the intent for the events is to reflect the actual workflow activity, we may define something like "languagechange" for change of display language of the EHR, or "Organization-change" when the user switches their "under authority of" organization from one clinic to another.
A separate question... A common resource (e.g. Patient) could be used in multiple events, e.g. Patient-change, ImageStudy-change, and DiagnosticReport(for labs)-change. Currently the subscribers are responsible for subscribing to events that are relevant to their workflow. If a DI viewlet subscribes to two events Patient-change and ImageStudy-change, and Labs viewlet subscribes to Patient-change and DiagnosticReport(for labs)-change, it seems to be legitimate because the DI viewlet is not interested in labs related events, and vise versa for the Labs viewlet. However there is a risk that the Labs viewlet won't be notified when the user switches the patient in the DI viewlet via ImageStudy-change event, therefore the patient would be out of synch. Any thoughts on whether FHIRcast should define some guiding principles on how to handle such scenarios, e.g. should the hub perform some sort of cross-reference checks and force the subscribers to subscribe all events that have overlapping resources?
Isaac Vetter (Nov 03 2019 at 18:00):
Hey Cindy!
Isaac Vetter (Nov 03 2019 at 18:01):
re: parameter-change event -- makes sense.
Isaac Vetter (Nov 03 2019 at 18:01):
I haven't (yet?) seen an implementer attempt to develop generic support the new scope syntax. Depending upon your specific scenario, defining previously un-used events, while perfectly valid, could slow adoption compared to re-use of well known and implemented events. Do note that we've currently only defined open and close as verbs, not change.
Isaac Vetter (Nov 03 2019 at 18:01):
seems to be legitimate because the DI viewlet is not interested in labs related events, and vise versa for the Labs viewlet. However ... the user switches the patient in the DI viewlet via ImageStudy-change event
Isaac Vetter (Nov 03 2019 at 18:01):
Great question! Do note that the question itself assumes that there's a "hierarchy" of context of Patient has Study and Patient has Lab.
Isaac Vetter (Nov 03 2019 at 18:01):
FHIRcast should define some guiding principles on how to handle such scenarios,
Isaac Vetter (Nov 03 2019 at 18:01):
Yes, it seems clear that we need to ensure this doesn't happen. We don't have this guidance currently.
Isaac Vetter (Nov 03 2019 at 18:01):
e.g. should the hub perform some sort of cross-reference checks and force the subscribers to subscribe all events that have overlapping resources?
Isaac Vetter (Nov 03 2019 at 18:01):
This would definitely be a solution. I wonder if a simpler solution would be to limit an event to only changing the FHIR resource in its name. E.g. imagingstudy-open/close could only change the ImagingStudy and not the patient. This would force a patient-open event to always occur before the problematic imagingstudy-open event in your example. This would work well as long as that assumed hierarchy actually exists in the synchronizing applications.
Isaac Vetter (Nov 03 2019 at 18:01):
What do you think?
Cindy Jiang (Nov 27 2019 at 15:50):
@Isaac Vetter we further defined the Parameters profile and the associated events. In our Parameters profile there are 2 slices - appLanugage to indicate the user's selection of the display language in the application, and consentTarget to indicate the information domain(s) that the consent override applies to. In the future we will add more parameters such as FromDate and ToDate to specify a common date range for search across all apps in the same context. We also identified two custom events: OH.languageChange and OH.consentTargetChange. The dilemma is what should be included in the Parameters resource for these events, i.e. 1) only include the slice for the parameter that is changed and leave the slices of the other unchanged parameters null, or 2) include the updated parameter and the populate the other parameters with previous known value. We do notice that FHIRcast says the events should be stateless and should not send delta only. However when it comes to Parameters, some of the participating apps in the context session may not support all parameters, therefore they won't store all parameters. There will be a risk for one app to overwrite some of the parameter values if we go with option 2). In our implementation the hub will maintain the state of the overall context, and we don't expect the individual apps to maintain state for themselves. Therefore we are leaning towards option 1). Wonder if you have any thoughts or suggestions?
Last updated: Apr 12 2022 at 19:14 UTC
