-
Type:
Change Request
-
Resolution: Persuasive with Modification
-
Priority:
Highest
-
FHIRCast (FHIR)
-
0.1 [deprecated]
-
Imaging Integration
-
(NA)
-
Event Notification
-
-
Eric Martin / Bill Wallace: 8-0-0
-
Correction
-
Compatible, substantive
This requires the application to decide and report this within the context of the http call.
This basically requires the hub to send all events in parallel and not in turn. In the case of user interaction, this might take some time, even more than 30 seconds. Especially as there. might be more than application requesting this…
As indicated above. The HTTP response should mean message received. Success full processing could be handled with a new syncerror type event, e.g. message-processed.
Existing Wording:
If the subscriber cannot follow the context of the event, for instance due to an error or a deliberate choice to not follow a context, the subscriber SHALL respond with an HTTP error status code as described in Event Notification Response. If the Hub does not receive a successful HTTP status from a event notification, it SHOULD generate a syncerror event to the other subscribers of that topic. A syncerror notification has the same structure as the other event notification with a single FHIR OperationOutcome as the event's context.
- is voted on by
-
BALLOT-11377 Negative - Bas van den Heuvel : 2020-Feb-FHIRCast R1 STU
- Balloted
- relates to
-
FHIR-25849 Does a success mean: has been received or does it mean that the application has changed to reflect the change?
-
- Resolved - No Change
-
-
FHIR-25850 Why not sending the Event Notification Response as an event?
-
- Resolved - No Change
-
-
FHIR-25851 Does the subscriber need to subscribe to syncerror event?
-
- Resolved - No Change
-