RFC 24059 Wijziging relatie DH/CZT van client naar bemiddeling

[rvanrest]

eDocs volgnummer

2024024636

Korte probleem omschrijving

autorisatie afdwingen voor een DH of CZT op de gegevens is met de huidige structuur complex. Daarnaast geeft de huidige structuur niet volledig de praktijk van relaties weer

Korte omschrijving voorgestelde oplossing

Relatie tussen DH/CZT verplaatsen van Client naar Bemiddeling

RFC gevolgen voor het onderdeel/de onderdelen

ERD (Register), Koppelvlak specificatie, Regels

Welk ander onderdeel?

No response

Betrokken partij RFC

Zorgkantoor, Zorginstituut, anders, (geef aan bij contactpersoon)

Andere betrokken partij

VECOZO

Indiener RFC

Zorginstituut

Andere organisatie / contactpersoon

VECOZO

Analyse

Analyse

Huidige situatie

Dossierhouder (DH) en CoordinatorZorgThuis (CZT) zijn gekoppeld aan Client. (zie graphmodel en ERD)

Bezwaren huidige situatie

De inzage van een DH/CZT op de bemiddelingspecificaties en bemiddeling zijn beperkt door de periode waarin de instelling is gekenmerkt als DH/CZT. Door de huidige implementatie moet die geldigheidsperiode meegenomen worden naar de via de client gekoppelde bemiddelingen (en bemiddelingspecificaties).

Dit is onnodig complex omdat er in werkelijkheid een directe relatie is tussen (de duur van een) bemiddeling en de DH/CZT periode. Deze is maximaal gelijk of de DH/CZT periode valt daarbinnen, maar de DH/CZT periode is nooit groter dan de periode van een bemiddeling.

Deze complexiteit werkt door in de benodigde autorisatie-policy.

Wijzigingsvoorstel

Voorstel aanpassing

Maak een directe relatie tussen DH/CZT met Bemiddeling en verwijder de relatie met Client en pas de notificatie inhoud aan

Voordelen Directe relatie tussen wat een DH/CZT vanuit zijn geldigheid mag raadplegen aan bemiddelingsspecificaties.

Nadelen Aanpassing ERD, Koppelvlakspecificatie, Policy, regels

Uitwerking wijzigingsvoorstel per onderdeel

ERD

< nog uit te werken >

schematisch:

Regels

BRB0043 (huidig): Het verantwoordelijke zorgkantoor legt in het Bemiddelingsregister bij de client de dossierhouder en/of de coordinator zorg thuis vast en houdt deze gegevens bij, inclusief de periodes waarin de betreffende zorgaanbieders deze rol hebben.

Hoewel met de vermelding 'bij de client' in deze regel niet letterlijk de entiteit Client bedoeld wordt, lijkt het toch duidelijker om deze vermelding uit de regel te verwijderen.

BRB0043 (nieuw): Het verantwoordelijke zorgkantoor legt in het Bemiddelingsregister de dossierhouder en/of de coordinator zorg thuis vast en houdt deze gegevens bij, inclusief de periodes waarin de betreffende zorgaanbieders deze rol hebben.

Er zijn geen gevolgen voor andere regels.

Proces

n.v.t.

Gegevens

Binnen de entiteiten Dossierhouder en CoordinatorZorgThuis wordt het attribuut clientID vervangen door het attribuut bemiddelingID.

Autorisatie In de autorisatiematrix moet binnen Dossierhouder en CoordinatorZorgThuis clientID vervangen worden door bemiddelingID.

Koppelvlak

< nog uit te werken >

minimaal:

• Aanpassing relaties (edges)

schematisch oude situatie:

nieuwe situatie:

• Aanvulling query specificatie met raadplegen Dossierhouder / Coordinator Zorg Thuis informatie door Instelling. Nodig voor het ophalen van de ingangs- en einddatum (periode)

  coordinatorZorgThuis(where: CoordinatorZorgThuisFilterInput): [CoordinatorZorgThuis!]!
  dossierhouder(where: DossierhouderFilterInput): [Dossierhouder!]!

Notificatie

• Aanpassing notificatie inhoud. subjectID moet Bemiddeling/BemiddelingID bevatten ipv Client/ClientID.

Policy

< nog uit te werken >

• query voorbeelden
• rego-policy

Overweging wijzigingsvoorstel(len)

Oplossing	Voordeel / Nadeel	Overweging Referentiegroep
1. ..	Voordeel:
	Nadeel:
#. Niets doen	Voordeel: geen wijziging nodig
	Nadeel: probleem blijft aanwezig

...

Conclusie

None

Gekozen oplossing

No response

Publicatiemoment

No response

Implementatiemoment

No response

controleer project en labels van het issue

• [X] gecontroleerd

[rvanrest]

2024-06-20: Besproken in TAO (technisch afstemmingsoverleg)

• Voorstel is akkoord, maar analyseer ook of DH/CZT een relatie moet krijgen met Bemiddelingsspecificatie.

[rvanrest]

Hoi allemaal,

Heb er nog even verder met Irene over doorgedacht en we denken toch dat de relatie naar Bemiddeling moet liggen en niet naar Bemiddelingspecificatie. Hieronder onze overweging.

Uitgangspunten:

• Het gaat erom dat een betrokken zorgaanbieder kan nagaan wie de actuele DH of CZT is. In het berichtenverkeer was dit alleen mogelijk door extra berichten te versturen zonder zorginhoudelijke wijziging. Hier is niet voor gekozen om administratieve last te beperken.
• een DH of CZT heeft vanuit zijn rol geen ander inzicht dan dat die DH of CZT al heeft vanuit zijn betrokkenheid als ZA bij een Bemiddeling. Een DH of CZT moet namelijk betrokken zijn (geldige bemiddelingspecificatie hebben), dat bepaald de inzage in de overige bemiddeingspecificaties. Er is ook geen specifieke autorisatiergel voor een zorgaanbieder als DH of CZT.
• een periode van DH of CZT kan nooit langer zijn dan de duur van de betrokken bemiddeling, immers die ZA is verantwoordelijk voor de combinatie Client, Indicatie en Verantwoordelijk ZK. Maar kan wel korter afhankelijk van de betrokkenheid of wens van de client.
• Bij een wijziging van DH/CZT geldt dat voor alle huidige en toekomstige bemiddelingspecificaties
• Er kan op 1 moment (behalve de 1-dag overlap) per DH of CZT maar 1 geldig zijn. (Bij regulier samen met overbrugging MPT kan er een DH en een CZT gellijktijdig geldig zijn, maar op de dag overlap na is het er altijd maar 1)

Er zijn naar onze optiek 5 mogelijkheden. Zie excelsheet

1. Koppeling aan Bemiddeling: Voordeel eenvoud van model, vanuit de ZA is op basis van opvraagmoment te achterhalen wie de dan geldende DH of CZT is. Voor ZK is dat ook mogelijk om te bepalen wie op welk moment verantwoordelijk is van de zorgaanbieders
2. Koppeling via een extra koppeltabel tussen DH/CZT en bemiddelingsspecificatie. Complexer, er wordt een extra laag toegevoegd, er moeten extra datafilters meegegeven worden voor hetzelfde resultaat.
3. Koppeling direct aan Bemiddelingspecificatie, met opknippen. Voordeel, direct verantwoordelijke DH/CZT, maar extra notificaties zonder dat het inhoudelijke zorg wijziging betreft = administratieve last historie direct zichtbaar (wie was de verantwoordelijke aanbieder)
4. Koppeling direct aan Bemiddelingspecificatie, met updates. Voordeel, direct verantwoordelijke DH/CZT, maar extra notificaties zonder dat het inhoudelijke zorg wijziging betreft = administratieve last + verlies aan historie. Wie was de DH/CZT. De directe koppeling is verbroken en moet eventueel verlopen zoals onder 1.
5. DH/CZT direct onder Bemiddelingspecifcatie. Geeft dubbele notificaties aan dezelfde DH of CZT (toekennen rol DH of CZT) . Per Bemiddelingsspecifiatie een notificatie. Redundante data

En dan heb ik de combi van CTZ en DH nog niet uitgewerkt wanneer er sprake is van wachten op verblijf i.c.m overbrugging MPT. Het zal duidelijk zijn dat in de oplossingen anders dan 1, koppelen aan Bemiddeling het nog complexer maakt de data integer te houden.

Onze advies (en voorkeur) is dus optie 1. Direct koppelen aan Bemiddeling omdat die de meest eenvoudige is die de behoefte voorziet van de vraag “wie is voor deze bemiddeling (via Bemiddelingspecificatie) de verantwoordelijke aanbieder. In elk geval is door het apart modeleren van de DH/CA het probleem bij het verlopen van de bemiddelingsspecificatie niet direct de DH/CZT periode afgesloten en kan er nieuwe zorg worden aangevraagd. Probleem dat nu nog eens gebeurd in het berichtenverkeer.

Als jullie daar anders over denken, hoor ik dat graag uiterlijk maandag 1 juli, zodat ik terugkoppeling kan geven tijdens het technische afstemmingsoverleg.

Met vriendelijke groet,

Remo

Analyse RFC24059 - DH_CZT-2.xlsx