Technische oplossingsrichting wordt kort en bondig uitgelegd wat er technisch nodig is om de wens te kunnen realiseren. Dit kan via tekst, plaatjes. Daarnaast wordt toegelicht welke (internationale) standaarden gekozen worden voor toepassing binnen de oplossing.
Uitwerking(en) technische oplossingsrichting
De onderstaande technische oplossingsrichting is vastgesteld tijdens de visiegroep bijeenkomst van dd-mm-jjjj
Oplossingsrichting
...
Oplossingsrichtingen
In het extra ingelaste leveranciers tech meetup d.d. 26 oktober 2023 zijn een aantal opties overwogen. Deze zijn (copy-paste uit de notulen):
Voorkeur: Extension toevoegen:
Met 2.0 mee
In 2.1 pas meenemen
Nieuwe optie: Gebruik van de OperationDefintion
Impl op additionele queryparams die ondersteund moeten worden (lastUpdated, status)
Niets doen: Laten zoals het is custom oplossingen behouden,
enkel de Itzos aanpassing, ref. impl moet Itzos volgen
Null optie: Weghalen uit de standaard en search parameter en Subscription op alle taken.
Extension toevoegen
Deze lopen we in het onderdeel Voorgestelde oplossingsrichting door.
Gebruik van de OperationDefintion
Dit is een zogenaamde “Named query” of “Stored procedure” die in de FHIR service kan worden aangeroepen. Anders dan een tijdelijke aanduiding (placeholder) is dit niet: iedere FHIR resource service moet deze op eigen wijze implementeren. Deze oplossingsrichting kan niet gebruikt worden in zoekparameters en chaining. Voor abonnementen kan deze dus niet gebruikt worden. Men dient te abonneren op bijvoorbeeld alle taken, en kan dan op een notificatie alleen taken voor zichzelf opvragen middels deze OperationDefinition. Hierdoor worden alleen de eigen taken teruggegeven, maar worden er waarschijnlijk onnodige notificaties uitgestuurd.
Niets doen
Eigenlijk gelden hiervoor dezelfde beperkingen als met de OperationDefintion, met als toevoeging dat het geen gestandaardiseerde manier is om met de afwijking om te gaan.
Null optie
In deze oplossingsrichting wordt geadviseerd een abonnement (Subscription) te nemen op alle taken (Tasks) en bij het ontvangen en ophalen te filteren op relevantie. Hiermee wordt aan het doel van Koppeltaal 2.0 voorbijgeschoten om gegevens enkel te delen met de relevante partijen. Als interimoplossing valt deze richting eventueel wel te overwegen.
Voorgestelde oplossingsrichting
De leveranciers spreken de voorkeur uit aan het Task een extensie toe te voegen waarmee via een reference (in plaats van een canonical reference) de taak (Task) aan de module (ActivityDefinition) wordt gekoppeld. Hiermee wordt het mogelijk zowel het abonnement (Subscription) als het zoeken correct te laten werken.
...
Met deze oplossingsrichting wordt het probleem in de kern opgelost. Hoewel het hier een afwijking van de standaard FHIR taak (Task) betreft, is het gebruik van extensies in Koppeltaal reeds wijdverbreid.
De volgende vragen zijn dan van toepassing:
Kan het profiel tijdig worden aangepast? De voorkeur van de leveranciers is dit in versie 2.0 mee te nemen.
Is het noodzakelijk de instantiatesCanonical in stand te houden of juist niet? In principe is het overbodige informatie, en bovendien werkt een canonical referentie anders dan een referentie op het gebied van versiebeheer. Het laatste gebruiken we (nog) niet in koppeltaal 2.0.