...
|
Referentie integriteit
Aanname is dat de gebruikte FHIR (Resource) Provider referentie integriteit afdwingt, waardoor resources altijd moeten worden aangeboden in zo'n volgorde dat referenties verwijzen naar reeds bestaande resources. Bijvoorbeeld in het geval dat er een eHealth Taak wordt aangeboden, zullen dus eerst de eHealth Activiteit (ActivityDefinition) en de Patient resource (waarnaar deze eHealth Taak verwijst) moeten bestaanDe FHIR resource service MOET referentiële integratie afdwingen. Dit houdt in dat er enkel naar resources gerefereerd kan worden indien deze ook daadwerkelijk bestaan in de FHIR resource service. Deze integriteit MOET op zowel “write” als “delete” interacties gewaarborgd worden.
Write integriteit
Aangezien gerefereerde resources altijd moeten bestaan, is de volgorde van resources aanmaken van belang. Bijvoorbeeld bij het aanmaken van een Task , kan dit de volgorde zijn van resources aanmaken:
Patient → Practitioner → Endpoint → ActivityDefinition → Task
Delete integriteit
Koppeltaal raadt het gebruik van deletes af [TODO: Link Lifecycle]. Indien dit toch gebruikt wordt, moet de referentiële integriteit bewaakt worden. De regel is: een referentie MOET refereren naar een bestaand, non-deleted, object. Zo is het verwijderen van een Task vaak simpel, omdat hier nauwelijks naar gerefereerd wordt. In het geval van een Patient delete is de kans op integriteitsproblemen veel groter. Een Task of een Practitioner verwijzen bijvoorbeeld vaak naar een Patient resource. Indien een delete niet voldoet aan de referentiële integriteit MOET de server de request afkeuren middels met een HTTP 409 Conflict .
Eisen
IDR - Eisen (en aanbevelingen) voor identifiers en referenties
...