Hieronder wordt de samenhang beschreven van de processen, rollen en informatiebehoefte.

Zorgtoepassingsrollen en functies

De betrokken actoren en rollen binnen het medicatieproces zijn in de tabel hieronder benoemd.

Actor/rol	Definitie	Bron
Patiënt (actor)	De patiënt is een natuurlijk persoon, de zorgvrager. In deze context is de patiënt degene die farmaceutische zorg nodig heeft.	AORTA
Zorgaanbieder Voorschrijver	De zorgaanbieder die onder andere verantwoordelijk is voor het voorschrijven van medicatie.	-
Voorschrijver (rol)	De arts schrijft voor en bij het voorschrijven wordt medicatiebewaking uitgevoerd.
Zorgaanbieder Verstrekker	De zorgaanbieder die onder andere verantwoordelijk is voor het verstrekken van medicatie.	-
Verstrekker (rol)	De rol verstrekker levert op basis van het voorschrift	MP 9.1
Apotheker (Actor)	De actor apotheker betreft de UZI-rollen apotheker, ziekenhuisapotheker, openbaar apotheker, apothekersassistent of apotheekhoudende huisarts. Dit zijn Zorgverleners.
Zorgverlener (actor)	Een zorgverlener is een persoon die bevoegd is tot handelingen op het gebied van de individuele gezondheidszorg.	Zibs.nl (Nictiz)
Zorgaanbieder (actor)	Een zorgaanbieder is een organisatie die medische-, paramedische- en/of verpleegkundige zorg aanbiedt, en ook daadwerkelijk verleent, aan cliënten/patiënten. Voorbeelden zijn: ziekenhuis, verpleeghuis, huisartsenpraktijk of Regionale Ambulancevoorziening.	Zibs.nl (Nictiz)
Medicatiebewaker (rol)	De rol medicatiebewaker stelt het werkelijke medicatiegebruik van de patiënt vast.
Toediener (rol)	De professionele toedieningsbevoegde die medicatie toedient.
WDS maker (rol)	De persoon die het doseerschema voor antistollingsmedicatie vaststelt op basis van de therapeutische INR range en de gemeten INR.
Vastlegger gebruik (rol)	De persoon die het gebruik van voorgeschreven medicatie of zelfzorgmedicatie vastlegt.
Trombosedienst (actor)	De trombosedienst bepaalt het specifieke doseerschema op basis van de therapeutische INR range en de gemeten INR. De trombosedienst maakt daarmee een nadere invulling van de medicatieafspraak

In de tabel hieronder staat beschreven welke rollen elk systeem kan vervullen.

Applicatieprofiel	Rollen
HIS	Medicatiebewaker
	Voorschrijver
EVS	Medicatiebewaker
	Voorschrijver
AIS/ZAIS	Medicatiebewaker
	Verstrekker
ZIS	Medicatiebewaker
	Toediener
VVT-instelling	Medicatiebewaker
	Voorschrijver
	Toediener
ETDR	Medicatiebewaker
	Voorschrijver
	Toediener
VVT- Thuiszorg	Toediener
	Vastlegger gebruik
TrIS	Medicatiebewaker
	Voorschrijver
	WDS maker

Gegevensmodel

Onderstaand figuur toont het logische gegevensmodel voor de informatie-uitwisseling. Dit model schetst de relevante begrippen en de samenhang daartussen en is essentieel voor een goed begrip van hoe informatie-uitwisseling met bouwstenen tot stand komt.

Figuur 3 Logisch gegevensmodel informatie-uitwisseling
Merk op dat in de figuur alle gegevenselementen generiek van aard zijn, dat wil zeggen dat het model herbruikbaar is over zorgtoepassingen heen. Daarmee wordt tegemoet gekomen aan het uitgangspunt dat de ketenzorgtoepassing rekening moet houden met bredere toepasbaarheid binnen AORTA. De zorgtoepassingspecifieke, medische inhoud zit opgesloten in deze generieke elementen, met name bouwsteentype en bouwsteeninstantiatie. Hieronder worden de entiteiten uit de figuur toegelicht.

Entiteit	Omschrijving
Organisatie	Een zorginstelling in de zin van AORTA (uit AORTA: organisatorisch verband van zorgverleners en ondersteunende medewerkers dat zorgdiensten verleent aan een patiënt/cliënt). Ook een zorggroep wordt als organisatie gezien. Identificatie: URA
Applicatie	Een GBZ-applicatie in de zin van AORTA (uit AORTA: zorgapplicatie die als onderdeel van een GBZ is aangesloten op de ZIM) die invulling geeft aan een of meerdere van de binnen medicatieproces gedefinieerde zorgtoepassingsrollen. Een applicatie wordt altijd beheerd door een organisatie en is onder de URA van die organisatie aangesloten. Identificatie:Applicatie-ID.
Zorgtoepassingsrol	Een toepassingsrol in de zin van AORTA (uit AORTA: rol van een applicatie in het kader van een bepaalde landelijke zorgtoepassing) die binnen medicatieproces is gedefinieerd.
Zorgverlener	Een zorgverlener in de zin van AORTA (uit AORTA: beroepsbeoefenaar als bedoeld in de artikelen 3 of 34 van de wet BIG; persoon die beroepsmatig zorgdiensten verleent aan een patiënt/cliënt). Identificatie:UZI-nummer
Zorgverlenerrol	Een zorgverlenerfunctie in de zin van AORTA (uit AORTA: de beroepstitel (en eventueel het specialisme) van een zorgverlener die bepaalt welke zorgdiensten hij of zijn zorginstelling kan verlenen) die binnen medicatieproces is toegewezen aan een of meerdere contexten. Identificatie: UZI-rolcode
Context	De specifieke omstandigheid waarvoor het initiatief tot informatie-uitwisseling via AORTA wordt genomen, met andere woorden: de specifieke vraag waar het om gaat.
Bouwsteentype	Een aanduiding voor een logisch afgebakende, herbruikbare eenheid van (zorggerelateerde) informatie.
Bouwsteeninstantiatie	Een instantiatie van een bouwsteentype. Deze betreft altijd "echte" data voor een echte patiënt, afkomstig uit de database van een applicatie.
Patiënt	Een patiënt in de zin van AORTA (uit AORTA: persoon die geneeskundig onderzoek of behandeling geniet of mogelijk zal genieten). Identificatie: BSN
Gegevenssoort	Een gegevenssoort in de zin van AORTA(uit AORTA: typering van een soort van patiëntgegevens), waarbij "soort" gelezen kan worden als een groepering van bouwsteentypen. Het is voor de architectuur niet belangrijk welk aggregatieniveau een gegevenssoort betreft. Een gegevenssoort "ontstaat" op het moment dat de beroepsgroepen in overleg met VZVZ afspreken dat een bepaalde groepering van bouwsteentypen bij de Verwijsindex aangemeld kan worden. Er kan sprake zijn van een "hiërarchische gegevenssoort", wanneer een gegevenssoort een aggregatie is van andere gegevenssoorten.
Selectie	Een beperking in de uit te wisselen bouwsteeninstantiaties, gebaseerd op de combinatie van zorgverlenerrol, context en bouwsteentype. Merk op dat de relatie met bouwsteeninstantiatie in de figuur is weggelaten.

Contexten

Een raadpleging aan het LSP moet altijd de context meegeven waarbinnen de opvraging gedaan wordt. De context maakt duidelijk met welke focus en waarom de vraag wordt gesteld. Elke zorgtoepassing op het LSP kent een vastgestelde set aan contexten. Voor de zorgtoepassing Medicatieoverdracht zijn de onderstaande contextcodes gedefinieerd. Elke context heeft een unieke contextcode uit een (centrale) waardenlijst.

Context	Display naam	MA	TA	MGB	MVE	MTD	WDS	Tijdsvenster
MEDGEG	Therapeutische medicatiegegevens	x	x	x			x	Begindatum: datum van opvraging minus 400 dagen. Einddatum: ongedefinieerd (alle toekomstig geldige gegevens vallen binnen het tijdsvenster).
MEDGEGTOT	Therapeutische en logistieke medicatiegegevens	x	x	x	x	x	x	Begindatum: datum van opvraging minus 400 dagen. Einddatum: ongedefinieerd (alle toekomstig geldige gegevens vallen binnen het tijdsvenster).
MEDMTD	Medicatietoedieningen					x		Begindatum: datum van opvraging minus 24 uur. Einddatum: ongedefinieerd (alle toekomstig geldige gegevens vallen binnen het tijdsvenster).
MEDMTDTOT	Benodigde medicatiegegevens om toedienlijst samen te stellen	x	x			x	x	Begindatum: datum van opvraging minus 400 dagen. Einddatum: ongedefinieerd (alle toekomstig geldige gegevens vallen binnen het tijdsvenster).

Het is mogelijk om het voorgedefineerde tijdsvenster specifiek in te vullen. Dat kan op de volgende manieren:

gebruiksperiode
toedieningsperiode
verstrekkingsperiode

Indien deze perioden worden ingevuld, dan worden deze data op een gedefinieerde mapping (zie berichtspecificaties Art-decor) overgenomen in de bouwsteen queries richting XIS'en van specifieke zorgaanbieders.

Het is ook mogelijk om het tijdsvenster zo in te vullen dat alleen de gewijzigde medicatiegegevens van de laatste 24 uur worden opgevraagd. De exacte mogelijkheden staan beschreven in de berichtspecificaties op Art-Decor.

Opvragingen vanuit een PGO door de Patiënt

De patiënt is geautoriseerd om alle medicatiegegevens, dus alle bouwstenen, te mogen opvragen. Dit werkt op een andere manier dan zorgaanbieder-zorgaanbieder communicatie en volgt de afspraken die gemaakt zijn in het MedMij-afsprakenstelsel (zie Actuele gegevensdiensten (medmij.nl) ). De medicatiegegevens worden ontsloten via een DVA richting de PGO. Dat kan LSP+ zijn, maar ook andere DVA's zijn mogelijk. Bij LSP+ wordt geen gebruik gemaakt van contexten. Vanuit de MedMij gegevensdienst 'Medicatiegegevens' wordt direct een vertaling gemaakt naar de juiste bouwsteen queries. Een tweede verschil is dat dit op dit moment een gerichte bevraging betreft bij een specifieke zorgaanbieder en geen gespreide bevraging.

MEDGEG en MEDGEGTOT

M.b.v. de MEDGEG context toont de bevrager zijn/haar informatiebehoefte in de therapeutische bouwstenen. Hierbij is de gegevensverzameling die relevant is voor het ondersteunen van de therapeutische behandeling bijv. voor voorschrijven, verstrekken en medicatiebewaking. MEDGEGTOT wordt gebruikt door de bevrager om aan te geven dat de informatiebehoefte uitgaat naar de therapeutische bouwstenen inclusief de logistieke bouwstenen.

De patiënt komt op consult bij de huisarts. Het HIS raadpleegt de meest actuele medicatiegegevens, waarbij het hier gaat om de therapeutische medicatiebouwstenen (context MEDGEG). Uit het gesprek blijkt dat de patiënt medicatie nodig heeft. De huisarts schrijft de benodigde medicatie voor. Deze informatie stuurt hij op naar de openbare apotheek waar de patiënt staat ingeschreven. De openbare apotheek ontvangt de voorgeschreven informatie en stelt de toediening, dosering en verstrekking op. De patiënt krijgt deze informatie op de verpakking te zien en krijgt het tevens mondeling toegelicht van de apothekersassistente.

MEDMTD

MEDMTD wordt tevens gebruikt door ETDR-systemen. Vaak worden vooral veel wijzigingen gemaakt op medicatietoedieningen. Op basis van een signaal kunnen gericht en accuraat de nieuwe medicatietoedieningen bij een zorgaanbieder worden opgevraagd. Niet alleen wordt op deze manier de belasting van bronsystemen zoveel mogelijk beperkt en hoeft het ETDR-systeem minder gegevens te verwerken, maar ontvangt de zorgaanbieder gerichte wijzigingen waarin degene verantwoordelijk is voor het verlenen van goede zorg aan de patiënt.

De patiënt krijgt thuiszorg en gaat eerder op die dag naar het ziekenhuis. In het ziekenhuis vinden enkele toedieningen plaats. Het ETDR-systeem van de thuiszorg heeft eerder abonnement genomen op de context MEDMTD en krijgt daarom nu een signaal dat er gegevens gewijzigd zijn. Hierop vraagt het ETDR-systeem de toedieningen van het ziekenhuis op o.b.v. deze context. Het ETDR-systeem verwerkt de ontvangen gegevens in het dossier van de thuiszorgorganisatie. Zo is de thuiszorgorganisatie op de hoogte van alle medicatietoedieningen. Als ze zien dat een bepaalde toediening eerder op die dag al is gegeven bij andere zorgaanbieder, bijv. het ziekenhuis, dan kunnen ze een dubbele dosis voorkomen.

MEDMTDTOT

ETDR-systemen hebben de verantwoordelijkheid om de toedienlijst samen te stellen. M.b.v. de contextcode MEDMTDTOT kunnen deze systemen aangeven dat zij informatiebehoefte hebben in de relevante inputgegevens voor de toedienlijst. MEDMTDTOT wordt gebruikt door ETDR-systemen om de toedienlijst samen te stellen. Ook wordt deze context gebruikt door ETDR-systemen om bij andere zorgaanbieders voor nieuwe toedieningen voorafgaande aan het samenstellen van de toedienlijst raad te plegen. De best practice hier is om een abonnement te nemen op deze context, zodat alleen bij wijzigingen een gerichte opvraging wordt uitgevoerd. Hierbij kan een kleinere periode worden opgevraagd, dus van een dag geleden.

Een thuiszorg organisatie wil het ETDR-systeem de toedienlijst laten samenstellen. De context MEDMTDTOT levert hiervoor alle benodigde medische gegevens.

Browser not supported