separate notification page - #106
Conversation
|
@stevenvegt ; enkele punten ter overweging:
|
stevenvegt
left a comment
stevenvegt
left a comment
There was a problem hiding this comment.
Nice write-up! Some small comments. Especially about the completeness of the subscription status and notification delivery system. Can we have a light version which works on a status code (200 means the client has received the notification) instead of the client needing to keep books on the event numbers etc. and using the $event and $status operations?
I'm not against a full version, the nuts-community will probably implement a full open source version of it, but other parties might find this too much work?
| Here is a brief overview of the processes that are involved: | ||
|
|
||
| 1. At the sending organization (the [Subscription Server](#subscription-server)) a `Subscription` is registered for the receiving organization (the [Subscription Client](#subscription-client)) against an agreed `SubscriptionTopic`. How this `Subscription` is created is use-case defined (in-band or out-of-band); see [Subscription](#subscription). | ||
| 2. After registration, the Subscription Server sends a `handshake-notification` to confirm the channel and updates `Subscription.status` accordingly. |
There was a problem hiding this comment.
Is this always needed, same question for the heartbeat? In an out-of-band subscription, the subscription server is always in control and the notification is "just a POST", so no book keeping needed?
|
|
||
|
|
||
|
|
||
| ### Components (actors) |
There was a problem hiding this comment.
The following requirements are a very good ways of ensuring data delivery. But they also require some thorough implementation work. That is all right if we decide we require this. We might also decide to start with an light weight version first. It should not be seen as an argument for just using a task because it is much simpler, since a task also does not bring you these guarantees.
|
|
||
| #### Subscription | ||
|
|
||
| A `Subscription` is created at the **sending** organization for a **receiving** organization before any notifications flow. The pattern is a **broad, long-lived Subscription per partner** for a given use-case topic, not a Subscription per case. A single Subscription covers all events that match the topic and filter between the two partners. |
There was a problem hiding this comment.
Here you use the organization roles, above the system roles. Not sure if that is intentional, I just wanted you to be aware of it.
| A `Subscription` is created at the **sending** organization for a **receiving** organization before any notifications flow. The pattern is a **broad, long-lived Subscription per partner** for a given use-case topic, not a Subscription per case. A single Subscription covers all events that match the topic and filter between the two partners. | ||
|
|
||
| How the Subscription is created is **use-case defined**: it MAY be created in-band (the client POSTs a Subscription to the server) or out-of-band. | ||
| For out-of-band managed subscriptions, the receiver's notification endpoint is typically resolved via the addressing function ([Care Services Query Directory](./care-services.html#query-directory)); see the [endpoint discovery example](./care-services.html#use-case-2-endpoint-discovery). An Endpoint capable of receiving notifications is defined by `connectionType = hl7-fhir-rest` and `.payloadType = Subscription` (see [Endpoint profile](./care-services.html#endpoint). |
There was a problem hiding this comment.
.payloadType = Subscription accidental . at the beginning?
|
|
||
| | Step | Resource | Referral (single candidate) | Transfer of care (multiple candidates) | | ||
| |------|--------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | 1 | Subscription | [np-referral-subscription](Subscription-np-referral-subscription.html) | [np-eov-subscription](Subscription-np-eov-subscription.html) (one per candidate Fulfiller) | |
There was a problem hiding this comment.
still would like to see these here
|
Why put the examples under routing? |
|
|
||
| - set `Subscription.status = active` while in use and `off` to retire the channel; | ||
| - set `Subscription.channel.type = rest-hook` with the Fulfiller's notification endpoint; | ||
| - identify the sending organization via the R5 cross-version `Subscription.managingEntity` extension, using a URA identifier; |
There was a problem hiding this comment.
You'll need this to identify the sending organization.
845d7c0 to
0cc9d78
Compare
2 participants
No description provided.