Stream: fhircast-github
Topic: docs / Issue #42 Addition of roles to the session
Github Notifications (FHIRcast) (Nov 15 2018 at 10:59):
jkiddo opened Issue #42
As part of the context session, a valuable addition could be to add the concept of roles - meaning that it should be possible to express which of the current clients in the active session that are able to change the context. Having this information makes it possible to create a better UI experience as fields can be 'grayed out' for the clients that only 'listening' to changes in the session. It also makes it more fault tolerant as clients cannot accidently change the eg. patient in question.
Github Notifications (FHIRcast) (Nov 17 2018 at 19:24):
jeremysrichardson commented on Issue #42
Would the owner of the session manage and enforce those roles? How would it know?
Github Notifications (FHIRcast) (Nov 17 2018 at 19:24):
jeremysrichardson {} a comment on Issue #42
Would the owner of the session manage and enforce those roles?
Github Notifications (FHIRcast) (Nov 20 2018 at 21:57):
isaacvetter commented on Issue #42
Hey @jkiddo!
To clarify, you're suggesting a production app capability and not just the sandbox, right?
To add to @jeremysrichardson's question:
- Shouldn't the ability of a synchronized app to suggest context changes be dependent upon the user's workflow, and not a pre-determined role of the app?
- Additionally, for the "grey-out" capability - wouldn't it be better to not represent those UI elements as inputs at all?What do you think?
Isaac
Github Notifications (FHIRcast) (Nov 20 2018 at 22:03):
@isaacvetter - yep - production app capability.
Well - the scenarios are probably many - but in a shared session you would find it useful not to have everybody in the driver's seat. You can think about it as pull requests or google docs. Some are in control of merging stuff into the session, while others are not.
Each session probably has an 'originator' - which should have the capacity to elevate joiners with permission to make context changes.
Github Notifications (FHIRcast) (Nov 20 2018 at 23:10):
isaacvetter commented on Issue #42
@jkiddo, thank you for explaining this to me. I totally agree with your sentiment. Our intent was that, in most cases, the hub is the same software as the driving application. This is why an app requests context changes and subscribers re notified.
I'd thought that we were explaining this in the spec, but maybe it dropped out at some point.
The intent is to not require a separate context manager -- by elevating the driving application to own the user's session and therefore, potentially, dictate context changes, including by possibly rejecting context change requests from other apps.
We kind of described that in the wiki, but not sufficiently.
One of the synchronized applications owns the user's session.
For simplicity's sake, one of the applications being synchronized must provide or integrate tightly with the authorization server, FHIR server and own the user's session by exposing it via a session management server. This application notifies subscribed applications of context changes. Subscribed applications request context changes of the session server.
Based upon your asking this question, I think that we should add some additional language to the specification to explain this.
Last updated: Apr 12 2022 at 19:14 UTC
