Bijlage A: CDA document (algemene specificatie)

Inleiding

Doel en Scope

Dit document beschrijft de implementatie van het uitwisselmechanisme voor de zorgtoepassing Ketenzorg. Dit borduurt voort op het architectuurontwerp voor deze zorgtoepassing, maar geeft hieraan een vorm die direct bruikbaar is voor ontwikkelaars van XIS-applicaties (en het LSP) om de betreffende applicatierollen te kunnen realiseren.

Conform het ontwerp beschrijft deze implementatiehandleiding vier interacties tussen applicaties binnen de zorgtoepassing Ketenzorg. Dit betreft de volgende interacties:

• Verwijzing (huisarts naar zorggroep)
• Opvragen huisartsgegevens (door zorggroep)
• Opleveren huisartsgegevens (aan zorggroep)
• Overdracht contactgegevens (zorggroep naar huisarts)

Deze ‘logische’ interacties verlopen allemaal in twee stappen, doordat het LSP als schakelpunt in de infrastructuur fungeert. In hoofdstuk 4 worden de interacties binnen deze zorgtoepassing nader uitgewerkt en wordt ook toegelicht welke rol het LSP daarbij speelt. Hierbij wordt onderscheid gemaakt tussen zogenaamde ‘push’ en ‘pull’ interacties.

De feitelijke (medische) inhoud wordt bij deze interacties uitgewisseld in de vorm van generieke bouwstenen (of eigenlijk: bouwsteeninstantiaties). De implementatie van deze bouwstenen wordt beschreven in een aparte implementatiehandleiding [HL7v3 IH Bouwstenen], aangezien deze onafhankelijk is van het gebruikte uitwisselmechanisme.

De scope van de gebruikte bouwstenen wordt voorlopig beperkt gehouden, omdat eerst wordt gewerkt aan een ‘proof of concept’ (PoC) project. Dit dient om het hier beschreven uitwisselmechanisme te toetsen op uitvoerbaarheid. Daarvoor zijn niet alle bouwsteen-typen nodig. Na de PoC zal een eerste pilotimplementatie in productie plaatsvinden.

Noot: de publicatievorm van deze interacties zal uiteindelijk liggen in de ART-DECOR omgeving, maar voorlopig wordt gebruik gemaakt van dit Word document voor een snelle afstemming met de werkgroep HL7 implementatie van het project Referentiearchitectuur Ketenzorg. Parallel wordt gewerkt aan het opzetten van een weergave in ART-DECOR, inclusief gekoppelde XML onderdelen en aangevuld met wiki-pagina’s, die leidend zal zijn voor de start van de proof of concept fase.

Doelgroep voor dit document

De doelgroep voor dit document bestaat uit de XIS-leveranciers die het hierin beschreven uitwisselmechanisme moeten ondersteunen binnen hun software. Daarbij hoort ook de leverancier van het LSP, aangezien het LSP een belangrijke rol heeft in de architectuur van de zorgtoepassing Ketenzorg. Alle interacties lopen via het LSP. Het LSP fungeert voor pull verkeer als ‘gateway’ (voor bronsystemen waar gegevens worden opgehaald). Voor push verkeer fungeert het LSP als ‘router’, oftewel als één-op-één doorgeefluik.

Relatie met overige documenten

Dit document is bewust zoveel mogelijk opgezet als een zelfstandige bron van informatie. De HL7 versie 3 standaard is nuttig als achtergrondinformatie, maar niet per se noodzakelijk om het uitwisselmechanisme te implementeren. Wel wordt er verwezen naar documenten waarin generieke onderdelen van de implementatie beschreven worden:

Implementatiehandleiding HL7v3 Basiscomponenten

Deze bevat de specificatie van de datatypes (conform DT Release 1 van HL7v3), die fungeren als basiscomponenten bij de uitwisseling van alle informatie, of dat nu om berichten of CDA documenten gaat (beide gebruiken dezelfde elementaire datatypes). Noot: deze implementatiehandleiding wordt beheerd door Stichting HL7 Nederland.

Implementatiehandleiding HL7v3 Berichtwrappers

Deze bevat de specificatie van de verschillende typen wrappers (batch, transmission en control act) die als ‘envelop’ met metagegevens dienen bij uitwisseling van HL7v3 berichten. Overigens worden binnen AORTA ook CDA documenten als ‘payload’ van berichten uitgewisseld, aangezien de infrastructuur op dit mechanisme gebaseerd is.

Implementatiehandleiding HL7v3 CDA Header

Deze bevat de specificatie van de metagegevens in een CDA document, waaronder bijv. de betreffende patiënt en de auteur van het document. De wijze waarop deze gegevens gevuld worden in Nederlandse CDA implementaties is gestandaardiseerd. Noot: deze implementatiehandleiding wordt beheerd door Stichting HL7 Nederland.

Er wordt in dit document nadrukkelijk niets vermeld over de implementatie van de bouwstenen waarin de (medische) inhoud wordt overgedragen. Deze handleiding beschrijft alleen de implementatie van het uitwisselmechanisme. De opzet van de bouwstenen is per definitie onafhankelijk daarvan. De enige wisselwerking die kan bestaan is dat sommige gegevenselementen in de bouwsteeninstantiaties optioneel kunnen zijn, omdat ze impliciet bekend zijn vanuit de omliggende gegevensdrager.

Documenthistorie

De bewerking van de gidsen over de bouwstenen ketenzorg en de uitwisseling (interacties enz.) worden synchroon gehouden waardoor er maar één historie wordt bijgehouden.

Versie	Datum	Omschrijving
0.1.0.0	01-01-2014	Eerste versie t.b.v. de werkgroep HL7 implementatie
0.2.0.0	02-01-2014	Update met nadere uitwerking diverse bouwstenen, plus aanpassing labbouwsteen aan bestaande spec’s.
0.9.0.0	15-01-2014	Verwerking reacties n.a.v. interne review plus aanvullen diverse specificaties.
1.0.0.0	01-03-2014	Verwerking reacties n.a.v. externe review plus verwerken nieuwe inzichten.
1.0.1.0	01-06-2014	Verwerking nieuwe inzichten mbt tot gebruik bouwsteen "Labbepaling" en "Medicatievoorschrift"
2.0.0.0	21-06-2015	Versie 2 van de gidsen, toevoegen van Contactverslag, Overdracht concern, Alert en Allergien en intoleranties en alle relevante informatie over structuur en uitwisselmechanismen.
2.0.1.0	30-11-2015	Nieuwe query parameter message type QUMT_RM020099NL03
2.0.1.0	30-12-2016	Implementatiehandleiding aangepast conform huidige kennis en afspraken binnen Ketenzorg

Legenda

Let op! Dit is een aandachtpunt. Een opmerking die de aandacht vestigt op een bepaald opvallend aspect

Dit is een 'open issue' of 'known issue'. Een kwestie die nog open ligt voor discussie, maar onderkend is.

Dit is een frequently asked question (FAQ) met antwoord.

Storyboards

De zorgtoepassing Ketenzorg is in detail beschreven in het document Zorgtoepassing ontwerp Ketenzorg versie 4.2, waarbij de analyse een verzameling interacties heeft opgeleverd die nodig zijn om de zorgtoepassing Ketenzorg volledig te implementeren.

Daarbij is aangetekend dat in de eerste fase van de implementatie van de zorgtoepassing slechts een subset van de mogelijke interacties tussen de betrokken actoren in scope is. Deze fase wordt ondersteund met een ‘proof of concept’ project en aansluitende pilot.

Deze interacties worden geïllustreerd door middel van onderstaande storyboards, waardoor duidelijk wordt hoe ze passen binnen het primair proces van de ketenzorg, voor zover dat betrekking heeft op de samenwerking tussen huisarts en zorggroep.

Storyboard ZTKZ_ST000001NL – Ketenzorg huisarts-zorggroep

Doel: Beschrijving van het proces waarbinnen gegevens worden uitgewisseld tussen huisartsen en een zorggroep bij ketenzorg, met diabeteszorg als voorbeeldcasus.

Storyboard narratives

Verwijzing (huisarts naar zorggroep)

Een huisarts ziet een patiënt op het spreekuur die melding maakt van bepaalde klachten, die de huisarts het vermoeden geven dat sprake is van diabetes. De huisarts neemt een gerichte anamnese af bij de patiënt, doet ter plaatse een glucosemeting en vraagt aanvullend labonderzoek aan om de diagnose te ondersteunen. Na ontvangst van de labresultaten wordt de diagnose diabetes type II gesteld. De patiënt wordt doorverwezen naar een diabetesverpleegkundige, onderdeel van de regionale diabeteszorggroep, die gebruik maakt van een keteninformatiesysteem (KIS). De elektronische verwijzing bevat een toelichting op de reden van verwijzing en zorgt ervoor dat de patiënt bekend is in het KIS, waarna de diabetesverpleegkundige een afspraak kan inplannen voor een bezoek.

Opvragen huisartsgegevens (door zorggroep)

Vlak voor het moment dat een patiënt gezien wordt binnen een zorggroep, wordt vanuit het keteninformatiesysteem een relevante subset van gegevens uit het huisartsdossier opgevraagd. Dit gebeurt door een generieke query naar het LSP te sturen, waarin wordt aangegeven wat de context van het gegevensverzoek is. Het LSP verwerkt dit verzoek en zet het om in een aantal specifieke deelverzoeken naar bronsystemen, die over de benodigde gegevens beschikken. De opgeleverde resultaten worden samengevoegd en geretourneerd aan het KIS. Deze gegevens worden gebruikt om het dossier in het KIS bij te werken en vormen de basis voor de registratie van het contact binnen de zorggroep.

Overdracht contactgegevens (zorggroep naar huisarts)

Nadat een contact bij de zorggroep heeft plaatsgevonden, wordt de huisarts op de hoogte gebracht van de resultaten door het betreffende subdossier met contactgegevens over te dragen. Dit subdossier omvat alleen gegevens die in het KIS van de zorggroep zelf zijn ontstaan en die nog niet eerder aan de huisarts waren overgedragen. De betreffende gegevens worden aangeboden aan het huisartsinformatiesysteem (HIS), met de veronderstelling dat de gegevens daarin permanent worden overgenomen. Vanaf dat moment is het HIS de bron van de betreffende gegevens, hoewel het auteurschap van afzonderlijke gegevens wel blijft liggen bij de inhoudsverantwoordelijke zorgverlener.

Interactiediagram

Interactiediagram Ketenzorg huisarts-zorggroep

Voor toelichting op de applicatierollen en interacties in bovenstaand diagram, zie hoofdstuk 3 respectievelijk hoofdstuk 4. In hoofdstuk 4 wordt eerst een algemene toelichting gegeven op het gebruik van ‘push’ en ‘pull’ als uitwisselmechanisme.

Binnen de scope van de zorgtoepassing Ketenzorg in de eerste fase zullen alle applicatierollen aan de linkerkant worden ingevuld door het huisarts-informatiesysteem (HIS) en alle applicatierollen aan de rechterkant door het ketenzorginformatiesysteem (KIS) dat gebruikt wordt binnen de zorggroep.

Applicatierollen

Dit hoofdstuk beschrijft de applicatierollen voor de zorgtoepassing Ketenzorg:

• ZTKZ_AR000001NL Patiëntverwijzend ketenzorgsysteem
• ZTKZ_AR000002NL Patiëntontvangend ketenzorgsysteem
• ZTKZ_AR000003NL Gegevensopvragend ketenzorgsysteem
• ZTKZ_AR000004NL Gegevensopleverend ketenzorgsysteem
• ZTKZ_AR000005NL Contactoverdragend ketenzorgsysteem
• ZTKZ_AR000006NL Contactovernemend ketenzorgsysteem
• AZIM_AR000000NL Zorg Informatie Makelaar (ZIM)

Het zal duidelijk zijn dat vaak meerdere applicatierollen door hetzelfde systeem vervuld zullen worden. De rollen zijn echter toch uitgesplitst in sets van twee, omdat mogelijk niet alle typen interacties door alle systemen ondersteund worden. Door deze indeling kan een HIS eenvoudig aangeven of het kan verwijzen, opleveren en/of overnemen, terwijl een KIS kan aangeven of het kan ontvangen, opvragen en/of overdragen.

Er kan gesteld worden dat de applicatierollen (en bijbehorende interacties) voor het verwijzen van de patiënt eigenlijk generiek van aard moeten zijn en niet specifiek voor zorgtoepassing Ketenzorg, laat staan specifiek voor de verwijzing van huisarts naar zorggroep. Dit moet nog worden besproken.

De rol van de ZIM is steeds dezelfde, namelijk die van intermediair bij de communicatie tussen twee systemen, of dat als ‘router’ voor push verkeer of als ‘gateway’ voor pull verkeer is.

ZTKZ_AR000001NL - Patiëntverwijzend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die ondersteuning kunnen bieden bij het verwijzen van een patiënt naar een zorggroep. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol vervuld door het HIS bij een huisarts(praktijk).

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	verwijzingHuisartsZorggroep	ZTKZ_IN000004NL	zender
2	Accept Acknowledgement	MCCI_IN000002	ontvanger

ZTKZ_AR000002NL - Patiëntontvangend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die ondersteuning kunnen bieden bij het registeren van de behandeling van een patiënt na verwijzing. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol vervuld door het KIS van een zorggroep.

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	verwijzingHuisartsZorggroep	ZTKZ_IN000004NL	ontvanger
2	Accept Acknowledgement	MCCI_IN000002	zender

Merk op dat de Accept Acknowledgement alleen dient om aan te geven of de verwijzing correct is ontvangen en opgeslagen. Het eventueel weigeren van verwijzingen in procedurele zin wordt (nog) niet via HL7 interfaces opgelost. Uitgangspunt is dat in dat geval mondelinge communicatie wordt toegepast.

ZTKZ_AR000003NL – Gegevensopvragend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die zorggegevens van een patiënt opvragen, voor zover deze van belang zijn in de ketenzorg. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol vervuld door het KIS binnen een zorggroep.

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	generiekeQueryZorggegevens	GQZG_IN000001NL	zender
2	Batch Antwoord	MCCI_IN200101	ontvanger

ZTKZ_AR000004NL – Gegevensopleverend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die zorggegevens van een patiënt opleveren, voor zover deze van belang zijn in de ketenzorg. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol primair vervuld door het HIS bij een huisarts(praktijk), hoewel het ook kan gaan om andere systemen die als bronsysteem fungeren voor de betreffende gegevens. Dit komt omdat de query voor het opvragen van de betreffende bouwstenen wordt doorgestuurd aan alle systemen die aanmelding bij de verwijsindex hebben voor gegevenssoorten die deze bouwstenen (mogelijk) omvatten.

Mogelijk is het correcter om deze applicatierol op te splitsen in aparte applicatierollen per bouwsteentype, aangezien de interacties waar het hier om gaat ook bouwsteenspecifiek zijn. Vooralsnog zijn deze samengenomen onder één applicatierol, omdat ze in het kader van de gegevensdeling binnen de zorgtoepassing Ketenzorg allemaal primair door het HIS vervuld worden.

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	opvragenLabUitslagen	POLB_IN354001NL03	ontvanger
2	opvragenAlgemeneUitslagen	POOB_IN990001NL	ontvanger
3	opvragenContactmomenten	PRPA_IN900300NL	ontvanger
4	opvragenVoorschritenLijst	QURX_IN990201NL01	ontvanger
5	opleverenLabUitslagen	POLB_IN364001NL02	zender
6	opleverenAlgemeneUitslagen	POOB_IN990003NL	zender
7	opleverenContactmomenten	PRPA_IN900350NL	zender
8	opleverenVoorschriftenLijst	QURX_IN990203NL01	zender

ZTKZ_AR000005NL – Contactoverdragend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die het subdossier kunnen overdragen dat is opgebouwd tijdens het contact binnen een zorggroep. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol vervuld door het KIS van een zorggroep.

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	overdrachtZorggroepHuisarts	ZTKZ_IN000004NL	zender
2	Accept Acknowledgement	MCCI_IN000002	ontvanger

ZTKZ_AR000006NL - Contactovernemend ketenzorgsysteem

Deze applicatierol heeft betrekking op systemen die het dossier kunnen verwerken dat is overgedragen na behandeling binnen een zorggroep. Binnen de huidige scope van de zorgtoepassing Ketenzorg wordt deze rol vervuld door het HIS bij een huisarts(praktijk).

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	overdrachtZorggroepHuisarts	ZTKZ_IN000004NL	ontvanger
2	Accept Acknowledgement	MCCI_IN000002	zender

Merk op dat de Accept Acknowledgement alleen dient om aan te geven of de contactgegevens correct zijn ontvangen en opgeslagen. Uitgangspunt is namelijk dat de beheeroverdracht niet geweigerd kan worden.

AZIM_AR000000NL – Zorg Informatie Makelaar (ZIM)

Deze applicatierol heeft betrekking op de Zorg Informatie Makelaar (ZIM) in diens rol als centrale component in de infrastructuur van AORTA. De ZIM fungeert daarbij als ‘gateway’ voor zogenaamd pull verkeer (waarbij de ZIM bepaalt welke systemen bevraagd moeten worden o.b.v. een inkomende query en het resultaat daarna bundelt).

De interacties voor deze applicatierol zijn:

#	Omschrijving	HL7v3-interactie	Zender/ontvanger
1	generiekeQueryZorggegevens	GQZG_IN000001NL	ontvanger
2	opvragenLabUitslagen	POLB_IN354001NL02	zender
3	opvragenAlgemeneUitslagen	POOB_IN990001NL	zender
4	opvragenContactmomenten	PRPA_IN900300NL	zender
5	opvragenVoorschritenLijst	QURX_IN990201NL01	zender
6	opleverenLabUitslagen	POLB_IN364001NL02	ontvanger
7	opleverenAlgemeneUitslagen	POOB_IN990003NL	ontvanger
8	opleverenContactmomenten	PRPA_IN900350NL	ontvanger
9	opleverenVoorschriftenLijst	QURX_IN990203NL01	ontvanger
10	Batch Antwoord	MCCI_IN200101	zender

Merk op dat de functie van de ZIM als ‘router’ voor push verkeer (waarbij het verzendende systeem zelf adresseert en de ZIM alleen doorstuurt) niet is opgenomen in deze tabel, omdat de ZIM daarbij in de zin van HL7 geen rol als ‘applicatie’ vervult.

Interacties

Dit hoofdstuk beschrijft de interacties voor de zorgtoepassing Ketenzorg:

1.	Verwijzing van huisarts naar zorgdroeg	push
2.	Opvragen huisartsgegevens door zorggroep	pull - query
3.	Retourneren huisartsgegevens aan zorggroep	pull - response
4.	Overdracht contact van zorggroep naar huisarts	push

Feitelijk bestaat het bovenstaande lijstje niet uit enkelvoudige interacties, omdat ze allen via het LSP lopen en dus uiteenvallen in twee stappen, die als volgt zijn samen te vatten:

• een interactie tussen het verzendende XIS en het LSP
• een interactie tussen het LSP en het ontvangende XIS.

De rol van het LSP hangt af van de vraag of het gaat om een push of een pull interactie. Om die reden zijn hieronder aparte paragrafen aangemaakt voor deze twee categorieën.

Beschrijving push mechanisme

Bij push interacties is de interactie die wordt verzonden van het verzendende XIS naar het LSP dezelfde als degene die wordt verzonden van het LSP naar het ontvangende XIS. Dit komt omdat het LSP hier fungeert als ‘router’ en de complete interactie (m.u.v. de adressering) doorzet van een inkomende web service naar een uitgaande web service.

De interactie wordt geïmplementeerd op basis van het aanroepen van een web service, waarbij een HL7 versie 3 bericht als SOAP body wordt meegestuurd. Dat HL7v3 bericht op zijn beurt heeft als payload een CDA document, waarin een verzameling gestructureerde bouwsteeninstantiaties (in de vorm van ‘clinical statements’ als ‘entries’ in het document) zijn opgenomen, naast een tekstuele weergave van de gegevensset.

De keuze voor een CDA document als gegevensdrager is ingegeven door het feit dat een push interactie zich leent voor toepassing van CDA. Er is immers sprake van een verzameling gegevens waarvoor de verzender integraal verantwoordelijkheid neemt en die op één moment verzonden wordt. Daarbij is het wenselijk om aan te sluiten bij de heersende trend om CDA in te zetten in dit soort situaties (bijv. CCD, dat breed wordt toegepast in de VS). Dit leidt er namelijk toe dat veel, vooral internationaal gebruikte systemen standaardinterfaces hebben om gegevens als CDA document op te leveren. Deze trend heeft zijn zwaartepunt in de 2e lijn, maar is daartoe niet beperkt.

Het lijkt ‘overkill’ om het CDA document ook nog te verpakken in bericht-wrappers, maar op de korte termijn is dat de enige manier om gegevens te verzenden via het LSP. Er kan worden bekeken of het mogelijk is om de relevante informatie uit de berichtwrappers (UZI-gegevens verzender, applicatie-ID ontvanger) in plaats daarvan op te nemen in de SOAP-laag, waar nu ook het authenticatietoken al in staat (zij het in gecodeerde vorm).

Push interacties

Hieronder worden de push interacties beschreven die relevant zijn voor Ketenzorg.

ZTKZ_IN000001NL - verwijzingHuisartsZorggroep

Deze interactie wordt gebruikt voor de initiële verwijzing door een huisarts naar een zorggroep, in het kader van ketenzorg. Daartoe moet het HIS van de huisarts het URA nummer en de applicatie ID van het KIS van de zorggroep kennen. Deze interactie dient als trigger voor de zorggroep om het behandelproces voor de patiënt in gang te zetten (bijv. door het maken van een afspraak voor één of meer consulten). Bij de interactie wordt alleen (optioneel) de reden van verwijzing (zoals ingegeven door de huisarts) meegestuurd. Kort voor het eerste consult van de patiënt zullen alle relevante gegevens (in de context van de behandeling) bij de huisarts worden opgevraagd (zie par. 4.4.1).

Er is op dit moment gekozen voor een ‘kale verwijzing’, dus zonder dat (het relevante deel van) het dossier wordt meegestuurd. Het was ook mogelijk geweest om deze gegevens wel met de verwijzing mee te sturen, maar dan zou later alsnog een update opgevraagd moeten worden, omdat de gegevens tussen verwijzing en eerste afspraak kunnen zijn bijgewerkt.

In hoofdstuk CDA Document staat beschreven hoe het CDA document in algemene zin gevuld moet worden voor gebruik in de zorgtoepassing Ketenzorg. De enige "bouwsteen" die voor mag komen bij gebruik in deze interactie is een tekst-sectie met klinische informatie i.v.m. de verwijzing.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Verwijzing ketenzorgpatiënt	ZTKZ_TE000001NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Control Act	MCAI_MT700201
Payload	Verwijzing ketenzorgpatiënt (Clinical Document)	ZTKZ_MT000001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Patiëntverwijzend ketenzorgsysteem	ZTKT_AR000001NL
Receiver	Patiëntontvangend ketenzorgsysteem	ZTKT_AR000002NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
Ontvangstbevestiging	MCCI_TE000002	MCCI_IN000002

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.1 Verwijzing Huisarts Zorggroep is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

ZTKZ_IN000004NL - overdrachtZorggroepHuisarts

Deze interactie wordt gebruikt voor het overdragen van gegevens door een zorggroep naar een huisarts, in het kader van ketenzorg. Daarbij worden de relevante gegevens meegestuurd die in de zorggroep zijn geregistreerd tijdens een specifiek patiëntcontact. Deze gegevens worden door het HIS overgenomen in het dossier van de huisarts en vanaf dat moment is de huisarts(praktijk) beheerverantwoordelijk voor deze gegevens. Dat wil zeggen dat het HIS de overgedragen gegevens ook oplevert als het bevraagd wordt, ook vanuit de zorggroep (indien de patiënt daar actief blijft).

Er is op dit moment gekozen voor verplichte overdracht van de gegevens bij het contact. In principe zou de zorggroep ook zelf als bron (en beheerder) van deze gegevens kunnen fungeren, maar dat is niet de afspraak. Ook zou het denkbaar zijn dat het HIS (of een huisarts die het gebruikt) de over te dragen gegevens kan weigeren. Ook die mogelijkheid bestaat nu nog niet.

In bijlage A staat beschreven hoe het CDA document in algemene zin gevuld moet worden voor gebruik in de zorgtoepassing Ketenzorg. De bouwstenen die voor mogen komen bij gebruik in deze interactie zijn de volgende (scope voor ‘proof of concept’):

• Labbepaling
• Algemene bepaling
• Contactmoment

Merk op dat er dus geen medicatievoorschriften overgedragen mogen worden.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Overdracht ketenzorgdossier	ZTKT_TE000004NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Control Act	MCAI_MT700201
Payload	Overdracht ketenzorgdossier (Clinical Document)	ZTKZ_MT000004NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Dossieroverdragend ketenzorgsysteem	ZTKT_AR000005NL
Receiver	Dossierontvangend ketenzorgsysteem	ZTKT_AR000006NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
Ontvangstbevestiging	MCCI_TE000002	MCCI_IN000002

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.2 Overdracht Zorggroep Huisarts is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

ZTKZ_IN000005NL - verwijzingAfbrekenHuisartsZorggroep

Deze interactie wordt gebruikt voor het afbreken van een eerder plaatsgevonden verwijzing door een huisarts naar een zorggroep, in het kader van ketenzorg.

In hoofdstuk CDA Document staat beschreven hoe het CDA document in algemene zin gevuld moet worden voor gebruik in de zorgtoepassing Ketenzorg. De enige "bouwsteen" die voor mag komen bij gebruik in deze interactie is een tekst-sectie met i.v.m. het afbreken van de verwijzing.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Verwijzing ketenzorgpatiënt	ZTKZ_TE000005NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Control Act	MCAI_MT700201
Payload	Verwijzing / afbreken verwijzing ketenzorgpatiënt (Clinical Document)	ZTKZ_MT000001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Patiëntverwijzend ketenzorgsysteem	ZTKT_AR000001NL
Receiver	Patiëntontvangend ketenzorgsysteem	ZTKT_AR000002NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
Ontvangstbevestiging	MCCI_TE000002	MCCI_IN000002

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.21 Verwijzing Afbreken Huisarts Zorggroep is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

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).

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).

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).

Interacties tussen vrager en LSP

GQZG_IN000001NL - generiekeQueryZorggegevens

Deze interactie wordt binnen de zorgtoepassing Ketenzorg gebruikt om een relevante subset van het huisartsdossier op te vragen vanuit de zorggroep. Deze interactie is universeel van aard en kan dus ook worden toegepast in andere settings. De aard van de opgevraagde gegevens wordt bepaald door de contextcode die als parameter wordt meegegeven (in combinatie met het autorisatieprofiel van de vragende zorgverlener).

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Versturen vraag ketenzorggegevens	GQZG_TE000001NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Generieke query zorggegevens	GQZG_MT000001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopvragend ketenzorgsysteem	ZTKT_AR000003NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query (de ZIM) moet de meegegeven parameters verwerken en bepalen welke bouwsteenspecifieke queries er nodig én toegestaan zijn (en met welke parameters) om aan de vraag te voldoen. Deze queries worden vervolgens gestuurd aan de bronsystemen die (mogelijk) deze gegevens bevatten. De responses op de uitgestuurde queries worden tenslotte verzameld en als batch geretourneerd. Het retourbericht is:	-	MCCI_IN200101

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.3 Generieke Query Zorggegevens is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

MCCI_IN200101 - batchAntwoord

Deze interactie wordt binnen de zorgtoepassing Ketenzorg gebruikt om een relevante subset van het huisartsdossier op te leveren vanuit het huisartssysteem. Deze interactie is universeel van aard en kan dus ook worden toegepast in andere settings. De payload van het batchAntwoord bestaat uit een set HL7v3 interacties (inclusief berichtwrappers). Deze interacties kunnen van een verschillend type zijn, elk weer met hun eigen payload.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag ketenzorggegevens	MCCI_TE200002UV01
Transmission Wrapper	Batch Wrapper event response message	MCCI_MT200101
Control Act Wrapper	n.v.t.
Message Type	n.v.t.

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopvragend ketenzorgsysteem	ZTKT_AR000003NL

R-MIM

Template

Zie de specificaties in het document Implementatiehandleiding HL7v3 Berichtwrappers, waar het message type van de “batchwrapper” wordt beschreven in paragraaf 13.4.

Een belangrijk verschil met de wijze waarop de batchwrapper tot nu toe wordt gebruikt binnen AORTA, is dat deze in de zorgtoepassing Ketenzorg (en andere toepassingen volgens hetzelfde ontwerp) verschillende typen interacties in dezelfde batch mag omvatten! Het batchAntwoord is weliswaar een reactie op één inkomende generiekeQueryZorggegevens, maar deze reactie bestaat uit alle query responses die zijn voortgekomen uit de bouwsteenspecifieke queries waarin de oorspronkelijke vraag door het LSP is omgezet.

In aanvulling op bovenstaande: van een bouwsteentype kunnen ook nog meerdere verschillende versies terecht komen in de batch, als er bron-systemen zijn die met verschillende versies werken (ze mogen maximaal één versie ‘achterlopen’. Omdat de regel is dat elk systeem de ‘voorgaande’ versie ook nog moet ondersteunen, levert deze mix geen problemen op.

Elke door het LSP ontvangen query response wordt meegenomen in de batch, ook als deze geen resultaten bevat (bijv. omdat de query parameters zodanig waren dat er geen gegevens aan voldeden) of er sprake was van een foutmelding (bijv. omdat het bronsysteem de query niet kon verwerken)

Bij het definiëren van het batchantwoord dat hoort bij een generieke query naar zorggegevens met een bepaalde contextcode, moet het mogelijk zijn om aan te geven welke mogelijke bouwsteenspecifieke antwoordinteracties voor kunnen komen in de batch. Deze lijstjes zijn direct gerelateerd aan de afleiding die op het LSP wordt gemaakt van contextcode naar bouwsteen-specifieke queries. Hiermee weet een vragend systeem welke bouwstenen (en bijbehorende interacties) het moet kunnen verwerken voor een context.

De template 2.16.840.1.113883.2.4.3.11.60.66.10.4 Batch antwoord is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

Tijdens de eerste fase van de zorgtoepassing Ketenzorg zullen de query responses overigens nog (vrijwel) allemaal uit hetzelfde systeem afkomstig zijn, aangezien alleen het HIS van de huisarts aanmeldingen in de verwijsindex zal hebben (met gegevenssoort ‘Primary Care Provision’) die leiden tot bouwsteenspecifieke queries die dan in scope zijn. Voor de definitie van de hierboven genoemde interacties, zie de paragraaf Interacties tussen LSP en bron.

Interacties tussen LSP en bron

De hiernavolgende interacties zijn query/response paren voor het opvragen van specifieke bouwsteentypen, voor zover deze in scope zijn voor de ‘proof of concept’ fase van de zorgtoepassing Ketenzorg. De query interacties worden hier volledig beschreven, inclusief het template voor de query parameters en bijbehorende XML voorbeelden.

Van de query responses wordt alleen beschreven hoe deze ‘verpakt’ worden. De payload van de query responses bestaat immers uit bouwsteenimplementaties, zoals die worden beschreven in het document HL7v3 IH Bouwstenen. Afhankelijk van het bouwsteentype kan deze verpakking (wrappers plus een eventuele header) een andere vorm hebben.

Initieel werden de bouwsteenspecifieke queries gerealiseerd o.b.v. bestaande interacties uit de AORTA specificaties (zoals bij labuitslagen en voorschriftenlijst). Alsnog werd besloten om een samenvattende nieuwe interactie uit te werken, die alle query parameters bevat.

Daar waar er voor de zorgtoepassing Ketenzorg aanpassingen worden gedaan aan een template dat al onderdeel is van de AORTA specificaties (hetgeen is gebeurd bij labuitslagen), moet nog overlegd worden om alsnog harmonisatie te bewerkstelligen, zeker als het gaat om niet-compatibele verschillen (zoals bij persoonsgegevens en inhoudsverantwoordelijke).

Een belangrijk aspect is de versionering van de bouwsteenspecifieke queries (en van de bouwstenen zelf). De versie van elke interactie (dus ook van de queries) is af te leiden uit het interactie ID, dat ook al root element fungeert. De versie van een bouwsteeninstantiatie is direct gerelateerd aan het template ID dat erin wordt meegegeven. Vermoedelijk zal het zo zijn dat als de bouwsteen van versie verandert, de bijbehorende query dat ook zal doen, maar daarover moet nog nader overleg gevoerd worden en er kan ervaring mee worden opgedaan in de proof of concept fase van het project.

Generiek query parameters

Om de implementatie van de afzonderlijke queries simpler te maken zijn de volgende queries allemaal voorzien van één generieke query parameter message type QUMT_MT020099NL03:

• POLB_IN354001NL02 - opvragenLabUitslagen
• POOB_IN990001NL - opvragenAlgemeneUitslagen
• PRPA_IN900300NL - opvragenContactmomenten
• QURX_IN990201NL01 - opvragenVoorschriften
• REPC_IN990100NL - opvragenContactverslagen
• REPC_IN990110NL - opvragenOverdrachtconcerns
• REPC_IN990120NL - opvragenAlerts
• REPC_IN990130NL - opvragenAllergieintoleranties

Het onderstaande R-MIM geeft het payload-model van het generieke query parameter message type

POLB_IN354001NL02 - opvragenLabUitslagen

Deze interactie wordt door het LSP gebruikt om laboratoriumuitslagen op te vragen bij bronsystemen. De daarbij gebruikte query is een update van de interactie die eerder is gespecificeerd om labuitslagen op te vragen t.b.v. medicatiebewaking door apotheken, vandaar de versieaanduiding 03 in het interactie ID. Beide varianten zijn een lokalisatie van de internationale standaard uit het Laboratory domein (vandaar de aanduiding NL).

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Labuitslagen	POLB_TE354001NL02
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Labuitslagen (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle labuitslagen die daaraan voldoen retourneren, voor zover deze niet lokaal afgeschermd zijn. Het retourbericht is:	POLB_TE364001NL02	POLB_IN364001NL02

Template

Het template voor deze interactie is vrijwel gelijk aan dat van de interactie om labuitslagen op te vragen t.b.v. medicatiebewaking door apotheken, zoals dat is opgenomen in de AORTA v6.12 specificaties. Deze wijzigingen zijn aangebracht:

• Het element <observationEffectiveTime> wordt iets anders gebruikt (zie aldaar).
• Het element <observationType> is toegevoegd (dit is wél onderdeel van de internationale specificaties, maar was uitgesloten in het Nederlandse template).
• Het element <responseTemplateId> heeft een andere (vaste) waarde, omdat het antwoordbericht in dit geval een iets ander template heeft.

Bovenstaande verschillen leiden niet tot aanpassingen in het schema van de interactie, ten opzichte van de versie uit de AORTA v6.12 specificaties. Dat verschil ontstaat doordat het element <value> onder de <observationType> herhalend is gemaakt (zie aldaar).

Er moet worden bekeken in hoeverre de update op het XML Schema, plus het gewijzigde gebruik van <observationEffectiveTime> en het toevoegen van <observationType> in het template, moeten worden doorgevoerd in de bestaande zorgtoepassing voor opvragen van labuitslagen door apotheken. Dit staat nog los van de discussie over het formaat van de labuitslagen zelf (de bouwsteendefinitie), zoals beschreven in de [HL7v3 IH Bouwstenen].

De template 2.16.840.1.113883.2.4.3.11.60.66.10.5 Opvragen Labuitslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

POLB_IN364001NL02 - opleverenLabUitslagen

Deze interactie wordt gebruikt door bronsystemen om aan het LSP labuitslagen op te leveren. Het bijbehorende XML Schema is exact gelijk aan dat van de interactie om labuitslagen op te leveren t.b.v. medicatiebewaking door apotheken, zoals dat is opgenomen in de AORTA v6.12 specificaties. Dit Schema is een lokalisatie van de internationale standaard uit het Laboratory domein (vandaar de toevoeging NL).

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Antwoord op OpvragenLabuitslagen	ZTKT_TE000005NL
Transmission Wrapper	Application Level Acknowledgement	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	OpleverenLabuitslagen	POLB_MT004000NL02

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

R-MIM

Het bovenstaande R-MIM geeft alleen het deel van het payload-model weer dat nodig is om de opgeleverde set bouwstenen (met afzonderlijke labbepalingen) te bundelen. Elke bouwsteen met een labuitslag fungeert dan als <component> in bovenstaand model.

De twee onderdelen samen (<observationReport> met <component> subelementen) zijn compatible met de specficaties die al op AORTA gebruikt worden voor het opvragen van labuitslagen. De <observationReport> klasse wordt feitelijk alleen gebruikt om te zorgen dat de patiënt slechts eenmaal hoeft te worden opgenomen voor alle uitslagen.

Elk van de <component> subelementen omvat één gestandaardiseerde bouwsteen met de uitslag van één enkele bepaling. De definitie van deze bouwsteen wordt nader gespecificeerd in de implementatiehandleiding met HL7v3 bouwstenen voor Ketenzorg.

Template

Het template voor deze interactie valt uiteen in twee delen:

• Het <observationReport> element fungeert als een header voor de opgeleverde verzameling labuitslagen. De patiëntidentificatie wordt meegeven op dit niveau.
• De <observationEvent> elementen bevatten de afzonderlijke labuitslagen. Elke herhaling van dit element is een instantiatie van de bouwsteen voor labuitslagen.

In dit hoofdstuk wordt alleen het template voor de header uitgewerkt. Dit template is gebaseerd op het template om labuitslagen op te leveren t.b.v. medicatiebewaking door apotheken, zoals dat is opgenomen in de AORTA v6.12 specificaties. De wijzigingen zijn:

• Diverse optionele onderdelen zijn niet overgenomen (dit is een valide restrictie).
• Het element <templateId> heeft door de wijzigingen een andere (vaste) waarde.
• Het element <observationReport><code> heeft een vaste waarde uit het codesysteem LOINC (namelijk 26436-6).
• Diverse onderdelen van <recordTarget><patient> zijn niet overgenomen, ook al zijn ze in het bestaande template verplicht. De reden is dat het onnodig lijkt om (verplicht) allerlei persoonsgegevens van de patiënt te retourneren aan de vrager.
• element <author> is niet overgenomen, ook al is het in het bestaande template verplicht. De reden is dat de inhoudsverantwoordelijke al wordt doorgegeven op het niveau van afzonderlijke labuitslagen (<observationEvent>).

De template 2.16.840.1.113883.2.4.3.11.60.66.10.6 Opleveren Labuitslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

De definitie van het subtemplate voor de bouwsteenimplementatie wordt nader gespecificeerd in de implementatiehandleiding met HL7v3 bouwstenen voor Ketenzorg, de template 2.16.840.1.113883.2.4.3.11.60.66.10.203 Labbepaling is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

POOB_IN990001NL - opvragenAlgemeneUitslagen

Deze interactie wordt door het LSP gebruikt om algemene uitslagen op te vragen bij bronsystemen. Deze interactie is nieuw ontwikkeld, omdat er nog geen bestaande standaard (nationaal of internationaal) is die hier precies voor bedoeld is. Het XML Schema dat gebruikt wordt voor de query parameters is de zogenaamde Generic Act Query, die ook wordt gebruikt bij het opvragen van ICA gegevens (intoleranties, contra-indicaties en allergieën), zoals opgenomen in de AORTA v6.12 specificaties. Dit Schema was ook bedoeld om voor verschillende soorten brongegevens te kunnen gebruiken.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Algemene Uitslagen	POOB_TE990001NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Algemene Uitslagen (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle algemene uitslagen die eraan voldoen retourneren, voor zover deze niet lokaal afgeschermd zijn. Het retourbericht is:	POOB_TE990003NL	POOB_IN990003NL

R-MIM

Het R-MIM is hetzelfde generieke model (en bijbehorend XML Schema) dat ook gebruikt wordt bij het opvragen van ICA-gegevens. Het biedt voldoende mogelijkheden om te filteren op de patiënt (verplicht), het tijdsinterval waarbinnen de bepaling werd gedaan en het soort zorgverlener dat inhoudsverantwoordelijk is voor het resultaat ervan.

Er heeft een uitbreiding op het model van de Generic Act Query plaatsgevonden om het mogelijk te maken om te kunnen filteren op basis van de code van de onderliggende Acts (in dit geval de algemene bepalingen). Dit is nodig omdat per contextcode een wisselende subset van diagnostische bepalingen in scope is (net zoals bij de labbepalingen). De toegevoegde parameter is typeSelection.

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.7 Opvragen Algemene Uitslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

POOB_IN990003NL – opleverenAlgemeneUitslagen

Deze interactie wordt door bronsystemen gebruikt om algemene bepalingen op te leveren naar aanleiding van een bevraging door het LSP. Deze interactie is nieuw ontwikkeld, omdat er nog geen bestaande standaard (nationaal of internationaal) is die hier precies voor bedoeld is (net zoals dat voor de query het geval is). De payload van de query response bestaat uit gestandaardiseerde bouwstenen die compatible zijn met CDA R2.

Het is mogelijk om een lijstconstructie in de query response toe te voegen om voor alle opgeleverde bepalingen in één keer aan te geven om welke patiënt het gaat. Dit mechanisme wordt ook toegepast bij de interactie voor het opvragen van medicatievoorschriften (opvragenVoorschriftenLijst). Vooralsnog is echter besloten om bij het opleveren van algemene bepalingen helemaal geen patiënt aan te duiden in de payload van de query response. Dit gebeurt in plaats daarvan in de <attentionLine> van de transmission wrapper van de interactie, zodat de vraagsteller (in dit geval het LSP) toch kan controleren dat gegevens van de juiste patiënt geretourneerd worden. Voordeel is dat het Clinical Statement van CDA R2 (d.w.z. de bouwsteen die erop gebaseerd is) direct als payload van de interactie gebruikt kan worden.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Antwoord op Opvragen Algemene Uitslagen	POOB_TE990003NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Opleveren Algemene Uitslagen (Clinical Statement)	POOB_MT990003NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL

R-MIM

De payload van de query response bestaat alleen uit een set bouwsteeninstantiaties. Zie bouwsteen Algemene Bepaling.

Template

De payload van de query response bestaat alleen uit een set bouwsteeninstantiaties. Zie bouwsteen Algemene Bepaling.

De template 2.16.840.1.113883.2.4.3.11.60.66.10.8 Opleveren Algemene Uitslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

PRPA_IN900300NL - opvragenContactmomenten

Deze interactie wordt door het LSP gebruikt om de contactmomenten op te halen bij bronsystemen. De interactie is gebaseerd op de query die is gedefinieerd in Release 2 van de Draft Standard for Trial Use (DSTU), onderdeel van de HL7v3 Normative Edition. Verschil is echter dat niet alle query parameters worden ondersteund en dat de payload van de query response is aangepast naar bouwstenen die compatible zijn met CDA R2.

De definitie van een contactmoment is “elke situatie waarbij contact is geweest (fysiek, mondeling of zelfs per mail) tussen een patiënt en één of meer van diens zorgverleners”. Dit omvat met name ambulante bezoeken (bijv. op spreekuur huisarts of specialist), maar ook klinische opnames (waarbij specialisten soms maar deels betrokken zijn). Ook een telefonisch consult of een chat via sociale media kan als contactmoment fungeren.

Merk op dat in deze fase de scope zodanig is dat vanuit het huisarts-dossier (opgebouwd conform het NHG model) niet elk deelcontact, maar alleen het contactmoment als geheel opgeleverd moet worden. Dit omdat voor nu alleen de administratieve aspecten relevant zijn, terwjl deelcontacten nodig zijn om de link naar episodes te leggen.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Find Encounters Query	PRPA_TE900300UV02
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Encounters (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle contactmomenten die eraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	PRPA_TE900350UV02	PRPA_IN900350NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.9 Opvragen Contactmomenten is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

PRPA_IN900350NL - opleverenContactmomenten

Deze interactie wordt door bronsystemen gebruikt om contactmomenten op te leveren naar aanleiding van een bevraging door het LSP. De interactie is gebaseerd op de query response die is gedefinieerd in Release 2 van de Draft Standard for Trial Use (DSTU), onderdeel van de HL7v3 Normative Edition. De payload van de query response is echter aangepast naar gestandaardiseerde bouwstenen die compatible zijn met CDA R2.

Het is mogelijk om een lijstconstructie in de query response toe te voegen om voor alle opgeleverde contactmomenten in één keer aan te geven om welke patiënt het gaat. Dit mechanisme wordt ook toegepast bij de interactie voor het opvragen van medicatievoorschriften (opvragenVoorschriftenLijst). Vooralsnog is echter besloten om bij het opleveren van contactmomenten helemaal geen patiënt aan te duiden in de payload van de query response. Dit gebeurt in plaats daarvan in de <attentionLine> van de transmission wrapper van de interactie, zodat de vraagsteller (in dit geval het LSP) toch kan controleren dat gegevens van de juiste patiënt geretourneerd worden. Voordeel is dat het Clinical Statement van CDA R2 (d.w.z. de bouwsteen die erop gebaseerd is) direct als payload van de interactie gebruikt kan worden.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Find Encounters Response	PRPA_TE900300UV02
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Opleveren Contactmomenten (Clinical Statement)	PRPA_MT900350NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

R-MIM

De payload van de query response bestaat alleen uit een set bouwsteeninstantiaties. Zie bouwsteen Contactmoment.

Template

De payload van de query response bestaat alleen uit een set bouwsteeninstantiaties. Zie bouwsteen Contactmoment.

De template 2.16.840.1.113883.2.4.3.11.60.66.10.10 Opleveren Contactmomenten is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

QURX_IN990201NL01 - opvragenVoorschriften

Deze interactie wordt door het LSP gebruikt om medicatievoorschriften op te halen bij bronsystemen. De interactie is identiek aan degene die wordt gebruikt binnen de zorgtoepassing Medicatieproces, maar wordt hier voor de volledigheid toch toegelicht.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen van medicatievoorschriften	QURX_TE990001NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen medicatievoorschriften (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle medicatievoorschriften die daaraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	-	QURX_IN990103NL02

R-MIM

Dit is het model dat gebruikt wordt binnen de zorgtoepassing Medicatieproces voor het opvragen van voorschriftenlijsten. Het biedt mogelijkheden om te filteren op de patiënt, het voorschriftnummer, het tijdsinterval waarbinnen het voorschrift beschikbaar kwam en het tijdsinterval waarbinnen de voorgeschreven medicatie naar schatting gebruikt wordt.

Het XML Schema dat bij deze query hoort bevat ook parameters die momenteel niet in scope zijn binnen de zorgtoepassing Medicatieproces. Eén daarvan is de parameter <medicationCode>, die gebruikt moet worden om te kunnen filteren op basis van de medicatiecode. Dit is nodig omdat per contextcode een wisselende subset van medicatiecodes in scope is (net zoals bij de labbepalingen). De parameter zal wel worden toegelicht in het template, maar het zal nodig zijn om de specificaties voor Medicatieproces ook aan te passen. Dat kan nu nog vrij gemakkelijk, omdat er nog geen applicaties gekwalificeerd zijn voor het opvragen van medicatievoorschriften.

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.11 Opvragen Medicatievoorschriften is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

QURX_IN990203NL01 - opleverenVoorschriften

Deze interactie wordt door bronsystemen gebruikt om medicatievoorschriften op te leveren naar aanleiding van een bevraging door het LSP.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag naar medicatievoorschriften	QURX_TE990002NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Lijst met medicatievoorschriften (als CDA R2 CS)	PORX_MT932200NL01

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

R-MIM

Het bovenstaande R-MIM geeft alleen het deel van het payload-model weer dat nodig is om de opgeleverde set bouwstenen (met medicatievoorschriften) te bundelen. Elke bouwsteen met een voorschrift fungeert dan als <component> in bovenstaand model.

De twee onderdelen (<medicationSubscriptionList> met <component> subelementen) zijn compatible met de specficaties die al op AORTA gebruikt worden voor het opvragen van medicatievoorschriften. De <medicationSubscriptionList> wordt feitelijk alleen gebruikt om te zorgen dat de patiënt slechts eenmaal hoeft te worden opgenomen.

Elk van de <component> subelementen omvat één gestandaardiseerde bouwsteen met één enkel medicatievoorschrift. De definitie van deze bouwsteen wordt nader gespecificeerd in de implementatiehandleiding met HL7v3 bouwstenen voor Ketenzorg.

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.12 Opleveren Medicatievoorschriften is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

De definitie van het subtemplate voor de bouwsteenimplementatie wordt nader gespecificeerd in de implementatiehandleiding met HL7v3 bouwstenen voor Ketenzorg, de template 2.16.840.1.113883.2.4.3.11.60.66.10.204 Voorschrift is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990100NL - opvragenContactverslagen

Deze interactie wordt door het LSP gebruikt om de contactverslagen op te halen bij bronsystemen.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Contactverslagen	REPC_TE990100NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Contactverslagen (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle contactverslagen die eraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	-	REPC_IN990101NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.13 Opvragen Contactverslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990101NL - opleverenContactverslagen

Deze interactie wordt door bronsystemen gebruikt om contactverslagen op te leveren naar aanleiding van een bevraging door het LSP.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag naar contactverslagen	REPC_TE990101NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Lijst met contactverslagen (als CDA R2 CS)	POCD_MT900001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.14 Opleveren Contactverslagen is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990110NL - opvragenOverdrachtconcerns

Deze interactie wordt door het LSP gebruikt om de overdrachtconcerns op te halen bij bronsystemen.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Overdrachtconcerns	REPC_TE990110NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Overdrachtconcerns (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle overdrachtconcerns die eraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	-	REPC_IN990111NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.15 Opvragen Overdrachtconcerns is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990111NL - opleverenOverdrachtconcerns

Deze interactie wordt door bronsystemen gebruikt om overdrachtconcerns op te leveren naar aanleiding van een bevraging door het LSP.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag naar overdrachtconcerns	REPC_TE990111NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Lijst met overdrachtconcerns (als CDA R2 CS)	POCD_MT900001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.16 Opleveren Overdrachtconcerns is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990120NL - opvragenAlerts

Deze interactie wordt door het LSP gebruikt om de alerts op te halen bij bronsystemen.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Alerts	REPC_TE990120NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Alerts (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle alerts die eraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	-	REPC_IN990121NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.17 Opvragen Alerts is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990121NL - opleverenAlerts

Deze interactie wordt door bronsystemen gebruikt om alerts op te leveren naar aanleiding van een bevraging door het LSP.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag naar alerts	REPC_TE990121NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Lijst met alerts (als CDA R2 CS)	POCD_MT900001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.18 Opleveren Alerts is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990130NL - opvragenAllergieintoleranties

Deze interactie wordt door het LSP gebruikt om de allergie/intoleranties op te halen bij bronsystemen.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Opvragen Allergieintoleranties	REPC_TE990130NL
Transmission Wrapper	Send Message Payload	MCCI_MT000100
Control Act Wrapper	Query Control Act Request : Query By Parameter	QUQI_MT021001
Message Type	Opvragen Allergieintoleranties (generieke query)	QUMT_MT020099NL03

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL
Receiver	Gegevensopleverend Ketenzorgsysteem	ZTKZ_AR000004NL

Receiver Responsibilities

Reden	Trigger Event	HL7v3-interactie
De ontvanger van de query moet de meegegeven parameters verwerken en alle allergie/intoleranties die eraan voldoen retourneren, voor zover deze gegevens niet lokaal afgeschermd zijn.	-	REPC_IN990131NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.19 Opvragen Allergieintoleranties is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

REPC_IN990131NL - opleverenAllergieintoleranties

Deze interactie wordt door bronsystemen gebruikt om allergie/intoleranties op te leveren naar aanleiding van een bevraging door het LSP.

Samenstelling interactie

	Omschrijving	ID
Trigger Event	Beantwoorden vraag naar allergie/intoleranties	REPC_TE990131NL
Transmission Wrapper	Send Message Payload	MCCI_MT000300
Control Act Wrapper	Query Control Act Response / Acknowledgement	QUQI_MT120001
Message Type	Lijst met allergie/intoleranties (als CDA R2 CS)	POCD_MT900001NL

Zendende en ontvangende rollen

	Omschrijving	ID
Sender	Gegevensopleverend ketenzorgsysteem	ZTKZ_AR000004NL
Receiver	Zorg Informatie Makelaar (ZIM)	AZIM_AR000000NL

Template

De template 2.16.840.1.113883.2.4.3.11.60.66.10.20 Opleveren Allergieintoleranties is weergegeven, in detail beschreven en met voorbeelden voorzien in ART-DECOR.

Bijlage A: CDA document (algemene specificatie)

In deze bijlage wordt weergegeven hoe een CDA document dat via het LSP verzonden wordt (via een ‘push’ interactie) voor de zorgtoepassing Ketenzorg gevuld moet worden, in generieke zin. Eerst wordt de algemene structuur van een CDA document beschreven en vervolgens worden er implementatierichtlijnen gegeven voor de header en de algemene onderdelen van de body, inclusief de sections met tekst. Tenslotte wordt aangegeven welke algemene richtlijnen er gelden voor de gestructureerde entries.

Algemene structuur CDA document

Een CDA document bestaat grofweg uit een Header en een Body.

De Header is vergelijkbaar met het briefhoofd van een papieren brief en bevat meta-gegevens die op het hele document betrekking hebben. Voornamelijk zijn hierbij van belang de patiënt (als onderwerp van het document) en de zorgverlener (als inhoudsverantwoordelijke).

De Body van het document beslaat de feitelijke zorginhoudelijke informatie. Deze body kan bestaan uit niets anders dan vrije tekst. In dat geval wordt gezegd dat sprake is van een CDA level 1 document. Het is ook mogelijk om de vrije tekst in te delen in aparte Sections, die fungeren als paragraafkoppen binnen het document. Deze secties zijn dan ook te voorzien van een codering (bijv. SNOMED), die aangeeft wat de aard van de gegevens in de sectie is (bijv. anamnese, cumulatief laboverzicht of actuele medicatie). Als de tekst voorzien is van secties, wordt gesproken van een CDA level 2 document.

Tenslotte is het mogelijk om binnen de secties zogenaamde Entries op te nemen, die gestructureerde (en vaak gecodeerde) gegevens bevatten in de vorm van zogenaamde clinical statements. Een clinical statement is een instantiatie van een bouwsteen met een bepaalde gegevensinhoud, gebaseerd op het model dat daarvoor in CDA aanwezig is.

Voor nadere toelichting zie: http://www.hl7.nl/wiki/index.php?title=CDA_Inleiding

Indien gebruik wordt gemaakt van gestructureerde bouwstenen als entries, wordt gesproken van een CDA level 3 document. Alle CDA documenten die in de zorgtoepassing Ketenzorg worden uitgewisseld, zijn level 3 documenten.

Clinical statements in CDA Release 2 worden toegelicht in de Implementatiehandleiding Bouwstenen, waar ze in principe als basis dienen voor de bouwsteenimplementaties (tenzij gebruik wordt gemaakt van een bestaande implementatie binnen AORTA).

Implementatierichtlijnen CDA Header

De header bevat slechts een paar elementen die ingevuld moeten worden en zijn verplicht van de onderliggende standaard (CDA).

ClinicalDocument.id

Elk CDA document dient een identificatie te hebben die door het aanmakende systeem wordt uitgedeeld. Let wel dat dit niet dezelfde id is als die van het bericht waar een CDA document wordt getransporteerd.

ClinicalDocument.code

De typering van het document (code) is per use case voorgeschreven en dient zoals beschreven overgenomen te worden.

ClinicalDocument.title

Elk CDA document heeft een titel, hier bijvoorbeeld "Verwijzing" met de datum daarachter. De naam van de patiënt wordt hier niet opgenomen.

ClinicalDocument.effectiveTime

Het aanmaakdatum van het CDA document (komt hier meestal overeen met het aanmaakdatum van het bericht zelf), kan dus hetzelfde zijn, tot op de seconde nauwkeurig aan te geven.

ClinicalDocument.confidentialityCode

Deze code geeft de vertrouwelijkheidsgraad van het CDA document weer en vooralsnog dient hier de waard "N" uit de value set gekozen te worden.

ClinicalDocument.recordTarget

Deze structuur geeft de patiënt weer.

ClinicalDocument.author

Deze structuur geeft de auteur (zorgverlener) van het document weer.

ClinicalDocument.custodian

Deze structuur geeft de beheerder van het CDA document weer, dit komt overeen met de zorgverlenende organisatie (zorginstelling).

Meer informatie

Een overzicht van de Nederlandse implementatierichtlijnen voor de CDA Header staat op:

http://www.hl7.nl/wiki/index.php?title=CDA_Header

Implementatierichtlijnen CDA Body

Daar waar voor de CDA Header strikte richtlijnen bestaan voor de minimaal te vullen gegevenselementen, geldt voor de CDA Body in feite dat er veel minder regels bestaan.

Kort samengevat zijn de regels als volgt:

• Er is geen regel ten aanzien van het gebruik van Sections. Het is wel toegestaan om de tekst van het document in te delen in paragrafen met elk hun eigen titel, maar het is geen verplichting. Er mag ook één ‘loze’ Section zijn met alle Entries.
• Hoewel het wenselijk is om Entries te plaatsen binnen de Section waarop deze betrekking hebben, is dat geen harde regel. Via een referentie is het mogelijk om een Entry te laten verwijzen naar tekst die in een andere Section is opgenomen.

Er is de nodige discussie geweest over de verplichting die CDA kent om in de vrije tekst minimaal dezelfde inhoud (qua betekenis) te hebben als in de gestructureerde Entries. Aangezien er in de scope van de zorgtoepassing Ketenzorg (nog) geen behoefte bestaat om informatie over te dragen buiten de Entries om, zou de tekstuele weergave in feite redundant zijn, terwijl de leverancier wel moeite moet doen om deze te genereren.

Enige voordeel kan zijn dat de toetredingsdrempel voor KIS leveranciers lager kan worden indien het mogelijk is om een patiëntverwijzing als vrije tekst te tonen, zonder de noodzaak om de Entries (bouwsteeninstantiaties) te verwerken en zelf weer te geven. Het volgende compromis is bereikt als afspraak binnen de zorgtoepassing Ketenzorg:

Een verzendend systeem mag in de vrije tekst (d.w.z. de som van de tekst van alle Sections) niet méér informatie (qua betekenis) doorgeven dan ook is opgenomen in de Entries (bouwsteeninstantiaties). Dit voorkomt dat de ontvanger verplicht is om náást de Entries ook de volledige documenttekst te bewaren, waarbij het lastig is om te bepalen waar de extra informatie staat.

Om te zorgen dat het genereren van de tekstuele weergave zo eenvoudig mogelijk is én bij voorkeur een gestandaardiseerd formaat aanhoudt, zal vanuit VZVZ een stylesheet worden ontwikkeld die kan worden ingezet om automatisch een tekstweergave te genereren vanuit de meegestuurde Entries. Deze stylesheet is beschikbaar vóór de start van de proof-of-concept.

Implementatierichtlijnen CDA Entries

Voor de CDA Entries geldt slechts één algemene richtlijn, namelijk dat ze conform één van de gedefinieerde bouwsteendefinities (en het bijbehorende template) moeten zijn.