Stream: subscriptions
Topic: FHIR subscriptions
Isaac Vetter (May 10 2017 at 16:57):
Overall, I think that the potential for FHIR Subscriptions is to enable FHIR "push" without requiring the external app to maintain a significant database of content.
The current spec is based around the idea that a clinical system uses FHIR resources as its native database format and executes subscribed FHIR queries against every resource as it's created or modified. This would work well for custom built middleware and FHIR reference implementations, but generally not for systems that implement clinical workflow.
I think that most clinical systems, mine included, are event-based. An implementable subscription criteria would rather be based on an event and then narrowed to specific attributes.
I've been trying to think about specific, practical use-cases for FHIR subscriptions. Most of them are more targeted subscriptions.
Some use-cases for FHIR Subscriptions:
- Family caregiver app subscribes to lab results and location information about their inpatient family member.
- Patient grants an aggregator or app access to their clinical record for purposes of clinical research.
- Clinician-facing inpatient "census board" subscribes to patient location within a specific department.
- Provider-facing app subscribes to abnormal lab results about patients on their patient list
- Provider-facing app subscribes to admitted patient location changes for a specific department or facility.
- Syndromic surveillance system monitors all new patient conditions for a given set of snomed codes.
Overall, I think that an event model is more appropriate for a more specific subscription. A FHIR search model is more appropriate for the transfer of a fuller, richer set of data.
Grahame Grieve (May 10 2017 at 17:14):
I agree that an event based model is preferable, having implemented subscription (and saying that as a native FHIR store ;-)
Last updated: Apr 12 2022 at 19:14 UTC
