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

Als persoon wil ik een overzicht van mijn (zorg)netwerk kunnen gebruiken om gegevens te lokaliseren. #42

Open
sergejvm opened this issue Oct 31, 2024 · 7 comments

Comments

@sergejvm
Copy link

sergejvm commented Oct 31, 2024

Eindgebruikers willen overzicht. Bijvoorbeeld in een specifieke situatie beheert iemand 40 zorgverleners, daarnaast ook andere betrokkenen die geen zorgrelatie hebben. Via dit netwerk kan je dan ook lokaliseren waar gegevens beschikbaar zijn. Als je daarbij steeds eerst de zorgaanbieder moet kiezen dan is dat veel werk. Kan dat vanuit een overzicht over het (zorg)netwerk? Ook delen van gegevens met anderen in dat netwerk wordt hiermee makkelijker.

In de norm is daarvoor een concept bundel zorgtraject. Daarin kunnen betrokken zorgverleners melden dat er gegevens zijn die daarbij horen en deze koppelen. Past deze requirement bij deze oplossingsrichting.

Hebben we het over lokalisatie van gegevens of van mensen? Bij deze mensen staan gegevens. Een zorgverlener is actief bij een zorgaanbieder, daar staan gegevens in een bron. Adressen daarvan staan in registers. De mensen zijn voor de burger het 'gezicht' van waar de gegevens staan.

Is de context hier het PGO als plaats waar je dit beheert? Nee breder dan PGO. Ook in PGO. Ook het PGO zelf is een bron die moet kunnen worden gelokaliseerd. Vanuit het proces van lokalisatie zou je deze samenvoeging niet willen, bijvoorbeeld om redenen van veiligheid. Er zijn relaties met andere generieke functies, waaronder IAA en adressering.

Scope van de requirements gaat nu over de grens van lokalisatie. Voorgestelde herformulering: Als persoon wil ik mijn persoonlijke (zorg)netwerk kunnen lokaliseren.

Ontluikende requirement (vraag). Hoe bepalen we de kwaliteit van lokalisatiegegevens?

Tweede herformulering. Als ik als burger een overzicht van mijn (zorg)netwerk heb dan kan ik dat gebruiken om gegevens te lokaliseren. Gegevens over de zorgverleners zijn ook lokaliseerbaar, zodat ik een netwerk zelf samen kan stellen.

Functie moet losstaan van de specifieke oplossing. Kan in een PGO, moet niet in een PGO, kan ook in andere omgevingen.

Is dit pro-actief vanuit de persoon, of breder? Ook zorgverleners willen zo'n functie. Extra requirements voor maken.

@sergejvm sergejvm converted this from a draft issue Oct 31, 2024
@jeroenvang
Copy link

Ik snap deze eis misschien niet goed. Ik snap dat je wellicht wilt kunnen zoeken en filteren in de antwoorden die je krijgt op een vraag die je stelt aan een lokalisatievoorziening, maar vraag me sterk af of dat een functionaliteit is die je in de lokalisatievoorziening moet (willen) oplossen. Stel me zo voor dat je dat (juist) in de eigen applicatie wil doen, zodat je het kunt combineren met gegevens die je daarin hebt (zoals info over het zorgnetwerk).

Of wordt hier wellicht bedoelt dat je - om dat je het zorgnetwerk kent - toch al weet wie je moet bevragen om info over een patiënt? In dat geval heb je dus eigenlijk helemaal geen lokalisatievoorziening nodig. Want dan gebruik je je eigen lijstje. Ook prima, maar lijkt me geen eis een de GF lokalisatie.

@VWSLANS
Copy link
Contributor

VWSLANS commented Dec 17, 2024

Guido. Begrip voor in meerdere trappen te kunnen voldoen. Bv eerste trap waar en vervolgens welke. In de NEN-norm is dit 1 geheel. Twee verschillende functie. Onderscheid tussen vinden van het netwerk en de gegevens. Relatie met #43

Bezwaar tegen het volledig loskoppelen van bronnen en welke gegevens. Enerzijds behoefte aan een zorgnetwerk (andere vraag en out-of-scope). Raakt aan tweede punt dat je de waar en welke vraag niet zou moeten willen ontkoppelen. 1 lokalisatie-flow. Dit heeft ook met security te maken. Je wil zeker weten dat de gebruiker de functie mag gebruiken. (Autorisatie).
AANVULLING GUIDO

Voorstel: 42 43 beschrijft dezelfde functionaliteit vanuit een andere rol.

Guido: Lokaliseer je gegevens of zorgaanbieders. Het kunnen vinden van gegevens die je kan lokaliseren.

Ron: Het netwerk meegeven als context.

@VWSLANS VWSLANS moved this from Opgesteld to Beoordeeld in GF Lokalisatie Requirements Dec 17, 2024
@VWSLANS VWSLANS moved this from Beoordeeld to Onder Beoordeling in GF Lokalisatie Requirements Dec 17, 2024
@jhofdijk7519
Copy link

De norm richt zich op het lokaliseren van het dossier dat de zorgverlener aanlegt in het kader van een zorgvraag (WGBO) en waarvoor 13940 het begrip episode of care heeft gedefinieerd , in Nederland in het kader van het RSAD model van de DBC bekostiging sinds 2005 geïmplementeerd als het zorgtraject. Vandaar dat binnen het informatiemodel van de lokalisatiefunctie het zorgtraject is opgenomen om een dossier te kunnen ontsluiten.
Met het oog op de integrale zorg, zoals voor chronische ziekte, maar ook de geboortezorg is ook het concept Episode of Care Bundle overgenomen geduid als zorgtrajectbundel. Dat maakt het mogelijk om de dossiers van aan een patient journey betrokken zorgverleners logisch te duiden. daarbij is in de norm een onderscheid gemaakt tussen een bundel van dossiers behorende bij een formele integrale zorg organisatie zoals een zorggroep of IGO en een rond de patient gevormde samenwerking zoals bij multimorbiditeit, zoals bij de intensieve kinderzorg of tumor behandelingen. Het is om te komen tot een overzicht van de dossiers van zorgverleners die samenwerken in de zorg voor een patient. Het concept van de bundel is ook nog van groot belang voor het vastleggen van de gezamenlijke afspraken rond het beleid van de zorg voor deze patient. Het gaat hier over het verbinden van dossiers van zorgverleners op grond waarvan een virtueel netwerkdossier ontstaat. De norm gaat dus over het lokaliseren van de dossiers van zorgverleners die in een netwerk samenwerken. Het idee van een zorgnetwerk van zorgverleners staat los van het lokaliseren van gegevens / dossiers.

@Guidonoord
Copy link

Bezwaar tegen het volledig loskoppelen van bronnen en welke gegevens. Enerzijds behoefte aan een zorgnetwerk (andere vraag en out-of-scope). Raakt aan tweede punt dat je de waar en welke vraag niet zou moeten willen ontkoppelen. 1 lokalisatie-flow. Dit heeft ook met security te maken. Je wil zeker weten dat de gebruiker de functie mag gebruiken. (Autorisatie).
AANVULLING GUIDO

Als je eerste en tweede trap volledig ontkoppelt en jet het 'lokalisatie proces' (dwz, opvragen LMR=-en) ook kunt ingaan met de naam of ID van een willekeurige zorgaanbieder, dan maak je de punten van de lokale zorgaanbieders die LMR'en beheren erg kwetsbaar. Beter om een token vanuit 1e / vorige trap mee te geven voordat je uberhaupt lokaal kunt opvragen. NB": alleen maar relevant bij meertraps lokalisatie.

Hoe dan ook gaat deze vraag uit van een interpretatie van de requirement. Maar het kan best zijn dat dat requirement alleen gaat over het in beeld brengen van alle behandelend zorgaanbieders, wat ook via een of meer (lokaliseerbare) informatie-resources "behandel netwerk" kan worden georganiseerd. Als het gaat om informatie kunnen opvragen, kan dat wellicht ook via MedMij -- in de zin van een patient-centrische "index" dat gebruikt kan worden door PGO's in MedMIJ.

@Guidonoord
Copy link

Guidonoord commented Jan 13, 2025

Mijn punten n.a.v. de discussie, met oog voor de onderliggende architectuur:

  • In kaart brengen (zorg)netwerk: prima, maar dat is niet lokalisatie in de zin van lokaliseren van gegevens. ZIjn twee verschllende eisen (dus en/en, beide wil je: lokaliseren gegevens en netwerk, maar apart beschouwen).

  • Lokaliseren van gegevens kan op 2 manieren (nu in de praktijk) gebeuren: in een PGO (MedMIJ) of als zorgaanbieder. M.i. is dat verschlllend, dus verschil tussen GFs voor ozrgaanbieder-zorgaanbieder en GF LOK voor patiënten.

  • Als je het wel wilt combineren (pt en zvl perspectief in de techniek) heb je aantal blokkades op te lossen: (a) scheiding trappen in NEN lokalisatie proces (ongewenst, niet toegestaan vanuit NEN 7519() (b) autorisatie, etc.

  • Medmij problematiek van steeds weer inloggen bij ophalen van gegevens is een probleem met I&A voor patiënten; dat moet / kan opgelost worden in de context van Medmij.

  • Merk op dat als je als pt in een PGO toegang hebt tot een bron, je ook lokalisatie gegevens inclusief autorisaties kunt opvragen bij de bron die je kunt "doorzetten" naar andere zorgverleners. Dus als patient kun je veel (van de wensen van Toon) oplossen op het moment dat je eenmaal toegang in een PGO hebt - of op een andere manier toegang hebt tot een bronsysteem.

  • Op die manier kun je schakelen tusssen zorgverlener-zorgverlener lokalisatie en uitwisseling en zorgverlener-patient en patient-zorgverlener lokalisatie en gegevensuitwisseling, zonder dat je technisch de twee architecturen teveel vervuilt (en potentieel stuk maakt).

Aldus rust ik.

@stevenvegt
Copy link
Contributor

Nav de opmerking hierboven van @jhofdijk7519

Bundels als concept voor het bundelen van dossiers waarvan een netwerk valt af te leiden.

Is het proces en dossier of het persoonlijk netwerk de "entiteit" waar op basis van wordt gelokaliseerd?
Hoe ga je om met mensen die gegevens willen lokaliseren die geen onderdeel van deze netwerken zijn?

Er lijken 2 strategieën van lokaliseren: op basis van lokaliseerbare dossiers en op basis van netwerken.
Is een netwerk onderdeel van het dossier?
Zoek je een netwerk op basis van het dossier, of juist andersom?

Guido:
Ja, je kunt informatie lokaliseren op basis van een netwerk, maar het beheer van een netwerk is een geheel eigen functie. Stel je hebt dit netwerk, heb je het probleem dan niet al opgelost, heb je deze lokalisatie functie dan nog nodig?

Toon:
Er leeft een behoefte om het netwerk in kaart te brengen. Ook personen in kaart brengen met gezichten en contactgegevens. Ook niet zorg contacten. Denk aan een soort "lifebook". Op basis van dit netwerk gegevens "pushen" naar elkaar. Ook toestemmingen en autorisaties inrichten op basis van dit netwerk.
Het zou in de NEN norm moeten passen, dus zou het dan ook in deze GF kunnen worden uitgewerkt?

Guido:
Als het netwerk in bijv. een PGO beschikbaar is. Kun je deze informatie als patient dan niet al gebruiken? Als je dit in het PGO al kan, kun je het dan bij laten en voor zorgverlener - zorgverlener communicatie dit niet gebruiken. Is de echte behoefte niet de behoefte van het in kaart brengen van een netwerk? Gaat dit over patienten of zorgaanbieders? Moeten we dat loskoppelen?

Een bundel van dossiers kan het netwerk zijn vanuit. het perspectief van de patient zijn, maar niet noodzakelijk vanuit het perspectief vanuit een zorgverlener.

Kunnen we nu het perspectief netwerk nu al gebruiken, gezien we nog geen gemeenschappelijk beeld van dit concept hebben.
Gaat het om netwerken van personen of organisaties?
Gaat het om het netwerk vanuit het perspectief vanuit de patient, behandeling of behandelaar? Wat betekent "betrokken bij"? Actief of in het verleden betrokken?

Jacob:
Er zijn de nodige voorbeelden hoe netwerken en bundels gebruikt worden in de norm. Deze opzoeken en delen.

@stevenvegt
Copy link
Contributor

We kunnen nu niet door want:

  • Geen duidelijk beeld wat een netwerk is. Een persoonlijk netwerk vanuit de patient is fundamenteel anders dan dat van zorgverleners.
  • Kan het al met de definitie zoals die in de NEN norm staat? Mappen de concepten netwerk op de norm?
  • Wil je het concept netwerk in de lokalisatie functie beschrijven/opnemen of is dat een eigen functie/bouwsteen?

Voorstel: dit concept in en latere fase uitwerken.

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

No branches or pull requests

6 participants