Stream: subscriptions
Topic: II context synchronization PSS
Ewout Kramer (Sep 13 2017 at 19:31):
As discussed at the San Diego Work Group Meeting just now, FHIR-I has accepted to be co-sponsor for the work on FHIR-based context-synhronization. The formal PSS is here: https://drive.google.com/open?id=165BU5ZmUyuwxz4kg2dtjRWkNM7o4u2PrdcIKSxP94Ts
Bryn Rhodes (Nov 15 2017 at 18:23):
I've added a draft resource for this based on the specs developed so far: http://build.fhir.org/usersession.html
Bryn Rhodes (Nov 15 2017 at 18:24):
I've added my thoughts as TODOs in the resource, very interested in feedback and review. Particularly @Josh Mandel @Isaac Vetter @Kevin Shekleton
Josh Mandel (Nov 16 2017 at 00:19):
Thanks for the mention @Bryn Rhodes ! It would be helpful if you could spell out a bit of the use case as part of that page. In particular I'm trying to get my head around the rationale for having a session be limited to a single workstation but permit multiple users. In the context you're envisioning, which parties would be able to issue changes to this session? And which parties would subscribe to learn about the changes? Does workstation refer to a physical device? Would a mobile phone be a workstation?
Grahame Grieve (Nov 16 2017 at 02:27):
I certainly agree about multiple users - what's the use case for that?
Bryn Rhodes (Nov 16 2017 at 08:55):
That's my bad, I missed that, cardinality of user should be 1..1, fixing now.
Bryn Rhodes (Nov 16 2017 at 08:56):
As far as workstation, I agree, and my notes on that are that I think that could just be a Device reference, that's what I see it as, the user's device, whatever that is, a laptop, desktop, tablet, mobile, etc.
Bryn Rhodes (Nov 16 2017 at 09:00):
As far as who could submit changes, I was thinking of this as a read-only resource from the client's perspective, and systems could subscribe to it to synchronize their context. For example, we would use this to synchronize the current patient in a user's context if we're providing asynchronous decision support for the current user.
Grahame Grieve (Nov 16 2017 at 09:42):
but who can initiate a change to the focus? I think that more than application can - certainly can in ccow and it's a core part of the radiologist workflow
Bryn Rhodes (Nov 16 2017 at 09:45):
Committed a few updates, still waiting for feedback from Isaac before I make any change to the workstation element though.
Bryn Rhodes (Nov 16 2017 at 09:50):
That's a good point on changing focus, but wouldn't that be a different session, but for the same user, because it's a different device?
Grahame Grieve (Nov 16 2017 at 09:51):
but the point is to share the session
Bryn Rhodes (Nov 16 2017 at 09:53):
Maybe, I thought the point was just to be able to synchronize the information between the sessions. Otherwise, "workstation" would have to be 1..*, right?
Grahame Grieve (Nov 16 2017 at 09:53):
maybe so
John Moehrke (Nov 16 2017 at 15:14):
is there a compelling current use-case (current implementations of CCOW) that actually have multiple workstations in a session? I know that the cath-lab tried to use this to coordinate all the machines in the cath-lab. But I don't know if adding that complexity today is as useful as the trouble it will bring.
John Moehrke (Nov 16 2017 at 15:19):
I don't want to hurt the efforts, but bring up CCOW only in a constructive way.... Lets learn and improve... CCOW has an abstract model, and two concrete models. FHIR could be seen as a third concrete model (or not)... Mapping to their abstract model can help us be complete. Mapping to their risk model can help us not re-learn failure-modes... See http://www.hl7.org/implement/standards/product_brief.cfm?product_id=1
John Moehrke (Nov 16 2017 at 15:39):
Thankfully much of the complexity of CCOW is totally not necessary.. such as patient and user mapping gents pluggability; and the context manager itself (as the FHIR Server fills this, right?) We also have OAuth (e.g. SMART) to manage other parts that were very complex in CCOW.... So I am mostly pointing at the data model from CCOW, and the risks of context sharing that they outline.
John Moehrke (Nov 16 2017 at 15:39):
Sooo.. since we are focused on the resource design, go directly to the ccow_subjects document, and show a mapping in the FHIR resource to the ccow_subjects.
John Moehrke (Nov 16 2017 at 15:51):
Is there a reason why it is currently modeled with the context as a completely open ended structure? I would have expected we would have had specific workflow resources. Expanding beyond that seems like could be done using the open ended structure. So I like the opended, but would have expected workflow would have been called out explicitly so that it is more directly useable.
John Moehrke (Nov 16 2017 at 15:53):
For example.. if you take the TL,DR approach to the CCOW spec... it ends up defining a structure of Patient, Encounter, Observation, DICOM.
Grahame Grieve (Nov 16 2017 at 15:54):
but why restrict to that? DIagnosticReport?
Isaac Vetter (Nov 21 2017 at 21:06):
@Bryn Rhodes - wow, it's like this is a real FHIR resource! Thanks for doing this work.
re: workstation
I'm defined this element as: Location that identifies the physical place at which the user's session is occurring. For the purposes of context synchronization, this is intended to represent the user's workstation.
Is that a FHIR Device? Is it a FHIR Location?
In practice, today's prod integrations typically use a hostname or ip address. This is why I suggested CodeableConcept, instead of Reference.
John Moehrke (Nov 21 2017 at 21:13):
That would not be a CodableConcept, It might be an Identifier. But most likely would be an EndPoint
Isaac Vetter (Nov 21 2017 at 21:23):
Hey @John Moehrke , the endpoint resource seems to require that one can talk to the workstation and that's not necessarily the case, right?
Isaac Vetter (Nov 21 2017 at 21:26):
Location is pretty clearly scoped to physical places, which doesn't quite seem to match.
Isaac Vetter (Nov 21 2017 at 21:27):
Would it make sense to add something like "Reading Room workstation" to this list: https://www.hl7.org/fhir/valueset-device-kind.html?
Bryn Rhodes (Nov 21 2017 at 21:28):
It seems to me that you would potentially want to capture both the Device (i.e. the machine running the process that has the session) and the Location (where the user is) although I see this as both less useful and more problematic.
Bryn Rhodes (Nov 21 2017 at 21:28):
I think for a context synchronization use case, it should really be a Device.
Isaac Vetter (Nov 21 2017 at 21:56):
@Bryn Rhodes - I think that make sense. Any suggestions on the device.type?
John Moehrke (Nov 21 2017 at 22:07):
choice... could be any of those, right? best part of core FHIR resouce modeling is you can define it multiple way
Bryn Rhodes (Nov 21 2017 at 22:53):
The current example binding is for medical devices, but we've used Device in CDS contexts to represent a CDS Service, for example. Would be nice to define a value set for device type appropriate to the space, but not sure what granularity to use. Maybe start with something really simple, "Desktop | Tablet | Mobile"?
Last updated: Apr 12 2022 at 19:14 UTC
