Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RonObbens opened this issue Jul 21, 2024 · 4 comments

Comments

@RonObbens
Copy link
Contributor

RonObbens commented Jul 21, 2024

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.

@RonObbens RonObbens changed the title ADR 4; volledigheid van lokalisatie ADR 4; volledigheid van lokalisatie; Altijd inzicht in welke partijen gegevens hebben, niet altijd in de daarbij behorende metadata Jul 21, 2024
@VWSLANS
Copy link
Contributor

VWSLANS commented Jul 23, 2024

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.

  • Losse ADR voor volledigheid/datakwaliteit, bijvoorbeeld vullen van de NVI

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

@RonObbens
Copy link
Contributor Author

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
Copy link

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.

@albertvlug
Copy link

het vullen van de NVI vanuit een LMR is om twee redenen niet handig:

  1. je bent afhankelijk van een werkende LMR, mist een veel belangrijker eerste stap (nl NVI) als een minder belangrijke tweede stap niet werkt. er is dan geen mogelijkheid om obv NVI de bron rechtstreeks te benaderen
  2. het standaardiseren van de LMR (aan EPD kant) gaat nog jaren duren, met NVI kan je vandaag beginnen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants