Stream: workflow
Topic: Why is Subscription not a request
Eric Haas (May 31 2019 at 15:30):
Subscription is asking for something but is not listed in the request pattern. Is there a reason why
Lloyd McKenzie (May 31 2019 at 15:39):
It's a technical structure, not a clinical / business authorization.
Eric Haas (Jun 01 2019 at 00:53):
We redefined it as: "Describes a particular client's request to be notified about a Topic." @Josh Mandel was the intent to imply its a request. if so would be need to follow the resource pattern?
Lloyd McKenzie (Jun 01 2019 at 04:40):
It's not a clinical or business resource. It's like MessageHeader. None of the intents would make any sense. It should NOT try to follow the Request pattern.
Josh Mandel (Jun 01 2019 at 22:50):
I really don't know what the question means -- but if Lloyd says 'no,' then no :)
Lloyd McKenzie (Jun 01 2019 at 23:47):
Eric is suggesting that Subscription should need to align with this pattern: http://hl7.org/fhir/request.html
Josh Mandel (Jun 02 2019 at 04:28):
I understood that much -- but I still have no idea what the question means :)
Lloyd McKenzie (Jun 02 2019 at 04:35):
Is Subscription in the same category of resources as MedicationRequest, ServiceRequest, DeviceRequest, VisionPrescription, etc.?
Jose Costa Teixeira (Jun 02 2019 at 06:39):
Request is - at the moment - an authorisation stating that something may/should/could be done and responded to, or just delegated, or postponed, or postprocessed, and is kept in medical / financial records. We have a pattern to avoid weird ways of doing that kind of stuff. Say a committees wants to create a resource like "TransplantNeeded". or worse, a resource called "Transplant" with a mood/status flag "needed / done" - this is what the pattern is avoiding.
Subscription seems a technical way for a system to enable another to send it updates of whatever is on the server that matches some criteria. It is not an actionable request as the former. So I understand it is not in the request. I can understand that it implies some functionality, but it is not in the level of the requests. Perhaps @Eric Haas is looking at it from a purely functional perspective, where it would make sense to keep track of subscriptions, e.g. for auditing purposes. We could address that but at a first glance i don't equate Subscription and Request. but there is no harm in seeing what could be harmonized there, as a one-off.
René Spronk (Jun 02 2019 at 17:00):
Also see http://build.fhir.org/messaging.html#3.4.1.1 , currency (which includes subscriptions, subscriptions are a kind of query) vs consequence
Last updated: Apr 12 2022 at 19:14 UTC
