Geplande FSH-uitwerking
Nog een nadeel van de voorgestelde implementatie, we moeten het profiel van de Patient uitbreiden. Alsjeblieft niet doen!
5 Matching Annotations
- Last 7 days
-
vzvznl.github.io vzvznl.github.io
-
-
Backfill bij initiële rollout
deze beschrijving is onnodig complex door de implementatie-keuze om de datum van laatste betrokkenheid in een extensie op te slaan. Kunnen we deze beschrijving terug brengen naar een functionele specificatie, dat zal de beschrijving sterk vereenvoudigen.
-
In een eerdere versie van het ontwerp werd "laatste betrokkenheid" telkens afgeleid uit het nieuwste relevante AuditEvent. Deze afleiding is in deze iteratie vervangen door een expliciete state op de Patient. Redenen: Eén resource-read in plaats van een tijdsgebonden search: voor de activiteitscheck vóór Deleted is één GET op de Patient voldoende. Ondersteuning voor zelf-inloggende applicaties: applicaties die hun eigen onboarding doen (zie hieronder) hebben geen Koppeltaal-AuditEvent bij elke gebruikersactiviteit; ze kunnen wel direct de meta-extension bijwerken. Eén canonieke bron van waarheid: het verwijdermoment wordt afgeleid uit één veld, niet uit een (potentieel inconsistente) verzameling AuditEvents.
Bij elk van deze punten zijn er ook tegenargumenten: - Elke wijziging van de datum leidt nu ook tot een **update ** van de patient resource, wat leidt tot erg veel extra versies van de Patient-resource. Dat terwijl database-queries (zeker voor IRIS) juist goedkoop zijn. - De tegenhanger van dat applicaties zichzelf ook met deze datum mogen bemoeien is dat elke applicatie nu ook bewust dat moet doen om te voorkomen dat die datum onbewust wordt overschreven of een onterechte waarde krijgt. Je kunt in mijn beleving niet allebei! Mijn advies is om alleen events te definiëren die de datum beïnvloeden, en op basis daarvan de datum af te leiden. - Voor mij is niet helder welke business-requirement hierom vraagt. Als er een wens is om extern te kunnen zien wat de datum van laatste betrokkenheid is kan die als een readonly-extensie worden toegevoegd bij het opvragen. Lijkt me goed om te bespreken!
Zie ook mijn commentaar op https://vzvznl.github.io/Koppeltaal-2.0-FHIR/opschoning-patient-data.html#startmoment-bewaartermijn-moet-eenduidig-zijn.
-
Een RelatedPerson is per definitie gekoppeld aan één specifieke patiënt; activiteit van de RelatedPerson telt als betrokkenheid bij die patiënt
Tijdens ons vorige overleg is expliciet gezegd dat dit niet zo zou zijn.Maar als het wel gewenst moet expliciet worden gemaakt wat met "activiteit" wordt bedoeld.
-
-
vzvznl.github.io vzvznl.github.io
-
Dit moment wordt vastgelegd als expliciete state op de Patient resource zelf, in een dedicated extension onder Patient.meta. Dit vervangt de eerdere benadering waarbij de laatste betrokkenheid telkens werd afgeleid uit het nieuwste AuditEvent: een expliciete waarde op de Patient is leesbaar zonder AuditEvent-query, ondersteunt apps die buiten de standaard launch-flows om hun eigen onboarding doen, en geeft één canonieke bron van waarheid voor het verwijdermoment.
Het opslaan van een afgeleide datum in de Patient-resource heeft nogal wat gevolgen, onder andere dat er heel veel versies van de Patient-resource zullen ontstaan. Ook moeten alle aangesloten applicaties nu expliciet logica toevoegen om om te gaan met deze extensie om te voorkomen dat deze wordt overschreven.
Het opnieuw bepalen van deze datum is minder complex vergeleken met alle logica die nodig is om bij de verschillende triggers steeds de Patient resource te updaten.
Kortom, ik vind dit geen goed idee.
-