Technical Specifications PoC 8 "eOverdracht"

[jorritspee]

Input Script

The demo is performed by couples of two parties: the Sender and the Receiver.

Steps:

1. Before: Receiver shall publish a representative selection of real life organizational entities in a mCSD Directory.
2. The demo consists of showing a transfer where an eTransfer application uses the GF Addressing to find a healthcare service and location of the receiver and obtain the associated endpoint.
3. The receiving organization can show that the transfer comes to the right location/part of the organisation instead of a general or organization-wide list/inbox.

Roles per vendor

Leverancier	PoC 8 Bronhouder/Sender	PoC 8 Raadpleger/Receiver
HINQ	N	J
Nedap	J	J
Gerimedica	J	J
NLcom	J	N
KPN	J	J
Bastionic	J	N

Principles

1. Authentication and Authorization are officially out of scope of PoC 8.
2. We use the current version of GF Authentication as a light weight form of authentication that is compatible with Knooppunt.
   • Rationale:
     • we need a way to communicate the URA between Sender and Receiver anyway.
     • The GF Authentication can be implemented using a Nuts v6 node
     • Many vendors already have Nuts v6 node in place so this seems like a pretty lightweight way to do this.
   • Current eOverdracht implementations use Nuts v5. It is hard/impossible to implement GF Authentication using Nuts v5. A Nuts v6 node can easily be deployed alongside with Knooppunt
3. We use x509Credentials based on fake or test UZI-server-certs to identify and authenticate Sender and Receiver
4. We do not authenticate persons
   • out of scope
5. We use the STU3 Task that is defined in TA Routing (eOverdracht-Task + extensions for .location and .healthcareservice = new profile), because we need Task.location and we need Task.healthcareservice to refer to a HealthcareService.
   • Rationale: The eOverdracht Task will use the TA Routing Task in the near future.
   • Rationale: Current eOverdracht Task is not suitable for handoff/referral to Organization Depts/ HealthcareServices so it needs changes anyway. We choose to change to the needed Task-format (TA Routing Task) in one go. See new profile for eOverdracht-Task.
6. We use the current eOverdracht notification mechanism (empty HTTP POST)
   • Rationale: We already make some changes to eOverdracht (Nuts v5 --> v6, eO-Task --> TA Routing-Task). We think also changing the notification mechanism is too much in one go
   • Rationale: The most logical choice for notification is to use FHIR Notifications but that's a pretty impactful change (think about counters and stuff)
7. We use the current eOverdracht STU3 resource profiles (but new eOverdracht-Task profile with 2 extensions for .location and .healthcareservice)
   • Rationale: minimize changes in current FHIR-data
   • Rationale: mixing STU3 for 'data' and Tasks and R4 for mCSD/Addressing seems like a bad idea. But we need to be able to support two FHIR-versions in parallel anyway to be able to implement new information standards (usually a dakpan-constructie is used in The Netherlands where at 1 point in time 2 versions need to be supported).
8. Data in scope is: Composition, Patient (in intersection of BgZ and eOverdracht), BloodPressure (in intersection of BgZ and eOverdracht), BodyWeight (in intersection of BgZ and eOverdracht)
   • Rationale: This PoC is not about data. But we need some data to show that it works. I just picked 3 profiles that are the same in eO and BgZ and are lightweight.

Specifications per step

Step 0: Preparation

1. Deploy Nuts node as part of Knooppunt or independent
2. Create Organization Identity: https://wiki.nuts.nl/books/implementing-a-nuts-use-case/page/1-create-organization-identity
3. Use x509credential based on fake or test uzi cert

Step 1: Publish HealthcareServices, Endpoints, Locations

1. Receiver publishes a HealthcareService with the correct .type
   • see example: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/TA-routering-update-examples-eOverdracht/HealthcareService-b48826dc-2d58-479a-bfd3-80b7a9d69757.json.html
2. Receiver publishes 2 or 3 Locations with the correct identifier, like https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/TA-routering-update-examples-eOverdracht/Location-9a2b8f1c-4e7d-42a1-b3c9-2d5e8f7a6c1b.json.html.
   • For Organizations the URA is the correct identifier.
   • For Org Depts/ Locations each organization can make up their own identifiers. See https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/identification.html#data-object-identification.
3. Receiver publishes eOverdracht-notification endpoint
4. Sender publishes fhir endpoint
5. Endpoints (except for mcsd query endpoint) are linked to the related healthcare services
6. Receiver and Sender publish mcsd query endpoints
7. Receiver and Sender publish OAuth server endpoint
8. Mcsd query and OAuth endpoints are linked to top-level organization(s)
9. Sync mCSD admin directories so that both Sender and Receiver have the same info in it.

Step 2: Sender sends notification

1. Sender XIS performs search at local Query Directory:
   PoC 8:

GET <fhir-base-url>/HealthcareService?service-type=6VV

2. Select the Location and Healthcareservice in Sender XIS that offers the combination of:
   • Location ('near home' ?)
   • AND HealthcareService.type (service-type= 6VV)
   • AND HealthcareService.endpoints support all needed payloadtypes
     • an Endpoint supporting payload-type=eOverdracht-notification (GET /Endpoint?payload-type=eOverdracht-notification)
     • AND an Endpoint supporting payload-type=Nuts-OAuth
3. Sender XIS fetches the correct Organization department in Sender XIS (Healthcareservice.providedBy)
4. Sender XIS constructs an eOverdracht Composition
   • that conforms to https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht/4.0.0/files/2424046
   • and stores it on own Resource Server
5. Sender XIS constructs a Task
   • that conforms to the new eOverdracht Task profile.
   • This is the original profile
   • but with extension for the .healthcareservice (step 2.2) and an extension for the .location (step 2.3) elements
   • the reference to the healthcareService and location MUST include the author-assigned-identifier when present
   • and stores it on own Resource Server.See also this example: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/branches/TA-routering-update-examples-eOverdracht/eOverdracht-Task-eov-test-1_1b-REQUESTED.xml
6. Sender finds correct Notification-endpoint-url of Receiver via found HealthcareService. Endpoint.payloadType="eOverdracht-notification"
7. Sender finds correct OAuth-endpoint-url of Receiver via found HealthcareService. Endpoint.payloadType = "Nuts-OAuth"
8. Sender requests access token from Receiver for its Notification endpoint:
   • using policy eOverdracht-receiver, see https://github.com/nuts-foundation/hackathon-resources/blob/main/gf-test-2026/test/eOverdracht-policy.json
   • This policy requires the presentation of a X590credential that contains the URA of Sender
   • See https://wiki.nuts.nl/books/implementing-a-nuts-use-case/page/requesting-access-outbound
9. Sender notifies Receiver by sending an empty POST
   • use the access token from the step above
   • See 5.3.2 of the eOverdracht spec

Step 3: Receiver fetches and shows Task-info and data

1. Receiver XIS receives incoming notification-request (result of step 2).
2. Introspect incoming access token
3. Find correct endpoint of Sender FHIR-API using the URA from incoming access token
4. Receiver finds correct OAuth-endpoint-url of Sender by querying its own Query Directory. Endpoint.payloadType = "Nuts-OAuth". NB: This endpoint should be referred from one of the (top-level) Organization.endpoints
5. Receiver XIS fetches Task: request access token
   • See https://nuts-foundation.gitbook.io/bolts/eoverdracht/leveranciersspecificatie#id-5.3.3-ophalen-task
   • but with the following changes:
     • Receiver requests access token from Sender for its FHIR-endpoint:
     • using policy eOverdracht-sender, see https://github.com/nuts-foundation/hackathon-resources/blob/main/gf-test-2026/test/eOverdracht-policy.json.
     • This policy requires the presentation of a X590credential that contains the URA of Receiver
     • See https://wiki.nuts.nl/books/implementing-a-nuts-use-case/page/requesting-access-outbound
6. Receiver XIS fetches Task: send read-request on Task
   • use the access token from the step above
   • use the identifier that was part of the received Notification-Empty-HTTP-POST from step 2. https://nuts-foundation.gitbook.io/bolts/eoverdracht/leveranciersspecificatie#id-5.3.3-ophalen-task
7. Receiver XIS fetches HealthcareService:
   • by querying its own Query Directory if identifier is included in Task.healthcareservice, or
   • send read-request on HealthcareService (Task.healthcareservice). use the access token from the step above.
8. Receiver XIS fetches Location:
   • by querying its own Query Directory if identifier is included in Task.location, or
   • send read-request on Location (Task.location). use the access token from the step above.
9. Receiver XIS show correct .name of receiving HealthcareService AND Location in UI
   • This is the minimum
   • If your applications supports more advanced functionality (e.g. a healthcareservice/location/sub-organisation level inbox or working list) I think you should show this
10. End user wants to show eOverdracht/BgZ-resources.
    • Receiver XIS follows the reference in Task.input for the Composition
11. Receiver XIS requests access token (see Step 2.4) and
    • fetches Composition (see step 2.5).
    • get Patient, BloodPressure, BodyWeight from Composition
12. Receiver XIS shows the FHIR-resources that it supports
    • Patient (in intersection of BgZ and eOverdracht)
    • BloodPressure (in intersection of BgZ and eOverdracht)
    • BodyWeight (in intersection of BgZ and eOverdracht)
    • STU3
    • https://informatiestandaarden.nictiz.nl/wiki/vpk:V4.0_FHIR_eOverdracht#HCIM_profiles
13. The end

[SimonVeldhuijzen]

Step 1:

• Receiver publishes eOverdracht-notification endpoint
• Sender publishes fhir endpoint
• Receiver and Sender publish mcsd query endpoints
• Endpoints (except for mcsd query endpoint) are linked to the related healthcare services
• Mcsd query and oauth endpoints are linked to top-level organization(s)

Step 2.1:

• The "supports the needed payload types" is not included in this query

Step 2.5:

• Should we be explicit that the reference to the healthcareService and location should include the author-assigned-identifier when present?

Step 2.8 & 3.5:

• Incorrect policy, see https://github.com/nuts-foundation/hackathon-resources/blob/main/gf-test-2026/test/eOverdracht-policy.json

Also: is showing the name of the location really enough to "show that the transfer comes to the right location/part of the organisation"?

[jorritspee]

Thanks for your review!

Step 1: processed
Step 2.1: processed. struckthrough that part
Step 2.5: yes I think so. I put it in as a MUST
Step 2.8: processed, inserted 'eOverdracht-receiver' with link
Step 3.5: processed, inserted 'eOverdracht-sender' with link

Also: is showing the name of the location really enough to "show that the transfer comes to the right location/part of the organisation"
It's the minimum yeah. I added some text to 3.9

[SimonVeldhuijzen]

You misunderstood step 2.1: we shouldn't strike-through step 2.2, but expand step 2.1. We should only search for 6VV-healthcare services that also support eOverdracht

[bramwesselo]

I rewrote 2.2 a little to make it more to the point. I'm proposing multiple queries here (a HealthcareService-query and an Endpoint-query. Doing this in a single query requires more advanced fhir search parameters (e.g. '_filter') to work, which is probably not implemented currently (it's also no requirement in GF Adressing)

[SimonVeldhuijzen]

Another point: when publishing endpoints we need to be clear on what system/codes we use

[bramwesselo]

The GF Endpoint profile specifies this codesystem (and codes) to use: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/CodeSystem-nl-gf-data-exchange-capabilities.html

[bgoorden]

The url on the documentation page wiki.nuts.nl for getting the access token are incorrect. The auth and v2 are switched in the path.

[jorritspee]

Thanks, changed it!