ADR 5; Topologie van de adresseringsfunctie

[RonObbens]

In de huidige voorgenomen opzet is er sprake van meerdere adresboeken die achter de adressen-url/digitale voordeur/base-url worden aangeboden. Deze adresboeken moeten wel voldoen aan standaarden die op landelijk niveau worden bepaald. Om te voorkomen dat deze dienstverlening (die voor alle zorgaanbieders eigenlijk hetzelfde moet zijn) concurrentieel wordt bewegen we naar een eindsituatie toe waarin er nog maar sprake is van één adresboek wat door de overheid wordt gefaciliteerd cq aangeboden.

Relevante architectuurplaat wordt ook in PR #149 besproken.

[RizAhmed85]

N.a.v. de werkgroep was het voorstel om de mogelijke scenario's te beschrijven.

Drie scenario's

1. LRZa die 'digitale voordeur' (prijsvraag staat nog uit) weet van een zorgorganisatie waar de adresseerbare punten kunnen worden opgevraagd (2-trapsraket).
2. Een beperkte set van centrale adresboeken waar je de adresseerbare punten kan opvragen o.b.v. een URA (beperkte adresboeken met adresseerbare punten)
3. Een centrale update consumer (LRZa) waar je op basis van een URA de adresseerbare punten direct kunt opvragen (nationaal adresregister).

[stevenvegt]

Zoals besproken op 2 september in de werkgroep.
We hebben het supplier/consumer deel van mCSD proberen in te vullen.
Een zorgaanbieder registreert een eigen Update Supplier bij een centrale dienst (bijv. het LRZa). Die lijst wordt gebruikt door adresboek(en) gebruikt om een compleet adresboek op te bouwen die aangeboden kan worden aan Selective Consumer.

Vraagstuk is nog hoe we omgaan met meerdere leveranciers per zorgaanbieder. Bijv. een DVA of LSP wil graag zijn eigen endpoints beheren. Meld je dan meerderen leveranciers aan, of leg je als zorgaanbieder een link vast in je eigen Update Supplier vast. En hoe weet de Update Consumer dan de endpoints van deze leveranciers?

[stevenvegt]

Op basis van de mCSD kom ik tot het volgende voorstel:

Elke organization kan een lijst van endpoints publiceren naar mCSD Update Suppliers en daarmee aan de Update Consumer aangeven waar er andere delen beschikbaar zijn. De consumer volgt ze allemaal en vormt zo een volledig overzicht. Bij het LRZA registreert de organisatie zijn primaire supplier, de rest zijn connectivity suppliers die alleen combinaties van Organization - Endpoint beheren.

[stevenvegt]

Samen met @bramwesselo naar de bovenstaande opties gekeken.

Omdat we niet weten hoe simpel of complex de bronnen en configuraties van adresseerbare punten zijn voor een specifieke zorgorganisatie, hebben we besloten dat organisaties bij het LRZA één digitale voordeur registreren, de zgn mCDS Update Supplier. Deze dienst levert aan de Update Consumers één actueel en volledig overzicht aan van de adresseerbare punten van de zorgorganisatie. Hoe dit overzicht tot stand komt is aan de zorgaanbieder zelf en kan worden samengesteld uit meerdere bronnen zoals aanvullende dienstverleners, of gebaseerd zijn op een simpel lijstje van endpoints, services en locaties.

Het plaatje wat we hebben besproken ziet er dan grofweg zo uit:

[RizAhmed85]

Ter bespreking straks tijdens werkgroep:

Is het dan de 'bedoeling' dat de Update Consumer voor iedere uitvraag het technische end-point opvraagt? Of 'meld' hij zich de eerste keer met een 'afnemersindicatie' waarna hij op de hoogte wordt gehouden van een eventuele mutatie in het end-point?

[RizAhmed85]

Afgesproken is dat een ieder zijn bedenkingen toevoegt aan deze conversatie. Daarna wordt er een moment geprikt om in overleg te treden tussen de indieners van bedenkingen en bedenkers van de eerste plaat. Dit overleg vindt (digitaal) plaats voor de eerst volgende werkgroep adressering.

[CS-Olav]

M.i. is de discussie van 23-7 nog onvoldoende beslecht: hoeveel moet decentraal beschikbaar worden gesteld en hoeveel centraal? De TA Routering gaat uit van ActivityDefinitions decentraal en in de laatste werkgroep is besproken waarom dat ook voor Practitioner(Role)s wellicht wenselijk is. Dat lijkt te vragen om een hybride model met sommige resources centraal en andere decentraal i.p.v. een Update Supplier (centraal) of Selective Supplier (decentraal) voor alle resources per zorgaanbieder. Daarbij komt dat de interactie tussen een Update Supplier en een Update Consumer gebaseerd is op polling waardoor adresboeken achter kunnen gaan lopen en je andersom voor relatief statische resources voor onnodig veel interacties zorgt.

[RonObbens]

Ik had uit de terugkoppeling geïnterpreteerd dat het discussiepunt nog zat op de voordeur vs achter de voordeur. Ik interpreteer uit de reactie van Olav dat het toch iets anders/genuanceerder ligt. We hebben idd centrale en decentrale componenten in de architectuurfunctie. De adressen-url moet centraal ter beschikking komen, dat verzorgen we in/via het LRZa. Daar zit een verwijzing in naar het adresboek van de betreffende entiteit. Met daar dus achter een adresboek met alle adresseerbare punten. De Activity-Definitions maken geen onderdeel uit van de functie zelf maar zijn wel decentraal. Maar dat geldt in principe voor alle adresseerbare punten. De discussie over hoe we die adresseerbare punten up to date houden in de adresboeken is volgens mij de discussie over update en selective consumers en suppliers.

[CS-Olav]

Zo benaderd vraag ik me af of we (voor alle resources) een interface tussen een zorgaanbieder en een adresboek (selective supplier) moeten willen definiëren of dat het adresboek ook de zorgaanbieder zelf kan zijn.

[RonObbens]

In theorie zou het adresboek ook een zorgaanbieder zelf kunnen zijn volgens mij. Maar...... we streven wel naar een paar adresboeken waarbij het een wens is later mogelijk naar één (publiek) adresboek te migreren/bewegen.

[CS-Olav]

@RonObbens ik denk niet dat we moeten streven naar één (of een klein aantal) adresboek(en) met alle resources uit mCSD. Wat voegt het hele idee van een centrale plek met verwijzingen naar adresboeken per partij immers nog toe als je er naar zou streven daar één adresboek van te maken? Je ontkracht dan het idee van wat we eerder een tweetraps-raket noemden.

[stevenvegt]

Riz

Is het dan de 'bedoeling' dat de Update Consumer voor iedere uitvraag het technische end-point opvraagt? Of 'meld' hij zich de eerste keer met een 'afnemersindicatie' waarna hij op de hoogte wordt gehouden van een eventuele mutatie in het end-point?

Het LRZa is in de basis ook een Update Supplier die met een history parameter kan worden aangeroepen. Alleen wijzigingen in de endpoints en organisatie komen terug waarna de volgende stap begint van het opvragen rechtstreeks bij de zorgaanbieder's update supplier.

Olav

M.i. is de discussie van 23-7 nog onvoldoende beslecht: hoeveel moet decentraal beschikbaar worden gesteld en hoeveel centraal? De TA Routering gaat uit van ActivityDefinitions decentraal en in de laatste werkgroep is besproken waarom dat ook voor Practitioner(Role)s wellicht wenselijk is. Dat lijkt te vragen om een hybride model met sommige resources centraal en andere decentraal i.p.v. een Update Supplier (centraal) of Selective Supplier (decentraal) voor alle resources per zorgaanbieder. Daarbij komt dat de interactie tussen een Update Supplier en een Update Consumer gebaseerd is op polling waardoor adresboeken achter kunnen gaan lopen en je andersom voor relatief statische resources voor onnodig veel interacties zorgt.

We weten nog niet of we persoonsgegevens in de Adresseringsfunctie willen of niet. Zo niet, kunnen de Practitioners nog steeds door het UZI register worden aangeboden, maar dan zonder persoonsgegevens en alleen UZI nummer en rolcode. Laten we dat bespreken in ADR 9.

Dat Activity definitions rechtstreeks bij de bron moeten worden opgehaald is irrelevant, gezien dit geld voor elke FHIR resource buiten het mCSD.

Het klopt dat diensten kunnen achterlopen. De adresseringsfunctie is daarom ook niet bedoeld voor real time data, die haal je daarom rechtstreeks bij de zorgaanbieder op.

Wat betreft polling: voor elke resource in het mCDS wordt een update-since query uitgevoerd waarna er een lijst met 0 of meer entries terug komt. Het doel is niet om onnodige interacties te voorkomen, het doel is een werkbaar systeem te bouwen. Een abonnement met informatie pushen vergt misschien minder interacties maar vergt meer administratie. Ik zou hier zo dicht mogelijk bij het mCSD model willen blijven.