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

[sergejvm]

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.

[jeroenvang]

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]

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.

[jhofdijk7519]

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]

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]

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]

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]

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.

[jhofdijk7519]

Hierbij de usecases zoals toegezegd, deze hebben vooral betrekking op 12, wat gaat over netwerkzorg dossiers, terwijl 7 het heeft over het zorgnetwerk van zorgverleners, en dat is dus anders en buiten scope van de lokalisatie van dossiers.
Use cases van netwerk- en integrale zorg
Voor de werkgroep requirements Lokalisatie 17-2-2025

1. Algemeen
   Om relevante informatie over behandelingen - al dan niet multidisciplinair, in ketens of netwerken waar de patiënt zijn zorg ontvangt - te kunnen opvragen is het van belang om te weten welke informatie zich waar bevindt.
2. Gegevensdeling binnen georganiseerd verband
   In deze usecase worden afspraken gemaakt over het delen van dossiers van zorgverleners die betrekking hebben op bv. een specifieke zwangerschap of integrale chronische zorg. Het gaat om een georganiseerd samenwerkingsverband. Aangezien er bij deze zorg meerdere zorgverleners zijn betrokken, is er sprake van meerdere dossiers of zorgtrajecten, maar wel gedeeld beleid. Voor de gegevensuitwisseling is het van belang om alle brondossiers die bij deze netwerkzorg zijn betrokken, te kunnen ontsluiten.
3. Gegevensdeling binnen niet vooraf georganiseerd verband
   Deze usecase richt zich op de zorg die aan een patiënt wordt geleverd in het zorgnetwerk waar er geen sprake is van een formeel georganiseerd samenwerkingsverband van de zorgverleners. Het kan de zorg betreffen die wordt geleverd aan chronisch zieke kinderen met multiproblematiek, die in meerdere ziekenhuizen, in kinderzorghuizen en thuis worden behandeld. Maar het kan ook bot-spierstelselzorg betreffen die door huisartsen, fysiotherapie, orthopedie en revalidatie wordt geleverd. Hier wordt keten- en netwerkzorg geleverd.
   Het betreft hier zorg die rond de problematiek van de patiënt ontstaat waarbij er geen overkoepelende formele (contractuele) afspraken of vooraf afgebakende verantwoordelijkheden tussen de samenwerkende individuele zorgverleners zijn gemaakt. Op het niveau van de patiënt moet de samenwerking dan ook worden gebundeld, om op het niveau van de netwerkzorg afspraken te kunnen maken over de uitwisseling van de betrokken medische dossiers en over het vastleggen van het afgesproken beleid.
4. Keten / Netwerk Een patiënt heeft voor een bepaalde aandoening meerdere behandelaren in zowel de eerste als tweede lijn.
   Een patiënt heeft voor een bepaalde aandoening meerdere behandelaren in zowel de eerste als tweede lijn op "centraal" niveau moeten die relaties worden vastgelegd, dan zal je vast moeten leggen wie dat allemaal zijn, de crew van de patientreis dus met links naar de betreffende zorgtrajecten/episodes.
5. Nabehandeling in de keten
   patiënt wordt na operatie ontslagen uit het ziekenhuis en verder thuis verzorgd door de thuiszorg. De thuiszorg verpleegkundige en huisarts en apotheek van de patiënt hebben inzage nodig in ontslaginformatie, eventueel medicatiegebruik e.d. vanuit het ziekenhuis om de patiënt goed te kunnen verzorgen.
6. Zorgvraag medebehandeling
   verwijzing is vastgelegd, informatie wordt gedeeld , episode wordt geopend bij het specialisme, dossier wordt gedeeld met de verwijzer

[Guidonoord]

Van belang autorisatie voor burger-georienteerde lokalisatie te cheiden van de (beveiliging van) zorgaanbieder-zorgaanbieder lokalisatie.

Dus je kunt niet zomaar met een lijstje zorganabieder_IDs starten, en daarmee willekeurige LMRs gaan bevragen. Een patient kan dat misschien (via DVZA - een specifiek protocol waarmee burgers bij zorgaanbieders kunnen inloggen), maar een zorgaanbieder zou dit zeker niet moeten mogen (ook niet onder NEN7519).. Dit opvragen van lokalisatie informatie om gegevens te lokaliseren loopt dan via een hele eigen identificatie/authenticatie en autorisatie architectuur, in casu, de MedMIJ DVP-DVZA protocollen.

Zorgaanbieders moeten zeker een "gereguleerde" meertraps lokalisatie opzet niet kunnen bypassen door zomaar rechtstreeks zorgaanbieders (LMRs) te bevragen! Dit is ook niet nodig.

[jhofdijk7519]

het laatste deel van de use cases :
7. Netwerk diagnostiek
Aanvraag - workflow - uitslag (vastleggen) Patholoog opvragen patient gegevens - Opvragen MDO - Vastleggen EPD
8. Patient wordt verwezen naar disease management programma zorggroep
Inschrijving zorggroep, vastlegging risicoprofiel en Individueel Zorgplan
9. Zelfverwijzing
de door de patient gekozen specialist legt vast welke andere specialist bij de health issue van de patient betrokken was
10. Zorgverlener Journey Ambulancezorg
Vastleggen proces, triage, uitkomst, verwijzen en rapporteren aan ketenpartners

[tw-babyconnect]

De kern van het zorgproces is, dat een zorgverlener eerst relevante gegevens van een burger gaat raadplegen. De grote wens is dat dat ook gegevens kunnen zijn die door andere zorgverleners zijn vastgelegd.
Na het raadplegen is er het contactmoment waarin nieuwe gegevens worden verzameld, en vervolgens worden die geregistreerd als nieuwe gegevens.
Vraag is hoe een zorgverleners gegevens kan vinden die door andere zorgverleners zijn vastgelegd.
Dat kan alleen gedaan zijn door zorgverleners/zorgaanbieders die onderdeel zijn van het persoonlijk netwerk van de burger. Wij van CareCodex pleiten ervoor dat dat ook beheerd wordt door die burger. (mogelijk door een vertrouwde persoon die dat doet onder machtiging van die burger).
De burger wil over datzelfde lijstje (persoonlijk netwerk) kunnen beschikken om het eigen PGO te vullen.
Huidige werkwijze is dat bij elke opvraging de burger eerst de betreffende zorgaanbieder moet zoeken.

[sergejvm]

Beheren netwerk levert dan nog relaties op met deze requirement voor lokalisatie, maar zijn niet in scope van GF lokalisatie.

[Guidonoord]

Zoals ik de requirement van Toon lees, is dit eigenlijk geen requirement voor lokalisatie, en zeker niet voor lokalisatie van gegevens, maar een wens tot functionaliteit voor PGO's.

Waar het op neerkomt is dat patient een lijstje zorgaanbieders (als startpunt van 'MedMIJ' interacties) wil kunnen krijjgen en wil kunnen importeren in het PGO (al dan niet geautomatiseerd). Een zorgnetwerk resource (of iets vergelijkbaars) kunnen krijgen / importeren in een PGO is genoeg voor het invullen van deze requirement / wens. Dit staat los van lokalisatie in de context van zorgverlener-zorgverlener communicatie.

Deze wens staat in feite ook los van hoe je lokaliseert vanuit PGO. Een PGO start ook nu daadwerkelijk met een lijstje zorgaanbieders om DVZA' s te kunnen vinden om bij te kunnen inloggen met een burger identificatie middel. De wens vult dit aan met een mechanisme om een lijstje zorgaanbieders te kunnen importeren, als startpunt voor patiënt-zorgaanbieder interacties.

Een zorgaanbieder begint daarentegen met een lokalisatie structuur die tot stand komt via de NEN norm lokalisatie, en benadert specifieke (aan hem/haar ontsloten) gegevensbronnen met een zorgaanbieder identificatie middel. Persoons en zorgaanbieder lokalisatie concepten en (technische) primitieven verschillen - zie ook #43.

Verzoek is en blijft in stand: scheid de functie van A. (het beheer van) het zorgnetwerk van de patient, en B. (het beheer van en toegang tot) de lokalisatie structuren om medische gegevens (lokaliseerbare data sets) te kunnen lokaliseren voor gebruik door zorgaanbieders/zorgverleners, conform de 7519. Het is niet verstandig om deze functies, die een heel eigen technische uitwerking vergen, te mengen/combineren.

#42 kan daarmee dus wel, uitgaande van een eigen implementatie van lokalisatie voor burgers/PGO's, en #43 niet.

[tw-babyconnect]

Als ik Guido goed begrijp is dan deze requirement niet correct: "Als persoon wil ik een overzicht van mijn (zorg)netwerk kunnen gebruiken om gegevens te lokaliseren." En dan specifiek het woord lokaliseren. Dat zou ook kunnen zijn "kunnen laden in mijn PGO".
Dit wordt ondersteund door dit rapport https://medmij.nl/media/onderzoek-naar-lokalisatie-van-medische-gegevens-afgerond/
Feit blijft dat dat hetzelfde lijstje is, als waar een zorgverlener gebruik van maakt.

[tw-babyconnect]

Jacob Hofdijk kwam nog met een voor mij nieuw argument: Als een burger ervoor kiest om een zorgverlener/aanbieder niet toe te voegen, mis je data.
We hebben dat intern CareCodex besproken en zien dit als een wens van een burger om geen gegevens te delen met die persoon/aanbieder. Dat dient onzer inziens gerespecteerd te worden.
Een andere manier is om de zorgaanbieder wel op te nemen in het persoonlijk netwerk, en de toestemmingen te blokkeren.