7kezo:V2.0 Beschrijving pull mechanisme: verschil tussen versies
(Copy of V1.0) |
k (Tekst vervangen - "{{#customtitle:" door "{{DISPLAYTITLE:") |
||
| Regel 1: | Regel 1: | ||
| − | {{ | + | {{DISPLAYTITLE: Beschrijving pull mechanisme | Beschrijving pull mechanisme}} |
<noinclude>{{DocumentPart|ns=7kezo|title=V2.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude> | <noinclude>{{DocumentPart|ns=7kezo|title=V2.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude> | ||
==Beschrijving pull mechanisme== | ==Beschrijving pull mechanisme== | ||
Huidige versie van 20 jul 2020 om 01:37
Dit materiaal is onderdeel van HL7v3-domein Ketenzorg V2.0_HL7v3-uitwisseling_Ketenzorg.
|
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. Waarschuwing:Titelweergave "Geretourneerde response" overschrijft eerdere titelweergave "Beschrijving pull mechanisme".
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).
|
|
Er is serieus overwogen om ook het pull mechanisme te implementeren op basis van de uitwisseling van CDA documenten. Dit stuitte op weerstand van de leveranciers, omdat CDA zorgt voor extra overhead zonder duidelijke meerwaarde. Dit komt omdat het niet wenselijk wordt geacht dat het LSP gegevens uit de bronsystemen samenvoegt in één CDA document, omdat daarmee de bewerkersrol te groot zou worden. Dat betekent dat het vragend systeem een set CDA documenten zou ontvangen (één per bronsysteem), die in feite geen andere rol hebben dan een extra envelop rond de gegevens. Daarbij komt dat een gegevensset die ad hoc uit een database is onttrokken en waar hoogstens geautomatiseerd een tekstuele omschrijving bij gemaakt kan worden, niet echt meer aansluit bij het concept van een document als een samenhangende, eventueel ondertekende, persistente set gegevens. Een praktisch argument is dat binnen AORTA al diverse bouwsteenspecifieke queries bestaan (o.a. EMD, ICA en Lab), die kunnen worden hergebruikt als het pull mechanisme ook in de nieuwe opzet op basis van berichten wordt gerealiseerd (naast het hergebruik van de bouwsteenimplementatie zelf). |
Waarschuwing:Titelweergave "Gebruik van de verwijsindex" overschrijft eerdere titelweergave "Geretourneerde response".
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.
|
|
Ook al is de zorgtoepassing Ketenzorg in eerste instantie beperkt tot uitwisseling tussen HIS en KIS, is het niet per definitie zo dat alleen gegevens uit het HIS worden opgeleverd als het KIS een generieke query verstuurt. Zodra andere systemen aanmeldingen doen voor gegevenssoorten die mappen naar relevante bouwsteentypen, zullen ook brongegevens uit deze systemen kunnen worden opgeleverd! Concreet betekent dit bijvoorbeeld dat de uitgaande query voor medicatievoorschriften ook terecht kan komen bij het EVS van een ziekenhuis, als die de gegevenssoort Medicatievoorschrift heeft aangemeld. In principe zal de ZIM dan ook deze gegevens opleveren, aangezien ze horen bij de gegevens die de opvrager wil en mag zien. Als een opvrager wil zorgen dat alleen gegevens uit het HIS worden opgeleverd, kan parameter <applicationID> uit de generieke query worden gebruikt om te zorgen dat bouwsteenqueries alleen worden doorgezet naar één applicatie (het HIS van de vaste huisarts dus). |
|
|
Merk op dat er een overgangsissue bestaat ten aanzien van labbepalingen, omdat in eerste instantie het HIS dienst doet als bron van alle bepalingen die door de huisarts zijn aangevraagd. Naarmate ook uitvoerende laboratoria gaan dienst doen als bronsysteem, ontstaat daarmee een doublure. Nadere afstemming is nodig, maar uitgangspunt moet zijn dat een HIS geen gegevens aanmeldt (en dus oplevert) die al door de bron zijn aangemeld. |
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).