...
Wie
...
Wat
...
Waarom
...
Kwaliteitsaspecten
...
Inleiding
Als leverancier wil je in Koppeltaal een abonnement (Subscription) kunnen afsluiten op alle activiteiten die worden aangemaakt op de modules (ActivityDefinitions) die je als leverancier hebt gemaakt. Omdat je als leverancier potentieel heel veel modules publiceert, wil je niet voor elke module een los abonnement (Subscription) aanmaken. Dit type abonnement is enigszins ‘de kern van Koppeltaal’ als het gaat om wat moduleleveranciers van Koppeltaal 2.0 doen; bijhouden welke taken worden aangemaakt in je platform.
Het probleem
Het pad van taak (Task) naar leverancier ziet er als volgt uit:
...
Het probleem blijkt dat in FHIR R4 het chainen van zoekpaden over het datatype canonical niet is toegestaan. Hierdoor is binnen de FHIR standaard het onmogelijk om als leverancier gemakkelijk een abonnement af te sluiten op taken die voor je eigen module (ActivityDefinitions) worden aangemaakt.
Laten we duidelijk zijn dat dit binnen de FHIR standaard zo geldt, zowel de implementatie van InZos als de referentie implementatie op basis van HAPI hebben beide manieren gevonden om hier omheen te werken. Wat impliceert dat, indien deze manier aangehouden wordt, alle FHIR services dit specifiek voor koppeltaal moeten gaan oplossen en implementeren.