FHIR Chat · fhircast-docs / Issue #291 Proposal for Content Sharing · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #291 Proposal for Content Sharing

Github Notifications (FHIRcast) (Sep 27 2019 at 21:16):

EricOnFHIR opened Issue #291:

Somewhat related to George's proposal #289, see: sharing of structured information for a complete description and 3 proposed operations (update content, get current content, and set active resource) enabling robust sharing of structured information content in a FHIRcast contextual subject. We are very interested in everyone's feedback.

Github Notifications (FHIRcast) (Sep 28 2019 at 13:24):

gkustas commented on Issue #291:

Nice work Eric, Arpad and team...
So to confirm - if I use the "report-centered workflow", where a DiagnosticReport is my contextual resource...

1. A client need only subscribe to the content-update event.
2. When a new context is requested (Let's say a new report opened or created), a client will send a notification event containing a bundle including a DiagnostReport resource. The event's container id will be the resource id of the DiagnosticReport.
3. The hub recognizes this is a new session, and each subsequent update-content event must reference the same container id, correct? Or would multiple sessions be allowed on the same topic?
4. The end of this session is usually when the radiologist signs/closes the report. At this time, the reporting client would send an update-content with a new DiagnosticReport object (perhaps containing the report status and other data. Is it necessary to have some sort of "context closing", or can we simply assume that the current context doesn't change until a new container id (and associated contextual resource) are added?

Github Notifications (FHIRcast) (Sep 28 2019 at 13:29):

gkustas edited a comment on Issue #291:

Nice work @ericonfhir, Arpad and team...
So to confirm - if I use the "report-centered workflow", where a DiagnosticReport is my contextual resource...

1. A client need only subscribe to the content-update event.
2. When a new context is requested (Let's say a new report opened or created), a client will send a notification event containing a bundle which includes a DiagnosticReport resource. The event's container id will be the resource id of the DiagnosticReport.
3. The hub recognizes this is a new session, and each subsequent update-content event must reference the same container id, correct? Or would multiple sessions be allowed on the same topic?
4. Ini this particular workflow, the session usually ends when the radiologist signs/closes the report. At this time, the reporting client would send an update-content with a new DiagnosticReport object (perhaps containing the report status and other data). Is it necessary to have some sort of "context closing" event, or can we simply assume that the current context doesn't change until a new container id (and associated contextual resource) are added?

I'm sure there are lots of little details to iron out with regards to outlying use cases, but this looks like a very workable solution. By making the event completely generic, it opens up infinite uses for all sorts of FHIR data.

Github Notifications (FHIRcast) (Oct 05 2019 at 23:28):

EricOnFHIR commented on Issue #291:

#1: that is correct. If I as a subscriber to a topic want to follow structured information being shared then I have to request to subscribe and be given permission to listen to the content update event.

#2: yes-ish. Someone sets a context and then anyone, including the application which set the context, could send a update-content request. Later a different application, or the same application, could send another update-content request. The container.id in the request is the resource id of the current context.

#3: Any close or switch of the context of a given topic closes the associated information sharing session. So a given topic may have only a single information sharing session. Of course a Hub may be hosting multiple topics simultaneously and each topic may or may not have an active sharing of structured information.

#4: exactly what we try to convey in the proposal. When the current context of a topic is closed or is switched, any current information held by the Hub is disposed. I don’t believe we need to add a new event on close. Each subscriber to a topic is already informed the topic’s context is closed. They then know any information sharing in which they were participating related to that context has now stopped. That means any topic subscriber that can close a context may terminate an information sharing session. In your scenario, a context the context on which the information sharing is happening could be a patient (or imaging study) to which a diagnostic report is one of the resources shared. That way you could update status, etc. before closing the topic’s context. This approach enables each subscriber to get updates before the context is closed.

I look forward to shaking out the proposal with the use cases everyone has; but, I do believe this general approach has a lot of flexibility while still being specific and clear enough to make semantic and consistent use rather straightforward.

Github Notifications (FHIRcast) (Oct 01 2020 at 14:32):

bvdh commented on Issue #291:


Uploaded images for use in the wiki

Last updated: Apr 12 2022 at 19:14 UTC