mp:Vdraft MigratieHybride

Deze pagina bevat de implementatiedocumentatie voor leveranciers omtrent migratie en de hybride situatie tijdens de Kickstart Medicatieoverdracht.

1 Inleiding

1.1 Migratie en hybride situatie

De komende jaren zullen de richtlijn ‘Overdracht van medicatiegegevens in de keten’ en de informatiestandaard Medicatieproces (MP9) zorgbreed geïmplementeerd worden via het implementatieprogramma Medicatieoverdracht. Dit zal eerst in een beperkte setting plaatsvinden, gedurende de Kickstart, gevolgd door de brede uitrol.

Gezien niet alle systemen tegelijkertijd de informatiestandaard MP9 implementeren, is er sprake van een transitiefase. Deze fase loopt van de migratie van het eerste systeem tot het moment dat uiteindelijk alle systemen over zijn op MP9. Systemen die gedurende de transitiefase overgaan naar MP9 hebben te maken met een hybride situatie: de systemen zullen zowel MP9 als oudere berichtenstromen (MP6.12 en/of EDIFACT) moeten ondersteunen.

Er zijn verschillen tussen de genoemde berichtenstromen. Er zijn daarom afspraken nodig om op basis van deze verschillende berichtenstromen toch tot een overzichtelijk medicatiedossier te komen. Deze afspraken zijn aanvullend op de informatiestandaard MP9 en betreffen:

• het migreren (het omzetten van de reeds beschikbare medicatiegegevens in een patiëntdossier naar een datamodel dat MP9-bouwstenen ondersteunt),
• het raadplegen (het proces van opvragen van beschikbare medicatiegegevens, zowel uit MP9- als MP6.12-systemen), en
• het reconciliëren (het samenbrengen en ontdubbelen van beschikbare gegevens met de ontvangen gegevens met als doel een overzichtelijk medicatiedossier op te bouwen).

1.2 Kaders

Deze pagina beschrijft de afspraken voor leveranciers omtrent migratie en de hybride situatie bij de Kickstart Medicatieoverdracht. Het doel van de Kickstart Medicatieoverdracht is onder andere het beproeven van de informatiestandaard MP9 in de praktijk. Bij start van de Kickstart Medicatieoverdracht worden er procedures opgesteld mochten er gedurende deze beproeving nieuwe inzichten ontstaan. Voor wijziging van deze pagina worden deze procedures gevolgd.

De huidige versie van deze pagina omvat de afspraken voor het elektronisch voorschrijfsysteem (EVS) en apotheekinformatiesysteem (AIS). Echter, leveranciers van een persoonlijke gezondheidsomgeving (PGO) of elektronisch toedienregistratiesysteem (eTDR) zijn tevens deelnemers van de Kickstart Medicatieoverdracht. Ook voor PGO’s en eTDR’s zijn mogelijk aanvullende afspraken nodig om in de hybride situatie te komen tot een medicatieoverzicht en toedienlijst waarbij medicatieveiligheid zo goed mogelijk gewaarborgd is. Deze afspraken zullen later toegevoegd worden aan deze pagina (zie hoofdstuk PGO's en eTDR's).

1.3 Leeswijzer

Hoofstukken

• Hoofdstuk 2 Achtergrond gaat in op de verschillen tussen de transitiefase en de uiteindelijke situatie waarin alle systemen over zijn op MP9, die maken dat er aanvullende afspraken nodig zijn om te komen tot een overzichtelijk medicatiedossier.
• Hoofdstuk 3 Migreren en beschikbaarstellen en Hoofdstuk 4 Raadplegen/ontvangen en reconciliëren beschrijven de afspraken omtrent het migreren en het beschikbaarstellen van de gemigreerde medicatiegegevens, het raadplegen en ontvangen van medicatiegegevens en het reconciliëren in de hybride situatie.
• Hoofdstuk 5 Aandachtspunten gedurende transitiefase geeft een toelichting op de overige aandachtspunten gedurende de transitiefase. Aandachtspunten zijn onder andere de doseerinstructies, doseerverlagingen en combinatiepreparaten.
• Hoofdstuk 6 Patiëntportalen, Hoofdstuk 7 PGO's en Hoofdstuk 8 eTDR's beschrijven de afspraken die gelden voor patiëntportalen, PGO's en eTDR's.
• Hoofdstuk 9 Early adopters biedt instructies ten aanzien van medicatiegegevens vanuit systemen die 'early adopter' zijn van de informatiestandaard MP9.

Bijlagen

• Bijlage 1: Verrijken EDIFACT id en vullen MP6.12 prescription/id geeft instructies omtrent het verrijken van de EDIFACT id en het vullen van het veld prescription/id in de MP6.12-verstrekking. Via het verrijken van de EDIFACT id is het mogelijk om in MP6.12-verstrekkingen de relatie naar een EDIFACT-voorschrift vast te leggen. Het vastleggen van de relaties in MP6.12-verstrekkingen naar voorschrift is van belang gezien in de transitiefase samenhangende medicatiegegevens niet altijd via de MP9-systematiek bij elkaar te groeperen zijn.
• Bijlage 2: Afkortingen en definities bevat een lijst met definities van de termen die in de tekst in deze layout staan.

Wijzigingen en beheerproces

• Wijzigingen in de pagina gaan via het beheerproces (BITS-issues). De wijzigingenhistorie van deze pagina en de releasenotes verwijzen naar deze BITS-issues. De BITS-issues worden geregistreerd binnen het project Medicatieproces, onder epic MP-431 Hybride situatie, zie filter Project = MP AND “Epic Link” = MP-431. Elk van deze BITS-issues wordt gerelateerd aan epic MP-431 Hybride situatie.

Aandachtspunten gebruikersondersteuning

• In de transitiefase zijn er aandachtspunten voor de gebruikersondersteuning om te komen tot een overzichtelijk medicatiedossier. Deze aandachtspunten zijn terug te vinden binnen het project Medicatieproces, onder epic MP-693, zie filter Project = MP AND "Epic Link" = MP-693. Elk van deze de BITS-issues wordt gerelateerd aan epic MP-693 Aandachtspunten gebruikersondersteuning.

Verwijzingen

• BITS-issues in epic MP-431 Hybride situatie
• BITS-issues in epic MP-693 Aandachtspunten gebruikersondersteuning
• Flowcharts ‘Raadplegen en reconciliëren in de hybride situatie’
• Documentatie met details omtrent de transformatiedienst (conversie van MP6.12-verstrekking naar een MP9-TA formaat) vanuit het Landelijk Schakelpunt (LSP) volgt via VZVZ, zie tevens https://bits.nictiz.nl/browse/MP-572

2 Achtergrond

Er zijn twee belangrijke verschillen tussen de transitiefase en de uiteindelijke situatie waarin alle systemen over zijn op MP9, die maken dat er aanvullende afspraken nodig zijn om te komen tot een overzichtelijk medicatiedossier gedurende de transitiefase. Ten eerste, in de transitiefase kunnen samenhangende medicatiegegevens niet altijd via de MP9-systematiek bij elkaar gegroepeerd worden. Dit komt omdat het technische begrip 'medicamenteuze behandeling' nieuw is MP9 en niet bestaat in MP6.12 en/of EDIFACT. Ten tweede, in de transitiefase zijn niet alle medicatiegegevens raadpleegbaar als MP9-bouwstenen. Dit hoofdstuk gaat in op bovenstaande twee punten.

2.1 Nieuw technisch begrip ‘medicamenteuze behandeling’

Medicatieproces gaat over voorschrijven van een geneesmiddel, gevolgd door ter hand stellen tot en met toedienen en gebruik. De medicamenteuze behandeling (MBH) bundelt verschillende medicatiebouwstenen die zo ontstaan. Alle medicatiebouwstenen hebben een verplichte identificatie: de MBH-id. MP6.12- en EDIFACT-informatie heeft geen MBH-id. Wanneer systemen onafhankelijk van elkaar migreren, genereren zij onafhankelijk van elkaar een MBH-id. Dan ontstaat het volgende probleem: er zullen verschillende MBH-id’s aangemaakt worden voor medicatiebouwstenen, terwijl deze conceptueel horen bij één MBH. Deze situatie kan leiden tot onduidelijkheid, administratieve last en eventueel zelfs tot medicatiefouten. Bijvoorbeeld: een medicatieafspraak (MA) en toedieningsafspraak (TA) die bij elkaar horen in dezelfde MBH staan in plaats van op één regel op twee verschillende regels in het medicatieoverzicht, waardoor onduidelijkheden kunnen ontstaan omtrent de dosering. Er dienen daarom afspraken gemaakt te worden om deze risico’s te minimaliseren. Dit betreft primair afspraken omtrent het toekennen van de MBH-id bij migratie (zie Migreren en beschikbaarstellen). Zo minimaliseren we het probleem van meerdere MBH-id’s voor conceptueel dezelfde MBH. Het kan echter niet volledig voorkomen worden. Deze pagina bevat daarom tevens afspraken omtrent de werkwijze voor het relateren van samenhangende medicatiegegevens en voor het ontdubbelen van MBH’s (zie Raadplegen/ontvangen en reconciliëren).

2.2 Medicatiegegevens vanuit MP9- en MP6.12-systemen

In de transitiefase zullen nog niet alle medicatiegegevens als MP9-bouwstenen raadpleegbaar zijn. Dit betekent onder andere dat gegevens over de voorgeschreven medicatie vanuit een MP6.12/EDIFACT-EVS (in tegenstelling tot een MP9-EVS) niet zichtbaar zijn voor andere systemen in de keten. Voor gegevens vanuit een MP6.12-AIS geldt dat er vanuit de infrastructuurleverancier een transformatiedienst zal worden aangeboden waarin de MP6.12-verstrekkingen geconverteerd worden naar het formaat van MP9-TA’s. Deze uit MP6.12-verstrekking geconverteerde gegevens (MP6.12-TA’s) zijn weliswaar raadpleegbaar in MP9-TA formaat, maar zijn om verschillende redenen niet op exact dezelfde manier te verwerken als een MP9-TA vanuit een MP9-AIS. Deze pagina bevat daarom afspraken omtrent de verwerking van deze MP6.12-TA’s in MP9-systemen (zie Raadplegen/ontvangen en reconciliëren).

Documentatie met details omtrent de transformatiedienst (conversie van MP6.12-verstrekking naar een MP9-TA formaat) vanuit het Landelijk Schakelpunt (LSP) volgt via VZVZ, zie tevens https://bits.nictiz.nl/browse/MP-572.

3 Migreren en beschikbaarstellen

Migratie betreft het omzetten van de medicatiegegevens in de lokale database van een systeem naar een datamodel dat MP9-bouwstenen ondersteunt. De benodigde stappen bij migreren zijn per leverancier verschillend. Dit is onder andere afhankelijk van de overeenkomsten en verschillen in het huidige datamodel van het systeem en het benodigde datamodel voor ondersteuning van MP9-bouwstenen. Dit hoofdstuk bevat afspraken omtrent het migreren. Het gaat dan om afspraken die de medicatieveiligheid bevorderen. Aanvullende (detail)afspraken worden gemaakt tussen leverancier en zorgaanbieder (gebruikersgroep).Daarnaast beschrijft dit hoofdstuk de afspraken omtrent het moment van het beschikbaarstellen van gemigreerde medicatiegegevens: na migratie mogen de medicatiegegevens direct beschikbaar gesteld worden.

3.1 Beschikbaarstellen van gemigreerde medicatiegegevens

Na migratie mogen de medicatiegegevens direct beschikbaargesteld worden. Figuur 1 geeft een overzicht van de processtappen migreren, (actief) beschikbaarstellen, raadplegen en reconciliëren. Raadplegen en reconciliëren vinden plaats wanneer de zorgverlener interactie heeft met het patiëntdossier. Dergelijke interactie kan plaatsvinden rondom patiëntcontact, maar ook bij proactief reconciliëren van (deel)populaties.
Een gemigreerd MP9-AIS zal tijdens de transitiefase de medicatiegegevens zowel via MP6.12 als MP9 beschikbaar moeten stellen. Dit zodat systemen die nog niet over zijn op MP9, de verstrekkingsgegevens kunnen blijven raadplegen.
Het uitgangspunt is dat MP9-systemen maar één query nodig hebben. De infrastructuurleverancier zorgt voor een conversie van MP6.12-verstrekkingen naar het formaat van MP9-TA’s (zie paragraaf [Medicatiegegevens vanuit MP9- en MP6.12-systemen|Medicatiegegevens vanuit MP9- en MP6.12-systemen] en hoofdstuk [#Raadplegen/ontvangen en reconciliëren|Raadplegen/ontvangen en reconciliëren]).

Figuur 1. Overzicht van de volgorde van de processtappen (migreren, (actief) beschikbaarstellen, raadplegen, reconciliëren) voor EVS en AIS.

3.2 Algemene migratieafspraken

3.2.1 Onderscheid tussen eigen en andermans medicatiegegevens

Er is een verschil tussen ‘eigen’ en ‘andermans’ medicatiegegevens. Het systeem is bron van ‘eigen’ gegevens. Een ánder systeem is bron van ‘andermans’ gegevens. Dit onderscheid is van belang om te voorkomen dat er onnodig dubbele bouwstenen uitgewisseld worden. Systemen moeten rekening houden met dit onderscheid bij migratie. Het uitwisselen van medicatiegegevens vindt onder andere plaats via de transactie raadplegen/beschikbaarstellen (of sturen/ontvangen) medicatiegegevens. Deze transactie verbiedt het beschikbaarstellen van andermans informatie. EVS’en, zoals bijvoorbeeld huisarts- en ziekenhuisinformatiesystemen (HIS’en en ZIS’en) moeten, indien mogelijk, achterhalen of het gaat om in- of externe voorschriften. Bijvoorbeeld: als het HIS een VV heeft uitgestuurd, zal het een eigen voorschrift betreffen. Iets dergelijks geldt ook voor andere type systemen, zoals AIS’en. Deze afspraak is van belang om dubbelingen in medicatiebouwstenen te voorkomen bij betrokkenheid van meerdere systemen bij een patiënt.

3.3 Migratieafspraken ter beperking van duplicate MBH’s en ter ondersteuning van ontdubbeling van MBH’s

3.3.1 Specifieke en generieke MBH-id

De informatiestandaard MP9 definieert de MBH-id als wereldwijd en eeuwig uniek. Deze MBH-id bevat een OID-root en -extensie. De root bevat een OID voor een ‘identificatiesysteem’ dat verschilt voor elke uitgevende organisatie. De extensie bevat een unieke string binnen dit identificatiesysteem. Dit type MBH-id noemen we een specifieke MBH-id. Daarnaast werken we met een generieke MBH-id: systemen kunnen onafhankelijk van elkaar dezelfde identificatie genereren voor medicatiebouwstenen met dezelfde prescriptiecode (PRK).

De generieke MBH-id bestaat uit een algemene OID-root (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.2), en de PRK-code in de OID-extension. Hiervoor wordt, indien bekend, de PRK uit de MA/ het voorschrift gebruikt.

Een generieke MBH-id is daarmee alleen uniek voor één patiënt, maar niet uniek over patiënten heen. De generieke MBH-id maakt dat systemen onafhankelijk van elkaar kunnen migreren, maar dat tegelijkertijd medicatiebouwstenen toch bij elkaar gegroepeerd worden. Echter, een generieke MBH-id heeft beperkingen. Er kunnen bijvoorbeeld onterechte groeperingen van medicatiebouwstenen ontstaan met eenzelfde MBH-id die in werkelijkheid onder verschillende MBH’s vallen. Verder leeft er een wens om MBH niet op PRK te baseren, maar dit ook mogelijk te maken op werkzame stof. De generieke MBH-id wordt daarom alleen in bepaalde situaties in de transitiefase toegepast. De intentie is om de generieke MBH-id zo snel mogelijk naar de historie te verdrijven.

Actuele, recent gestopte vs. historische medicatie
MP9 maakt onderscheid tussen actuele, recent gestopte en historie van medicatie. Bij migratie is dit onderscheid tevens van belang. Actuele medicatie is medicatie waarvan de stopdatum (op het moment van migratie) nog niet verstreken is. Dit betreft huidige (heden ligt tussen start- en stopdatum) en toekomstige (heden ligt voor startdatum) medicatie. Recent gestopte medicatie omvat medicatie die in de afgelopen twee maanden is gestopt. Historie van medicatie is medicatie met een stopdatum die meer dan twee maanden in het verleden ligt.

In de transitiefase wordt historische medicatie gebundeld per PRK in een generieke MBH-id. Daarmee is er een verschil in de migratie van actuele en recent gestopte medicatie versus historische informatie. Dit beperkt het probleem van meerdere MBH-id’s voor bouwstenen die eigenlijk bij elkaar horen. Tegelijkertijd draagt dit bij aan een ‘schone start’: actuele en recent gestopte medicatie zal sneller voldoen aan MP9. Zorgverleners zullen actuele en recent gestopte medicatie zorgvuldig reconciliëren volgens MP9. Dit gebeurt niet bij historische informatie tenzij daar directe aanleiding voor is. Dit zorgt er ook voor dat zorgverleners niet onnodig belast worden met reconciliatietaken (administratieve lasten) voor historische medicatie die vandaag niet echt belangrijk meer is.

EVS vs. AIS
Voor actuele en recent gestopte medicatie geldt dat het EVS bij migratie een specifieke MBH-id toekent. Het AIS wijst in de transitiefase echter een generieke MBH-id toe. Het AIS initieert in principe géén specifieke MBH-id (zie voor de uitzonderingssituaties paragraaf Bijzondere situaties). Het AIS maakt alleen medicatiebouwstenen met een specifieke MBH-id, wanneer het een specifieke MBH-id ontvangen heeft. Dit komt overeen met de uitgangspunten van de informatiestandaard MP9 waarin een MA leidend is ten opzichte van de andere medicatiebouwstenen. Om ervoor te zorgen dat de generieke MBH-id verdwijnt in de historie, is het niet wenselijk dat het EVS na migratie nieuw aangemaakte MP9-bouwstenen toevoegt aan een MBH met generieke MBH-id. In plaats daarvan heeft het de voorkeur om een nieuwe MBH met specifieke MBH-id te starten. Tabel 1 biedt een overzicht in welke situaties een specifieke of generieke MBH-id toegekend moet worden.

Sommige systemen zijn zowel EVS als AIS, bijvoorbeeld ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken. Meestal hebben TA’s uit het AIS-onderdeel van het systeem een relatie naar een MA (of eventueel medicatiegebruik (MGB)) in het EVS-onderdeel. Wanneer er een interne relatie bestaat tussen de TA en MA (of MGB), zal de TA na migratie direct met de juiste specifieke MBH-id beschikbaargesteld kunnen worden. Wanneer er geen interne link tussen TA en MA (of MGB) uit het EVS-onderdeel blijkt te zijn, wordt teruggevallen op een generieke MBH-id.

Tabel 1. Overzicht situaties specifieke en generieke MBH-id voor EVS en AIS

Situatie	EVS	AIS
Migreren van actuele en recent gestopte medicatie	Specifieke MBH-id	Generieke MBH-id
Migreren van historische medicatie	Generieke MBH-id	Generieke MBH-id
Starten van nieuwe MBH	Specieke MBH-id	Generieke MBH-id

3.3.2 Einddatum in medicatiegegevens

Bij migratie naar MP9 moet, indien bekend, een einddatum (stopdatum) gebruik vastgelegd worden.

Einddatum in medicatieafspraak
Wanneer in de lokale database de einddatum van het voorschrift bekend is, wordt bij migratie de einddatum in de MA gevuld. Wanneer er meerdere opeenvolgende voorschriften zijn in de lokale database, krijgt de MA als einddatum de begindatum van de daaropvolgende MA. Ook voor medicatie met het kenmerk chronisch wordt bij migratie een einddatum meegegeven, indien de lokale database een einddatum van het voorschrift bevat. Het meegeven van een einddatum in MA’s bij migratie zorgt ervoor dat er bij betrokkenheid van meerdere EVS’en bij een patiënt slechts tijdelijk sprake is van eventuele dubbelingen in MA’s en daarmee dubbelingen in MBH’s. Alleen indien er helemaal geen einddatum bekend is in het systeem, wordt de einddatum van de MA open gelaten.

Einddatum in toedieningsafspraak
De einddatum van TA’s mag gebaseerd worden op therapeutische informatie uit de lokale database (bijvoorbeeld afkomstig uit het medicatieprofiel of de distributieregels) of logistieke informatie (einddatum van verbruiksperiode van de verstrekking). De meegegeven einddatum in een TA bij migratie is daarmee minder eenduidig te interpreteren dan de einddatum in een TA die is aangemaakt vanuit een MP9-AIS (in die situatie betreft de einddatum in een TA wel altijd een therapeutische einddatum). Zo kan het zijn dat de gebruiksperiode van langdurige medicatie mogelijk niet overeenkomt met de therapeutische gebruiksperiode (einddatum uit de verstrekking is mogelijk eerder dan einde van de voorraad). Echter, afspraken over het meegeven van een einddatum in een TA bij migratie zorgen ervoor dat duplicate MBH’s (TA staat in andere MBH dan MA) vanzelf uitsterven, er geen onterecht actieve TA’s zijn en er in minder gevallen handmatige afsluiting van TA’s nodig is. Een einddatum in een TA die niet overeenkomt met de werkelijke therapeutische einddatum heeft met name risico’s voor de toedienlijsten en voor het medicatieoverzicht voor de patiënt. Deze risico’s nemen we in acht bij aanvullende afspraken over verwerking van deze TA’s door PGO’s (zie hoofdstuk PGO's) en eTDR’s (zie eTDR's).

3.3.3 Samenhang van identificaties in EDIFACT, MP6.12 en MP9

Gezien systemen onafhankelijk van elkaar migreren, komt het in de transitiefase voor dat medicatiegegevens die conceptueel in dezelfde MBH horen te staan, niet dezelfde MBH-id hebben. Wanneer verstrekkingen de relatie bevatten naar de voorschriftgegevens, kunnen systemen deze samenhangende medicatiegegevens toch aan elkaar relateren. Op basis van deze relaties zijn duplicate MBH's vervolgens te ontdubbelen. Het is daarom van belang dat bekende identificaties in MP6.12- en/of EDIFACT-berichten bij migratie niet verloren gaan. Tabel 2 geeft een overzicht van de verschillende identificaties in EDIFACT, MP6.12 en MP9 en hun onderlinge relaties.

Tabel 2. Overzicht identificaties en hun onderlinge relaties

EDIFACT	MP6.12	MP9
-	MP6.12-vooraankondiging id	MA/relatieMA (vullen met id van meest recente MP6.12-vooraankondiging)
		VV id
		TA/relatieMA
		MVE/relatieVV
Verrijkt EDIFACT id	MP6.12-verstrekking/prescription/id (gevuld met MP6.12-vooraankondiging id óf verrijkt EDIFACT id)	MA/relatieMA
		VV id
		TA/relatieMA
		MVE/relatieVV
-	MP6.12-verstrekking id	MVE id
		MGB/relatieMVE (medicatieverificatie)
	Bij beschikbaarstellen MP6.12-verstrekkingen na MP9-voorschrift: MP6.12-verstrekking/prescription/id	MA id
	-	TA id
		MBH id

4 Raadplegen/ontvangen en reconciliëren

Bij het raadplegen van de medicatiegegevens uit andere systemen kan een MP9-systeem in de transitiefase informatie binnenkrijgen uit MP9-systemen, maar ook uit MP6.12/EDIFACT-systemen. Ook kan na het raadplegen blijken dat MP9-medicatiegegevens nog niet in de juiste MBH staan. Deze duplicate MBH’s dienen ontdubbeld te worden. Dit hoofdstuk beschrijft de systematiek voor de verwerking van medicatiegegevens in de hybride situatie. Deze systematiek zorgt ervoor dat ook in de transitiefase een overzichtelijk medicatiedossier kan worden opgebouwd.
Daarnaast kan een MP9-AIS in de transitiefase voorschriften ontvangen via MP9, maar ook nog via MP6.12 en/of EDIFACT. Dit hoofdstuk licht toe hoe systemen de relaties naar deze voorschriften kunnen leggen in de verschillende berichtenstromen.
Tot slot, het reconciliëren tot een overzichtelijk medicatiedossier vraagt om ondersteuning vanuit systemen aan de gebruiker. Dit hoofdstuk benoemt de aandachtspunten. Het is aan de leverancier en zorgaanbieder (gebruikersgroep) om de wijze van de gebruikersondersteuning verder af te stemmen.

De aandachtspunten ten aanzien van gebruikersondersteuning staan verzameld in BITS (zie filter Project = MP AND "Epic Link" = MP-693).

De te volgen processen bij raadplegen en reconciliëren in de hybride situatie zijn in de vorm van flowcharts uitgewerkt (zie Raadplegen en reconciliëren in de hybride situatie].

4.1 Verwerken en matchen van medicatiegegevens

4.1.1 Medicatiegegevens raadplegen

Via de transactie raadplegen medicatiegegevens kan een MP9-systeem in de transitiefase verschillende typen medicatiegegevens binnenkrijgen. Tabel 3 geeft een overzicht van deze medicatiegegevens, afhankelijk van het bronsysteem dat deze gegevens beschikbaar heeft gesteld.

Tabel 3. Type medicatiebouwstenen afhankelijk van bronsysteem
bij MP9-transactie raadplegen medicatiegegevens

Bronsysteem	Type medicatiebouwsteen
EDIFACT-EVS	-
EDIFACT-AIS	-
MP6.12-EVS	-
MP6.12-AIS	MP6.12-TA
MP9-EVS	MA + MGB met specifieke MBH-id
MP9-AIS	TA + MGB met generieke MBH-id, indien (nog) niet in MBH van bijbehorende MA TA + MGB met specifieke MBH-id, indien in MBH van bijbehorende MA

Het systeem verduidelijkt aan de gebruiker of de binnengekomen AIS-informatie een conversie vanuit de infrastructuurleverancier betreft (MP6.12-TA), een MP9-TA met generieke MBH-id of een MP9-TA met specifieke MBH-id. De acties die een gebruiker kan uitvoeren op basis van een MP6.12-TA versus een MP9-TA zijn verschillend. Wijzigingen op een MP6.12-TA kunnen niet via MP9-berichten gecommuniceerd worden naar MP6.12-systemen. Daarnaast is onderscheid tussen een TA met generieke MBH-id en specifieke MBH-id van belang voor de gebruiker. Voor een (actuele of recent gestopte) TA met generieke MBH-id geldt dat deze nog niet gegroepeerd staat in dezelfde MBH als de bijbehorende MA. Bovendien, een TA met generieke MBH-id die gegenereerd is bij migratie bevat mogelijk nog geen 'volwaardige' MP9-informatie. Bijvoorbeeld: de TA bevat een logistieke einddatum die niet overeenkomt met de werkelijke therapeutische einddatum (zie paragraaf Einddatum in medicatiegegevens) of bevat complexe doseerinstructies in vrije tekst (zie paragraaf Doseerinstructies).

Indien mogelijk worden samenhangende medicatiebouwstenen aan elkaar gerelateerd op basis van een match in identificatie (MP6.12-vooraankondiging id of ‘verrijkt’ EDIFACT-id) (zie Tabel 2). Wanneer een match hierop niet mogelijk is, bijvoorbeeld omdat de id niet in beide bouwstenen is opgenomen, wordt gekeken naar de PRK. Wanneer een match op deze elementen niet mogelijk is, is tussenkomst van de gebruiker nodig om de informatie te reconciliëren. Deze laatste optie heeft uiteraard niet de voorkeur. Systemen bieden waar mogelijk gebruikersondersteuning.

4.1.2 Voorschrift ontvangen en identificaties

Gedurende de transitiefase kan een MP9-AIS medicatievoorschriften ontvangen in MP9, maar ook in EDIFACT en/of MP6.12. Tabel 4 geeft weer hoe de relaties naar deze voorschriften gelegd moeten worden.

Tabel 4. Overzicht identificaties en hun onderlinge relaties voor ieder formaat van voorschrift en antwoord bericht

	MEDREC-AFL	MP6.12-verstrekking/prescription id	MP9-TA/relatieMA	MP9-MVE/relatieVV
MEDREC-AAN	EDIFACT id	Verrijkt EDIFACT id	Verrijkt EDIFACT id	Verrijkt EDIFACT id
MP6.12-vooraankondiging	-	MP6.12-vooraankondiging id	MMP6.12-vooraankondiging id	MP6.12-vooraankondiging id
MP9-voorschrift	-	MP9-MA id	MP9-MA id	MP9-VV id

4.2 Ontdubbelen van MBH's

Na raadplegen zijn er soms meerdere MBH-id’s voor conceptueel dezelfde MBH. Systemen gebruiken dan de volgende uitgangspunten om (de gebruiker te helpen) te kiezen welke MBH blijft bestaan en welke gestopt wordt.

• Specifieke MBH-id gaat voor generieke MBH-id. Het systeem ‘vlagt’ de MBH met generieke MBH-id als ‘potentieel duplicate medicamenteuze behandeling’. Het doel is dat de specifieke MBH-id blijft bestaan en de generieke naar de historie verdwijnt.
• Meest recente bouwsteen gaat voor. Bij gelijk type MBH-id (dus meerdere generieke of meerdere specifieke MBH-id’s) dient de MBH met de meest recente bouwsteen te blijven bestaan (op basis van afspraakdatum van MA en TA of registratiedatum van MGB). Het systeem ‘vlagt’ de MBH die niet de meest recente bouwsteen heeft als ‘potentieel duplicate medicamenteuze behandeling’.
  

Het systeem stelt aan de gebruiker voor om medicatiebouwstenen in een potentieel duplicate MBH te stoppen per ‘heden’ (datum/tijd van reconciliatie) met als reden ‘loopt in andere medicamenteuze behandeling’. De gebruiker kan er vervolgens voor kiezen om dit voorstel zonder wijziging te accorderen, of om de voorgestelde stopdatum aan te passen. Op basis van deze reden van wijzigen (‘loopt in andere medicamenteuze behandeling’) wordt de gebruikersinterface zo ontworpen dat inzichtelijk is voor de gebruiker dat er niet daadwerkelijk gestopt moet worden met deze medicatie, maar dat de medicatiebouwsteen wordt gestopt in het kader van reconciliatie.

4.2.1 TA in andere MBH dan MA

Soms staat een MP9-TA in een generieke MBH terwijl er een bijbehorende MP9-MA in een specifieke MBH bestaat. Deze duplicate generieke MBH willen we ontdubbelen. Bij ontdubbelen door een EVS kan daarvoor een stop-MA gemaakt worden in de generieke MBH. Bij ontdubbelen door een AIS kan dit met een stop-TA. Beide krijgen in zo’n geval de reden ‘loopt in andere medicamenteuze behandeling’. Het systeem stelt deze stop-MA of stop-TA beschikbaar. Ook verstuurt het deze stop-bouwsteen naar het AIS dat bronsysteem is van de te stoppen MP9-TA, net zoals elke andere stop-MA of stop-TA. Na ontvangen van deze stop-bouwsteen kan het AIS een nieuwe TA in de specifieke MBH maken. Systemen bieden waar mogelijk gebruikersondersteuning.

Er kunnen ook duplicate MBH’s ontstaan zijn met MP6.12-TA’s. Systemen kunnen ook in deze situatie de gebruiker de optie aanbieden om MBH’s te ontdubbelen. Als een gebruiker een MP6.12-TA stopt, kan ieder ander MP9-systeem gebruik maken van deze actie. Dan hoeft er niet opnieuw gereconcilieerd te worden. Dit geldt echter wel alleen tot het moment van het beschikbaarstellen van een nieuwere MP6.12-TA. Deze ontstaat bij elke nieuwe verstrekking vanuit een MP6.12-AIS. AIS’en maken met name bij een geneesmiddelendistributiesysteem (GDS) vaak nieuwe verstrekkingen. De verstrekkende apotheker kan in dit geval geen nieuwe TA in de MBH van de MA aanmaken, omdat dit AIS nog niet over is op MP9. Wanneer een voorschrijver het gebruik van het betreffende geneesmiddel daadwerkelijk wil stoppen, zal deze de apotheker via andere routes dan MP9 moeten informeren. Dit zijn eigenlijk de bestaande routes van voor MP9, denk aan een stopbericht via EDIFACT, telefonisch of via fax. MP9-systemen die de optie aanbieden voor het stoppen van MP6.12-TA’s attenderen hun gebruikers op bovenstaande punten.

Bij het stoppen van een TA vanwege ontdubbeling, komt er mogelijk niet direct een TA in de specifieke MBH. Medicatieveiligheid vraagt daarom om verdere uitwerking van:

• afspraken over het samenstellen van het medicatieoverzicht in PGO's (zie hoofdstuk PGO's),
• afspraken over het opstellen van de toedienlijst (zie hoofdstuk eTDR's) en
• aanvullende werkprocesafspraken tussen zorgverleners (de actie tot nadere uitwerking hiervan is opgenomen in BTIS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-694).
  

4.2.2 Duplicate MA’s

Een duplicate MA kan ontstaan wanneer een EVS ‘andermans’ MA per abuis heeft gemigreerd als ‘eigen’ MA (zie paragraaf [#Onderscheid tussen eigen en andermans medicatiegegevens|Onderscheid tussen eigen en andermans medicatiegegevens]]). Een dergelijke duplicate MA, in een duplicate MBH, willen we stoppen. Een EVS maakt hiervoor een stop-MA. Een AIS kan hiervoor een voorstel-stop-MA maken. Beide stop-bouwstenen krijgen reden ‘loopt in andere medicamenteuze behandeling’. Het systeem stuurt deze stop-MA of voorstel-stop-MA naar het EVS dat bronsysteem is van de te stoppen MA.  

5 Verrijken EDIFACT-id en vullen 6.12 prescription/id

Met de introductie van MP6.12 berichten en de aanstaande MP9-migratie, is het van belang om betrouwbaar te kunnen ontdubbelen. Dit geldt vooral wanneer systemen medicatie-informatie via verschillende stromen (EDIFACT, MP6.12 en MP9) ontvangen. Het ontdubbelen is het meest betrouwbaar met identificaties. Relaties vastleggen tussen EDIFACT-, MP6.12 en MP9 informatie helpt (geautomatiseerde) ontdubbeling en reconciliatie. Dit vermindert administratieve lasten voor zorgverleners. Hiervoor is het verrijken van het EDIFACT-id en het vullen van de relatie naar het voorschrift in de 6.12 verstrekkingen van belang. Onderstaande paragrafen bevatten nadere toelichting over deze systematiek.

5.1 Huidige situatie

Een voorschrijver die een of meer voorschriften via EDIFACT naar de apotheker stuurt, doet dat met een MEDREC-AAN (aanvraag-) bericht. De apotheker stuurt na het verstrekken van een medicament een MEDREC-AFL (aflever-) bericht naar de huisarts van de patiënt. In het MEDREC-AFL bericht zit, indien mogelijk, een referentie naar de voorschrift-IDs van het MEDREC-AAN bericht. De huisarts krijgt op deze manier ook AFL-berichten van door specialisten voorgeschreven medicatie. Deze AFL-berichten hebben echter géén relatie naar een MP6.12 vooraankondiging.

De huisarts herkent aan het al dan niet aanwezige voorschrift-ID of het een aflevering van een eigen voorschrift is of van een andere voorschrijver. Deze koppeling is niet afhankelijk van het medicament en daarom ook mogelijk wanneer de apotheker iets anders afgeleverd heeft dan voorgeschreven was.

5.2 Gewenste situatie

De gewenste situatie is om zoveel mogelijk te kunnen ontdubbelen en reconciliëren door het matchen van identifiers, óók met oudere versies van de standaard (EDIFACT en MP6.12).

5.2.1 Uitgangspunten

Het is ongewenst om aanpassingen te doen aan (legacy) EDIFACT-implementaties.

5.2.2 MP6.12: relatie leggen vanuit verstrekking naar 6.12 voorschrift

Verstrekkingen bevatten conceptueel gezien altijd een referentie naar de identificatie van het bijbehorende voorschrift, ongeacht of ze beide in hetzelfde berichtformaat verstuurd zijn.

Om goede relaties te kunnen leggen, moet de referentie naar het voorschrift altijd gevuld worden. Ervaringen uit de praktijk leren dat niet alle MP6.12 verstrekking-berichten een referentie naar de MP6.12 vooraankondiging hebben. een MP6.12 vooraankondiging heeft een prescription/id. Dit prescription/id moet verplicht opgenomen worden in de MP6.12 verstrekking.

5.2.3 Verrijkt EDIFACT ID

Wanneer het voorschrift via EDIFACT ontvangen was, kan deze referentie nu niet ingevuld zijn. De EDIFACT-identifier is niet globaal uniek, maar enkel uniek per organisatie. Deze identifier kan daarnaast niet onaangepast meegegeven worden in MP9- of MP6.12-berichten omdat EDIFACT de OID-systematiek niet ondersteunt. Het EDIFACT-id veld heeft maximaal 35 posities. Dit is te klein om een volledige OID in te zetten. De afgesproken werkwijze voor het ‘verrijken’ van de EDIFACT-id die geschikt is voor communicatie in HL7v3 / FHIR is als volgt samen te vatten:

• Een vaste OID-root, vastgesteld door Nictiz: 2.16.840.1.113883.2.4.3.11.61.1
• Een OID-extension die bestaat uit de AGB-code van de verzender en het ID van het EDIFACT voorschrift. Deze twee onderdelen scheiden met een pipe separator.
  • Het ID van het voorschrift wordt gehaald uit het EDIFACT S05 LIN segment
  • De AGB-code van de verzender wordt gehaald uit het EDIFACT S01 NAD+MS segment

5.2.3.1 Voorbeeld 1

De AGB-code van de verzender wordt gehaald uit het S01 NAD+MS segment.

S01+1' 
NAD+MS+01023456:CGP:VEK++Cerelio Tertius' 
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ' 
S01+2' 
NAD+MR+02000456:PHA:VEK++gezondheidszorgwerkers 102' 
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ' 
NAD+MS+01023456:CGP:VEK++Cerelio Tertius' 
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ'

In dit voorbeeld is dat

01023456

.

Het ID van het voorschrift wordt gehaald uit het S05 LIN segment.

S05+1' 
LIN+1+AAN+728999::PRF:LOC' 
RFF+G1:01023456' 
CLI+MED+00008079:PRK:ZI:DICLOFENAC-NATRIUM TABLET MSR 50MG' 
QTY+46:42+245:THE002:ZI:STUK' 
DTM+7:20220203:102' 
DTM+36:20220217:102' 
S07+1' 
DSG+X+3:WCIA25G:NHG:3' 
DSG+T+19:WCIA25G:NHG:per dag' 
DSG+Y+1:WCIA25G:NHG:1' 
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ' 
DSG+A+100:WCIA25G:NHG:tablet'

In dit voorbeeld is dat

728999

De volledige OID extension wordt dan:

01023456|728999

5.2.3.2 Voorbeeld 2

UNB+UNOC:1+01023456+0456+220203:1232+0' 
UNH+0+MEDREC:3:2:OZ:REC32H+MEDREC_3_2_OZ_REC32H' 
BGM+REC:MF:CSI:OMNIHIS' 
DTM+137:202202031232:203' 
S01+1' 
NAD+MS+01023456:CGP:VEK++Cerelio Tertius'
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ' 
S01+2' 
NAD+MR+02000456:PHA:VEK++gezondheidszorgwerkers 102' 
ADR+WO+1:Kosterijland 70+Bunnik+3981AJ' 
S02+1' 
RFF+ROI:728999' 
S03+1' 
PNA+PAT+69::999999837:PCL:LOC+++NAN:Aardoom+NVV:D.*+NVN:+NEA:+NEV:' 
ADR+HO+1:Ademdstraat:10*+DEMOSTAD+9999ZA' 
DTM+329:19610529:102' 
PDI+2' 
S05+1' 
LIN+1+AAN+728999::PRF:LOC' 
RFF+G1:01023456' 
CLI+MED+00008079:PRK:ZI:DICLOFENAC-NATRIUM TABLET MSR 50MG' 
QTY+46:42+245:THE002:ZI:STUK' 
DTM+7:20220203:102' 
DTM+36:20220217:102' 
S07+1' 
DSG+X+3:WCIA25G:NHG:3' 
DSG+T+19:WCIA25G:NHG:per dag' 
DSG+Y+1:WCIA25G:NHG:1' 
DSG+A+100:WCIA25G:NHG:tablet' 
S05+2' LIN+2+AAN+729000::PRF:LOC' 
RFF+G1:01023456' 
CLI+MED+00067903:PRK:ZI:PARACETAMOL TABLET 500MG' 
QTY+46:20+245:THE002:ZI:STUK' 
DTM+7:20220203:102' 
DTM+36:20220223:102' 
S07+1' 
DSG+X+1:WCIA25G:NHG:1' 
DSG+T+19:WCIA25G:NHG:per dag' 
DSG+Y+1:WCIA25G:NHG:1' 
DSG+A+100:WCIA25G:NHG:tablet' 
FTX+DOS+++Dit is extra tekst bij paracetamol' 
S05+3' 
LIN+3+AAN+729001::PRF:LOC' 
RFF+G1:01023456' 
CLI+MED+00000353:PRK:ZI:OXAZEPAM TABLET 10MG' 
QTY+46:30+245:THE002:ZI:STUK' 
DTM+7:20220203:102' 
DTM+36:20220211:102' 
S07+1' 
DSG+X+4:WCIA25G:NHG:4' 
DSG+T+19:WCIA25G:NHG:per dag' 
DSG+Y+1:WCIA25G:NHG:1' 
DSG+A+100:WCIA25G:NHG:tablet' 
FTX+DOS+++ '
UNT+55+0' 
UNZ+1+0'

Dit voorbeeldbericht bevat 3 voorschriften. De verrijkte EDIFACT-ids zien er in XML zo uit:

• voor Diclofenac:

  <id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|728999"/>
  

• voor Paracetamol:

  <id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729000"/>
  

• voor Oxazepam:

  <id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729001"/>
  

5.3 Impact voor de XIS-leveranciers

5.3.1 AIS

MP 6.12 verstrekking/prescription id vullen:

• Indien nog niet geïmplementeerd: prescription/id uit MP6.12 vooraankondiging én
• Verrijkt EDIFACT-id zoals afgeleid uit MEDREC-AAN bericht.

5.3.2 Alle systemen

Het overzicht van identificaties in paragraaf Matchingsregels:

• Bij migratie gebruiken om relaties in MP9 bouwstenen te leggen.
• Bij reconciliëren herkennen en gebruiken, bijvoorbeeld door de medicatie-informatie te kunnen ordenen bij de juiste MBH.

6 Matchingsregels

De te volgen processen bij raadplegen en reconciliëren in de hybride situatie zijn in de vorm van flowcharts uitgewerkt, zie Stroomdiagrammen Raadplegen en Reconciliëren.

6.1 Samenhang van identificaties EDIFACT, MP6.12 met MP9

Tabel 2 geeft een overzicht van de verschillende identificaties en hun onderlinge relaties.

Tabel 2. Overzicht identificaties en hun onderlinge relaties

EDIFACT	MP6.12	MP9
-	6.12 Vooraankondiging id	MA / relatie MA
		VV id
		TA / relatieMA
		MVE / relatieVV
Verrijkt EDIFACT id	Verstrekking/prescription/id (gevuld met 6.12 vooraankondiging id óf verrijkt EDIFACT id)	MA / relatie MA
		VV id
		TA / relatieMA
		MVE / relatieVV
-	Verstrekking id	MVE id
		MGB / relatieMVE (medicatieverificatie)
	Bij beschikbaarstellen 6.12 verstrekkingen na MP9 voorschrift: Verstrekking/prescription/id	MA/id
	-	TA/id
		MBH/id

Tabel 3 geeft een overzicht van diezelfde relaties afhankelijk van het formaat van het medicatievoorschrift. Dit is met name van belang voor een AIS dat over is op MP9. Dit AIS kan in de transitiefase nog medicatievoorschriften krijgen in EDIFACT en/of MP6.12. Onderstaande tabel geeft weer hoe de relaties naar deze voorschriften gelegd moeten worden.

Tabel 3. Overzicht identificaties en hun onderlinge relaties voor ieder formaat van het medicatievoorschrift

Medicatievoorschrift	MEDREC-AFL	MP6.12 verstrekking/ prescription id	MP9 TA/relatieMA	MP9 MVE/relatieVV
MEDREC-AAN	edifact id	verrijkt edifact id	verrijkt edifact id	verrijkt edifact id
MP6.12 vooraankondiging	-	MP6.12 prescription id	MP6.12 prescription id	MP6.12 prescription id
MP9 MA/VV	-	MP9 MA id	MP9 MA id	MP9 VV id

6.2 Matchen van MP9-, MP6.12- en EDIFACT-berichten via prescription-id, via PRK of door gebruiker

Indien mogelijk wordt er voor de matching tussen MP9 en MP6.12/EDIFACT gebruik gemaakt van een identificatie (vooraankondiging-id voor 6.12 en ‘verrijkt’ EDIFACT-id voor EDIFACT). Wanneer een match hierop niet mogelijk is, bijvoorbeeld omdat de id niet in beide bouwstenen is opgenomen, wordt gekeken naar het PRK. Wanneer een match op deze elementen niet mogelijk is, is tussenkomst van de gebruiker nodig om de informatie te reconciliëren. Deze laatste optie heeft uiteraard niet de voorkeur.

7 Reconciliëren

De te volgen processen bij raadplegen en reconciliëren in de hybride situatie zijn in de vorm van flowcharts uitgewerkt, zie Stroomdiagrammen Raadplegen en Reconciliëren.

7.1 ‘Ontdubbelen’ van MBH’s

Na raadplegen kan er sprake blijken te zijn van meerdere MBH’s voor conceptueel dezelfde MBH. Systemen dienen dan de volgende uitgangspunten te hanteren in de keuze welke MBH kan blijven bestaan, en van welke MBH de medicatiebouwstenen gestopt moeten worden (om zo de MBH’s te ontdubbelen).

• Specifieke MBH-id gaat voor generieke MBH-id. Indien er sprake blijkt van meerdere MBH’s voor conceptueel dezelfde MBH, ‘vlagt’ het systeem de MBH met generieke MBH-id als ‘potentieel duplicate medicamenteuze behandeling’. Het doel is dat de specifieke MBH-id blijft bestaan en de generieke naar de historie verdwijnt.
• Meest recente bouwsteen gaat voor. Bij gelijk type MBH-id (dus meerdere generieke of meerdere specifieke MBH-id’s) dient de MBH van de meest recente bouwsteen te blijven bestaan (op basis van afspraakdatum van MA en TA en registratiedatum van MGB). MA gaat daarbij vóór TA, TA gaat vóór MGB. Het systeem ‘vlagt’ de MBH van de bouwsteen met de minder recente afspraakdatum als ‘potentieel duplicate medicamenteuze behandeling’.

Het systeem stelt aan de gebruiker voor om medicatiebouwstenen in een potentieel duplicate MBH (die reeds publiek zijn) te stoppen per ‘heden’ (datum/tijd van reconciliatie), met als reden ‘loopt in andere medicamenteuze behandeling’. De gebruiker kan er vervolgens voor kiezen om dit voorstel zonder wijziging te accorderen, of om de voorgestelde stopdatum aan te passen.

7.2 Controle en correcties bij reconciliatie

Na raadplegen kan het systeem gedurende de transitiefase MP9-bouwstenen en/of 6.12 verstrekkingen ontvangen. Deze binnengekomen gegevens dienen samen met de eigen MP9-bouwstenen gereconcilieerd te worden tot een overzicht waarin idealiter medicatiegegevens die conceptueel tot dezelfde MBH behoren bij elkaar gegroepeerd worden. Het XIS kan op basis van hoofdstuk Matchingsregels de beschikbare medicatiegegevens (eigen MP9-bouwstenen, ontvangen MP9-bouwstenen en/of ontvangen 6.12 verstrekkingen bij raadplegen) aan elkaar relateren. Het is afhankelijk van een aantal factoren of na reconciliatie door het systeem, op basis van deze matchingsregels, al dan niet acties uitgevoerd dienen te worden door de gebruiker voor het ontdubbelen van MBH’s. Het betreft de volgende factoren:

• Het aantal EVS’en en AIS’en van waaruit medicatie voorgeschreven en verstrekt wordt aan de patiënt,
• De onderlinge migratievolgorde van systemen,
• Het moment van beschikbaarstellen van bouwstenen door een EVS,
• Het moment van raadplegen en reconciliëren ten opzichte van de migratievolgorde van andere systemen,
• De vastgelegde gegevens (bijvoorbeeld prescription-id in de 6.12 verstrekking).

8 Early adopters

Er zijn op dit moment verschillende systemen die reeds via MP9 informatie uitwisselen (via MP9.07). Gezien deze ‘early adopters’ vanuit verschillende trajecten aangesloten zijn op bepaalde onderdelen van MP9, wordt de MBH-id door sommige early adopters al wel en door andere niet toegepast.

8.1 Early adopters MP9 met (mogelijk) MBH-id

In MP9 bestaat (tot op heden) niet de methodiek van een generieke MBH-id. Indien een early adopter van MP9 reeds medicatiebouwstenen met een MBH-id beschikbaar heeft gesteld, zullen dit daarom altijd specifieke MBH-id’s betreffen. Deze medicatiebouwstenen kunnen daarmee gezien worden als ‘volwaardige’ MP9-informatie. Er kunnen mogelijk publieke MBH’s met specifieke MBH-id’s gegenereerd zijn door systemen binnen de informatiestandaard BgZ, het programma VIPP GGZ (VIPP 3), de informatiestandaard Ketenzorg en via MedMij.

• BgZ. Zeer waarschijnlijk is er nog geen gebruik gemaakt van MBH-id’s.
• VIPP GGZ. Er wordt gebruik gemaakt van MBH-id’s. Gezien dit programma gericht was op EVS’en, worden geen problemen voorzien gedurende het transitieproces naar MP9 2.0.0. Werkafspraken voor de transitieperiode zijn immers dat het EVS leidend is en eigen bouwstenen direct beschikbaarstelt.
• Ketenzorg. Gezien de MBH-id geen onderdeel was van kwalificatie, zullen systemen zeer waarschijnlijk nog geen MBH-id’s gegenereerd hebben.
• MedMij
  • DVZA-BgZ. Gezien de MBH-id geen onderdeel was van kwalificatie, zullen systemen zeer waarschijnlijk nog geen MBH-id’s gegenereerd hebben.
  • DVZA-verstrekkingenvertalingen. In ‘verstrekkingenvertalingen’ wordt de MBH-id gevuld met de 6.12 verstrekking-id, met als doel een relatie te leggen tussen de TA en MVE. Deze id is niet geschikt voor MP9 2.0.0, dus deze partijen kunnen beschouwd worden als early adopters van MP9, zonder MBH-id.

8.2 Early adopters MP9 zonder MBH-id

Tijdens de hybride situatie kan de MP9-informatie zonder MBH-id in veel gevallen genegeerd worden, bijvoorbeeld omdat deze informatie al via een andere route, zoals MP6.12, bekend is. Eventueel kan een systeem in bepaalde gevallen informatie uit deze stroom tonen aan de gebruiker, maar er vindt geen reconciliatie plaats op id of op PRK.

9 Doseringen

Tijdens de transitiefase verdienen doseringen speciale aandacht. Dit omdat de doseringen in MP9 2.0 functioneel zijn uitgebreid en technisch anders worden uitgewisseld dan in MP6.12. Algemeen geldt: Gestructureerd waar mogelijk, maar indien het te complex wordt, opnemen in vrije tekst. Hieronder volgt een korte opsomming van deze elementen en de afgesproken werkwijze voor omzetten van doseerschema’s van MP9 naar MP6.12.

• Weekdag: Gebruiken van ankerdatum (PIVL_TS/low) in combinatie met frequentie 1 week om zo te zorgen dat de toedieningen op specifieke dagen plaatsvinden.
• Dagdeel: Deze informatie kan op verschillende manieren meegegeven worden. Bijv. via frequentie (X keer per dag, aannemende dat het over de dag verdeeld is) of middels toedientijden. Daarnaast worden de dagdelen inhoudelijk opgenomen in tekst.
• Interval: In MP6.12 is geen onderscheid tussen interval en frequentie. Daarom wordt dit onderscheid opgenomen in de tekst. Hiervoor komt een voorbeeldtekst.
• isFlexibel voor toedientijden: Dit kan niet gestructureerd worden gedeeld, daarom wordt deze informatie opgenomen in de tekst.

10 Patiëntportalen

Patiëntportalen van EVS'en of AIS'en kunnen patiënten de mogelijkheid bieden om MGB te registreren. Indien het EVS of AIS deze informatie uit het patiëntportaal beschikbaarstelt, dient er aandacht te zijn voor het volgende.

• Het patiëntportaal dient te faciliteren dat de patiënt bij de registratie van MGB gebruik kan maken van MP9-bouwstenen (zowel MP9-informatie uit het betreffende EVS of AIS als MP9-informatie uit andere XIS’en). Dit om ervoor te zorgen dat MGB in de MBH van bijbehorende MA en/of TA geregistreerd wordt.
• Het patiëntportaal dient te faciliteren dat de patiënt MGB kan registreren via G-Standaard coderingen.

11 PGO's

Naast EVS’en en AIS’en zijn er nog andere XIS’en die te maken kunnen krijgen met een hybride situatie. Dit betreft bijvoorbeeld PGO’s die de beschikbare medicatiegegevens raadplegen en op termijn ook MGB beschikbaar zullen stellen (tijdens de Kickstart Medicatieoverdracht wordt er vanuit de PGO’s nog geen MGB beschikbaargesteld).

Voor PGO’s is het tijdens de transitiefase mogelijk om dezelfde informatie via verschillende routes op te vragen. Daarom is het wenselijk dat PGO’s prioriteren in het type gegevens dat bij raadplegen binnenkomt vanuit de verschillende systemen. Als er MP9 2.0 informatie is, dan zou die informatie leidend moeten zijn. Als er geen MP9 2.0 informatie is, wordt gekeken naar MP9.0.7 informatie met een MBH-id en als laatste alternatief kan gebruik gemaakt worden van MP6.12 informatie.

12 Definities

• Actuele medicatie: Medicatie waarvan de stopdatum (op een bepaald moment moment) nog niet verstreken is. Dit betreft huidige (heden ligt tussen start- en stopdatum) en toekomstige (heden ligt voor startdatum) medicatie.
• (Actief) beschikbaarstellen: Het proces van het ter beschikking stellen van de eigen MP9-gegevens zodat andere systemen deze informatie kunnen raadplegen en/of het sturen van de eigen MP9-gegevens.
• Generieke MBH-id: De generieke MBH-id wordt zodanig gegeneerd dat systemen onafhankelijk van elkaar dezelfde identificatie genereren voor medicatiebouwstenen met hetzelfde prescriptiekenmerk (PRK). De generieke MBH-id bestaat uit een algemene OID-root (2.16.840.1.113883.2.4.3.11.61.2), gevolgd door de code van het PRK in de OID-extension. Een generieke MBH-id is daarmee alleen uniek binnen een patiënt, maar niet uniek over patiënten heen. Deze variant MBH-id is alleen bedoeld als tijdelijke oplossing in de transitiefase voor bepaalde situaties.
• Historie van medicatie: Medicatie met een einddatum die meer dan twee maanden in het verleden ligt.
• Hybride situatie: De situatie waarbij een systeem (tijdelijk) zowel MP9 als MP6.12/ EDIFACT ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen.
• Migreren: Het omzetten van de reeds beschikbare medicatiegegevens in een patiëntdossier naar een datamodel dat MP9-bouwstenen ondersteunt.
• Raadplegen: Het proces van opvragen van beschikbare medicatiegegevens, zowel MP9-gegevens als MP6.12-gegevens (raadplegen en reconciliëren zijn nauw aan elkaar verwant en zijn samen met het gesprek met de patiënt/ cliënt onderdeel van verificatie).
• Recent gestopte medicatie: Medicatie die in de afgelopen twee maanden is geëindigd of gestopt.
• Reconciliëren: Het proces van het samenbrengen en ontdubbelen van beschikbare gegevens met ontvangen gegevens met als doel een overzichtelijk en juist medicatiedossier op te bouwen (raadplegen en reconciliëren zijn nauw aan elkaar verwant en zijn samen met het gesprek met de patiënt/ cliënt onderdeel van verificatie).
• Specifieke MBH-id: Een specifieke MBH-id is wereldwijd en eeuwig uniek. De MBH-id zoals deze in de informatiestandaard MP9 beschreven is, is een specifieke MBH-id. Het EVS wijst aan alle actuele en recent gestopte MP9-bouwstenen een specifieke MBH-id toe bij migratie. Het AIS maakt geen specifieke MBH-id’s aan (indien sprake van een publieke MBH), maar hanteert indien mogelijk ontvangen specifieke MBH-id’s.
• Transitiefase: De fase waarin systemen de informatiestandaard MP9 implementeren. Deze fase loopt van de migratie van het eerste systeem tot het moment dat uiteindelijk alle systemen over zijn op MP9.
• Prescription-id in 6.12 verstrekking: Identificatie van het voorschrift waarop de 6.12 verstrekking is gebaseerd. De prescription-id kan met verschillende typen waarden gevuld worden, afhankelijk van het type voorschrift dat de basis vormde voor deze verstrekking: vooraankondiging-id (indien MP6.12), ‘verrijkt’ EDIFACT-id (indien EDIFACT) of MA-id (indien MP9). De prescription-id kan gebruikt worden om relaties te leggen van 6.12 verstrekkingen naar het voorschrift of vanuit MP9-bouwstenen naar de MP6.12-berichtenstroom.
• Private MBH: Bouwstenen binnen een private MBH worden niet uitgewisseld.
• Publieke MBH: Bouwstenen binnen een publieke MBH worden uitgewisseld. De MBH zoals beschreven in de informatiestandaard MP9 is een publieke MBH.
• ‘Verrijkt’ EDIFACT-id: Een EDIFACT-id is niet wereldwijd uniek en is geen OID, waardoor het niet zonder meer in een prescription-id van MP6.12 gebruikt kan worden. Deze id kan uniek gemaakt worden door een verrijkte EDIFACT-id samen te stellen uit een vaste OID-root en een OID-extension die bestaat uit het EDIFACT-id en de organisatie-id (hash).