7kezo:V1.0 Gebruik van de verwijsindex: verschil tussen versies
| Regel 5: | Regel 5: | ||
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. | 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- | + | 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. | 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. | ||
Versie van 9 jun 2014 03:14
{{#customtitle: Gebruik van de verwijsindex | Gebruik van de verwijsindex}}
Dit materiaal is onderdeel van HL7v3-domein Ketenzorg V1.0_HL7v3-uitwisseling_Ketenzorg.
|
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).