Technical specifications PoC 9 "BgZ referral"

[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 an mCSD Directory.
2. The demo consists of showing a transfer where an eReferral application uses the GF Addressing to find a receiving healthcare service and obtain the associated endpoint.
3. The receiving organisation can show that the referral comes to the right healthcareservice/ part of the organisation instead of a general or organization-wide list/inbox.

Roles per vendor

Leverancier	PoC 9 Bronhouder/Sender	PoC 9 Raadpleger/Receiver
SYS (EPD DiSy)	J	N
Openline Vitaly	N	J

Principles

1. Authentication and Authorization are officially out of scope of PoC 9.
2. Put Sender URA in the Notification-Task
   • Rationale: This PoC only has 2 vendors: OpenLine and SYS. Authentication is out of scope.
3. We do not authenticate persons
   • out of scope
4. We use the current TANP notification mechanism (posting a 'Notification-Task')
   • Rationale: We already make some changes to TANP-BgZ. 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)
5. We use the current BgZ STU3 resource profiles
   • 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).
6. Data in scope is: 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 Knooppunt or another software that complies to the GF Addressing
2. Sender and Receiver Create Organization-resource and publish admin-directory url to (Llama-)Lrza-service

Step 1: Publish HealthcareServices, Endpoints

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
   • For Organizations the URA is the correct identifier.
   • For Org Depts each organization must make up their own identifiers. See https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/identification.html#data-object-identification.
2. 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:

GET /HealthcareService?type=MDT

or

GET /HealthcareService?providedBy=<<Receiver-Organization>>

3. Select the Healthcareservice in Sender XIS that offers the combination of:
   • HealthcareService.type (e.g. type = MDT)
   • AND the HealthcareService.endpoints support all needed payloadtypes (shall have an Endpoint supporting payloadtype=http://nuts-foundation.github.io/nl-generic-functions-ig/CodeSystem/nl-gf-data-exchange-capabilities|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities)
4. Sender XIS fetches the correct Organization department in Sender XIS (Healthcareservice.providedBy)
5. Sender XIS constructs a Workflow-Task
   • but with extension for the .healthcareservice
   • and stores it on own Resource Server.
6. Sender finds correct Notification-endpoint-url of Receiver via found HealthcareService. Endpoint.payloadType="TOBEDETERMINED"
7. Sender notifies Receiver by sending a Notification-Task
   • See example Notification Task here: https://github.com/nuts-foundation/nuts-use-case-profile-bgz-referral?tab=readme-ov-file#example

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

1. Receiver XIS receives incoming notification-request (result of step 2).
2. Find correct endpoint of Sender FHIR-API using the URA Notification-Task (Task.requester)
3. Receiver XIS fetches Task: send read-request on Task
   • use Notification-Task.basedOn.reference-element to find the reference to the (Workflow-)Task.
4. 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).
5. Receiver XIS show correct .name of receiving HealthcareService in UI
6. End user wants to see BgZ-resources.
   • Receiver XIS follows the references in Task.input for Patient, BloodPressure, BodyWeight
7. Receiver XIS fetches
   • Patient,
   • BloodPressure,
   • BodyWeight
8. 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
9. The end

[gasperr]

the URA from the custom http-header/ Notification-Task --> @gasperr which one is it?

in the notification task

Step 0: Preparation
Deploy Knooppunt

or an alternative sync client/mcsd stuff, right? Knooppunt is not strictly required.

Step 1: Publish HealthcareServices, Endpoints, Locations

pre-step also that Organization needs to be present.

AND HealthcareService.type (type= TOBEDETERMINED?)

this query is not happening like that because in BgZ there is no specific use case. We're doing a BgZ referral for the purpose of the MDT so our HealthcareService.type is quite specific to that use case rather to the BgZ itself. SYS does a query on organization and then displays all our HealthcareServices (representing subdepartments).

Sender finds correct Notification-endpoint-url of Receiver via found HealthcareService. Endpoint.payloadType="TOBEDETERMINED"

endpoint type:
{
"coding": [
{
"code": "http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities",
"system": "http://nuts-foundation.github.io/nl-generic-functions-ig/CodeSystem/nl-gf-data-exchange-capabilities",
"display": "BGZ Server"
}
]
},

5. Receiver XIS fetches Location

No location part of this poc. Just HelathcareService-based routing.

[jorritspee]

Thanks Gasper. I think I processed all your feedback items.