7kezo:V1.0 Beschrijving pull mechanisme

Dit materiaal is onderdeel van HL7v3-domein Ketenzorg V1.0_HL7v3-uitwisseling_Ketenzorg. Compatible wijzigingen/nadere bewoordingen, tikfouten kunnen direct in de Wiki gewijzigd worden Open issues die discussie vergen s.v.p. in de commentaarsectie opnemen.

Beschrijving pull mechanisme

Bij pull interacties, waarbij sprake is van een query/response paar, was traditioneel geen verschil tussen de query die wordt verzonden van het verzendende XIS naar het LSP en degene die wordt verzonden van het LSP naar het ontvangende XIS. Weliswaar fungeert het LSP als ‘gateway’ en verwerkt zelf ook (een deel van) de parameters uit de query (t.b.v. het zoeken in de verwijsindex), maar de inkomende query werd wel één-op-één doorgezet naar de bronsystemen. Dat verandert echter bij de zorgtoepassing Ketenzorg.

Inkomende query

Bij de zorgtoepassing Ketenzorg wordt het LSP bevraagd d.m.v. een generieke query, die geparametriseerd wordt met o.a. een zogenaamde contextcode. Hierdoor kunnen precies die gegevens opgevraagd worden die nodig en relevant zijn binnen een bepaalde applicatiecontext, terwijl de implementatievorm van de query toch steeds gelijk blijft.

De bronsystemen worden echter door het LSP bevraagd met queries die specifiek zijn voor een bepaald bouwsteentype. Hierdoor weten de bronsystemen veel beter welk type vragen ze kunnen verwachten en treed er ook geen wildgroei op in het aantal verschillende antwoordsets dat vanuit bronsystemen moet kunnen worden opgeleverd.

De omzetting van de contextspecifieke query die het LSP ontvangt naar de bouwsteen-specifieke queries die de bronsystemen ontvangen, wordt uitgevoerd op het LSP (o.b.v. de contextcode en het autorisatieprofiel van de vragende zorgverlener). Daarbij worden ook de query parameters van de bouwsteenqueries afgeleid en gevuld. Dit proces wordt hier verder niet uitgewerkt, omdat het intern is aan de werking van het LSP (‘black box’).

Hieronder een schematisch overzicht van het query mechanisme:

Bouwsteenspecifieke parameters zijn eventuele extra parameters die relevant zijn voor het betreffende bouwsteentype, zoals de gebruiksperiode bij een medicatievoorschrift. Merk op dat het dus ook mogelijk is dat het LSP twee verschillende bouwsteenqueries stuurt naar één bronsysteem, op basis van dezelfde inkomende contextspecifieke query.

Geretourneerde response

De response interacties vanuit de bronsystemen worden vervolgens door het LSP verzameld en gebundeld in een zogenaamde batchwrapper. Dit is hetzelfde mechanisme dat momenteel door het LSP wordt gehanteerd, alleen is het uitgangspunt nu dat de payloads van responses bestaan uit clinical statements die compatible zijn met CDA R2 (tenzij er al een install base bestaat voor een niet CDA-compatible AORTA-standaard).

Gebruik van de verwijsindex

Bij het omzetten van inkomende naar uitgaande queries maakt het LSP gebruik van de aanmeldingen in de verwijsindex om te bepalen naar wie de query moet worden doorgestuurd, dat is en blijft het geval. Aangezien de uitgaande queries op het niveau van één bouwsteentype liggen, zal de trend bestaan om ook aanmeldingen in de verwijsindex steeds meer per bouwsteentype te doen. Op die manier is direct bekend welke bronsystemen over dit bouwsteentype beschikken en dus de query moeten krijgen.

Feit is echter dat de vulling van de verwijsindex niet op slag kan worden aangepast, dus in eerste instantie moet het nieuwe query mechanisme ook werken o.b.v. het bestaande aanmeldniveau, te weten het niveau van het hele dossier, zoals huisartsen dat nu doen. Het aardige is dat dit ook prima werkt, waarbij in plaats van een 1-op-1 relatie dus sprake is van een 1-op-meer relatie tussen de gegevenssoort en bouwsteentypen. Per gegevenssoort moet bekend zijn welke bouwsteentypen er onder kúnnen vallen.

Dat wil zeggen dat als er een generieke query met als contextcode ‘ketenzorg diabetes’ binnenkomt, en het LSP als gevolg daarvan onder andere naar medicatievoorschriften gaat zoeken, de gegevenssoort huisartsdossier (Primary Care Provision) ook gebruikt wordt, aangezien het LSP weet (dankzij achterliggende mappingtabellen) dat een huisartsdossier onder andere medicatievoorschriften kán bevatten. Dezelfde gegevens-soort werkt dus als trigger voor alle bouwsteentypen die in de resultset zullen zitten.

Er wordt nu een aparte beschrijving gegeven van enerzijds de interacties tussen vragend systeem en LSP (met batchantwoord op generieke query) en anderzijds de interacties tussen LSP en bronsystemen (met afzonderlijk antwoord op bouwsteenspecifieke query).