search

minvws / generiekefuncties-lokalisatie

Repo generiekefuncties-lokalisatie for minvws
https://irealisatie.nl
1 stars 3 forks source link

ADR 4; volledigheid van lokalisatie; Altijd inzicht in welke partijen gegevens hebben, niet altijd in de daarbij behorende metadata #17

Open RonObbens opened 1 month ago

RonObbens commented 1 month ago

Gezien de gedistribueerde aard van de architectuur kan het voorkomen dat een lokalisatie vraag vanwege uitval van een van de betrokken systemen geen volledig antwoord kan krijgen.

Hoe gaan we om met deze uitval, 2 situaties:

  1. De of een van de NVI's werken niet: je weet niet wat je mist.
  2. Een van de LMRs werkt niet: je weet dat er gegevens missen en bij welke bronhouder dit staat.

UX: hoe informeer je de gebruiker hier over?

Hoe ontwerpen we een systeem wat om kan gaan met deelresultaten/onvolledige antwoorden? Hoe ontwerpen we een systeem dat je zo veel mogelijk weet waar er gegevens staan, dus de NVI moet antwoord kunnen geven, of de NVI informatie moet je lokaal kunnen cachen.

Vraag aan de requirements groep

  1. Heeft een onvolledig overzicht nog waarde, of is dat afhankelijk van de use-case?

Relatie met andere ADRs

De topologie zoals besproken in #15, bepaald voor een deel of we te maken hebben met 1 of meerdere NVIs en of de data gecached kan worden.

Aannames

Deze ADR stelt dat (met uitzondering van calamiteiten) een lokalisatie vraag een volledig beeld moet geven van alle partijen die data over een patiënt hebben voor een bepaalde uitwisseling. Dus situatie 1 ten alle tijden voorkomen.

Het uitgangspunt is dat een onvolledig antwoord een onwerkbaar resultaat oplevert voor de zorgmedewerker. Dit betekent dat een lokalisatie vraag altijd antwoord geeft welke partijen gegevens hebben. Het is in dergelijke gevallen dus wel nodig inzicht te krijgen in welke partijen gegevens hebben, maar de metadata die daarbij in het antwoord normaliter wordt meegegeven blijft in dergelijke situaties achterwege. Daardoor is dan onduidelijk welke onderzoeken er beschikbaar zijn (bijvoorbeeld vanwege tijdelijke onbeschikbaarheid van de bron). Deze onderzoeken kunnen dan op een andere manier worden opgevraagd bij de in het antwoord verkregen partijen.

VWSLANS commented 1 month ago

NVI: Centraal voordeel van volledigheid op 1 plek. Lost het probleem van datakwaliteit niet op. Maakt het wel makkelijker om hiaten in volledigheid op te sporen.

LMR: Inzicht get geven in hoeveel van LMR's beschikbaar zijn. Delen door het aantal bronnen uit de NVI.

RonObbens commented 1 month ago

uitdaging van data kwaliteit speelt in dit geval volgens mij niet. We willen dat vanuit een LMR gegevens direct worden gepushed naar de NVI. Direct na registratie van die gegevens in de bron. Daarmee ondervangen we die uitdaging op data kwaliteit volgens mij.

bramwesselo commented 3 weeks ago

Het grotere (functionele) probleem wat hier geadresseerd wordt is data-kwaliteit; krijg ik als zorgverlener een compleet (en bruikbaar!) beeld van de data van de patient? Dit probleem is een meerkoppig monster en, om kort door de bocht te gaan, het functioneren van de NVI, LMR's of de daadwerkelijke dossierhouder-endpoints is, m.i., een van de kleinere issues.... Mijn voorstel zou zijn om, uitgaande van 1 NVI per patient, de gebruiker terugkoppeling te geven dat de NVI niet werkt (dan gaat er niets...en dus pech gehad) of terug te koppelen welke LMR's/dossierhouder-endpoints er niet functioneren. Alle data die wel opgehaald is, wordt verder wel getoond.