Stream: subscriptions
Topic: Subscription Validation
Jenni Syed (Sep 30 2018 at 18:11):
More on the "asynch" subscription workflow:
- App/GP POSTs Subscription in requested status
- Subscribe request goes to a queued process that will check privs/capability
- At some point, this will be confirmed to be a valid or invalid request
Thoughts:
- Could leave it in a requested status, but the part of the spec that requires the OperationOutcome won't be met for the error status. App won't know immediately that it was rejected, currently the POST response would indicate success.
- How does the app know that it eventually was reject?
- App could query the subscription and see that it's in "requested" or "error" or "active" later
- Could use the Asynch response pattern: http://hl7.org/fhir/2018Sep/async.html
- This is different than the use case described currently in the spec, but seems applicable to the general pattern as described by the RFC
- Content-Location would be the subscription URL, the status would change to error or active?
- 202 HTTP definition states that an entity can exist which provides detailed status, this could be the Subscription resource itself. If so, we need to adjust guidance on the asynch page to describe this.
Jenni Syed (Sep 30 2018 at 18:14):
@Dave Barnet @Christiaan Knaap @Isaac Vetter @Grahame Grieve @James Agnew thoughts?
Grahame Grieve (Sep 30 2018 at 18:45):
personally I don't think we need the async process for this. In principle, the subscription may fail for one of a number of reasons at any time. The client should periodically check that the subecription is ok whatever
Jenni Syed (Sep 30 2018 at 19:14):
It might be nice for the client to know that the 201 created response doesn't mean that it won't "immediately" go into an error (without the server attempting to contact/notify).
Last updated: Apr 12 2022 at 19:14 UTC
