Migratie en hybride

Uit informatiestandaarden
Versie door Remco Heeringa (overleg | bijdragen) op 12 okt 2023 om 07:37 (→‎Bijlage: Afkortingen en definities)
Ga naar: navigatie, zoeken


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

Voor een overzicht van relevante Wiki-pagina's voor Medicatieproces zie Landingspagina Medicatieproces.

Inhoud

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 Medicatieoverdracht. De brede uitrol volgt hierop.

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. Dat maakt dat er afspraken nodig zijn 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 ook MP9-bouwstenen ondersteunt),
  • het raadplegen (het proces van opvragen van beschikbare medicatiegegevens, uit zowel 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), apotheekinformatiesysteem (AIS) en de persoonlijke gezondheidsomgeving (PGO). De afspraken voor het elektronisch toedienregratiesysteem (eTDR) zijn nog niet volledig en zullen aangevuld worden (zie Toedienlijsten).

1.3 Leeswijzer

Hoofdstukken

  • Hoofdstuk 2 gaat in op de verschillen tussen de transitiefase en de uiteindelijke situatie waarin alle systemen over zijn op MP9. Er zijn aanvullende afspraken nodig om tijdens de transitiefase te komen tot een overzichtelijk medicatiedossier.
  • Hoofdstuk 3 en Hoofdstuk 4 beschrijven de afspraken voor 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 geeft een toelichting op de overige aandachtspunten gedurende de transitiefase (onder andere de doseerinstructies, doseerverlagingen en combinatiepreparaten).
  • Hoofdstuk 6 beschrijft de afspraken voor toedienlijsten in de hybride situatie.

Bijlagen

  • Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id geeft instructies voor 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: Early adopters van MP9 geeft een toelichting op de 'early adopters' van MP9 (o.a. programma VIPP GGZ, informatiestandaard BgZ, MedMij), met een inventarisatie in welke berichtenstromen wel of niet sprake is van 'volwaardige' MP9-informatie.
  • Bijlage: Afkortingen en definities bevat een lijst met definities van de termen die in de tekst in deze layout staan.
  • Bijlage: Documenthistorie geeft een overzicht van de wijzigingen in deze pagina.

Wijzigingen en beheerproces

Aandachtspunten gebruikersondersteuning

Verwijzingen

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 ook in de transitiefase een overzichtelijk medicatiedossier op te kunnen stellen. Allereerst, in de transitiefase is het niet altijd mogelijk om samenhangende medicatiegegevens via de MP9-systematiek bij elkaar te groeperen. Dit omdat het technische begrip 'medicamenteuze behandeling' nieuw is in MP9 en niet bestaat in MP6.12 en/of EDIFACT. Bovendien zijn in de transitiefase niet alle medicatiegegevens raadpleegbaar als MP9-bouwstenen. Dit hoofdstuk geeft een toelichting op deze verschillen en legt uit waarom er voor de transitiefase aanvullende afspraken nodig zijn om te komen tot een overzichtelijk medicatiedossier.

2.1 Nieuw technisch begrip ‘medicamenteuze behandeling’

Medicatieproces gaat over het voorschrijven van een geneesmiddel, gevolgd door ter hand stellen tot en met toedienen en gebruik. De medicamenteuze behandeling (MBH) bundelt de verschillende medicatiebouwstenen die zo ontstaan. Alle medicatiebouwstenen hebben een verplichte identificatie: de MBH-id. MP6.12- en EDIFACT-informatie bevat deze MBH-id niet. Wanneer systemen onafhankelijk van elkaar migreren, genereren zij onafhankelijk van elkaar een MBH-id. Dit geeft het volgende probleem: systemen zullen verschillende MBH-id’s aanmaken 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 zijn daarom afspraken nodig om deze risico’s te minimaliseren. Dit betreffen primair afspraken voor het toekennen van de MBH-id bij migratie (zie Migreren en beschikbaarstellen). Via deze afspraken proberen we dubbelingen in MBH's zoveel mogelijk te beperken. Echter, volledig voorkomen van duplicate MBH's is niet mogelijk. Deze pagina bevat daarom tevens instructies voor het relateren van samenhangende medicatiegegevens en het ontdubbelen van MBH’s (zie Raadplegen/ontvangen en reconciliëren).

2.2 Medicatiegegevens vanuit MP9- en MP6.12/EDIFACT-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 EVS'en en AIS'en in de keten. Gegevens vanuit het MP6.12-AIS zullen via een transformatiedienst van de infrastructuurleverancier geconverteerd worden. De transformatie betreft een conversie van MP6.12-verstrekkingen naar het formaat van MP9-TA’s. Echter, 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 voor 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 ook 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 voor het migreren en het moment van beschikbaarstellen van de gemigreerde medicatiegegevens. Het gaat dan om afspraken die de medicatieveiligheid bevorderen. Aanvullende (detail)afspraken worden gemaakt tussen leverancier en zorgaanbieder (gebruikersgroep).

3.1 Beschikbaarstellen van gemigreerde medicatiegegevens

3.1.1 EVS, AIS en eTDR

Voor het EVS, AIS en eTDR geldt dat na migratie de medicatiegegevens direct beschikbaargesteld mogen worden. Ook historie wordt beschikbaargesteld. Figuur 1 geeft een overzicht van de processtappen migreren, Sturen en/of beschikbaar stellen, raadplegen en reconciliëren voor het EVS, AIS en eTDR. 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-systeem zal tijdens de transitiefase ook de oude berichtenstromen (MP6.12 en/of EDIFACT) moeten blijven ondersteunen. Zo zal een gemigreerd MP9-AIS tijdens de transitiefase de medicatiegegevens via zowel 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 via een transformatiedienst voor een conversie van MP6.12-verstrekkingen naar het formaat van MP9-TA’s (zie Medicatiegegevens vanuit MP9- en MP6.12/EDIFACT-systemen en Raadplegen/ontvangen en reconciliëren).

Figuur 1. Overzicht van de volgorde van de processtappen (migreren, Sturen en/of beschikbaar stellen, raadplegen, reconciliëren) voor EVS, AIS en eTDR.

3.1.2 PGO

PGO's zijn bron van medicatiegebruik (MGB) geregistreerd door de patiënt. Voor PGO’s geldt dat zij na migratie ook historisch medicatiegebruik beschikbaarstellen, maar wel pas nadat de patiënt de medicatiegegevens geraadpleegd heeft in de PGO en eventueel ook nieuw medicatiegebruik geregistreerd heeft. Figuur 2 geeft een overzicht van de processtappen migreren, sturen en/of beschikbaar stellen, raadplegen en reconciliëren voor PGO's.

Figuur 2. Overzicht van de volgorde van de processtappen (migreren, Sturen en/of beschikbaar stellen, raadplegen, reconciliëren) voor PGO.

Tijdens de Kickstart Medicatieoverdracht stellen PGO’s nog geen MGB beschikbaar.

3.2 Algemene migratieafspraken

3.2.1 Onderscheid tussen eigen en andermans medicatiegegevens

Bij migratie dienen systemen onderscheid te maken tussen ‘eigen’ en ‘andermans’ medicatiegegevens. Het systeem is bron van ‘eigen’ gegevens. Een ánder systeem is bron van ‘andermans’ gegevens. 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 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 te voorkomen dat er onnodig dubbele medicatiebouwstenen uitgewisseld worden bij betrokkenheid van meerdere systemen bij een patiënt.

3.2.2 Einddatum in medicatiegegevens

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

  • MA: 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, laat het systeem de einddatum van de MA open.
  • TA: 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. Deze risico’s nemen we in acht bij afspraken voor toedienlijsten in de hybride situatie (zie Toedienlijsten).

3.2.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 1 geeft een overzicht van de verschillende identificaties in EDIFACT, MP6.12 en MP9 en hun onderlinge relaties.

Tabel 1. Identificaties en hun onderlinge relaties
EDIFACT MP6.12 MP9
- MP6.12-vooraankondiging id MA/relatieMA
(vullen met id van meest recente MP6.12-vooraankondiging[1])
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 In TA na conversie van MP6.12-verstrekking:
TA id (gevuld met MP6.12-verstrekking id, @root prefixen met vaste root oid[2])
MVE id
MGB/relatieMVE (medicatieverificatie)
Bij beschikbaarstellen MP6.12-verstrekkingen na MP9-voorschrift:
MP6.12-verstrekking/prescription/id 		MA id
- TA id
MBH id
  1. ↑ Sommige MP6.12-systemen werken in de lokale database al op een vergelijkbare manier als de MP9-MA’s, waaronder het mogelijk is om meerdere verstrekkingsverzoeken te doen. In deze situatie dient bij migratie het veld MA/relatieMA gevuld te worden met de identificatie van de meest recente MP6.12-vooraankondiging.
  2. ↑ Zie https://bits.nictiz.nl/browse/MP-572

3.3 Specifieke vs. generieke MBH-id

Gedurende de transitiefase werken we niet alleen met de specifieke MBH-id zoals gedefinieerd in de informatiestandaard MP9, maar ook met een generieke MBH-id. De generieke MBH-id heeft als doel het minimaliseren van het probleem van meerdere MBH-id’s voor conceptueel dezelfde MBH. Via de generieke MBH-id kunnen systemen onafhankelijk van elkaar dezelfde identificatie genereren voor medicatiebouwstenen met dezelfde prescriptiecode (PRK) of, indien PRK niet bekend is, handelsproductcode (HPK).

Een generieke MBH-id is 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 (zie Actuele en recent gestopte vs. historische medicatie en EVS vs. andere systemen (AIS, eTDR, PGO)). De intentie is om de generieke MBH-id zo snel mogelijk naar de historie te verdrijven.

  • 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. 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.
  • Generieke MBH-id op basis van PRK: De generieke MBH-id op basis van PRK bestaat uit een algemene OID-root ‘generiekeMBHIdPRK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.2), en de PRK in de OID-extension. Hiervoor wordt, indien bekend, de PRK uit de MA/ het voorschrift gebruikt.
  • Generieke MBH-id op basis van HPK: De generieke MBH-id op basis van G-Standaard HPK bestaat uit een algemene OID-root ‘generiekeMBHIdHPK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.3), en de HPK in de OID-extension. In uitzonderingssituaties, zoals bij migratie van medicatiegegevens uit verre historie, kan het zo zijn dat de HPK wel bekend is, maar de PRK niet. Wanneer de PRK niet te achterhalen is, dient de leverancier een generieke MBH-id te genereren op basis van HPK.

3.3.1 Actuele en recent gestopte vs. historische medicatie

De informatiestandaard 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 (of HPK) 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.

3.3.2 EVS vs. andere systemen (AIS, eTDR, PGO)

Voor het toekennen van een specifieke vs. generieke MBH-id bij migratie van actuele en recent gestopte medicatie en bij het starten van een MBH gelden andere afspraken voor het EVS dan voor AIS'en, eTDR's en PGO's. Voor systemen anders dan EVS geldt dat zij in principe géén specifieke MBH-id genereren (tenzij er geen HPK of PRK is, zie Bijzondere situaties). Dit komt overeen met de uitgangspunten van de informatiestandaard MP9 waarin een MA leidend is ten opzichte van de andere medicatiebouwstenen. De afspraken voor het toekennen van een specifieke vs. generieke MBH-id per systeemrol lichten we hieronder toe. Een overzicht van de situaties waarin systemen een specifieke of generieke MBH-id dienen toe te kennen is te vinden in Tabel 2.

  • EVS: Voor actuele en recent gestopte medicatie kent het EVS bij migratie een specifieke MBH-id toe. 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 dat het EVS een nieuwe MBH met specifieke MBH-id start.
  • AIS: Het AIS wijst in de transitiefase een generieke MBH-id toe. Het AIS maakt in principe alleen medicatiebouwstenen met een specifieke MBH-id wanneer het een specifieke MBH-id vanuit het EVS ontvangen heeft.
  • eTDR: Het eTDR wijst in principe een generieke MBH-id toe. Het komt echter regelmatig voor dat een MBH start met een medicatietoediening (denk aan spoedsituaties of intensive care). In zo’n geval is het EVS niet leidend maar volgend. Dit betekent dat eTDR’s, ook in de uiteindelijke MP9-situatie, veel vaker een MBH zullen starten dan AIS’en. Een eTDR volgt dan niet het EVS, zoals typisch wel het geval is bij een AIS. Daarom zijn er voor eTDR’s in de transitiefase andere afspraken dan voor AIS’en. Indien het eTDR ‘weet’ dat de bijbehorende MA gaat komen uit een MP9-EVS, dan mag het eTDR de MBH starten met een specifieke MBH-id. Zo voorkomen we onnodig dubbele MBH’s.
  • PGO: Een PGO kent bij migratie een generieke MBH-id toe voor reeds geregistreerd MGB. In de transitiefase wijst de PGO bij het starten van een MBH een generieke MBH-id toe. De PGO maakt alleen MGB met een specifieke MBH-id wanneer deze een specifieke MBH-id vanuit het EVS/AIS ontvangen heeft. Een PGO volgt het EVS/AIS: als er bij een medicament geen specifieke MBH-id bekend is, deelt de PGO het MGB met een generieke MBH-id. Indien nodig, wordt gebruik gemaakt van de G-Standaard om een generieke MBH-id toe te kennen.
  • Meerdere systeemrollen: Sommige systemen hebben meerdere rollen, denk aan EVS en AIS of EVS en eTDR. Dit geldt voor ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken. Meestal hebben TA’s uit het AIS-onderdeel van het systeem een relatie naar een MA (of eventueel MGB) in het EVS-onderdeel. MTD’s uit het eTDR-onderdeel kunnen ook een relatie hebben naar een MA. Wanneer er een interne relatie bestaat naar een MA of MGB die een specifieke MBH-id heeft, zal de te migreren bouwsteen (TA of MTD) direct aan de juiste specifieke MBH-id gekoppeld kunnen worden. Wanneer een MBH start met een MTD én het eTDR wéét dat de bijbehorende MA later zal volgen uit het eigen MP9-EVS, mag het eTDR een specifieke MBH toekennen. In de andere gevallen valt een AIS of eTDR terug op een generieke MBH-id.

Tabel 2. Specifieke of generieke MBH-id per situatie en systeem[1]
Situatie EVS AIS eTDR PGO Meerdere systeemrollen[2]
Migreren van actuele en recent gestopte medicatie Specifiek Generiek Generiek Generiek Specifiek of generiek
Migreren van historische medicatie Generiek Generiek Generiek Generiek Generiek
Starten van nieuwe MBH Specifiek Generiek Specifiek of generiek[3] Generiek Specifiek of generiek
  1. ↑ Alleen wanneer er geen HPK of PRK is, maken systemen anders dan EVS een specifieke MBH-id aan (zie Bijzondere situaties).
  2. ↑ Zie toelichtende tekst bij 'Meerdere systeemrollen'.
  3. ↑ Indien eTDR zeker weet dat EVS MP9 doet: specifieke MBH-id, anders: generieke 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 uiteindelijk ontdubbeld te worden. Daarnaast bestaan er ‘early adopters’ van MP9. Dit hoofdstuk beschrijft de systematiek voor de verwerking van medicatiegegevens in de hybride situatie in EVS’en, AIS’en en PGO’s. Deze systematiek zorgt ervoor dat ook in de transitiefase een overzichtelijk medicatiedossier kan worden opgebouwd. Het reconciliëren tot een overzichtelijk medicatiedossier vraagt om ondersteuning vanuit systemen aan de gebruiker. Deze aandachtspunten worden in dit hoofdstuk benoemd. 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 medicatiebouwstenen vanuit MP9-systemen binnenkrijgen én vanuit MP6.12-AIS'en via de transformatiedienst van de infrastructuurleverancier. De medicatiegegevens uit MP9-systemen kunnen een specifieke of generieke MBH-id bevatten (zie Specifieke vs. generieke MBH-id). De medicatievoorschriften uit MP6.12/EDIFACT-EVS'en, in tegenstelling tot MP9-EVS'en, zijn niet zichtbaar voor andere EVS'en en AIS'en in de keten.

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 1). 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 en waar van toepassing gebruikersondersteuning.

Het EVS en AIS verduidelijken 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 Einddatum in medicatiegegevens) of bevat complexe doseerinstructies in vrije tekst (zie Doseerinstructies).

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 informatie is uit MP9 2.0.0 of latere release, dan zou die informatie leidend moeten zijn. Is deze informatie er niet, dan wordt gekeken naar MP9.0.7-informatie met een MBH-id en als laatste alternatief kan gebruik gemaakt worden van MP9.07-informatie zonder MBH-id of MP6.12-informatie (zie Bijlage: Early adopters van MP9). Afspraak voor de transitiefase is dat PGO’s de medicatiegegevens uit verschillende bronnen geïntegreerd tonen.

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 3 geeft weer hoe de relaties naar deze voorschriften gelegd moeten worden.

Tabel 3. 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 MP6.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’.

Vanuit het EVS of AIS kan een zorgverlener MBH's ontdubbelen. 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.

Vanuit PGO's kan (vooralsnog) niet ontdubbeld worden (het verzoek voor het kunnen stoppen van MGB in een duplicate MBH is opgenomen in BITS, zie voor de actuele status https://bits.nictiz.nl/browse/MP-1026). Als er dubbele MBH’s zijn, dan is het de bedoeling dat de patiënt MGB registreert in de MBH die volgens bovenstaande regels zou moeten blijven bestaan (‘specifieke MBH-id gaat voor generieke MBH-id’ en ‘meest recente bouwsteen gaat voor’).

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 opstellen van de toedienlijst (zie Toedienlijsten) en
  • Aanvullende werkprocesafspraken tussen zorgverleners (de actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-694).

Ook voor PGO's bij het samenstellen van het medicatieoverzicht is dit een aandachtspunt in de transitiefase: na het stoppen van een TA vanwege ontdubbeling is mogelijk niet direct een TA in de specifieke MBH aangemaakt.

4.2.2 Duplicate MA’s

Een duplicate MA kan ontstaan wanneer een EVS ‘andermans’ MA per abuis heeft gemigreerd als ‘eigen’ MA (zie 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 Aandachtspunten gedurende transitiefase

Dit hoofdstuk geeft een toelichting op de aandachtspunten voor MP9-systemen in de transitiefase (onder andere doseringen en combinatiepreparaten).

5.1 Doseerinstructies

Tijdens de transitiefase verdienen doseringen speciale aandacht. Dit omdat de doseringen in MP9 functioneel zijn uitgebreid. Daarnaast is de technische uitwisseling verschillend in MP9, MP6.12 en EDIFACT. MP9 wisselt toedieningsschema’s technisch uit volgens het FHIR-datatype Timing. MP6.12 maakt gebruik van het HL7v3-datatype GTS (General Timing Specification). EDIFACT bevat doseerinstructies volgens NHG Tabel25.

5.1.1 MP6.12

Algemeen geldt voor het omzetten van doseerinstructies tussen MP9 en MP6.12: Gestructureerd waar mogelijk, maar indien het te complex wordt, terugvallen op alleen vrije tekst.

Dat geldt met name bij het omzetten van MP6-12 doseringen naar MP9. HL7v3-GTS is een complex model, waarbij de exacte dosering soms moeilijk te achterhalen valt. Op de mapping pagina voor de MedMij gegevensdienst verstrekkingenvertaling is daarbij een opzet gemaakt die als leidraad kan dienen. Zie bij TA/Doseerinstructie.

Hieronder volgt een korte opsomming van de verschillen in doseringen en de afgesproken werkwijze voor omzetten van MP9 naar MP6.12.

  • Weekdag: Dit is toegevoegd in MP9 als expliciet concept. In MP6.12 bestaat dit niet als expliciet concept, maar het kan toch vertaald worden via een schema in GTS. Gebruik daarvoor een ankerdatum (PIVL_TS/low) die valt op die weekdag. Combineer dit met frequentie 1x per week om zo te zorgen dat de toedieningen op specifieke weekdagen plaatsvinden. Eventueel kunnen meerdere PIVL_TS’en gebruikt worden voor meerdere weekdagen.
  • Dagdeel: Dit is toegevoegd in MP9 als expliciet concept. In MP6.12 bestaat dit niet en kan het niet met dezelfde betekenis worden uitgewisseld. Deze informatie zal dus gestructureerd (deels) verloren gaan. De informatie kan op verschillende manieren meegegeven worden:
    • via doseCheckQuantity of
    • middels toedientijden of
    • via frequentie (X keer per dag, aannemende dat het over de dag verdeeld is)

De methode via doseCheckQuantity verdient daarbij de voorkeur omdat deze geen precisie toevoegt die er eigenlijk niet is. Daarnaast moeten de dagdelen inhoudelijk opgenomen in tekst zodat deze betekenis niet verloren gaat voor de gebruiker (zorgverlener / patiënt).

  • Interval: In MP6.12 is geen onderscheid tussen interval en frequentie. Daarom wordt dit onderscheid opgenomen in de tekst. Hiervoor komt een voorbeeldtekst. De actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-515).
  • isFlexibel voor toedientijden: Dit kan niet gestructureerd worden gedeeld, daarom wordt deze informatie alleen opgenomen in de tekst.

5.1.2 EDIFACT (NHG Tabel25)

Er zijn verschillen tussen NHG Tabel25 en het doseringsmodel in MP9. Dit vraag om aandacht voor migratie van doseringen en de mapping tussen beide doseringsmodellen. Immers, MP9-systemen zullen in de transitiefase ook nog berichten via EDIFACT moeten ontvangen of versturen (naar een systeem dat nog niet kan uitwisselen via MP9). De actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-644.

5.2 Doseerverlagingen

Een MP9-AIS voert een doseerverlaging in het eigen systeem door als nieuwe TA. Dit AIS werkt een eerdere MP6.12-verstrekking echter niet bij en maakt ook géén nieuwe ‘fake’ MP6.12-verstrekking aan. Een MP6.12-systeem zal bij raadplegen daarom alleen de initiële MP6.12-verstrekking ontvangen. Deze bevat dus niet de doseerverlaging uit de meest recente MA en TA. Dit is overigens dezelfde informatie die dit systeem ook ontving vóór MP9 bestond.

Een MP9-AIS kan en mag ook anders werken. Het kan zijn dat het MP9-AIS de MP6.12-verstrekking niet als zodanig vastlegt in het eigen systeem. Een dergelijk AIS genereert de MP6.12-verstrekking op het moment van raadplegen. Dit AIS moet de MP6.12-verstrekking genereren op basis van de geldige TA(‘s) op datum en tijd van de verstrekking. Dit zodat een reeds gedane MP6.12-verstrekking niet achteraf inhoudelijk verandert, wat niet toegestaan is in de MP6.12-wereld.

Wanneer een EVS nog over moet gaan naar MP9, terwijl het AIS wel al MP9 geïmplementeerd heeft, kan het volgende voorkomen bij een doseerverlaging. Het MP9-AIS heeft een TA aangemaakt op basis van een MP6.12-vooraankondiging. Het EVS registreert een doseerverlaging. Gezien er geen nieuwe verstrekking nodig is, ontvangt het AIS geen MP6.12-vooraankondiging met vermelding van deze verlaagde dosis. Wanneer het EVS wel overgaat naar MP9, zal het AIS de MA met verlaagde dosis kunnen raadplegen. De TA zal dan een dosering bevatten die niet overeenkomt met de dosering in de MA. Desalniettemin mag deze TA in de MBH van de MA gezet worden.

5.3 Bijzondere situaties

5.3.1 Combinatiepreparaten

Combinatiepreparaten zijn geneesmiddelen waarin werkzame stoffen zijn gecombineerd. Deze werkzame stoffen zijn ook als los geneesmiddel verkrijgbaar. Het gaat dan bijvoorbeeld om Exforge HCT of Atozet. Deze combinatiepreparaten kunnen vervangen worden door het gebruik van drie respectievelijk twee losse geneesmiddelen.

Een voorschrijver kan kiezen om een dergelijk combinatiepreparaat voor te schrijven (een MA met 1 geneesmiddel). In het vervolg van het medicatieproces komt het echter voor dat niet het combinatiepreparaat, maar de losse middelen daadwerkelijk geleverd worden. Dat kan financiële (combinatiepreparaat is te kostbaar) of logistieke (combinatiepreparaat zit niet in assortiment of is niet op voorraad) redenen hebben. Dit gebeurt bijvoorbeeld in een openbare apotheek, maar kan ook gebeuren wanneer een patiënt opgenomen wordt in of juist ontslagen wordt uit een instelling. Feitelijk ontstaan er dan meerdere TA’s met ieder een eigen geneesmiddel in dezelfde MBH. Dit kan overigens ‘gewoon’ via de normale MP9-regels.

Zowel in de transitiefase als bij migratie kunnen er specifieke uitdagingen ontstaan die vragen om extra afspraken. Dit lichten de hiernavolgende secties nader toe.

5.3.1.1 Transitiefase

In de transitiefase kan een situatie ontstaan met combinatiepreparaten die extra aandacht vereist. Dit komt doordat systemen die nog niet over zijn op MP9 informatie uitwisselen met systemen die dat wel zijn. Dat is het gemakkelijkst toe te lichten aan de hand van een praktijkgeval.

Er is ooit een MBH “MBH-1” voor een combinatiepreparaat X gestart door MP9-EVS “ABC”. Dit EVS heeft een MA gemaakt voor bijvoorbeeld een maand. Een tijd later beslist een huisarts om dit te herhalen. Deze huisarts heeft nog geen MP9-systeem en stuurt vanuit EVS “DEF” een EDIFACT voorschrift naar MP9-AIS “GHI”. Dit AIS herkent dat het gaat om dezelfde MBH “MBH-1”. Het AIS splitst dit preparaat in middel XY en middel XZ, dus in twee parallelle TA’s in diezelfde MBH. Als een derde voorschrijver daarna weer de actuele situatie van deze MBH raadpleegt dan ontvangt deze geen actieve MA (die was ‘ooit’ afgelopen na een maand), maar wel twee actieve, parallelle TA’s voor middel XY en middel XZ.

Een MBH is één (uitklapbare) regel op een medicatieoverzicht. Eventuele parallelle TA’s die daaronder hangen kun je in samenhang zien onder die regel (bijvoorbeeld bij openklappen). Het stoppen of wijzigen van een MBH doet een voorschrijver per MBH en niet per onderliggende TA. Voor dit praktijkgeval kan het systeem een additionele query doen om de PRK uit het MP9-EVS “ABC” (de MA) te achterhalen. De informatiestandaard kent hiervoor de queryparameter MBH-id. Het systeem hoeft dus niet álle historie op te vragen maar alleen voor die MBH waar deze situatie optreedt. Het systeem kan deze situatie (geen actieve EVS-bouwsteen en actieve parallelle TA’s) herkennen. Vanaf AORTA 8.3 kunnen systemen dergelijke query’s op het LSP zelfstandig, dus zonder UZI-pas authenticatie, uitvoeren. In dat geval is de PRK van de MA alsnog achterhaald en kan er gewijzigd/gestopt worden volgens normale MP9-regels.

Voortbordurend op dit praktijkgeval:

Stel dat:

  • het systeem, om welke reden dan ook, de MA met het combinatiepreparaat niet heeft kunnen achterhalen én
  • de voorschrijver ook niet herkent dat dit om zo’n preparaat gaat én
  • de voorschrijver deze MBH wil stoppen of wijzigen.

Welk geneesmiddel moet er dan in de stop-MA gezet worden? De voorschrijver ziet twee TA’s met middel XY en XZ. Een stop-MA kan maar één geneesmiddel bevatten. Een stop-MA zonder referentie naar de vorige MA (en die is hier dus niet bekend) stopt de hele MBH.

Afspraak voor deze praktijksituatie is om in de stop-MA een ‘magistraal’ geneesmiddel te zetten met daarin twee ingrediënten: te weten middel XY en XZ uit de parallelle TA’s. Ook als de voorschrijver alleen één van de twee middelen wil stoppen of wijzigen is de afspraak om:

  • deze hele MBH op bovenstaande manier te stoppen en
  • een of meer nieuwe MBH’s te starten met de gewenste eindsituatie voor elk middel.

Hierbij hoort dan ook een nieuw verstrekkingsverzoek naar de apotheek. Bijeffect van deze afspraak is dat de apotheker stop-MA’s krijgt én een nieuw VV. De apotheker heeft echter wel inzicht in de voorraad/verstrekkingen van middelen XY en XZ en beschikt over de informatie om dit adequaat te kunnen behandelen. Voor medicatieveiligheid is dit de beste oplossing.

5.3.1.2 Migratie en ontdubbelen

Na migratie kan een vergelijkbare situatie ontstaan. Stel dat er vóór migratie een voorschrift is geweest met combinatiepreparaat X en de apotheker dit heeft gesplitst in middel XY en XZ. Het AIS dat migreert heeft twee mogelijkheden:

  1. het AIS heeft een relatie naar het oorspronkelijke voorschrift met bijbehorend PRK (van het combinatiepreparaat) of
  2. het AIS kent deze relatie niet (meer).

In het eerste geval migreert het AIS verstrekkingen naar TA’s in één generieke MBH. Volgens de afspraken gebruikt het AIS daarbij de PRK van het voorschrift (zie paragraaf Specifieke en generieke MBH-id). Zo ontstaan er 2 parallelle TA's in één generieke MBH. De MA krijgt, als deze nog niet historisch was bij migratie, een specifieke MBH van het EVS (zie paragraaf Specifieke en generieke MBH-id). Dan ontstaan er twee MBH’s die ontdubbeld kunnen worden op basis van de normale afspraken (zie paragraaf Ontdubbelen van MBH's). Een EVS kan de generieke MBH met de parallelle TA’s stoppen middels een stop-MA met magistraal product zoals hierboven beschreven. Een AIS kan de generieke MBH stoppen met stop-TA’s volgens de normale MP9-regels. Als de MA wel historisch was, is deze terecht gekomen in dezelfde generieke MBH als die van de TA’s en hoeft er niet ontdubbeld/gestopt te worden.

In het tweede geval maakt het AIS 2 generieke MBH’s met ieder 1 TA. De MA heeft een andere PRK en zal door het EVS in een andere, derde MBH gezet zijn. Dus na migratie ontstaan er 3 verschillende MBH’s die conceptueel eigenlijk één MBH hadden moeten zijn. Deze situatie moet door een zorgverlener herkend en ontdubbeld worden. Dat ontdubbelen kan volgens de normale afspraken bij migratie/hybride (zie paragraaf Ontdubbelen van MBH's).

5.3.1.3 Tot slot

Het is goed om ons te realiseren dat MP9 de telefoon niet helemaal kan vervangen. Soms zullen zorgverleners elkaar nog moeten bellen als dit soort complexe grensgevallen optreden.

5.3.2 Medicatie voorgeschreven in het buitenland en 'over the counter'-medicatie

Bij de migratie van medicatie voorgeschreven in het buitenland en ‘over the counter’-medicatie (zelfzorgmedicatie) is de werkwijze voor migratie afhankelijk van twee factoren:

  • Heeft het middel een PRK of HPK?
    • Indien het middel geen PRK of HPK heeft, is het niet mogelijk om een generieke MBH-id te genereren. Afspraak is dat voor deze middelen altijd een specifieke MBH-id wordt gegenereerd, ook als het historie betreft, en ook door het AIS, eTDR of PGO.
  • Is het geneesmiddel voorgeschreven of is de behandeling overgenomen door een voorschrijver?
    • Indien dit niet het geval is, kan volstaan worden met het vastleggen van MGB.
    • Wanneer de voorschrijver wel verantwoordelijk is voor de behandeling, is het wenselijk om er bij migratie een MA van te maken.

5.3.3 Magistralen

Sinds MP6.12.3 is het een vereiste om de ingrediënten van magistralen gestructureerd via ingrediëntcodes uit te wisselen. Dit blijkt echter onvoldoende toegepast in systemen. In plaats daarvan wordt de samenstelling van magistralen als vrije tekst uitgewisseld. Gemigreerde historische gegevens voldoen daarom mogelijk niet aan de eis van gestructureerde en gecodeerde vastlegging van de ingrediënten van magistralen. Voor gegevens die aangemaakt zijn in het verleden is deze eis in MP9 daarom versoepeld.

5.3.4 Experimentele medicatie

De actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-567.

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

6 Toedienlijsten

De uitwerking van de afspraken voor toedienlijsten in de hybride situatie vindt plaats in aanvullende sessies met eTDR-leveranciers. Op basis van deze sessies zullen de afspraken in dit hoofdstuk ingevuld worden.

7 Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id

Zoals aangegeven in het hoofdstuk Achtergrond is het van belang om duplicate MBH’s betrouwbaar te kunnen ontdubbelen. 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 MP6.12-verstrekkingen van belang. Onderstaande paragrafen bevatten nadere toelichting over deze systematiek.

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

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

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

7.2.1 Uitgangspunten

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

7.2.2 MP6.12: relatie leggen vanuit verstrekking naar MP6.12-voorschrift

Om goede relaties te kunnen leggen, moet de referentie van de verstrekking naar het voorschrift ook gevuld worden in de berichten. Ervaring uit de praktijk leert dat niet alle MP6.12-verstrekkingsberichten 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.

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

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

7.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 id's 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"/>

7.3 Impact voor de XIS-leveranciers

7.3.1 AIS

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

7.3.2 Alle systemen

Het overzicht van identificaties in paragraaf Samenhang van identificaties in EDIFACT, MP6.12 en MP9:

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

8 Bijlage: Early adopters van MP9

Er zijn op dit moment verschillende systemen die reeds via MP9 informatie uitwisselen (versie MP9.0.7). Deze ‘early adopters’ zijn vanuit verschillende trajecten aangesloten op bepaalde onderdelen van MP9. Dientengevolge passen sommige early adopters de MBH-id al wél en andere juist nog níét toe.

Early adopters MP9 met (mogelijk) MBH-id
De generieke MBH-id bestaat niet in MP9.0.7. Indien een early adopter van MP9 reeds medicatiebouwstenen met een MBH-id beschikbaar heeft gesteld, betreffen dit daarom altijd specifieke MBH-id’s. Deze medicatiebouwstenen kunnen daarmee gezien worden als ‘volwaardige’ MP9-informatie.

Dergelijke early adopters bestaan bij de informatiestandaard BgZ, het programma VIPP GGZ (VIPP 3), de informatiestandaard Ketenzorg en MedMij.

  • VIPP GGZ: Systemen gebruiken MBH-id’s. Gezien dit programma gericht was op EVS’en, worden geen problemen voorzien in de transitiefase naar MP9 2.0.0 (of latere release). Werkafspraken voor de transitieperiode zijn immers dat het EVS leidend is en eigen bouwstenen direct beschikbaarstelt.
  • BgZ: Zeer waarschijnlijk is er nog geen gebruik gemaakt van MBH-id’s.
  • Ketenzorg: Gezien de MBH-id geen eis is én ook geen onderdeel was van kwalificatie, zullen systemen zeer waarschijnlijk nog geen MBH-id’s ondersteunen.
  • MedMij
    • DVZA-BgZ: Gezien de MBH-id geen onderdeel was van kwalificatie, zullen systemen zeer waarschijnlijk nog geen MBH-id’s gegenereerd hebben.
    • DVZA-huisartsgegevens: Zeer waarschijnlijk geen MBH-id’s volgens MP9-systematiek.
    • DVZA-verstrekkingenvertalingen: In ‘verstrekkingenvertalingen’ wordt de MBH-id gevuld met de MP6.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 (of latere release), dus deze partijen kunnen beschouwd worden als early adopters van MP9, zonder MBH-id.


Early adopters MP9 zonder MBH-id
MP9-informatie zonder MBH-id kan 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 Bijlage: Afkortingen en definities

Afkortingen

  • AIS: apotheekinformatiesysteem
  • eTDR: elektronisch toedienregistratiesysteem
  • EVS: elektronisch voorschrijfsysteem
  • MA: medicatieafspraak
  • MBH: medicamenteuze behandeling
  • MGB: medicatiegebruik
  • MVE: medicatieverstrekking
  • PGO: persoonlijke gezondheidsomgeving
  • TA: toedieningsafspraak
  • VV: verstrekkingsverzoek

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.
  • Sturen en/of beschikbaar stellen: 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 dezelfde prescriptiecode (PRK) of, indien PRK niet bekend is, de handelsproductcode (HPK). De generieke MBH-id gebaseerd op PRK bestaat uit een algemene OID-root ‘generiekeMBHIdPRK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.2), en de PRK in de OID-extension. De generieke MBH-id gebaseerd op HPK bestaat uit een algemene OID-root ‘generiekeMBHIdHPK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.3), en de HPK in de OID-extension. Een generieke MBH-id is 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.
  • MP6.12-TA: Uit MP6.12-verstrekking geconverteerde gegevens in een MP9-TA formaat ("jasje").
  • 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. 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. Het EVS wijst aan alle actuele en recent gestopte MP9-bouwstenen een specifieke MBH-id toe bij migratie. Systemen anders dan het EVS maken in principe geen specifieke MBH-id’s aan, maar hanteren indien mogelijk ontvangen specifieke MBH-id’s vanuit het EVS.
  • Transformatiedienst: Bij het raadplegen van medicatiegegevens via MP9 via het Landelijk Schakelpunt (LSP) zal vanuit de infrastructuurleverancier een transformatiedienst aangeboden worden. Deze transformatiedienst zorgt voor conversie van MP6.12-verstrekkingen vanuit MP6.12-AIS'en naar een MP9-TA formaat. Dit betekent dat een MP9-systeem bij een MP9-query vanuit andere MP9-systemen de MP9-bouwstenen zal ontvangen, net zoals in de volledige MP9-situatie, en vanuit MP6.12-AIS'en de uit MP6.12-verstrekking geconverteerde gegevens (MP6.12-TA'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 MP6.12-verstrekking: Identificatie van het voorschrift waarop de MP6.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: MP6.12-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 MP6.12-verstrekkingen naar het voorschrift of vanuit MP9-bouwstenen naar de MP6.12-berichtenstroom.
  • ‘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).

10 Bijlage: Documenthistorie

Versie Datum Releasenotes
4 3 maart 2023 Versie t/m sessie 14 februari 2023 van werkstroom Migratie/hybride situatie
3 4 juli 2022 Versie t/m sessie 30 mei 2022 van werkstroom Migratie/hybride situatie
2 9 maart 2022 Versie t/m sessie 23 februari 2022 van werkstroom Migratie/hybride situatie, zie ook pdf
Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=mp:Vkickstart_MigratieHybride&oldid=185588"