-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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. |
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). 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. |
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. |
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. |
Mijn punten n.a.v. de discussie, met oog voor de onderliggende architectuur:
Aldus rust ik. |
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? Er lijken 2 strategieën van lokaliseren: op basis van lokaliseerbare dossiers en op basis van netwerken. Guido: Toon: Guido: 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. Jacob: |
We kunnen nu niet door want:
Voorstel: dit concept in en latere fase uitwerken. |
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.
The text was updated successfully, but these errors were encountered: