Stream: subscriptions
Topic: Unifying FHIRcast and Subscription connections
Bill Wallace (Jun 23 2020 at 19:54):
Is there any way we can get the FHIRcast and the Subscription models to share both the notification object as well as the binding method? There are real use cases for talking to a single server and getting both FHIRcast and Subscription notifications on the same websocket. For the rest hook, it doesn't matter nearly so much, since it is always possible to have just a different endpoint specified, but imagine the situation where:
Client starts up, decides to display Patient 1 after querying the fhir/Patient and finding such a result.
Client subscribes to ImagingStudy notifications and DiagnosticReport notifications where Patient.id=1
(assuming using the bind: id notification mechanism).
Client then does an imaging study query, notices it has a pathology study that hte user chooses to view. Client doesn't handle pathology, performs a smart-launch to a pathology viewer with a new fhircast subscription, PLUS the existing FHIR subscriptions.
Pathology viewer gets launched, subscribes to the fhircast subscription, marking it as Patient., ImagingStudy. notifications.
User looks at the study, then another ImagingStudy arrives.
Pathology viewer gets notification, checks study for the type, and pops up a notice to the user that there is a new pathology study they can view/compare with the current one.
User decides to view
Pathology viewer now sends an ImagingStudy.open event.
Last updated: Apr 12 2022 at 19:14 UTC
