Let op: Deze subtype-code zit niet standaard in http://hl7.org/fhir/R4/valueset-audit-event-sub-type.html, dus vereist aanpassing van het profiel

TOPIC 11 spreekt specifiek over event type User Authentication. Op dit moment wordt er in de voorziening een User Authentication event met subtype https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_D.html#DCM_110122 Login gelogd indien er delegated authentication plaatsvindt, niet voor elke /authorize.

Dat moet echter altijd gebeuren, ook als geen delegated authentication plaatsvindt, of als die mislukt en de externe idp niet terugstuurt naar het redirect endpoint

Mijn (aangepaste) voorstel is om bovenstaande zo te laten, maar daarnaast bij elke /authorize een User Authentication event met subtype https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_D.html#DCM_110144 Authorization Decision te loggen.

Let op: Deze subtype-code zit niet standaard in http://hl7.org/fhir/R4/valueset-audit-event-sub-type.html, dus vereist aanpassing van het profiel

@RolandGroen, Kees had voorgesteld om hier hetzelfde proces toe te passen als bij de 3 bestaande bronnen hierboven. Het zou overzichtelijker om deze situatie daar als 4e conditie op te nemen in plaats van als edge-case.

@RolandGroen , het plaatje mixt nu de Task-status en de Patient lifecycle status. De Task.status canceled wordt gebruikt maar valt niet op want in status staat "Actief". Net zo goed de Task.status completed valt niet op omdat in de status staat "Deleted". Ik zou fan zijn van dat alle blokjes de Task.status te geven.

Op dit moment lijkt de DELETE_HOLD status oneindig lang te kunnen duren. Zijn er hier verdere afspraken nodig? Bijvoorbeeld na gereedkomen resultaat delen mag deze maximaal 30 dagen duren?

1. Lengte van grace period moet worden afgesproken als deel van de IG. Voorstel: 14 dagen
2. Startmoment van de grace period moet ergens worden vastgelegd, of kan worden afgeleid vanuit laatste delete-initiated AuditEvent voor de patient.

Dit deel is nog wat complex en vraagt nogal veel aanpassingen in zowel voorzieningen als applicaties.: 1. Het zetten van de DELETE_PENDING tag mag niet gezien worden als een wijziging op de Patient omdat daarmee Patient-resources die 2 jaar bestaan en waarvoor nog nooit een Task is aangemaakt of Launch is uitgevoerd weer terug komt in een status dat die gewijzigd is en dus altijd blijft bestaan. Dit vraagt over verduidelijking van de verwachtingen ten aanzien van $meta-add. Specifiek: * Geen wijziging van meta.lastUpdated en meta.version * Geen REST Audit event * Daarom ook geen notificatie op basis van de standaard Patient-subscription (want de Patient is volgens bovenstaande niet gewijzigd) 2. De te versturen AuditEvents zijn nog niet voldoende gespecificeerd 3. Wat betreft de Notificaties: * Het is mijns inziens niet gewenst dat applicaties op de bestaande Patient subscription ook de delete_pending notificaties krijgen, dat zal alleen maar lijden tot verwarring * Omdat het gebruik van de noodrem feitelijk ongewenst isen als een advanced usecase moet worden gezien is het geen enkel probleem als applicaties geen subscriptie hebben * Al het bovenstaande pleit voor een specifieke subscriptie- en notificatie-endpoint voor alle notificaties rond het opschonen van patientdata * Ik ben van mening dat juist een subscriptie op de relevante AuditEvents het meest duidelijk en krachtig is.

Het is voor mij niet duidelijk wat het doel is van deze voorbeelden, het is wat verwarrend omdat de eerder bepaalde last-patient-engagement zoals ik het begrijp allesomvattend is, en hier lijkt te worden aangevuld met nog iets anders?

Nog een nadeel van de voorgestelde implementatie, we moeten het profiel van de Patient uitbreiden. Alsjeblieft niet doen!

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.

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.

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.

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.