mp:Vkickstart MigratieHybride: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(EVS, AIS en eTDR)
(Kaders)
 
(19 tussenliggende versies door 2 gebruikers niet weergegeven)
Regel 1: Regel 1:
{{DISPLAYTITLE:Migratie en hybride}}
+
{{DISPLAYTITLE: Implementatiehandleiding migratie en hybride V2.0}}
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
 
Deze pagina bevat de implementatiedocumentatie voor leveranciers omtrent migratie en de hybride situatie tijdens de [https://www.samenvoormedicatieoverdracht.nl/kickstart-medicatieoverdracht/ Kickstart Medicatieoverdracht].
 
Deze pagina bevat de implementatiedocumentatie voor leveranciers omtrent migratie en de hybride situatie tijdens de [https://www.samenvoormedicatieoverdracht.nl/kickstart-medicatieoverdracht/ Kickstart Medicatieoverdracht].
  
 
Voor een overzicht van relevante Wiki-pagina's voor Medicatieproces zie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Landingspagina Medicatieproces].
 
Voor een overzicht van relevante Wiki-pagina's voor Medicatieproces zie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Landingspagina Medicatieproces].
=Inleiding=
 
==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 [[#term_transitiefase|{{term|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 [[#term_hybride_situatie|{{term|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 [[#term_migreren|{{term|migreren}}]] (het omzetten van de reeds beschikbare medicatiegegevens in een patiëntdossier naar een datamodel dat ook MP9-bouwstenen ondersteunt),
 
*het [[#term_raadplegen|{{term|raadplegen}}]] (het proces van opvragen van beschikbare medicatiegegevens, uit zowel MP9- als MP6.12-systemen), en
 
*het [[#term_reconcilieren|{{term|reconciliëren}}]] (het samenbrengen en ontdubbelen van beschikbare gegevens met de ontvangen gegevens met als doel een overzichtelijk medicatiedossier op te bouwen).
 
 
==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|Toedienlijsten]]).''
+
=Leeswijzer=
 +
Om de implementatiehandleiding effectief te gebruiken, is het belangrijk om te begrijpen hoe de informatie is gestructureerd. De volgende leeswijzer biedt een overzicht van de hoofdstukken en bijlagen.  
  
==Leeswijzer==
 
 
'''Hoofdstukken'''<br>
 
'''Hoofdstukken'''<br>
*[[#Achtergrond|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.
+
*[[#Achtergrond|Hoofdstuk 3]] behandelt de verschillen tussen de transitiefase en de uiteindelijke situatie waarin alle systemen over zijn naar MP9. Er zijn aanvullende afspraken nodig om tijdens de transitiefase te komen tot een overzichtelijk medicatiedossier.
*[[#Migreren en beschikbaarstellen|Hoofdstuk 3]] en [[#Raadplegen/ontvangen en reconciliëren|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.
+
*[[#Migreren en beschikbaarstellen|Hoofdstuk 4]] en [[#Raadplegen/ontvangen, consolideren en reconciliëren|Hoofdstuk 5]] beschrijven de afspraken voor het migreren en het beschikbaarstellen van de gemigreerde medicatiegegevens, het raadplegen en ontvangen van medicatiegegevens en het consolideren en reconciliëren in de hybride situatie.
*[[#Aandachtspunten gedurende transitiefase|Hoofdstuk 5]] geeft een toelichting op de overige aandachtspunten gedurende de transitiefase (onder andere de doseerinstructies, doseerverlagingen en combinatiepreparaten).
+
*[[#Aandachtspunten gedurende transitiefase|Hoofdstuk 6]] geeft een toelichting op enkele overige aandachtspunten gedurende de transitiefase (onder andere de doseerinstructies, doseerverlagingen en combinatiepreparaten).
*[[#eTDR's|Hoofdstuk 6]] beschrijft de afspraken voor toedienlijsten in de hybride situatie.
+
*[[#Aandachtspunten toedieninformatie|Hoofdstuk 7]] beschrijft de aandachtspunten met betrekking tot toedieninformatie.  
  
 
'''Bijlagen'''<br>
 
'''Bijlagen'''<br>
*[[#Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id|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: Verrijken EDIFACT id en vullen MP6.12 prescription/id en MP6.12 vooraankondiging-id|Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id en MP6.12 vooraankondiging-id]] geeft instructies voor het verrijken van de EDIFACT id en het correct vullen van het veld prescription/id in de MP6.12-verstrekking. Daarnaast wordt het proces voor het vullen van MP6.12 vooraankondiging id toegelicht.  
*[[#Bijlage: Early adopters van MP9|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: Early adopters van MP9|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 'complete' MP9-informatie.
 
*[[#Bijlage: Afkortingen en definities|Bijlage: Afkortingen en definities]] bevat een lijst met definities van de termen die in de tekst [[#Definities|{{term|in deze layout}}]] staan.
 
*[[#Bijlage: Afkortingen en definities|Bijlage: Afkortingen en definities]] bevat een lijst met definities van de termen die in de tekst [[#Definities|{{term|in deze layout}}]] staan.
*[[#Bijlage: Documenthistorie|Bijlage: Documenthistorie]] geeft een overzicht van de wijzigingen in deze pagina.
+
*[[#Bijlage: Documenthistorie en beheerproces|Bijlage: Documenthistorie en beheerproces]] geeft een overzicht van de wijzigingen in deze pagina.
  
 
'''Wijzigingen en beheerproces'''<br>
 
'''Wijzigingen en beheerproces'''<br>
*Wijzigingen in de pagina verlopen via het beheerproces (BITS-issues). De wijzigingenhistorie van deze pagina en de releasenotes verwijzen naar deze BITS-issues, zie [[#Bijlage: Documenthistorie|Bijlage: Documenthistorie]]. De BITS-issues worden geregistreerd binnen het project Medicatieproces, onder epic MP-431 Hybride situatie, zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-431 filter Project = MP AND “Epic Link” = MP-431]. Elk van deze BITS-issues wordt gerelateerd aan [https://bits.nictiz.nl/browse/MP-431 epic MP-431 Hybride situatie].
+
*Wijzigingen in de pagina verlopen via het [https://nictiz.atlassian.net/servicedesk/customer/portal/4 serviceportaal van Nictiz] en volgen het beheerproces. De wijzigingenhistorie van deze pagina en de releasenotes verwijzen naar deze wijzigingsverzoeken, zie [[#Bijlage: Documenthistorie en beheerproces|Bijlage: Documenthistorie en beheerproces]].
  
 
'''Aandachtspunten gebruikersondersteuning'''<br>
 
'''Aandachtspunten gebruikersondersteuning'''<br>
*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 Aandachtspunten gebruikersondersteuning, zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 filter Project = MP AND "Epic Link" = MP-693]. Elk van deze de BITS-issues wordt gerelateerd aan epic [https://bits.nictiz.nl/browse/MP-693 MP-693 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, zie [[#Bijlage: Documenthistorie en beheerproces|Bijlage: Documenthistorie en beheerproces]].  
  
 
'''Verwijzingen'''<br>
 
'''Verwijzingen'''<br>
*BITS-issues in [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-431 epic MP-431 Hybride situatie]
+
*Wijzigingsverzoeken in [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-431 epic MP-431 Hybride situatie]
*BITS-issues in [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 epic MP-693 Aandachtspunten gebruikersondersteuning]
+
*Wijzigingsverzoeken in [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 epic MP-693 Aandachtspunten gebruikersondersteuning]
*Flowcharts [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie]
+
*Flowcharts [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie]. Deze flowcharts geven een globaal overzicht van de stappen en volgorde bij de verwerking van ontvangen informatie.
 
*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
 
*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
 +
 +
=Inleiding=
 +
Het implementatieprogramma Medicatieoverdracht zal de komende jaren de richtlijn ‘Overdracht van medicatiegegevens in de keten’ en de informatiestandaard Medicatieproces (MP9) zorgbreed implementeren. Dit proces begint met een beperkte implementatie tijdens de Kickstart Medicatieoverdracht, gevolgd door een brede uitrol. Om een goed begrip te krijgen van de context en uitdagingen van dit implementatieprogramma, starten we met een beschrijving van de migratie en hybride situatie.
 +
==Migratie en hybride situatie==
 +
Gezien niet alle systemen tegelijkertijd de informatiestandaard MP9 implementeren, is er sprake van een [[#term_transitiefase|{{term|transitiefase}}]]. Deze fase begint met de migratie van het eerste systeem en eindigt wanneer alle systemen zijn overgestapt naar MP9. Gedurende de transitiefase zullen systemen te maken hebben met een [[#term_hybride_situatie|{{term|hybride situatie}}]]: ze moeten zowel MP9 als eerdere berichtenstromen (onder andere MP6.12 en/of EDIFACT) ondersteunen.
 +
 +
<span id="Transitie en subprocessen.png" title="Transitie en subprocessen">[[Bestand:Transitie en subprocessen.png|miniatuur|geen|x200px|Figuur 1. De transitiefase en de bijbehorende sub-processen bij de implementatie van de informatiestandaard medicatieproces 9.]]</span>
 +
 +
Vanwege de verschillen tussen deze berichtenstromen zijn er specifieke afspraken nodig om een overzichtelijk medicatiedossier te kunnen creëren. In de werkstroom migratie & hybride heeft het programma Medicatieoverdracht samen met leveranciers en zorgverleners technische- en zorgprocesafspraken gemaakt. Deze afspraken, aanvullend op de informatiestandaard MP9, betreffen onder andere de transitie, de hybride situatie, het migratieproces, de co-existentie, het raadplegen van medicatiegegevens en het consolideren en reconciliëren ervan.
 +
*De [[#term_transitie|{{term|transitie}}]] (het proces van migreren en co-existentie dat uiteindelijk leidt tot de brede gegevensuitwisseling via MP9).
 +
 +
<span id="Transitie definitie.png" title="Transitie definitie">[[Bestand:Transitie definitie.png|miniatuur|geen|x225px|Figuur 2. Definitie van de transitie bij de implementatie van de informatiestandaard Medicatieproces 9.]]</span>
 +
 +
*De [[#term_hybride_situatie|{{term|hybride situatie}}]] (De situatie waarbij een systeem (tijdelijk) zowel MP9 als eerdere berichtenstromen MP6.12/EDIFACT ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen).
 +
 +
<span id="Hybride situatie definitie.png" title="Hybride situatie definitie">[[Bestand:Hybride situatie definitie.png|miniatuur|geen|x151px|Figuur 3. Definitie van de hybride situatie bij implementatie van de informatiestandaard Medicatieproces 9.]]</span>
 +
 +
*Het [[#term_migreren|{{term|migreren}}]] (het omzetten van de reeds beschikbare medicatiegegevens in een systeem naar een datamodel dat ook MP9-bouwstenen ondersteunt).
 +
 +
<span id="Migratie definitie.png" title="Migratie definitie">[[Bestand:Migratie definitie.png|miniatuur|geen|x104px|Figuur 4. Definitie van de migratie bij implementatie van de informatiestandaard Medicatieproces 9.]]</span>
 +
 +
*De [[#term_Co-existentie|{{term|co-existentie}}]] (De situatie waarin binnen de keten de noodzaak bestaat tot het uitwisselen van gegevens in meerdere standaarden).
 +
 +
<span id="Co-existentie definitie.png" title="Co-existentie definitie">[[Bestand:Co-existentie definitie.png|miniatuur|geen|x225px|Figuur 5. Definitie co-existentie bij de implementatie van de informatiestandaard Medicatieproces 9.]]</span>
 +
 +
*Het [[#term_Raadplegen|{{term|raadplegen}}]] (het proces van opvragen van beschikbare medicatiegegevens, uit zowel MP9- als MP6.12-systemen).
 +
*Het [[#term_Consolideren|{{term|consolideren <ref name = "definities consolideren en reconcilieren"> De definities voor de termen consolideren en reconciliëren zijn onder voorbehoud van een landelijke definitie</ref>}}]] (het proces waarbij het informatiesysteem beschikbare medicatiegegevens samenvoegt met ontvangen gegevens uit verschillende bronnen. Het doel is om een enkel, uniform en coherent medicatiedossier op te bouwen). 
 +
*Het [[#term_Reconciliëren|{{term|reconciliëren <ref name="definities consolideren en reconcilieren"/>}}]] (het met elkaar in overeenstemming brengen van beschikbare gegevens met de ontvangen gegevens. Dit omvat het vergelijken van gerelateerde informatie uit verschillende bronnen om eventuele discrepanties of tegenstrijdigheden te identificeren en op te lossen. Dit proces kan menselijke interventie of beoordeling vereisen om een overzichtelijk en accuraat medicatiedossier op te bouwen).
 +
 +
Met de complexiteit van de migratie- en hybride situatie in gedachten, is het cruciaal om duidelijke kaders te stellen voor leveranciers tijdens dit proces.
 +
 +
<references/>
 +
 +
==Kaders==
 +
Deze implementatiehandleiding bevat afspraken voor de leveranciers met betrekking tot migratie en de hybride situatie tijdens de Kickstart Medicatieoverdracht. In de Kickstart beproeft een beperkte groep zorgaanbieders de kwaliteitsstandaard 'Overdracht van medicatiegegevens in de keten' in samenhang met de informatiestandaard Medicatieproces 9. Doel is om eerst op kleine schaal te leren zodat degenen die volgen de implementatie zo efficiënt en vlot mogelijk kunnen doen. Bij aanvang van de Kickstart Medicatieoverdracht worden er procedures opgesteld voor het geval er nieuwe inzichten ontstaan tijdens deze testperiode. Eventuele wijziging aan deze pagina worden volgens deze procedures doorgevoerd.
 +
 +
''De huidige versie van deze pagina omvat de afspraken voor het elektronisch voorschrijfsysteem (EVS), apotheekinformatiesysteem (AIS), de persoonlijke gezondheidsomgeving (PGO), het elektronisch toedienregistratiesysteem (eTDR) en het tromboseregistratiesysteem (TRIS).''
 +
 +
Dit hoofdstuk heeft de basis gelegd voor het begrijpen van de migratie en hybride situatie tijdens de implementatie van MP9. Met duidelijke kaders en een overzicht van de belangrijkste aspecten, zijn leveranciers goed voorbereid om aan de slag te gaan met de volgende stappen in het proces. De komende hoofdstukken bieden gedetailleerde richtlijnen en specifieke afspraken die essentieel zijn voor een succesvolle overgang naar de nieuwe informatiestandaard.
  
 
=Achtergrond=
 
=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.
+
Tijdens de transitiefase, waarin systemen geleidelijk overgaan naar MP9, zijn er twee belangrijke verschillen ten opzichte van de uiteindelijke situatie waarin alle systemen MP9 gebruiken.
 +
*In de transitiefase is het niet altijd mogelijk om samenhangende medicatiegegevens via de MP9-systematiek bij elkaar te groeperen. Dit komt doordat het concept van een 'medicamenteuze behandeling' nieuw is in MP9 en niet voorkomt in eerdere standaarden zoals MP6.12 en EDIFACT.  
 +
*Niet alle medicatiegevens zijn tijdens de transitiefase raadpleegbaar als MP9-bouwstenen.  
 +
Dit hoofdstuk geeft een toelichting op deze verschillen en de noodzaak van aanvullende afspraken tijdens de transitiefase. Zo kan een overzichtelijk medicatiedossier behouden blijven.
 +
Met deze achtergrond in gedachten, richten we ons nu op een cruciaal nieuw begrip binnen MP9: de ‘medicamenteuze behandeling’.
 +
 
 +
==Nieuw begrip ‘medicamenteuze behandeling’==
 +
Het medicatieproces omvat het voorschrijven, ter hand stellen, toedienen en gebruiken van een geneesmiddel. De medicamenteuze behandeling (MBH) bundelt de verschillende medicatiebouwstenen die zo ontstaan. Alle medicatiebouwstenen moeten worden geïdentificeerd met een unieke code, de MBH-id. MP6.12- en EDIFACT-informatie bevat deze MBH-id niet. Wanneer systemen afzonderlijk migreren, genereren ze elk een eigen MBH-id, onafhankelijk van elkaar. 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, kunnen onbedoeld apart worden weergegeven in het medicatiedossier, wat verwarring kan veroorzaken over de dosering. Er zijn daarom afspraken nodig om deze risico’s te minimaliseren. Dit betreffen voornamelijk afspraken voor het toekennen van de MBH-id bij migratie (zie [[#Migreren en beschikbaarstellen|Migreren en beschikbaarstellen]]). Deze afspraken hebben tot doel om duplicate MBH's zoveel mogelijk te beperken. Echter, volledig voorkomen van duplicate MBH's is niet mogelijk. Deze pagina bevat ook instructies voor het relateren van samenhangende medicatiegegevens en het ontdubbelen van MBH’s (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]]).
 +
 
 +
Met de introductie van de medicamenteuze behandeling en de bijbehorende uitdagingen, is het essentieel om te begrijpen hoe medicatiegegevens tijdens de transitiefase worden uitgewisseld.
 +
 
 +
==Medicatiegegevens vanuit MP9 en andere berichtenstromen==
 +
In de transitiefase worden verschillende berichtenstromen gebruikt voor de uitwisseling van medicatiegevens.
 +
 
 +
===MP6.12/Edifact berichtenstromen===
 +
In de transitiefase zullen nog niet alle medicatiegegevens beschikbaar zijn als MP9-bouwstenen.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 XIS’en in de keten. Een gemigreerd MP9-systeem zal tijdens de transitiefase ook de eerdere berichtenstromen (MP6.12 en/of EDIFACT) moeten blijven ondersteunen. Een MP9-EVS moet bijvoorbeeld nog EDIFACT berichten ondersteunen en in staat zijn om een MP6.12 vooraankondiging te kunnen sturen.
 +
Een gemigreerd MP9-AIS moet de medicatiegegevens zowel via MP6.12 als MP9 beschikbaar stellen, zodat systemen die nog niet overgestapt zijn naar MP9 de verstrekkingsgegevens kunnen blijven raadplegen. Het uitgangspunt is dat MP9-systemen maar één query nodig hebben. De infrastructuurleverancier zorgt via een [[#term_transformatiedienst|{{term|transformatiedienst}}]] voor de conversie van MP6.12-verstrekkingen naar het formaat van MP9-TA’s (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]]).
 +
Hoewel de gegevens die zijn geconverteerd vanuit MP6.12 verstrekkingen (MP6.12-TA’s) raadpleegbaar zijn in MP9-TA formaat, moeten ze om verschillende redenen niet op dezelfde manier worden verwerkt als een MP9-TA vanuit een MP9-AIS. Daarom bevat deze pagina afspraken voor de verwerking van deze MP6.12-TA’s in MP9-systemen (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]]).
  
==Nieuw technisch begrip ‘medicamenteuze behandeling’==
+
''Gedetailleerde documentatie over de transformatiedienst (conversie van MP6.12-verstrekking naar MP9-TA formaat) vanuit het Landelijk Schakelpunt (LSP) zal beschikbaar worden gesteld via VZVZ, zie ook https://bits.nictiz.nl/browse/MP-572.''
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|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|Raadplegen/ontvangen en reconciliëren]]).
 
  
==Medicatiegegevens vanuit MP9- en MP6.12/EDIFACT-systemen==
+
Naast MP6.12 en Edifact zijn er nog andere berichtenstromen die tijdens de transitiefase een rol spelen.
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 [[#term_transformatiedienst|{{term|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 ([[#term_MP6.12-TA|{{term|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|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.''
+
===Overige berichtenstromen===
 +
Naast de MP6.12- en Edifact-berichtenstromen worden er in de praktijk ook andere berichtenstromen gebruikt voor de uitwisseling van medicatiegegevens. Dit omvat onder andere de uitwisseling van gegevens op niet digitale manieren, het gebruik van maatwerkkoppeling, en de uitwisseling via een eerdere versie van MP9 (versie MP9.0.7.). Deze berichtenstromen zullen niet allemaal uitgefaseerd worden bij de implementatie van MP9. Waar mogelijk zijn er afspraken gemaakt voor de hybride situatie. Het is daarnaast de verantwoordelijkheid van de leveranciers om de berichtenstromen die niet uitgefaseerd worden bij de implementatie van MP9 te blijven ondersteunen.
 +
 
 +
In deze transitiefase, waarin systemen overstappen naar MP9, is het cruciaal om duidelijke afspraken en richtlijnen te hebben om de consistentie en nauwkeurigheid van medicatiegegevens te waarborgen. Door de complexiteit van het combineren van verschillende berichtenstromen en het introduceren van nieuwe concepten zoals de medicamenteuze behandeling, is samenwerking en duidelijke communicatie tussen alle betrokken partijen essentieel. Dit zal niet alleen de kwaliteit van de gegevens verbeteren, maar ook de veiligheid van de patiëntenzorg verhogen. De beschreven afspraken en processen zijn daarom van groot belang voor een succesvolle implementatie van MP9.
  
 
=Migreren en beschikbaarstellen=
 
=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).
+
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 hangt onder andere af van de overeenkomsten en verschillen tussen het huidige datamodel van het systeem en het vereiste 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. Leverancier en zorgaanbieder (gebruikersgroep) kunnen hiernaast aanvullende (detail)afspraken maken.
  
 
==Beschikbaarstellen van gemigreerde medicatiegegevens==
 
==Beschikbaarstellen van gemigreerde medicatiegegevens==
 +
Dit hoofdstuk beschrijft de stappen van migratie tot implementatie van MP9 voor verschillende type informatiesystemen. Voor elk informatiesysteem worden de processtappen migreren, (actief) beschikbaar stellen, raadplegen, registreren, consolideren & reconciliëren en beschikbaarstellen uitgelegd.
 +
 +
===EVS en AIS===
 +
 +
Voor het EVS en AIS geldt dat na migratie de medicatiegegevens direct beschikbaargesteld mogen worden, inclusief de historische data.  [[#Stappen van migratie tot implementatie EVS en AIS.png|Figuur 6]] geeft een overzicht van de processtappen migreren, (actief) beschikbaarstellen, raadplegen en reconciliëren voor het EVS en AIS. Raadplegen en reconciliëren vinden plaats wanneer de zorgverlener interactie heeft met het patiëntdossier, zoals bij patiëntcontact of proactief reconciliëren van (deel)populaties.
  
===EVS, AIS en eTDR===
+
<span id="Stappen van migratie tot implementatie EVS en AIS.png" title="Stappen van migratie tot implementatie EVS en AIS">[[Bestand:Stappen van migratie tot implementatie EVS en AIS.png|miniatuur|geen|x150px|Figuur 6. Overzicht van de volgorde van de processtappen (migreren, (actief) beschikbaarstellen, raadplegen, consolideren&reconciliëren) voor EVS en AIS.]]</span>
  
Voor het EVS, AIS en eTDR geldt dat na migratie de medicatiegegevens direct beschikbaargesteld mogen worden. Ook historie wordt beschikbaargesteld. [[#Migratie_hybride_Processtappen.png|Figuur 1]] geeft een overzicht van de processtappen migreren, (actief) 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.
+
===eTDR===
 +
In de huidige situatie is een apotheek verantwoordelijk voor het verzorgen van de toedienlijst voor een patiënt. Dit is meestal de apotheek waar de patiënt doorgaans komt (WPDK). Als deze apotheek overstapt naar MP9, kan ook het eTDR voor die patiënt overgaan naar MP9. Omdat de apotheek waar de patiënt doorgaans komt de meeste toedieningsafspraken heeft voor die patiënt, zal het eTDR per apotheek en per patiënt overgaan naar MP9. Deze migratie omvat alle historische gegevens. Voordat medicatietoedieningen in MP9 geregistreerd kunnen worden, moet het systeem de medicatiegegevens uit de keten raadplegen. Deze gegevens worden na consolidatie de toedienlijst voor de patiënt. Er is afgesproken dat de toediener medicatiegegevens niet mag reconciliëren. Zodra medicatietoedieningen zijn geregistreerd in MP9, worden deze gegevens beschikbaar gesteld.
 +
Voor apotheken die nog niet zijn overgestapt naar MP9 blijft de huidige werkwijze voor het eTDR van kracht.
  
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|Medicatiegegevens vanuit MP9- en MP6.12/EDIFACT-systemen]] en [[#Raadplegen/ontvangen en reconciliëren|Raadplegen/ontvangen en reconciliëren]]).<br>
+
<span id="Stappen van migratie tot implementatie eTDR.png" title="StappenStappen van migratie tot implementatie eTDR">[[Bestand:Stappen van migratie tot implementatie eTDR.png|miniatuur|geen|x150px|Figuur 7. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren en (actief) beschikbaarstellen) voor eTDR.]]</span>
<br>
 
  
<span id="Migratie-hybride Processtappen.png" title="Migratie-hybride Processtappen EVS-AIS-eTDR">[[Bestand:Migratie-hybride Processtappen.png|miniatuur|geen|x150px|Figuur 1. Overzicht van de volgorde van de processtappen (migreren, Sturen en/of beschikbaar stellen, raadplegen, reconciliëren) voor EVS, AIS en eTDR.]]</span>
+
===TRIS===
 +
Bij een TRIS zal over het algemeen geen sprake zijn van migratie van gegevens. De medicatiegegevens die momenteel worden vastgelegd, zijn niet of nauwelijks te migreren naar MP9. Het TRIS zal per patiënt overgaan naar MP9. Bij deze overgang zullen de medicatiegegevens uit de keten worden geraadpleegd en geconsolideerd door het TRIS. Aangezien trombosediensten in zeer beperkte mate medicatie voorschrijven, zal reconciliatie waarschijnlijk niet nodig zijn. Als er een MA is ontvangen voor trombosemedicatie en er is een nieuw INR bekend, zal er nieuw wisselend doseerschema (WDS) worden gemaakt. Alleen het nieuwe WDS zal beschikbaar worden gesteld; lopende schema’s en historische schema’s zullen niet beschikbaar worden gesteld.
 +
 
 +
<span id="Stappen van migratie tot implementatie TRIS.png" title="Stappen van migratie tot implementatie TRIS">[[Bestand:Stappen van migratie tot implementatie TRIS.png|miniatuur|geen|x150px|Figuur 8. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren, (actief) beschikbaarstellen) voor TRIS.]]</span>
  
 
===PGO===
 
===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. [[#Migratie_hybride_Processtappen PGO.png|Figuur 2]] geeft een overzicht van de processtappen migreren, sturen en/of beschikbaar stellen, raadplegen en reconciliëren voor PGO's.<br>
+
PGO's zijn bron van medicatiegebruik (MGB) die de gebruiker registreert. Voor PGO’s geldt dat zij na migratie ook historisch medicatiegebruik beschikbaarstellen<ref>Tijdens de Kickstart Medicatieoverdracht stellen PGO’s nog geen MGB beschikbaar.</ref> , maar pas nadat de patiënt de medicatiegegevens heeft geraadpleegd in de PGO en eventueel ook nieuw medicatiegebruik heeft geregistreerd.
<br>
 
  
<span id="Migratie-hybride Processtappen PGO.png" title="Migratie-hybride Processtappen PGO">[[Bestand:Migratie-hybride Processtappen PGO.png|miniatuur|geen|x150px|Figuur 2. Overzicht van de volgorde van de processtappen (migreren, Sturen en/of beschikbaar stellen, raadplegen, reconciliëren) voor PGO.]]</span>
+
<span id="Stappen van migratie tot implementatie PGO.png" title="Stappen van migratie tot implementatie PGO">[[Bestand:Stappen van migratie tot implementatie PGO.png|miniatuur|geen|x150px|Figuur 9. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren, (actief) beschikbaarstellen) voor PGO.]]</span>
  
''Tijdens de Kickstart Medicatieoverdracht stellen PGO’s nog geen MGB beschikbaar.''
+
Na het beschrijven van de specifieke stappen van migratie tot implementatie in verschillende informatiesystemen, richten we ons nu op algemene migratieafspraken die van toepassing zijn op alle informatiesystemen.
<br>
+
<references/>
  
 
==Algemene migratieafspraken==
 
==Algemene migratieafspraken==
 
===Onderscheid tussen eigen en andermans medicatiegegevens===
 
===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.
+
Bij migratie is het essentieel dat systemen onderscheid maken tussen ‘eigen’ en ‘andermans’ medicatiegegevens. Het systeem fungeert als bron van ‘eigen’ gegevens, terwijl andere systemen bron zijn van ‘andermans’ gegevens. Het uitwisselen van medicatiegegevens vindt onder andere plaats via de transactie voor het raadplegen/beschikbaarstellen (of sturen/ontvangen) van medicatiegegevens. Deze transactie verbiedt het beschikbaarstellen van informatie van anderen. EVS’en, zoals huisarts- en ziekenhuisinformatiesystemen (HIS’en en ZIS’en), moeten, indien mogelijk, achterhalen of het gaat om interne of externe voorschriften. Bijvoorbeeld: als het HIS een verstrekkingsverzoek (VV) heeft uitgestuurd, zal het een eigen voorschrift betreffen. Deze benadering geldt ook voor andere type systemen. Deze afspraak is van belang om te voorkomen dat er onnodig dubbele medicatiebouwstenen worden uitgewisseld wanneer er meerdere systemen betrokken zijn bij een patiënt.
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.
 
  
 
===Einddatum in medicatiegegevens===
 
===Einddatum in medicatiegegevens===
Bij migratie naar MP9 moet, indien bekend, een einddatum (stopdatum) gebruik vastgelegd worden.<br>
+
Bij migratie naar MP9 moet, indien bekend, een einddatum voor gebruik worden vastgelegd.<br>
  
* '''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.<br>
+
* '''MA''': Wanneer de lokale database de einddatum van het voorschrift bevat, wordt bij migratie de einddatum in de MA ingevuld. Als 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, als de lokale database een einddatum van het voorschrift bevat. Het toevoegen van een einddatum in MA’s bij migratie zorgt ervoor dat er bij betrokkenheid van meerdere EVS’en bij een patiënt tijdelijk sprake kan zijn van eventuele dubbelingen in MA’s en daarmee dubbelingen in MBH’s. Als er helemaal geen einddatum bekend is in het systeem, blijft de einddatum van de MA open.<br>
* '''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|Toedienlijsten]]).
+
* '''TA''': De einddatum van TA’s kan gebaseerd worden op:
 +
**therapeutische informatie uit de lokale database. Bijvoorbeeld afkomstig uit het medicatieprofiel of de distributieregels;
 +
**logistieke informatie. Bijvoorbeeld de 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. Het kan zijn dat de gebruiksperiode van langdurige medicatie mogelijk niet overeenkomt met de therapeutische gebruiksperiode. De einddatum uit de verstrekking kan mogelijk eerder zijn dan het einde van de voorraad. Echter, afspraken over het toevoegen 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 minder vaak  handmatige afsluiting van TA’s nodig is. Een einddatum in een TA die niet overeenkomt met de werkelijke therapeutische einddatum brengt vooral risico’s met zich mee voor de toedienlijsten.
  
 
===Samenhang van identificaties in EDIFACT, MP6.12 en MP9===
 
===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. [[#tabel1|Tabel 1]] geeft een overzicht van de verschillende identificaties in EDIFACT, MP6.12 en MP9 en hun onderlinge relaties.<br>
+
Tijdens de transitie, waarin systemen onafhankelijk van elkaar migreren, kan het voorkomen dat medicatiegegevens die conceptueel in dezelfde MBH zouden moeten staan, niet dezelfde MBH-id hebben. Desondanks kunnen systemen, indien verstrekkingen verwijzen naar voorschriftgegevens, deze medicatiegegevens toch aan elkaar relateren. Op basis van deze relaties kunnen dubbele MBH's vervolgens worden geïdentificeerd en samengevoegd. Het behouden van bekende identificaties in MP6.12- en/of EDIFACT-berichten tijdens migratie is daarom cruciaal. [[#tabel1|Tabel 1]] biedt een overzicht van de verschillende identificaties in EDIFACT, MP6.12 en MP9, en hun onderlinge relaties. Bovendien is er een pagina beschikbaar met voorbeelden die de informatie in de tabel verduidelijken.<br>
 +
[[mp:Vdraft_kickstart_MigratieHybride/Identificaties en hun onderlinge relaties|Identificaties en hun onderlinge relaties]]
  
 
{{anchor|tabel1}}
 
{{anchor|tabel1}}
Regel 103: Regel 158:
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;" rowspan=4|-  
 
| style="background-color: white;vertical-align:top;" rowspan=4|-  
| style="background-color: white;vertical-align:top;" rowspan=4|MP6.12-vooraankondiging id
+
| style="background-color: white;vertical-align:top;" rowspan=4|MP6.12-vooraankondiging-id <br>(na overgang naar MP9 de id opbouwen met MA-id en VV-id*)
 
| style="background-color: white;vertical-align:top;"|MA/relatieMA<br>(vullen met id van meest recente MP6.12-vooraankondiging<ref>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.</ref>)
 
| style="background-color: white;vertical-align:top;"|MA/relatieMA<br>(vullen met id van meest recente MP6.12-vooraankondiging<ref>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.</ref>)
 
|-
 
|-
| style="background-color: white;vertical-align:top;"|VV id
+
| style="background-color: white;vertical-align:top;"|VV-id
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;"|TA/relatieMA
 
| style="background-color: white;vertical-align:top;"|TA/relatieMA
Regel 112: Regel 167:
 
| style="background-color: white;vertical-align:top;"|MVE/relatieVV
 
| style="background-color: white;vertical-align:top;"|MVE/relatieVV
 
|-
 
|-
| style="background-color: white;vertical-align:top;" rowspan=4|Verrijkt EDIFACT id
+
| style="background-color: white;vertical-align:top;" rowspan=4|Verrijkt EDIFACT-id
| style="background-color: white;vertical-align:top;" rowspan=4|MP6.12-verstrekking/prescription/id<br>(gevuld met MP6.12-vooraankondiging id óf verrijkt EDIFACT id)
+
| style="background-color: white;vertical-align:top;" rowspan=4|MP6.12-verstrekking/prescription/id<br>(gevuld met MP6.12-vooraankondiging-id óf verrijkt EDIFACT-id)
 
| style="background-color: white;vertical-align:top;"|MA/relatieMA
 
| style="background-color: white;vertical-align:top;"|MA/relatieMA
 
|-
 
|-
| style="background-color: white;vertical-align:top;"|VV id
+
| style="background-color: white;vertical-align:top;"|VV-id
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;"|TA/relatieMA
 
| style="background-color: white;vertical-align:top;"|TA/relatieMA
Regel 123: Regel 178:
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;" rowspan=6|-
 
| style="background-color: white;vertical-align:top;" rowspan=6|-
| style="background-color: white;vertical-align:top;" rowspan=3|MP6.12-verstrekking id
+
| style="background-color: white;vertical-align:top;" rowspan=3|MP6.12-verstrekking-id
| style="background-color: white;vertical-align:top;"|In TA na conversie van MP6.12-verstrekking:<br>TA id (gevuld met MP6.12-verstrekking id, @root prefixen met vaste root oid<ref>Zie https://bits.nictiz.nl/browse/MP-572</ref>)
+
| style="background-color: white;vertical-align:top;"|In TA na conversie van MP6.12-verstrekking:<br>TA-id (gevuld met MP6.12-verstrekking id, @root prefixen met vaste root oid<ref>Zie https://bits.nictiz.nl/browse/MP-572</ref>)
 
|-
 
|-
| style="background-color: white;vertical-align:top;"|MVE id
+
| style="background-color: white;vertical-align:top;"|MVE-id
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;"|MGB/relatieMVE (medicatieverificatie)
 
| style="background-color: white;vertical-align:top;"|MGB/relatieMVE (medicatieverificatie)
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;"|Bij beschikbaarstellen MP6.12-verstrekkingen na MP9-voorschrift:<br>MP6.12-verstrekking/prescription/id
 
| style="background-color: white;vertical-align:top;"|Bij beschikbaarstellen MP6.12-verstrekkingen na MP9-voorschrift:<br>MP6.12-verstrekking/prescription/id
| style="background-color: white;vertical-align:top;"|MA id
+
| style="background-color: white;vertical-align:top;"|MA-id
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;" rowspan=2| -
 
| style="background-color: white;vertical-align:top;" rowspan=2| -
| style="background-color: white;vertical-align:top;"|TA id
+
| style="background-color: white;vertical-align:top;"|TA-id
 
|-
 
|-
| style="background-color: white;vertical-align:top;"|MBH id
+
| style="background-color: white;vertical-align:top;"|MBH-id
 
|}
 
|}
 +
 +
Met een duidelijk begrip van de algemene migratieafspraken, gaan we nu dieper in op de specifieke aspecten van MBH-identificaties en hun toepassing tijdens de transitiefase, zoals beschreven in de volgende paragraaf.
 +
 
<references/>
 
<references/>
  
==Specifieke vs. generieke MBH-id==
+
==Specifieke en generieke MBH-id==
Gedurende de transitiefase werken we niet alleen met de [[#term_specifieke_MBH|{{term|specifieke MBH-id}}]] zoals gedefinieerd in de informatiestandaard MP9, maar ook met een [[#term_generieke_MBH|{{term|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).<br>
+
Tijdens de transitiefase maken we niet alleen gebruik van de [[#term_specifieke_MBH|{{term|specifieke MBH-id}}]] zoals gedefinieerd in de informatiestandaard MP9, maar ook van een [[#term_generieke_MBH|{{term|generieke MBH-id}}]]. Het doel van de generieke MBH-id is om het probleem van meerdere MBH-id’s voor conceptueel dezelfde MBH te minimaliseren. 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). De generieke MBH-id is uniek voor één patiënt, maar niet uniek over verschillende patiënten.
 +
 
 +
De generieke MBH-id stelt systemen in staat om onafhankelijk van elkaar te migreren, terwijl medicatiebouwstenen toch bij elkaar worden gegroepeerd. Echter, de generieke MBH-id heeft beperkingen. Zo kunnen er bijvoorbeeld onterechte groeperingen van medicatiebouwstenen ontstaan met dezelfde MBH-id die in werkelijkheid onder verschillende MBH’s vallen. Bovendien is er een wens om de MBH niet op PRK te baseren, maar op werkzame stof. Daarom wordt de generieke MBH-id alleen in bepaalde situaties in de transitiefase toegepast (zie [[#Actuele en recent gestopte versus historische medicatie|Actuele en recent gestopte versus historische medicatie]] en [[#EVS versus andere systemen (AIS, eTDR,TRIS en PGO)|EVS versus andere systemen (AIS, eTDR,TRIS en PGO)]]). Het streven 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 beschreven in de informatiestandaard MP9 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, terwijl de extensie een unieke string binnen dit identificatiesysteem bevat.
 +
* '''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. Indien bekend, wordt 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. In dat geval moet de leverancier een generieke MBH-id  genereren op basis van de 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 [[#eActuele en recent gestopte vs. historische medicatie|Actuele en recent gestopte vs. historische medicatie]] en [[#EVS vs. andere systemen (AIS, eTDR, PGO)|EVS vs. andere systemen (AIS, eTDR, PGO)]]). De intentie is om de generieke MBH-id zo snel mogelijk naar de historie te verdrijven.<br>
+
===Actuele en recent gestopte versus historische medicatie===
 +
De informatiestandaard MP9 maakt onderscheid tussen actuele, recent gestopte en historische  medicatie; dit onderscheid is van belang bij migratie. [[#term_actuele_medicatie|{{term|Actuele medicatie}}]] betreft medicatie waarvan de stopdatum (op het moment van migratie) nog niet is verstreken. Dit omvat zowel huidige medicatie (waarbij het heden tussen de start- en stopdatum ligt) als toekomstige medicatie (waarbij het heden voor de startdatum ligt). [[#term_recent_gestopt|{{term|Recent gestopte medicatie}}]] omvat medicatie die in de afgelopen twee maanden is gestopt. [[#term_historie|{{term|Historie van medicatie}}]] is medicatie met een stopdatum die meer dan twee maanden in het verleden ligt.
 +
In de transitiefase wordt historische medicatie per PRK (of HPK) gebundeld in een generieke MBH-id. Hierdoor wordt een verschil gecreëerd in de migratie van actuele en recent gestopte medicatie versus historische informatie. Dit helpt het probleem van meerdere MBH-id’s voor bouwstenen die eigenlijk bij elkaar horen te beperken. 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-richtlijnen. Dit gebeurt niet bij historische informatie, tenzij daar een directe aanleiding voor is. Dit zorgt ervoor dat zorgverleners niet onnodig worden belast met reconciliatietaken (administratieve lasten) voor historische medicatie die vandaag de dag niet meer relevant is.
  
* '''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.<br>
+
===EVS versus andere systemen (AIS, eTDR,TRIS en PGO)===
* '''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.<br>
+
EVS’en hebben een andere rol dan AIS'en, eTDR's, TRIS’en en PGO's. Dit komt doordat MA’s leidend zijn in een MBH. Daarom gelden er andere afspraken voor EVS’en bij het toekennen van MBH-ids. Systemen anders dan EVS’en genereren in principe géén specifieke MBH-id, tenzij dit onvermijdelijk is, bijvoorbeeld wanneer er geen HPK of PRK beschikbaar is (zie [[#Bijzondere situaties|Bijzondere situaties]]). Hieronder staan de afspraken voor het toekennen van een specifieke versus generieke MBH-id puntsgewijs opgesomd per type systeem. [[#tabel2|Tabel 2]] toont een overzicht van de situaties waarin systemen een specifieke of generieke MBH-id moeten  toekennen.
* '''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.<br>
 
  
===Actuele en recent gestopte vs. historische medicatie===
+
'''EVS:'''
De informatiestandaard MP9 maakt onderscheid tussen actuele, recent gestopte en historie van medicatie. Bij migratie is dit onderscheid tevens van belang. [[#term_actuele_medicatie|{{term|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. [[#term_recent_gestopt|{{term|Recent gestopte medicatie}}]] omvat medicatie die in de afgelopen twee maanden is gestopt.
+
*Bij migratie kent het EVS voor actuele en recent gestopte medicatie een specifieke MBH-id toe.
[[#term_historie|{{term|Historie van medicatie}}]] is medicatie met een stopdatum die meer dan twee maanden in het verleden ligt.
+
*Om ervoor te zorgen dat de generieke MBH-id in de historie verdwijnt, voegt het EVS nieuw aangemaakte MP9-bouwstenen niet toe aan een generieke MBH. In plaats daarvan start het EVS een nieuwe specifieke MBH.
  
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.<br>
+
'''AIS:'''
 +
*In de transitiefase kent het AIS generieke MBH-id’s toe.
 +
*Het AIS creëert in principe alleen medicatiebouwstenen met een specifieke MBH-id wanneer deze vanuit een ander XIS zijn ontvangen.  
  
===EVS vs. andere systemen (AIS, eTDR, PGO)===
+
'''eTDR:'''
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|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 [[#tabel2|Tabel 2]].
+
*Er wordt bij migratie van een systeem onderscheid gemaakt tussen een los eTDR en een eTDR dat geïntegreerd is met een EVS.
 +
*'''Los eTDR:'''
 +
**Bij migratie kent het eTDR een generieke MBH-id toe.
 +
*'''Geïntegreerd eTDR en EVS:'''
 +
**Bij migratie volgen de medicatietoedieningen de MBH-id van de bijbehorende MA.
 +
**Dit betekent dat medicatietoedieningen die bij historische MA’s horen een generieke MBH-id krijgen en medicatietoedieningen die bij recent gestopte en actuele MA’s horen een specifieke MBH-id krijgen.
 +
*'''Hybride situatie:'''
 +
**Medicatietoedieningen  volgen de MBH-id van de bijbehorende MP9-bouwsteen (MA, TA of WDS).
 +
**Indien het eTDR geen MBH-id kan achterhalen, kent het een specifieke MBH-id toe. Dit geldt bijvoorbeeld voor ongeplande toedieningen in de spoedsituatie of medicatietoedieningen gebaseerd op niet-digitale toedieninformatie.
  
* '''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.
+
'''TRIS:'''
* '''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.
+
*Bij een TRIS zal over het algemeen geen sprake zijn van een migratie van gegevens.
* '''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.
+
*Een TRIS volgt altijd het specifieke MBH-id van de MA waarop het WDS is gebaseerd.
* '''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.
+
*Als er (nog) geen MA bekend is voor trombosemedicatie, zal het TRIS geen WDS beschikbaar stellen.
* '''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.<br>
+
 
 +
'''PGO:'''
 +
*Bij migratie kent een PGO een generieke MBH-id toe voor reeds geregistreerde MGB’s.
 +
*In de transitiefase wijst de PGO bij het starten van een MBH een generieke MBH-id toe.
 +
*De PGO creëert alleen MGB met een specifieke MBH-id wanneer deze vanuit het EVS/AIS zijn ontvangen.
 +
 
 +
'''Meerdere systeemrollen'''
 +
*Sommige systemen vervullen meerdere rollen, zoals EVS en AIS of EVS en eTDR. Dit geldt voor ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken.
 +
*Sommige systemen vervullen meerdere rollen, zoals EVS en AIS of EVS en eTDR. Dit geldt voor ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken.  
 +
*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 met een specifieke MBH-id, kan de te migreren bouwsteen (TA of MTD) direct aan de juiste specifieke MBH-id worden gekoppeld.
  
 
{{anchor|tabel2}}
 
{{anchor|tabel2}}
Regel 176: Regel 262:
 
|-
 
|-
 
! style="text-align:left;"|Migreren van actuele en recent gestopte medicatie
 
! style="text-align:left;"|Migreren van actuele en recent gestopte medicatie
| style="background-color: white;vertical-align:top;"|Specifiek||Generiek||Generiek||Generiek||Specifiek of generiek
+
| style="background-color: white;vertical-align:top;"|Specifiek||Generiek||Specifiek of Generiek<ref>Afhankelijk of het systeem alleen de rol van eTDR heeft of ook de rol van EVS.</ref>||Generiek||Specifiek of generiek
 
|-
 
|-
 
! style="text-align:left;"|Migreren van historische medicatie
 
! style="text-align:left;"|Migreren van historische medicatie
Regel 182: Regel 268:
 
|-
 
|-
 
! style="text-align:left;"|Starten van nieuwe MBH
 
! style="text-align:left;"|Starten van nieuwe MBH
| style="background-color: white;vertical-align:top;"|Specifiek||Generiek||Specifiek of generiek<ref>Indien eTDR zeker weet dat EVS MP9 doet: specifieke MBH-id, anders: generieke MBH-id.</ref>||Generiek||Specifiek of generiek
+
| style="background-color: white;vertical-align:top;"|Specifiek||Generiek||Specifiek of generiek<ref>Afhankelijk of de medicatietoediening gebaseerd is op een MP9 bouwsteen en welke MBH-id de medicatiebouwsteen heeft.</ref>||Generiek||Specifiek of generiek
 
|-
 
|-
 
|}
 
|}
 
<references/>
 
<references/>
  
=Raadplegen/ontvangen en reconciliëren=
+
De implementatie van MP9 vereist een gestructureerde aanpak voor migratie tot beschikbaarstelling van medicatiegegevens binnen diverse informatiesystemen. Door de specifieke stappen en afspraken in dit hoofdstuk te volgen, kunnen leveranciers en zorgaanbieders binnen de keten op een veilige manier de informatiestandaard MP9 implementeren. Het nauwkeurig hanteren van migratieprocessen en het correct toekennen van MBH-ids dragen bij aan een efficiënte overgang en zorgen ervoor dat medicatiegegevens betrouwbaar beschikbaar zijn voor zorgverleners en patiënten.
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.<br>
 
  
''De aandachtspunten ten aanzien van gebruikersondersteuning staan verzameld in BITS (zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 filter Project = MP AND "Epic Link" = MP-693]).''
+
=Raadplegen/ontvangen, consolideren en reconciliëren=
 +
In de transitiefase kan een MP9-systeem bij het raadplegen van de medicatiegegevens informatie ontvangen van zowel andere MP9-systemen als van MP6.12/EDIFACT-systemen. Het kan ook voorkomen dat na het raadplegen blijkt dat MP9-medicatiegegevens nog niet correct zijn geplaatst in de juiste MBH. Dit resulteert in dubbele MBH’s die uiteindelijk moeten worden samengevoegd. Dit hoofdstuk beschrijft de systematiek voor de verwerking van medicatiegegevens in EVS’en, AIS’en, eTDR’s, TRIS’en en PGO’s in de hybride situatie. Deze systematiek is ontworpen  om te zorgen voor een overzichtelijk medicatiedossier tijdens de transitiefase. Het reconciliëren naar een overzichtelijk medicatiedossier vereist ondersteuning vanuit de systemen aan de gebruiker. Dit hoofdstuk benadrukt deze aspecten. Het is aan de leverancier en zorgaanbieder (gebruikersgroep) om de juiste gebruikersondersteuning verder af te stemmen.
  
''De te volgen processen bij raadplegen en reconciliëren in de hybride situatie zijn in de vorm van flowcharts uitgewerkt (zie [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie]].
+
''De aandachtspunten met betrekking tot gebruikersondersteuning zijn verzameld in BITS (zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 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 [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie]]].''
 +
 
 +
Na de initiële raadpleging van medicatiegegevens door een MP9-systeem, volgt het cruciale proces van verwerken en matchen. Dit omvat het ontvangen van informatie in zowel MP9 als MP6.12 en Edifact formaat. Hierbij trachten systemen samenhangende medicatiegegevens te identificeren.
  
 
==Verwerken en matchen van medicatiegegevens==
 
==Verwerken en matchen van medicatiegegevens==
 
===Medicatiegegevens raadplegen===
 
===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 [[#term_transformatiedienst|{{term|transformatiedienst}}]] van de infrastructuurleverancier. De medicatiegegevens uit MP9-systemen kunnen een specifieke of generieke MBH-id bevatten (zie [[#Specifieke vs. generieke MBH-id|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.
+
Via de transactie 'raadplegen medicatiegegevens' kan een MP9-systeem in de transitiefase medicatiegegevens ontvangen vanuit zowel MP9-systemen als vanuit MP6.12-AIS'en, via de [[#term_transformatiedienst|{{term|transformatiedienst}}]] van de infrastructuurleverancier. In dit proces negeren eTDR-systemen de vertaalde MP6.12 verstrekkingen voor de toedienlijst (zie voor meer informatie [[#Aandachtspunten toedieninformatie|Hoofdstuk 7 Aandachtspunten teodieninformatie]]). De medicatiegegevens afkomstig uit MP9-systemen kunnen zowel een specifieke als generieke MBH-id bevatten, zoals beschreven in het gedeelte over ‘[[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]]. Het is echter belangrijk om op te merken dat medicatievoorschriften van MP6.12/EDIFACT-EVS'en, in tegenstelling tot die van MP9-EVS'en, niet zichtbaar zijn voor andere XIS’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 [[#tabel1|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.
+
Wanneer mogelijk relateren systemen samenhangende medicatiebouwstenen aan elkaar op basis van een match in identificatie, zoals het MP6.12-vooraankondiging id of ‘verrijkt’ EDIFACT-id (zie [[#tabel1|Tabel 1]]). Als deze match niet mogelijk is, zoekt het systeem een match op basis van PRK. Een match op basis van PRK is minder betrouwbaar dan een match op basis van een match in identificatie. Daarnaast kan het voorkomen dat er geen match gevonden wordt. In die gevallen is tussenkomst van de gebruiker nodig om de informatie te reconciliëren. Het reconciliatieproces mag echter alleen worden uitgevoerd door een voorschrijver of apotheker. Tussenkomst van een zorgverlener heeft uiteraard niet de voorkeur. Systemen bieden waar mogelijk en waar van toepassing gebruikersondersteuning zodat administratieve lasten tot een minimum beperkt kunnen worden.
 +
Het is belangrijk dat medicatiegegevens voor risicopatiënten en toedienpatiënten snel worden gereconcilieerd. In de ambulante setting wordt apotheken dan ook ten zeerste aangeraden om de signaalfunctie van de infrastructuurleverancier te gebruiken, zodat zij worden geïnformeerd wanneer er nieuwe gegevens van een patiënt beschikbaar zijn. Hiermee hebben zij een trigger om de medicatiegegevens voor deze patiënt te reconciliëren. Indien gewenst kan deze signaalfunctie specifiek worden ingesteld om signalen te ontvangen van wijzigingen in het WDS.
  
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|Einddatum in medicatiegegevens]]) of bevat complexe doseerinstructies in vrije tekst (zie [[#Doseerinstructies|Doseerinstructies]]).
+
Het EVS en AIS informeren de gebruiker over de herkomst van ontvangen AIS-informatie. Dit kan een conversie betreffen vanuit de infrastructuurleverancier (MP6.12-TA), een MP9-TA met generieke MBH-id, of een MP9-TA met specifieke MBH-id. De acties die een gebruiker kan ondernemen op basis van een MP6.12-TA versus een MP9-TA verschillen. Aanpassingen op een MP6.12-TA kunnen niet worden doorgegeven aan MP6.12-systemen via MP9-berichten. Daarnaast is het onderscheid tussen een TA met generieke MBH-id en specifieke MBH-id belangrijk voor de gebruiker. Een (actuele of recent gestopte) TA met generieke MBH-id staat nog niet gegroepeerd in dezelfde MBH als de bijbehorende MA. Daarnaast bevat een TA met generieke MBH-id, gegenereerd bij migratie, mogelijk nog niet alle aspecten van volledige MP9-informatie. Bijvoorbeeld: de TA kan een logistieke einddatum bevatten die niet overeenkomt met de werkelijke therapeutische einddatum (zie [[#Einddatum in medicatiegegevens|Einddatum in medicatiegegevens]]), of complexe doseerinstructies in vrije tekst (zie [[#Doseerinstructies|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|Bijlage: Early adopters van MP9]]). Afspraak voor de transitiefase is dat PGO’s de medicatiegegevens uit verschillende bronnen geïntegreerd tonen.
+
PGO’s kunnen tijdens de transitiefase dezelfde informatie via verschillende routes opvragen. Daarom is het belangrijk dat PGO’s prioriteit geven aan het type gegevens dat binnenkomt vanuit de verschillende systemen. Als er informatie beschikbaar is uit een MP9-versie nieuwer dan MP9.0.7, dan moet die informatie als leidend worden beschouwd. Als deze informatie niet beschikbaar is, wordt gekeken naar MP9.0.7-informatie met een MBH-id, en als laatste alternatief kan gebruik worden gemaakt van MP9.0.7-informatie zonder MBH-id of MP6.12-informatie (zie [[#Bijlage: Early adopters van MP9|Bijlage: Early adopters van MP9]]). Afspraak is dat PGO’s tijdens de transitiefase de medicatiegegevens uit verschillende bronnen geïntegreerd tonen.
  
 
===Voorschrift ontvangen en identificaties===
 
===Voorschrift ontvangen en identificaties===
Gedurende de transitiefase kan een MP9-AIS medicatievoorschriften ontvangen in MP9, maar ook in EDIFACT en/of MP6.12. [[#tabel3|Tabel 3]] geeft weer hoe de relaties naar deze voorschriften gelegd moeten worden.
+
Tijdens de transitiefase kan een MP9-AIS medicatievoorschriften ontvangen, zowel in MP9 als in EDIFACT en/of MP6.12. [[#tabel3|Tabel 3]] geeft weer hoe de relaties naar deze voorschriften gelegd moeten worden.
  
{{anchor|tabel4}}
+
{{anchor|tabel3}}
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
 
|+ Tabel 3. Identificaties en hun onderlinge relaties voor ieder formaat van voorschrift en antwoord bericht
 
|+ Tabel 3. Identificaties en hun onderlinge relaties voor ieder formaat van voorschrift en antwoord bericht
Regel 214: Regel 304:
 
! style="text-align: left;"|
 
! style="text-align: left;"|
 
! style="text-align: left;"|MEDREC-AFL  
 
! style="text-align: left;"|MEDREC-AFL  
! style="text-align: left;"|MP6.12-verstrekking/prescription id
+
! style="text-align: left;"|MP6.12-verstrekking/prescription-id
 
! style="text-align: left;"|MP9-TA/relatieMA
 
! style="text-align: left;"|MP9-TA/relatieMA
 
! style="text-align: left;"|MP9-MVE/relatieVV
 
! style="text-align: left;"|MP9-MVE/relatieVV
 
|-
 
|-
 
! style="text-align: left;"|MEDREC-AAN
 
! style="text-align: left;"|MEDREC-AAN
| EDIFACT id|| Verrijkt EDIFACT id|| Verrijkt EDIFACT id|| Verrijkt EDIFACT id
+
| EDIFACT-id|| Verrijkt EDIFACT-id|| Verrijkt EDIFACT-id|| Verrijkt EDIFACT-id
 
|-
 
|-
 
!  style="text-align: left;"|MP6.12-vooraankondiging
 
!  style="text-align: left;"|MP6.12-vooraankondiging
 
| style="background-color: white;vertical-align:top;"|-  
 
| style="background-color: white;vertical-align:top;"|-  
| style="background-color: white;vertical-align:top;"|MP6.12-vooraankondiging id
+
| style="background-color: white;vertical-align:top;"|MP6.12 vooraankondiging-id
| style="background-color: white;vertical-align:top;"|MP6.12-vooraankondiging id
+
| style="background-color: white;vertical-align:top;"|MP6.12 vooraankondiging-id
| style="background-color: white;vertical-align:top;"|MP6.12-vooraankondiging id
+
| style="background-color: white;vertical-align:top;"|MP6.12 vooraankondiging-id
 
|-
 
|-
 
!  style="text-align: left;"|MP9-voorschrift
 
!  style="text-align: left;"|MP9-voorschrift
 
| style="background-color: white;vertical-align:top;"|-  
 
| style="background-color: white;vertical-align:top;"|-  
| style="background-color: white;vertical-align:top;"|MP9-MA id
+
| style="background-color: white;vertical-align:top;"|MP9 MA-id
| style="background-color: white;vertical-align:top;"|MP9-MA id
+
| style="background-color: white;vertical-align:top;"|MP9 MA-id
| style="background-color: white;vertical-align:top;"|MP9-VV id
+
| style="background-color: white;vertical-align:top;"|MP9 VV-id
 
|}
 
|}
 +
 +
Na ontvangst en identificatie van medicatiegegevens begint het kritische proces van het ontdubbelen van MBH’s. Dit is van vitaal belang om ervoor te zorgen dat er geen onterecht dubbele MBH’s in het dossier van de patiënt blijven bestaan.
  
 
==Ontdubbelen van MBH's==
 
==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.  
+
Na raadplegen zijn er soms meerdere MBH-id’s voor conceptueel dezelfde MBH. Systemen zullen de medicatiegegevens indien mogelijk aan elkaar relateren op basis van identificatie of PRK en de gegevens consolideren. Vervolgens hanteren systemen bepaalde criteria om de gebruiker te helpen bepalen welke MBH behouden blijft en welke wordt gestopt. Dit maakt deel uit van het reconciliatieproces. Omdat alleen de voorschrijver en apotheker mogen reconciliëren gaan systemen verschillend om met het consolidatie- en reconciliatieproces.
*'''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’.<br>
+
'''EVS en AIS:''' Voor EVS- en AIS-systemen gelden specifieke criteria om te bepalen welke MBH behouden blijft en welke wordt gestopt.
 +
*'''Specifieke MBH-id gaat voor generieke MBH-id:''' Het systeem markeert 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 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 voor kiezen dit voorstel zonder wijziging te accorderen of de voorgestelde stopdatum aan te passen. Op basis van deze reden van wijzigen (‘loopt in andere medicamenteuze behandeling’) wordt de gebruikersinterface zo ontworpen dat voor de gebruiker inzichtelijk is dat er niet daadwerkelijk met de medicatie gestopt moet worden. De medicatiebouwsteen wordt gestopt in het kader van reconciliatie.
 +
 
 +
'''eTDR:''' In het proces van het samenstellen van een toedienlijst worden verschillende procedures gevolgd, afhankelijk van de rol van het systeem. In situaties waarin het systeem fungeert als een eTDR en een EVS, zoals vaak het geval is in ziekenhuizen, wordt de toedienlijst gebaseerd op een geverifieerde medicatielijst. Bij opname voert een voorschrijver of apotheker verificatie uit op het medicatiedossier, samengesteld op basis van zowel interne als externe medicatiegegevens. Op basis hiervan wordt een toedienlijst gegenereerd.
 +
Het is ook mogelijk dat de toedienlijst niet gebaseerd wordt op een geverifieerde medicatielijst. In dat geval consolideert het eTDR medicatiegegevens uit verschillende bronnen tot een toedienlijst. Het kan voorkomen dat er meerdere MBH-id’s zijn voor dezelfde MBH. Als het eTDR een relatie kan leggen tussen de MA en de TA op basis van een ID, worden de geplande toedieningen gebaseerd op de meest specifieke medicatiebouwsteen (MA, TA of WDS).
 +
Als het eTDR geen relatie kan leggen tussen de MA en de TA op basis van een ID, worden de medicatiegegevens indien mogelijk aan elkaar gerelateerd op basis van de PRK. Als de medicatiegegevens niet aan elkaar kunnen worden gekoppeld, wordt aan de gebruiker getoond dat er een MA is waarvoor geen bijbehorende TA gevonden kan worden. Dit kan bijvoorbeeld door een melding te tonen. De toediener moet vervolgens, in overleg met de voorschrijver/verstrekker, bepalen of er op basis van dit voorschrift toegediend moet worden.
  
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.<br>
+
'''TRIS:''' In de praktijk schrijft de trombosedienst slechts een beperkt aantal geneesmiddelen voor, meestal van kortlopende aard. Hierdoor is het proces van reconciliatie voor de trombosedienst niet van toepassing, of slechts in zeer beperkte mate. Reconciliatie wordt alleen uitgevoerd voor medicatie die de trombosedienst zelf voorschrijft of aanpast.
  
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’).<br>
+
'''PGO:''' Vanuit PGO's kunnen MBH’s niet ontdubbeld worden. 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’). Bij de registratie van MGB in de MBH die moet blijven bestaan kan (automatisch) eerder geregistreerd MGB worden gestopt met de reden ‘loopt in een andere MBH’. 
 
    
 
    
 
===TA in andere MBH dan MA===
 
===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.<br>
+
In sommige gevallen bevindt een MP9-TA zich in een generieke MBH terwijl er een bijbehorende MP9-MA in een specifieke MBH bestaat. Dit resulteert in dubbele MBH’s die moeten worden ontdubbeld. Een EVS kan een stop-MA maken in de generieke MBH. Een AIS kan dit doen met een stop-TA. In beide gevallen wordt als reden voor het stoppen of wijzigen ‘loopt in andere medicamenteuze behandeling’ gebruikt. Het systeem maakt deze stop-MA of stop-TA beschikbaar en stuurt deze naar het AIS dat het bronsysteem is van de te stoppen MP9-TA, net zoals elke andere stop-MA of stop-TA. Nadat dit AIS de stop-bouwsteen heeft ontvangen, kan het een nieuwe TA in de specifieke MBH aanmaken. 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.<br>
+
Er kunnen ook dubbele MBH’s ontstaan met MP6.12-TA’s. In deze situatie kunnen systemen de gebruiker de optie bieden om MBH’s te ontdubbelen. Als een gebruiker een MP6.12-TA stopt, kan elk ander MP9-systeem deze actie gebruiken, waardoor er geen nieuwe reconciliatie nodig is. Deze situatie geldt echter alleen tot het moment van het beschikbaarstellen van een nieuwere MP6.12-TA. Deze MP6.12-TA ontstaat bij elke nieuwe verstrekking vanuit een MP6.12-AIS. Met name bij een geneesmiddelendistributiesysteem (GDS) maken AIS’en vaak nieuwe verstrekkingen aan. In dit geval kan de verstrekkende apotheker geen nieuwe TA in de MBH van de MA aanmaken, omdat het AIS nog niet is overgestapt naar MP9. Als een voorschrijver het gebruik van het betreffende geneesmiddel daadwerkelijk wil stoppen, moet deze de apotheker informeren via andere routes dan MP9, zoals via een stopbericht via EDIFACT, telefonisch of via fax. MP9-systemen die de optie bieden om MP6.12-TA’s te stoppen, wijzen hun gebruikers op deze 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:
+
Bij het stoppen van een TA vanwege ontdubbeling wordt mogelijk niet direct een nieuwe TA in de specifieke MBH aangemaakt. Voor PGO’s en eTDR’s is dit een aandachtspunt bij het samenstellen van het medicatieoverzicht en de toedienlijst.
*Afspraken over het opstellen van de toedienlijst (zie [[#Toedienlijsten|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)''.<br>
 
  
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.
+
===Duplicate MA’s===
 +
Een duplicaat van een MA kan ontstaan wanneer een EVS per abuis de MA van een ander heeft gemigreerd als zijn eigen MA (zie [[#Onderscheid tussen eigen en andermans medicatiegegevens|Onderscheid tussen eigen en andermans medicatiegegevens]]). Het doel is om deze duplicaat MA, die zich bevindt in een duplicaat MBH, te stoppen. Een EVS zal hiervoor een stop-MA maken, terwijl een AIS een voorstel-stop-MA kan maken. In de stop-bouwstenen wordt als reden voor het stoppen of wijzigen ‘loopt in andere medicamenteuze behandeling’ vermeld. Het systeem zal vervolgens deze stop-MA of voorstel-stop-MA sturen naar het EVS dat het bronsysteem is van de te stoppen MA.
  
===Duplicate MA’s===
+
Efficiënte gebruikersondersteuning en duidelijke processtappen zijn van essentieel belang bij het raadplegen, consolideren en reconciliëren van medicatiegegevens in de hybride situatie. Door systematische aanpakken zoals beschreven in dit hoofdstuk te implementeren, kunnen leveranciers en zorgaanbieders ervoor zorgen dat een geordend medicatiedossier behouden blijft gedurende de transitiefase naar MP9.
Een duplicate MA kan ontstaan wanneer een EVS ‘andermans’ MA per abuis heeft gemigreerd als ‘eigen’ MA (zie [[#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.
 
  
 
=Aandachtspunten gedurende transitiefase=
 
=Aandachtspunten gedurende transitiefase=
Regel 261: Regel 359:
  
 
==Doseerinstructies==
 
==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.  
+
In de transitiefase is het belangrijk om extra aandacht te besteden aan doseringen, vanwege zowel de functionele uitbreidingen in MP9 als de verschillen in technische uitwisseling tussen MP9, MP6.12 en EDIFACT. MP9 maakt gebruik van het FHIR-datatype Timing voor de uitwisseling van toedieningsschema’s, terwijl MP6.12 het HL7v3-datatype GTS (General Timing Specification) hanteert. Daarentegen bevatten doseerinstructies in EDIFACT de NHG Tabel25-standaard. Voor een soepele overgang naar MP9 is het cruciaal om deze verschillen te begrijpen.  
  
 
===MP6.12===
 
===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.''' <br>
+
Over het algemeen geldt voor het omzetten van doseerinstructies tussen MP9 en MP6.12 het volgende: '''Gestructureerd waar mogelijk, maar indien het te complex wordt, terugvallen op alleen vrije tekst.'''
 +
 
 +
In het bijzonder bij het omzetten van MP6.12 doseringen naar MP9 kan het soms moeilijk zijn om de exacte dosering te achterhalen. Dit komt door de complexiteit van het HL7v3-GTS model. Op de [https://informatiestandaarden.nictiz.nl/wiki/Mappings/MP612Dispense_2_MP9VerstrekkingenVertaling mapping pagina voor de MedMij gegevensdienst verstrekkingenvertaling] is een opzet gemaakt die als leidraad kan dienen, zie bij TA/Doseerinstructie.
  
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 [https://informatiestandaarden.nictiz.nl/wiki/Mappings/MP612Dispense_2_MP9VerstrekkingenVertaling mapping pagina voor de MedMij gegevensdienst verstrekkingenvertaling] is daarbij een opzet gemaakt die als leidraad kan dienen. Zie bij TA/Doseerinstructie. <br>
+
Hieronder volgt een beknopte 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 een frequentie van 1x per week om ervoor te zorgen dat de toedieningen op specifieke weekdagen plaatsvinden, wat helpt om de juiste doseringen te bepalen. 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).
  
Hieronder volgt een korte opsomming van de verschillen in doseringen en de afgesproken werkwijze voor omzetten van MP9 naar MP6.12.<br>
+
De methode via doseCheckQuantity verdient hierbij de voorkeur omdat deze geen onnodige precisie toevoegt. Daarnaast dienen de dagdelen inhoudelijk te worden opgenomen in tekst, zodat de betekenis niet verloren gaat voor de gebruiker, zoals een zorgverlener of patiënt.
*'''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.
+
*'''Interval:''' In MP6.12 is er geen onderscheid tussen interval en frequentie, daarom wordt dit onderscheid expliciet in de tekst vermeld. 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).
*'''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:
+
*'''isFlexibel voor toedientijden:''' Het is niet mogelijk om ‘isFlexibel’ voor toedientijden gestructureerd te delen, daarom wordt deze informatie alleen in de tekst opgenomen.
**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.
 
  
 
===EDIFACT (NHG Tabel25)===
 
===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.''
+
Er zijn verschillen tussen NHG Tabel25 en het doseringsmodel in MP9, wat  vraagt om aandacht voor de migratie van doseringen en de mapping tussen beide modellen. Dit is belangrijk, aangezien MP9-systemen tijdens de transitiefase ook nog berichten via EDIFACT moeten ontvangen of versturen naar systemen die nog niet kunnen 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.
 +
 
 +
Na het bespreken van de doseerinstructies, verschuiven we nu de focus naar een ander cruciaal aandachtspunt tijdens de transitiefase: doseerverlagingen.
  
 
==Doseerverlagingen==
 
==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.<br>
+
Doseerverlagingen worden binnen een MP9-AIS ingevoerd als nieuwe TA in het eigen systeem. Echter, het AIS past een eerdere MP6.12-verstrekking niet aan en genereert ook geen nieuwe ‘nep’-MP6.12-verstrekking. Als gevolg hiervan ontvangt een MP6.12-systeem bij raadpleging alleen de initiële MP6.12-verstrekking,die de doseerverlaging uit de meest recente MA en TA niet bevat. Dit komt overeen met de informatie die het systeem ontving vóór de introductie van MP9.
 +
 
 +
Een MP9-AIS kan echter anders opereren. Het is mogelijk dat het AIS de MP6.12-verstrekking niet als zodanig vastlegt in het eigen systeem. Het AIS genereert de MP6.12-verstrekking op het moment van raadplegen, op basis van de geldige TA(‘s) op de datum en tijd van de verstrekking. Dit zorgt ervoor dat een reeds gedane MP6.12-verstrekking achteraf inhoudelijk verandert, wat niet is toegestaan in MP6.12.
  
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.<br>
+
In het geval dat een EVS nog moet migreren naar MP9, terwijl het AIS al wel MP9 heeft geïmplementeerd, kan het volgende scenario zich voordoen bij een doseerverlaging. Het MP9-AIS heeft een TA aangemaakt op basis van een MP6.12-vooraankondiging. Vervolgens registreert het EVS een doseerverlaging. Omdat er geen nieuwe verstrekking nodig is, ontvangt het AIS geen MP6.12-vooraankondiging met betrekking tot deze verlaagde dosis. Zodra het EVS echter de overstap maakt naar MP9, kan het AIS de MA met verlaagde dosis raadplegen. In dit geval zal de TA een dosering bevatten die niet overeenkomt met de dosering in de MA. Desondanks mag deze TA wel worden opgenomen in de MBH van de MA.  
  
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.<br>
+
Met een goed begrip van doseerverlagingen, is het tijd om te kijken naar bijzondere situaties die tijdens de migratie naar MP9 kunnen ontstaan.
  
 
==Bijzondere situaties==
 
==Bijzondere situaties==
 
===Combinatiepreparaten===
 
===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.<br>
+
Combinatiepreparaten zijn geneesmiddelen waarin werkzame stoffen zijn gecombineerd, terwijl deze stoffen ook afzonderlijk verkrijgbaar zijn als losse geneesmiddelen. Voorbeelden hiervan zijn Exforge HCT of Atozet. Deze combinatiepreparaten kunnen vervangen worden door het gebruik van respectievelijk twee of drie 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.<br>
+
Een voorschrijver kan ervoor kiezen om een dergelijk combinatiepreparaat voor te schrijven met een MA voor één geneesmiddel. Echter, in het vervolg van het medicatieproces kan het voorkomen dat niet het combinatiepreparaat, maar juist de afzonderlijke middelen geleverd worden. Dit kan verschillende redenen hebben, zoals financiële (het combinatiepreparaat is te duur) of logistieke (het combinatiepreparaat zit niet in het assortiment of is niet op voorraad). Dit kan bijvoorbeeld voorkomen in een openbare apotheek, maar kan ook wanneer een patiënt wordt opgenomen in of juist ontslagen uit een instelling. In dergelijke gevallen ontstaan er feitelijk meerdere TA’s met elk een eigen geneesmiddel in dezelfde MBH. Dit kan echter worden afgehandeld volgens de standaard 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.
+
Zowel in de transitiefase als bij migratie kunnen specifieke uitdagingen ontstaan die vragen om aanvullende afspraken. Deze worden nader toegelicht in de volgende secties.
  
 
====Transitiefase====
 
====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.<br>
+
Deze passage beschrijft een situatie met combinatiepreparaten tijdens de transitiefase die speciale aandacht vereist. Dit komt doordat systemen die nog niet zijn overgestapt naar MP9 informatie uitwisselen met systemen die dat wel hebben gedaan. Een praktijkvoorbeeld verduidelijkt dit:
<br>
+
 
''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.''<br>
+
''Stel, een MBH genaamd “MBH-1” is gestart voor een combinatiepreparaat X door MP9-EVS “ABC”. Dit EVS heeft een MA heeft voor bijvoorbeeld een maand. Later besluit een huisarts om dit recept te herhalen. Deze huisarts heeft echter nog geen MP9-systeem en stuurt vanuit EVS “DEF” een EDIFACT-voorschrift naar MP9-AIS “GHI”. Dit AIS herkent dat het om dezelfde MBH “MBH-1” gaat en splitst het preparaat op in middel XY en middel XZ, wat resulteert in twee parallelle TA’s binnen dezelfde MBH. Als een derde voorschrijver later de huidige situatie van deze MBH raadpleegt, ontvangt deze geen actieve MA (die was immers ‘ooit’ afgelopen na een maand), maar wel twee actieve, parallelle TA’s voor middel XY en middel XZ.''
<br>
+
 
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.<br>
+
Een MBH vertegenwoordigt één (uitklapbare) regel op een medicatieoverzicht. Eventuele parallelle TA’s die hieraan gekoppeld zijn, kunnen gezamenlijk worden weergegeven onder die regel. Zo kun je deze bijvoorbeeld zien bij het uitklappen. Een voorschrijver stopt of wijzigt per MBH en niet per individuele TA. In het geval van bovenstaand praktijkvoorbeeld kan het systeem een aanvullende query uitvoeren om de PRK uit het MP9-EVS “ABC” (de MA) te achterhalen. De informatiestandaard MP9 kent hiervoor de queryparameter MBH-id. Hierdoor hoeft het systeem niet álle historische gegevens op te vragen, maar alleen voor die MBH waarin deze specifieke situatie zich voordoet. Het systeem kan deze situatie (geen actieve EVS-bouwsteen en actieve parallelle TA’s) herkennen. Vanaf AORTA 8.3 kunnen systemen dergelijke query’s zelfstandig op het LSP uitvoeren bij het raadplegen van gegevens, zonder dat UZI-pas authenticatie nodig is. In dit geval kan de PRK van de MA toch worden achterhaald en kunnen er wijzigingen of stopzettingen worden doorgevoerd volgens de normale MP9-regels.  
<br>
+
 
Voortbordurend op dit praktijkgeval:<br>
+
Voortbordurend op dit praktijkgeval:
  
''Stel dat:''
+
Wanneer het systeem niet in staat is geweest om de MA met het combinatiepreparaat te achterhalen én de voorschrijver zich niet bewust is van het combinatiepreparaat, ontstaat de vraag welk geneesmiddel moet worden opgenomen in de stop-MA. Omdat de voorschrijver twee TA’s ziet met middel XY en XZ, maar een stop-MA slechts één geneesmiddel kan bevatten, ontstaat er een dilemma.
*''het systeem, om welke reden dan ook, de MA met het combinatiepreparaat niet heeft kunnen achterhalen én''
+
Voor deze praktijksituatie zijn er twee opties om de parallelle TA’s te stoppen:
*''de voorschrijver ook niet herkent dat dit om zo’n preparaat gaat én''
 
*''de voorschrijver deze MBH wil stoppen of wijzigen.'' <br>
 
''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.''<br>
 
<br>
 
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.<br>
+
:1. Een mogelijkheid is om in de stop-MA een ‘magistraal’ geneesmiddel op te nemen met beide ingrediënten, namelijk middel XY en XZ uit de parallelle TA’s. Zelfs als de voorschrijver alleen één van de twee middelen wil stoppen of wijzigen, is de afspraak om:
 +
::*de hele MBH op deze manier te stoppen en;
 +
::*een of meer nieuwe MBH’s te starten met de gewenste eindsituatie voor elk middel.
 +
:2. Een andere mogelijkheid is om in de stop-MA het geneesmiddel van een van de twee TA’s op te nemen. Met de stop-MA worden alsnog beide TA’s gestopt. Beide situaties vereisen een nieuw verstrekkingsverzoek naar de apotheek. Een bijeffect van deze aanpak 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. Dit is de beste oplossing voor de medicatieveiligheid.
  
 
====Migratie en ontdubbelen====
 
====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:
+
Na migratie kan een vergelijkbare situatie ontstaan. Stel dat er vóór de migratie een voorschrift was voor combinatiepreparaat X, waarbij de apotheker dit heeft gesplitst in middel XY en XZ. Het migrerende AIS heeft twee mogelijkheden:
# het AIS heeft een relatie naar het oorspronkelijke voorschrift met bijbehorend PRK (van het combinatiepreparaat) of
+
# Het AIS heeft een relatie naar het oorspronkelijke voorschrift met bijbehorend PRK (van het combinatiepreparaat).
# het AIS kent deze relatie niet (meer).
+
# 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|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|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|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 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|Specifieke en generieke MBH-id]]). Hierdoor ontstaan 2 parallelle TA's in één generieke MBH. Als de MA nog niet historisch was bij migratie, krijgt deze een specifieke MBH van het EVS (zie paragraaf [[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]]). Vervolgens kunnen er twee MBH’s ontstaan die ontdubbeld kunnen worden volgens de normale afspraken (zie paragraaf [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]]). Een EVS kan de generieke MBH met de parallelle TA’s stoppen middels een stop-MA zoals eerder 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|Ontdubbelen van MBH's]]).
+
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. Na migratie ontstaan dus 3 verschillende MBH’s die conceptueel eigenlijk één MBH hadden moeten zijn. Deze situatie moet door een zorgverlener herkend en ontdubbeld worden volgens de normale afspraken bij migratie/hybride (zie paragraaf [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]]).
  
 
====Tot slot====
 
====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.<br>
+
Het is belangrijk om te erkennen dat, ondanks de mogelijkheden van MP9, er momenten zullen zijn waarop zorgverleners op een andere manier met elkaar moeten communiceren, vooral bij complexe grensgevallen.
  
 
===Medicatie voorgeschreven in het buitenland en 'over the counter'-medicatie===
 
===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:
+
De werkwijze voor de migratie van medicatie voorgeschreven in het buitenland en ‘over the counter’-medicatie (zelfzorgmedicatie) hangt af van twee belangrijke factoren:
*Heeft het middel een PRK of HPK?
+
# 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.  
+
::*Als het middel geen PRK of HPK heeft, kan er geen generieke MBH-id worden gegenereerd. Volgens de afspraak wordt voor deze middelen dan een specifieke MBH-id gegenereerd, zelfs als het historische gegevens betreft. Dit geldt voor het AIS, eTDR en PGO.
*Is het geneesmiddel voorgeschreven of is de behandeling overgenomen door een voorschrijver?
+
# 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.  
+
::*Als dit niet het geval is, volstaat 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.
+
::*Als de voorschrijver echter verantwoordelijk is voor de behandeling, is het wenselijk om bij migratie een MA aan te maken.
  
 
===Magistralen===
 
===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.  
+
Sinds MP6.12.3 is het verplicht om de ingrediënten van magistrale preparaten gestructureerd uit te wisselen via ingrediëntcodes. Helaas blijkt dat systemen deze vereiste niet altijd naleven. In plaats daarvan wordt de samenstelling van magistrale preparaten vaak als vrije tekst uitgewisseld. Als gevolg hiervan voldoen de gemigreerde historische gegevens mogelijk niet aan de eis van gestructureerde en gecodeerde vastlegging van magistrale ingrediënten. Daarom is deze eis in MP9 versoepeld voor gegevens die in het verleden zijn aangemaakt.
  
 
===Experimentele medicatie===
 
===Experimentele medicatie===
''De actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-567.  
+
''De actie tot nadere uitwerking hiervan is opgenomen in BITS, zie voor de actuele status: https://bits.nictiz.nl/browse/MP-567.''
''
+
 
 +
Na het behandelen van bijzondere situaties, gaan we nu verder met het verkennen van andere belangrijke overwegingen tijdens de implementatie van MP9.
  
 
==Patiëntportalen==
 
==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.
+
Patiëntportalen van XIS’enkunnen patiënten de mogelijkheid bieden om MGB te registreren. Indien het EVS of AIS deze informatie uit het patiëntportaal beschikbaar stelt, zijn de volgende aandachtspunten van belang:
*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 de patiënt in staat te stellen bij de registratie van MGB gebruik te maken van MP9-bouwstenen, zowel afkomstig uit het betreffende EVS of AIS als uit andere XIS’en. Dit helpt om MGB correct te registreren in de MBH van de bijbehorende MA en/of TA.
*Het patiëntportaal dient te faciliteren dat de patiënt MGB kan registreren via G-Standaard coderingen.<br>
+
*Het patiëntportaal dient de patiënt de mogelijkheid te bieden om MGB te registreren via G-Standaard coderingen.
 +
 
 +
In dit hoofdstuk hebben we de cruciale aandachtspunten besproken die leveranciers moeten overwegen tijdens de transitiefase naar MP9-systemen. Van doseerinstructies tot bijzondere situaties met combinatiepreparaten en magistrale preparaten, elke fase van de migratie vereist gedegen planning en afstemming. Door het begrijpen van de technische verschillen tussen MP9 en eerdere berichtenstromen en het implementeren van passende omzettingsstrategieën, kunnen leveranciers een soepele overgang waarborgen voor zorgverleners en patiënten.
 +
 
 +
=Aandachtspunten toedieninformatie=
 +
Dit hoofdstuk gaat in op een aantal specifieke situaties en afspraken die gelden voor de eTDR-systemen, zoals het negeren van MP6.12 informatie, het omgaan met digitale en niet-digitale toedieninformatie en het gebruik van maatwerkkoppelingen.
 +
 
 +
==Negeren van MP6.12 verstrekkingen==
 +
Tijdens de transitiefase kan een MP9-systeem via de transactie ‘raadplegen medicatiegegevens’ medicatiebouwstenen ontvangen van zowel MP9-systemen als van MP6.12-AIS'en, via de [[#term_transformatiedienst|{{term|transformatiedienst}}]] van de infrastructuurleverancier. Omdat MP6.12 verstrekkingen niet alle aspecten van een volledige MP9-TA bevatten, is het niet mogelijk om MP6.12-informatie te integreren met MP9-informatie op een toedienlijst. Zodra een eTDR voor een patiënt overgaat naar MP9, worden de vertaalde MP6.12 verstrekkingen die via het LSP beschikbaar zijn genegeerd.
 +
 
 +
Het negeren van de vertaalde MP6.12 verstrekkingen is gebaseerd op de HL7:id/@root. Een voorbeeld van de root oid is: concat('1.3.6.1.4.1.58606.1.', @root). Dit betekent dat een TA/id/@root die begint met 1.3.6.1.4.1.58606.1. is geconverteerd vanuit MP6.12.
 +
 
 +
Na het behandelen van het negeren van MP6.12 verstrekkingen, richt dit hoofdstuk zich nu op het onderscheid tussen digitale en niet-digitale toedieninformatie binnen het toedienproces.
 +
 
 +
==Digitale en niet-digitale toedieninformatie==
 +
Wanneer de apotheek (WPDK) de overstap maakt naar MP9, kan het bijbehorende eTDR voor die patiënt ook overgaan naar MP9. Echter, het kan voorkomen dat de patiënt medicatie ontvangt vanuit een andere apotheek. Dit kan bijvoorbeeld medicatie betreffen die is verstrekt door de poliklinische apotheek of tijdens de avond-, nacht- en weekenddienst (ANW) door de dienstapotheek. Het kan zijn dat deze apotheek nog niet is overgestapt naar MP9. Alleen als de apotheek (WPDK) de volledige verantwoordelijkheid voor de verstrekte medicatie overneemt, kan deze een MP9-TA aanmaken die door het eTDR kan worden gebruikt voor de toedienlijst.
 +
 
 +
Deze werkwijze kan resulteren in de beschikbaarheid van zowel digitale als niet-digitale toedieninformatie voor de toediener. Het kan echter ook voorkomen dat er helemaal geen digitale toedieninformatie beschikbaar is voor de toediener.
 +
 
 +
===Geen digitale toedieninformatie===
 +
In bepaalde situaties kan het gebeuren dat de toediener niet over digitale toedieninformatie (MA/TA) beschikt. Wanneer er geen digitale toedieninformatie beschikbaar is, kunnen medicatietoedieningen alsnog digitaal worden geregistreerd. Deze medicatietoedieningen starten dan een nieuwe MBH - er is immers geen MA of TA beschikbaar – met een specifieke MBH-id. Medicatietoedieningen die niet op MP9-informatie zijn gebaseerd maar wel bij hetzelfde voorschrift horen, worden idealiter in dezelfde specifieke MBH geregistreerd.
 +
 
 +
Een voorbeeld illustreert een situatie waarin deze werkwijze van toepassing is.
 +
''Stel, er is een EVS dat een MP6.12-voorschrift stuurt naar een AIS dat nog niet is overgestapt naar MP9. Dit AIS is een andere apotheek dan de apotheek WPDK. Het AIS verstrekt de medicatie en levert een MP6.12 verstrekking op. De apotheek WPDK werkt met een MP9-systeem. Hoewel de MP6.12 verstrekking raadpleegbaar is voor de apotheek WPDK via de transformatiedienst, zal het eTDR deze vertaalde MP6.12 verstrekkingen negeren Er is dan geen digitale toedieninformatie beschikbaar voor het eTDR. De toediener zal de medicatie toedienen op basis van niet-digitale informatie.''
 +
 
 +
<span id="Voorbeeld situatie geen digitale toedieninformatie.png" title="Voorbeeld situatie geen digitale toedieninformatie">[[Bestand:Voorbeeld situatie geen digitale toedieninformatie.png|miniatuur|geen|x300px|Figuur 10. Schematische weergave van de situatie waarbij de toedienorganistatie, in de hybride situatie, niet over digitale toedieninformatie (MA/TA) beschikt.]]</span>
 +
 
 +
===Digitale en niet-digitale toedieninformatie===
 +
In sommige situaties kan het voorkomen dat de toediener beschikt over zowel digitale als niet-digitale toedieninformatie. Tijdens de hybride situatie wordt deels met MP9 gewerkt en blijft de huidige werkwijze (papieren toedienlijst, telefonisch contact tussen zorgverleners, enzovoort) deels behouden. Als er digitale en niet-digitale toedieninformatie beschikbaar is, worden de medicatietoedieningen bij voorkeur geregistreerd op basis van de digitale toedieninformatie (MA/TA).
 +
 
 +
In het volgende voorbeeld wordt een situatie geschetst waarin deze werkwijze wordt toegepast.
 +
''In deze situatie is er een EVS dat een MP9 MA beschikbaar maakt. Daarnaast stuurt het EVS een voorschrift aan een AIS dat nog niet is overgestapt naar MP9. Het gaat in deze situatie om een andere apotheek dan de apotheek WPDK. Dit AIS verstrekt de medicatie en stelt een MP6.12 verstrekking beschikbaar. De apotheek WPDK betreft een MP9 systeem. De MP6.12 verstrekking is door de transformatiedienst raadpleegbaar voor de apotheek WPDK. Daarnaast ontvangt de apotheek WPDK een MP9 MA vanuit het EVS. Het eTDR zal de vertaalde MP6.12 verstrekkingen negeren maar ontvangt wel een MP9 MA bij het raadplegen van medicatiegegevens. Tenzij de apotheek WPDK de volledige verantwoordelijkheid voor de verstrekte medicatie overneemt en een TA aanmaakt is er voor het eTDR alleen een MP9 MA digitaal beschikbaar. Daarnaast kan het zijn dat de toediener beschikt over niet digitale toedieninformatie vanuit de apotheek die nog niet overgestapt is naar MP9.''
 +
 
 +
<span id="Voorbeeld situatie digitale en niet-digitale toedieninformatie.png" title="Voorbeeld situatie digitale en niet-digitale toedieninformatie">[[Bestand:Voorbeeld situatie digitale en niet-digitale toedieninformatie.png|miniatuur|geen|x315px|Figuur 11. Schematische weergave van de situatie waarbij de toedienorganistatie, in de hybride situatie, over digitale en niet-digitale toedieninformatie beschikt.]]</span>
 +
 
 +
Terwijl we nu begrijpen hoe in het toedienproces omgegaan wordt met digitale en niet-digitale toedieninformatie, kijken we nu naar de impact van maatwerkkoppelingen op de eTDR systemen.
 +
 
 +
==Maatwerkkoppelingen voor eTDR's==
 +
In de praktijk worden verschillende maatwerkkoppeling gebruikt tussen eTDR’s en andere XIS’en. De hybride situatie kan invloed hebben op deze maatwerkkoppelingen. Deze paragraaf beschrijft de afspraken over twee specifieke maatwerkkoppelingen.
 +
 
 +
===Maatwerkkoppeling gebaseerd op MP9===
 +
In de huidige situatie bestaan er maatwerkkoppelingen tussen eTDR’s en andere XIS’en. Als het XIS dat de toedieninformatie via de maatwerkkoppeling aanlevert aan het eTDR overgestapt is naar MP9 kan het zijn dat er sprake is van een maatwerkkoppeling gebaseerd op het MP9 datamodel. Er is afgesproken dat leveranciers vrij zijn om in een dergelijke maatwerkkoppeling al dan niet een MBH-id op te nemen. Als er in de maatwerkkoppeling een MBH-id wordt meegegeven, moet het eTDR deze gebruiken bij de registratie van medicatietoedieningen.
 +
 
 +
===Maatwerkkoppeling voor het tromboseschema===
 +
In de huidige situatie bestaan er maatwerkkoppelingen tussen eTDR’s en TRIS’en. Het TRIS stuurt een tromboseschema naar het eTDR of stelt deze beschikbaar.
 +
Totdat er in MP9 een MA en WDS beschikbaar zijn, zal het eTDR / de toediener het tromboseschema op de gebruikelijke wijze ontvangen. Dit kan gebeuren via een maatwerkkoppeling of op een niet-digitale manier.
 +
Wanneer het eTDR een tromboseschema ontvangt via een maatwerkkoppeling en er tegelijkertijd MP9-gegevens beschikbaar zijn(MA/TA), worden het tromboseschema en de MP9 gegevens samengevoegd. De samenvoeging kan worden uitgevoerd op basis van het Burgerservicenummer (BSN) en het geneesmiddel. Medicatietoedieningen kunnen worden geregistreerd onder de MA en/of TA. Hierbij worden de uitgangspunten voor het toekennen van een MBH-id vanuit een eTDR gevolgd, zoals beschreven in paragraaf 3.3.2.
 +
Om het tromboseschema samen te voegen met MP9-gegevens, moeten de geneesmiddelcodes van het TRIS worden gekoppeld aan de codes zoals gebruikt in MP9. Aangezien TRIS’en momenteel nog niet met de G-standaard werken, verschillen deze geneesmiddelcodes van die in MP9. Het is de verantwoordelijkheid van de leveranciers om de eventueel benodigde koppeltabellen te maken, gebruiken en onderhouden.
 +
Het eTDR bepaalt tot welk moment een maatwerkkoppeling nodig is voor de doseerinformatie vanuit de trombosedienst. Op het moment dat het eTDR zowel een MP9-WDS als informatie via de maatwerkkoppeling ontvangt van dezelfde bron-TRIS, kan het eTDR aangeven dat de maatwerkkoppeling voor die patiënt niet langer nodig is. 
  
=Toedienlijsten=
+
Concluderend biedt dit hoofdstuk inzicht in essentiële aspecten van toedieninformatie voor eTDR-systemen tijdens de transitie naar MP9. Door het negeren van MP6.12 verstrekkingen, de variabiliteit tussen digitale en niet-digitale toedieninformatie, en de flexibele omgang met maatwerkkoppelingen, kunnen leveranciers effectief MP9 implementeren voor het toedienproces.
''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.
+
 
''
+
=Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id en MP6.12 vooraankondiging-id=
 +
Zoals aangegeven in het hoofdstuk [[#Achtergrond|Achtergrond]] is het van belang om duplicate MBH’s betrouwbaar te kunnen ontdubbelen. Het ontdubbelen is het meest betrouwbaar wanneer er gebruik wordt gemaakt van unieke identificaties. Relaties vastleggen tussen EDIFACT-, MP6.12- en MP9-informatie helpt (geautomatiseerde) ontdubbeling en reconciliatie. Dit vermindert de administratieve lasten voor zorgverleners met betrekking tot het krijgen van een actueel medicatiedossier. Hieronder volgen gedetailleerde uitleg en richtlijnen voor het verrijken van het EDIFACT-id en het vullen van de relatie naar het voorschrift in de MP6.12-verstrekkingen en de MP6.12 vooraankondiging.
  
=Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id=
 
Zoals aangegeven in het hoofdstuk [[#Achtergrond|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.
 
 
==Huidige situatie==
 
==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 huidige situatie is als volgt: een voorschrijver stuurt één of meer voorschriften via EDIFACT naar de apotheker met een MEDREC-AAN (aanvraag-) bericht. Nadat de apotheker het medicijn heeft verstrekt, stuurt hij een MEDREC-AFL (aflever-) bericht naar de huisarts van de patiënt, waarin indien mogelijk een verwijzing naar de voorschrift-ID’s van het MEDREC-AAN bericht wordt opgenomen. De huisarts ontvangt op deze manier ook AFL-berichten voor door specialisten voorgeschreven medicatie. Echter, deze AFL-berichten hebben géén relatie naar een MP6.12-vooraankondiging.
 +
 
 +
De huisarts kan aan de hand van het al dan niet aanwezige voorschrift-id bepalen of het een aflevering van een eigen voorschrift betreft of van een andere voorschrijver. Deze koppeling is niet afhankelijk van het medicament, waardoor het ook mogelijk is wanneer de apotheker iets anders aflevert dan voorgeschreven.
 +
 
 +
Om de effectiviteit van ontdubbeling en reconciliatie te verbeteren, is het belangrijk om de huidige situatie te begrijpen waarbij voorschrift- en afleverberichten via EDIFACT worden uitgewisseld. Daarnaast streven we naar een situatie waarin identificaties consistent gematcht worden tussen EDIFACT, MP6.12 en MP9.
 +
 
 +
==Gewenste situatie en uitgangspunten==
 +
De gewenste situatie is om ontdubbelen en reconciliatie zoveel mogelijk te vergemakkelijken, zelfs met eerdere versies van de standaard zoals EDIFACT en MP6.12, door identificaties te matchen. Het vermijden van aanpassingen aan (legacy) EDIFACT-implementaties die dit proces verder kunnen vereenvoudigen, is echter van cruciaal belang.
 +
 
 +
In principe bevatten verstrekkingen altijd een verwijzing naar de identificatie van het bijbehorende voorschrift, ongeacht of deze beide in hetzelfde berichtformaat zijn verstuurd.
 +
 
 +
===MP6.12: relatie leggen vanuit verstrekking naar 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 bevat een prescription/id. Dit [[#term_prescription/id|{{term|prescription/id}}]] moet verplicht opgenomen worden in de MP6.12-verstrekking.
  
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.
+
Na migratie van een EVS naar MP9 wordt bij het verzenden van een MP6.12 vooraankondiging het prescription/id gevuld met het id van de MA en, indien mogelijk, de id van de VV.  
==Gewenste situatie==
+
De opbouw van de MP6.12 vooraankondiging-id is als volgt:
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.
+
* in de prescription-id een @root met de oid van de MA, geprefixt met ‘1.3.6.1.4.1.58606.1.3.
===Uitgangspunten===
+
* in de extension een unieke identifier, opgebouwd als volgt:
Het is ongewenst om aanpassingen te doen aan (legacy) EDIFACT-implementaties.
+
**de MA-id @extension
===MP6.12: relatie leggen vanuit verstrekking naar MP6.12-voorschrift===
+
** een '|'
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 [[#term_prescription/id|{{term|prescription/id}}]] '''moet verplicht''' opgenomen worden in de MP6.12-verstrekking.
+
**een string om de identifier uniek te maken. Als de totale lengte binnen de 64 karakters (AORTA-restrictie) blijft, kan dit een VV-id @extension zijn. Als de lengte de 64 karakters overschrijdt (bijvoorbeeld wanneer beide extensions een uuid bevatten), kan een volgnummer of een datum/tijd worden gebruikt. De eis blijft dat deze identifier eeuwig wereldwijd uniek moet zijn.
===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 [[#term_verrijkt id|{{term|‘verrijken’}}]] van de EDIFACT id die geschikt is voor communicatie in HL7v3 / FHIR is als volgt samen te vatten:
+
===Verrijkt EDIFACT-id===
*Een vaste OID-root, vastgesteld door Nictiz: 2.16.840.1.113883.2.4.3.11.61.1
+
Wanneer het voorschrift via EDIFACT is ontvangen, kan het zijn dat de referentie tussen voorschrift en verstrekking niet is ingevuld. De EDIFACT-identificatie is niet wereldwijd uniek, maar alleen uniek binnen een organisatie. Bovendien kan deze identificatie niet rechtstreeks worden gebruikt in MP9- of MP6.12-berichten vanwege het ontbreken van ondersteuning voor de OID-systematiek in EDIFACT. Het EDIFACT-id veld heeft een maximale  lengte van 35 posities, wat te beperkt is voor het invoeren van een volledige OID. De overeengekomen methode om het EDIFACT-id te [[#term_verrijkt id|{{term|‘verrijken’}}]] voor gebruik in HL7v3 / FHIR communicatie kan als volgt worden samengevat:
*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.
+
*Een vaste OID-root, vastgesteld door Nictiz: 2.16.840.1.113883.2.4.3.11.61.1.
**Het id van het voorschrift wordt gehaald uit het EDIFACT S05 LIN segment
+
*Een OID-extension die bestaat uit de AGB-code van de verzender en het id van het EDIFACT-voorschrift, gescheiden door een pipe separator.
**De AGB-code van de verzender wordt gehaald uit het EDIFACT S01 NAD+MS segment
+
**Het voorschrift-id wordt verkregen uit het EDIFACT S05 LIN segment.
 +
**De AGB-code van de verzender wordt verkregen uit het EDIFACT S01 NAD+MS segment.
  
 
====Voorbeeld 1====
 
====Voorbeeld 1====
Regel 472: Regel 631:
 
*voor Paracetamol: <syntaxhighlight lang="xml"><id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729000"/></syntaxhighlight>
 
*voor Paracetamol: <syntaxhighlight lang="xml"><id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729000"/></syntaxhighlight>
 
*voor Oxazepam: <syntaxhighlight lang="xml"><id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729001"/></syntaxhighlight>
 
*voor Oxazepam: <syntaxhighlight lang="xml"><id root="2.16.840.1.113883.2.4.3.11.61.1" extension="01023456|729001"/></syntaxhighlight>
 +
 +
In de gewenste situatie streven we ernaar om ontdubbeling te vergemakkelijken door goede relaties te leggen tussen EDIFACT-, MP6.12- en MP9-informatie. Dit heeft directe impact op XIS-leveranciers, die moeten zorgen dat alle systemen correct zijn geconfigureerd om deze relaties te ondersteunen.
  
 
==Impact voor de XIS-leveranciers==
 
==Impact voor de XIS-leveranciers==
 
===AIS===
 
===AIS===
MP6.12-verstrekking/prescription id vullen:
+
Het is belangrijk om het MP6.12-verstrekking/prescription id correct in te vullen: te weten met het prescription/id uit de MP6.12-vooraankondiging. Bij een EDIFACT-voorschrift gebruikt het AIS hiervoor het verrijkt EDIFACT-id.
*Indien nog niet geïmplementeerd: prescription/id uit MP6.12-vooraankondiging én
+
 
*Verrijkt EDIFACT id zoals afgeleid uit MEDREC-AAN bericht.
 
 
===Alle systemen===
 
===Alle systemen===
Het overzicht van identificaties in paragraaf [[#Samenhang van identificaties in EDIFACT, MP6.12 en MP9|Samenhang van identificaties in EDIFACT, MP6.12 en MP9]]:
+
Zie het overzicht van identificaties in de paragraaf [[#Samenhang van identificaties in EDIFACT, MP6.12 en MP9|Samenhang van identificaties in EDIFACT, MP6.12 en MP9]]:
*Bij migratie gebruiken om relaties in MP9-bouwstenen te leggen.
+
*Gebruik dit overzicht bij migratie 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.
+
*Herken en maak gebruik van deze identificaties om te consolideren én gebruikers te ondersteunen bij het reconciliëren, bijvoorbeeld door de medicatie-informatie te ordenen bij de juiste MBH.
 +
 
 +
Het verrijken van EDIFACT-id's en het vullen van MP6.12-voorschrift-id's zijn essentieel voor het ondersteunen van reconciliatie in de hybride situatie. Door consistente identificatiemechanismen te implementeren, kunnen zorgverleners makkelijker een medicatiedossiers opbouwen en worden de administratieve lasten verminderd. XIS-leveranciers spelen een cruciale rol in het ondersteunen van deze processen door ervoor te zorgen dat hun systemen deze identificaties correct verwerken en integreren.
  
 
=Bijlage: Early adopters van MP9=
 
=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.<br>
+
Op dit moment zijn er verschillende systemen die al informatie uitwisselen via MP9 (versie MP9.0.7). Dit hoofdstuk belicht de ‘early adopters’ van MP9. Deze early adopters zijn aangesloten op specifieke aspecten van MP9 vanuit verschillende trajecten. Als gevolg daarvan passen sommige early adopters de MBH-id al toe, terwijl anderen dit nog níét doen.
<br>
+
 
'''Early adopters MP9 met (mogelijk) MBH-id'''<br>
+
'''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. <br>
+
In MP9.07 bestaat er geen generieke MBH-id. Als een early adopter van MP9 al medicatiebouwstenen met een MBH-id beschikbaar heeft gesteld, zijn dit altijd specifieke MBH-id’s. Deze medicatiebouwstenen kunnen dus worden beschouwd als volwaardige MP9-informatie.
  
 
Dergelijke early adopters bestaan bij de informatiestandaard BgZ, het programma VIPP GGZ (VIPP 3), de informatiestandaard Ketenzorg en MedMij.
 
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.
+
*'''VIPP GGZ:''' Bij het programma VIPP GGZ (VIPP 3) worden MBH-id’s gebruikt, wat de overgang naar MP9 3.0.0 (of latere versie) waarschijnlijk probleemloos maakt, omdat het programma gericht was op EVS’en.
*'''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.
+
*'''BgZ:''' Bij de BgZ is het waarschijnlijk dat er nog geen gebruik gemaakt is van MBH-id’s.
*'''MedMij'''
+
*'''Ketenzorg:''' Voor ketenzorg geldt dat de MBH-id geen vereiste is én waarschijnlijk nog niet wordt ondersteund.
**'''DVZA-BgZ''': Gezien de MBH-id geen onderdeel was van kwalificatie, zullen systemen zeer waarschijnlijk nog geen MBH-id’s gegenereerd hebben.
+
*'''MedMij:'''
**'''DVZA-huisartsgegevens''': Zeer waarschijnlijk geen MBH-id’s volgens MP9-systematiek.
+
**''' Dienstverlener zorgaanbieder (DVA-)BgZ en DVA-huisartsgegevens:''' Bij de DVA-BgZ en DVA-huisartsgegevens is het onwaarschijnlijk dat er al MBH-id’s zijn gegenereerd, gezien dit geen onderdeel was van de kwalificatie.
**'''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.<br>
+
**''' DVA-verstrekkingenvertalingen:''' Bij DVA-verstrekkingenvertalingen worden MBH-id’s momenteel gevuld met MP6.12-verstrekking id’s, met als doel een relatie te leggen tussen de TA en MVE. Deze id is niet geschikt voor MP9 3.0.0 (of latere release), dus deze partijen kunnen beschouwd worden als early adopters van MP9, zonder MBH-id.
<br>
+
 
'''Early adopters MP9 zonder MBH-id'''<br>
+
'''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.
+
MP9-informatie zonder MBH-id kan in veel gevallen worden genegeerd, vooral als deze informatie al beschikbaar is via een andere route, zoals MP6.12. In sommige gevallen kan een systeem ervoor kiezen om informatie uit deze bron weer te geven aan de gebruiker, maar er vindt geen reconciliatie plaats op basis van id of PRK.
 +
 
 +
De variatie onder early adopters van MP9 in het gebruik van de MBH-id illustreert de diversiteit en complexiteit van de implementatie van deze nieuwe standaard binnen de gezondheidszorg. Terwijl sommige systemen al profiteren van de voordelen van gestandaardiseerde medicatie-identificatie, blijft voor anderen de integratie van deze id een uitdaging. De voortdurende ontwikkeling en adoptie van MP9 zullen naar verwachting bijdragen aan een meer uniforme en efficiënte informatie-uitwisseling in de toekomst.
  
 
=Bijlage: Afkortingen en definities=
 
=Bijlage: Afkortingen en definities=
 +
Deze bijlage biedt een uitgebreide lijst van afkortingen en definities die cruciaal zijn voor een goed begrip van de context en uitdagingen die komen kijken bij de implementatie van MP9. Het begrijpen van deze termen is essentieel voor het correct interpreteren en toepassen van de afspraken in de praktijk.
 +
 
'''Afkortingen'''
 
'''Afkortingen'''
 
*AIS: apotheekinformatiesysteem
 
*AIS: apotheekinformatiesysteem
 
*eTDR: elektronisch toedienregistratiesysteem
 
*eTDR: elektronisch toedienregistratiesysteem
 
*EVS: elektronisch voorschrijfsysteem
 
*EVS: elektronisch voorschrijfsysteem
*MA: medicatieafspraak
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Therapeutische_en_logistieke_bouwstenen MA: medicatieafspraak]
*MBH: medicamenteuze behandeling
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling MBH: medicamenteuze behandeling]
*MGB: medicatiegebruik
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Therapeutische_en_logistieke_bouwstenen MGB: medicatiegebruik]
*MVE: medicatieverstrekking
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Therapeutische_en_logistieke_bouwstenen MVE: medicatieverstrekking]
 
*PGO: persoonlijke gezondheidsomgeving
 
*PGO: persoonlijke gezondheidsomgeving
*TA: toedieningsafspraak
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Therapeutische_en_logistieke_bouwstenen TA: toedieningsafspraak]
*VV: verstrekkingsverzoek
+
*[https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0-beta_Ontwerp_medicatieproces_9#Therapeutische_en_logistieke_bouwstenen VV: verstrekkingsverzoek]
  
 
'''Definities'''
 
'''Definities'''
*<span id="term_actuele_medicatie">{{term|Actuele medicatie}}</span>: 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.
+
*<span id="term_actuele_medicatie">{{term|Actuele medicatie}}</span>: Medicatie waarvan de stopdatum nog niet is verstreken, op een bepaald moment. Dit omvat zowel huidige (waarvan de huidige datum tussen tussen start- en stopdatum ligt) als toekomstige (waarvan de huidige datum vóór de startdatum ligt) medicatie.
*<span id="term_Sturen en/of beschikbaar stellen">{{term|Sturen en/of beschikbaar stellen}}</span>: 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.
+
*<span id="term_(actief) beschikbaarstellen">{{term|(actief beschikbaarstellen}}</span>: Het proces waarbij een systeem zijn eigen MP9-gegevens ter beschikking stelt voor raadpleging door andere systemen en/of het versturen van deze gegevens naar andere systemen.
*<span id="term_generieke_MBH">{{term|Generieke MBH-id}}</span>: 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.
+
*<span id="term_Co-existentie">{{term|Co-existentie}}</span>: De situatie waarin binnen de keten de noodzaak bestaat tot het uitwisselen van gegevens in meerdere standaarden.
 +
*<span id="term_Consolideren">{{term|Consolideren}}</span>: Het proces waarbij het informatiesysteem beschikbare medicatiegegevens samenvoegt met ontvangen gegevens uit verschillende bronnen.  Het doel is om een enkel, uniform en coherent medicatiedossier op te bouwen.
 +
*<span id="term_generieke_MBH">{{term|Generieke MBH-id}}</span>: De generieke MBH-id wordt gegeneerd op een zodanige manier dat systemen onafhankelijk van elkaar dezelfde identificatie kunnen maken voor medicatiebouwstenen met dezelfde prescriptiecode (PRK) of, als de PRK niet bekend is, de handelsproductcode (HPK). De generieke MBH-id gebaseerd op PRK bestaat uit een algemene OID-root genaamd ‘generiekeMBHIdPRK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.2), samen met de PRK in de OID-extension. De generieke MBH-id gebaseerd op HPK bestaat uit een algemene OID-root genaamd ‘generiekeMBHIdHPK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.3), samen met de HPK in de OID-extension. Een generieke MBH-id is uniek binnen een patiënt, maar niet uniek over verschillende patiënten heen. Deze variant van de MBH-id is uitsluitend bedoeld als tijdelijke oplossing tijdens de transitiefase voor bepaalde situaties.
 
*<span id="term_historie">{{term|Historie van medicatie}}</span>: Medicatie met een einddatum die meer dan twee maanden in het verleden ligt.
 
*<span id="term_historie">{{term|Historie van medicatie}}</span>: Medicatie met een einddatum die meer dan twee maanden in het verleden ligt.
*<span id="term_hybride_situatie">{{term|Hybride situatie}}</span>: De situatie waarbij een systeem (tijdelijk) zowel MP9 als MP6.12/EDIFACT ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen.
+
*<span id="term_hybride_situatie">{{term|Hybride situatie}}</span>: De situatie waarbij een systeem (tijdelijk) zowel MP9 als eerdere berichtenstromen ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen.
*<span id="term_migreren">{{term|Migreren}}</span>: Het omzetten van de reeds beschikbare medicatiegegevens in een patiëntdossier naar een datamodel dat MP9-bouwstenen ondersteunt.
+
*<span id="term_migreren">{{term|Migreren}}</span>: Het omzetten van de reeds beschikbare medicatiegegevens in een systeem naar een datamodel dat MP9-bouwstenen ondersteunt.
 
*<span id="term_MP6.12-TA">{{term|MP6.12-TA}}</span>: Uit MP6.12-verstrekking geconverteerde gegevens in een MP9-TA formaat ("jasje").
 
*<span id="term_MP6.12-TA">{{term|MP6.12-TA}}</span>: Uit MP6.12-verstrekking geconverteerde gegevens in een MP9-TA formaat ("jasje").
*<span id="term_raadplegen">{{term|Raadplegen}}</span>: 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).
+
*<span id="term_Raadplegen">{{term|Raadplegen}}</span>: Het proces van het opvragen van beschikbare medicatiegegevens, zowel gegevens die conform de MP9-standaard zijn als gegevens met het MP6.12-formaat. (raadplegen en reconciliëren zijn nauw aan elkaar verwant en vormen samen met het gesprek met de patiënt/ cliënt een onderdeel van de verificatie).
 
*<span id="term_recent_gestopt">{{term|Recent gestopte medicatie}}</span>: Medicatie die in de afgelopen twee maanden is geëindigd of gestopt.
 
*<span id="term_recent_gestopt">{{term|Recent gestopte medicatie}}</span>: Medicatie die in de afgelopen twee maanden is geëindigd of gestopt.
*<span id="term_reconcilieren">{{term|Reconciliëren}}</span>: 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).
+
*<span id="term_Reconciliëren">{{term|Reconciliëren}}</span>: het met elkaar in overeenstemming brengen van beschikbare gegevens met de ontvangen gegevens. Dit omvat het vergelijken van gerelateerde informatie uit verschillende bronnen om eventuele discrepanties of tegenstrijdigheden te identificeren en op te lossen. Dit proces kan menselijke interventie of beoordeling vereisen om een overzichtelijk en accuraat medicatiedossier op te bouwen.
*<span id="term_specifieke_MBH">{{term|Specifieke MBH-id}}</span>: 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.
+
*<span id="term_specifieke_MBH">{{term|Specifieke MBH-id}}</span>: Een specifieke MBH-id is wereldwijd en eeuwig uniek. In de MP9-standaard is de MBH-id beschreven als specifiek. Deze MBH-id bevat een OID-root en -extensie, waarbij de root een OID voor een uniek ‘identificatiesysteem’ van elke uitgevende organisatie bevat, terwijl de extensie een unieke string binnen dat systeem bevat. Bij migratie wijst het EVS specifieke MBH-id’s toe aan alle actuele en recent gestopte MP9-bouwstenen. Systemen behalve het EVS genereren over het algemeen geen specifieke MBH-id’s aan, maar gebruiken ontvangen specifieke MBH-id’s van het EVS indien beschikbaar.
*<span id="term_transformatiedienst">{{term|Transformatiedienst}}</span>: 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).
+
*<span id="term_transformatiedienst">{{term|Transformatiedienst}}</span>: De transformatiedienst wordt aangeboden door de infrastructuurleverancier bij het raadplegen van medicatiegegevens via MP9 op het Landelijk Schakelpunt (LSP). Deze dienst converteert MP6.12-verstrekkingen vanuit MP6.12-AIS'en naar een MP9-TA formaat. Dit betekent dat bij een MP9-query van andere MP9-systemen het MP9-systeem de MP9-bouwstenen ontvangt zoals in een volledige MP9-situatie, en dat vanuit MP6.12-AIS'en de geconverteerde gegevens (MP6.12-TA's) beschikbaar zijn.
*<span id="term_transitiefase">{{term|Transitiefase}}</span>: 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.
+
*<span id="term_transitie">{{term|Transitie}}</span>: Het proces van migreren en co-existentie dat uiteindelijk leidt tot de brede gegevensuitwisseling via MP9.
*<span id="term_prescription/id">{{term|Prescription/id in MP6.12-verstrekking}}</span>: 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.  
+
*<span id="term_transitiefase">{{term|Transitiefase}}</span>: De transitiefase, die begint met de migratie van het eerste systeem, omvat de periode waarin systemen de informatiestandaard MP9 implementeren. Deze fase eindigt wanneer alle systemen volledig overgestapt zijn naar MP9.
*<span id="term_verrijkt id">{{term|‘Verrijkt’ EDIFACT id}}</span>: 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).
+
*<span id="term_prescription/id">{{term|Prescription/id in MP6.12-verstrekking}}</span>: Dit is de identificatie van het voorschrift waarop de MP6.12-verstrekking is gebaseerd. De prescription/id kan verschillende typen waarden hebben, 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). Deze identificatie kan worden gebruikt om relaties te leggen van MP6.12-verstrekkingen naar het voorschrift of vanuit MP9-bouwstenen naar de MP6.12-berichtenstroom.  
 +
*<span id="term_verrijkt id">{{term|‘Verrijkt’ EDIFACT id}}</span>: Een EDIFACT-id is niet wereldwijd uniek en is geen OID, waardoor het niet zonder meer in een prescription/id van MP6.12 kan worden gebruikt. Om deze id uniek te maken, kan een ‘verrijkt’ EDIFACT-id worden samengestekd. Hierbij wordt een vaste OID-root gebruikt, samen met een OID-extension die bestaat uit het EDIFACT-id en de organisatie-id (hash).
 +
 
 +
=Bijlage: Documenthistorie en beheerproces=
 +
De wijzigingenhistorie van de implementatiehandleiding wordt bijgehouden in deze bijlage. 
 +
Wijzigingsverzoeken worden geregistreerd binnen het project Medicatieproces, onder epic MP-431 Hybride situatie, zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-431 filter Project = MP AND “Epic Link” = MP-431]. Elk van deze wijzigingsverzoeken wordt gerelateerd aan [https://bits.nictiz.nl/browse/MP-431 epic MP-431 Hybride situatie].
 +
De releasenotes verwijzen naar deze wijzigingsverzoeken.
 +
 
 +
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 Aandachtspunten gebruikersondersteuning, zie [https://bits.nictiz.nl/issues/?jql=%22Epic%20Link%22%20%3D%20MP-693 filter Project = MP AND "Epic Link" = MP-693]. Elk van deze de wijzigingsverzoeken wordt gerelateerd aan epic [https://bits.nictiz.nl/browse/MP-693 MP-693 Aandachtspunten gebruikersondersteuning].  
  
=Bijlage: Documenthistorie=
 
 
{{anchor|tabel 5}}
 
{{anchor|tabel 5}}
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 537: Regel 712:
 
!style="text-align:left;"|Datum
 
!style="text-align:left;"|Datum
 
!style="text-align:left;"|Releasenotes
 
!style="text-align:left;"|Releasenotes
 +
|-
 +
| style="background-color: white;vertical-align:top;"| 5
 +
| style="background-color: white;vertical-align:top;"| 4 juli 2024
 +
| style="background-color: white;vertical-align:top;"| Versie t/m sessie 07 maart 2024 van werkstroom Migratie/hybride situatie
 +
* [https://bits.nictiz.nl/browse/MP-1422 MP-1422] Gewijzigd en Toegevoegd: toekennen van een MBH-id vanuit een eTDR (zie [[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]])
 +
* [https://bits.nictiz.nl/browse/MP-1423 MP-1423] Gewijzigd en toegevoegd: stappen van migratie tot implementatie van MP9 in een eTDR (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 +
* [https://bits.nictiz.nl/browse/MP-1424 MP-1424] Toegevoegd: Vertaalde MP6.12 verstrekkingen negeren (zie [[#Verwerken en matchen van medicatiegegevens|Verwerken en matchen van medicatiegegevens]] en [[#Negeren van MP6.12 verstrekkingen|Negeren van MP6.12 verstrekkingen]])
 +
* [https://bits.nictiz.nl/browse/MP-1434 MP-1434] Toegevoegd: eTDR kan een relatie leggen tussen medicatiegegevens (MA en TA) (zie [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]])
 +
* [https://bits.nictiz.nl/browse/MP-1435 MP-1435] Toegevoegd: eTDR kan geen relatie leggen tussen medicatiegegevens (MA en TA) (zie [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]])
 +
* [https://bits.nictiz.nl/browse/MP-1446 MP-1446] Toegevoegd: Contextcode op WDS bij signaalfunctie LSP mogelijk (zie [[#Medicatiegegevens raadplegen|Medicatiegegevens raadplegen]])
 +
* [https://bits.nictiz.nl/browse/MP-1452 MP-1452] Deels toegevoegd: eTDR in ziekenhuissetting (zie [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]])
 +
* [https://bits.nictiz.nl/browse/MP-1454 MP-1454] Toegevoegd: Het eTDR consolideert medicatiegegevens waar mogelijk (zie [[#Medicatiegegevens raadplegen|Medicatiegegevens raadplegen]])
 +
* [https://bits.nictiz.nl/browse/MP-1456 MP-1456] & [https://bits.nictiz.nl/browse/MP-1665 MP-1665] Toegevoegd en gewijzigd: Opbouw MP6.12 vooraankondiging-id door MP9 systemen (zie [[#Samenhang van identificaties in EDIFACT, MP6.12 en MP9|Samenhang van identificaties in EDIFACT, MP6.12 en MP9]] en [[#MP6.12: relatie leggen vanuit verstrekking naar voorschrift|MP6.12: relatie leggen vanuit verstrekking naar voorschrift]])
 +
* [https://bits.nictiz.nl/browse/MP-1472 MP-1472] Toegevoegd: Geen digitale toedieninformatie (zie [[#Geen digitale toedieninformatie|Geen digitale toedieninformatie]])
 +
* [https://bits.nictiz.nl/browse/MP-1473 MP-1473] Toegevoegd: Digitale en niet-digitale toedieninformatie (zie [[#Digitale en niet-digitale toedieninformatie|Digitale en niet-digitale toedieninformatie]])
 +
* [https://bits.nictiz.nl/browse/MP-1508 MP-1508] Toegevoegd: Stappen van migratie tot implementatie van MP9 in TRIS (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 +
* [https://bits.nictiz.nl/browse/MP-1512 MP-1512] Toegevoegd: Toekennen MBH-id vanuit TRIS (zie [[#EVS versus andere systemen (AIS, eTDR,TRIS en PGO)|EVS versus andere systemen (AIS, eTDR,TRIS en PGO)]]
 +
* [https://bits.nictiz.nl/browse/MP-1518 MP-1518] Toegevoegd: eTDR maatwerkkoppeling gebaseerd op MP9 (zie [[#Maatwerkkoppeling gebaseerd op MP9|Maatwerkkoppeling gebaseerd op MP9]])
 +
* [https://bits.nictiz.nl/browse/MP-1519 MP-1519] Toegevoegd: Abonnement voor AIS op toedienpatiënten (zie [[#Medicatiegegevens raadplegen|Medicatiegegevens raadplegen]])
 +
* [https://bits.nictiz.nl/browse/MP-1521 MP-1521] Toegevoegd: Reconciliatie maar beperkt van toepassing voor trombosedienst (zie [[#TRIS|TRIS]] en [[#Ontdubbelen van MBH's|Ontdubbelen van MBH's]])
 +
* [https://bits.nictiz.nl/browse/MP-1523 MP-1523] Toegevoegd: Mapping tabellen om het tromboseschema te koppelen met MP9 gegevens (zie [[#Maatwerkkoppeling voor het tromboseschema|Maatwerkkoppeling voor het tromboseschema]])
 +
* [https://bits.nictiz.nl/browse/MP-1524 MP-1524] Toegevoegd: Tromboseschema koppelen aan MA en TA in ETDR (zie [[#Maatwerkkoppeling voor het tromboseschema|Maatwerkkoppeling voor het tromboseschema]])
 +
* [https://bits.nictiz.nl/browse/MP-1525 MP-1525] Toegevoegd: Maatwerkkoppeling voor tromboseschema (zie [[#Maatwerkkoppeling voor het tromboseschema|Maatwerkkoppeling voor het tromboseschema]])
 +
* [https://bits.nictiz.nl/browse/MP-1527 MP-1527] Toegevoegd: Tot wanneer heeft eTDR maatwerkkoppeling nodig voor tromboseschema (zie [[#Maatwerkkoppeling voor het tromboseschema|Maatwerkkoppeling voor het tromboseschema]])
 +
* [https://bits.nictiz.nl/browse/MP-1544 MP-1544] Toegevoegd: Reconciliatie kan en mag niet door toediener worden gedaan (zie [[#eTDR|eTDR]] en [[#Medicatiegegevens raadplegen|Medicatiegegevens raadplegen]])
 +
* [https://bits.nictiz.nl/browse/MP-1581 MP-1581] Toegevoegd: Stoppen van parallelle TA's voor combinatiepreparaten in de hybride situatie (zie [[#Transitiefase|Transitiefase]])
 +
* Beantwoorde vragen en uitgevoerde acties: [https://bits.nictiz.nl/browse/MP-1131 MP-1131], [https://bits.nictiz.nl/browse/MP-1453 MP-1453], [https://bits.nictiz.nl/browse/MP-1457 MP-1457], [https://bits.nictiz.nl/browse/MP-1462 MP-1462], [https://bits.nictiz.nl/browse/MP-1463 MP-1463], [https://bits.nictiz.nl/browse/MP-1464 MP-1464], [https://bits.nictiz.nl/browse/MP-1466 MP-1466], [https://bits.nictiz.nl/browse/MP-1469 MP-1469], [https://bits.nictiz.nl/browse/MP-1470 MP-1470], [https://bits.nictiz.nl/browse/MP-1474 MP-1474], [https://bits.nictiz.nl/browse/MP-1476 MP-1476], [https://bits.nictiz.nl/browse/MP-1478 MP-1478], [https://bits.nictiz.nl/browse/MP-1482 MP-1482], [https://bits.nictiz.nl/browse/MP-1483 MP-1483], [https://bits.nictiz.nl/browse/MP-1484 MP-1484], [https://bits.nictiz.nl/browse/MP-1504 MP-1504], [https://bits.nictiz.nl/browse/MP-1505 MP-1505], [https://bits.nictiz.nl/browse/MP-1507 MP-1507], [https://bits.nictiz.nl/browse/MP-1510 MP-1510], [https://bits.nictiz.nl/browse/MP-1513 MP-1513], [https://bits.nictiz.nl/browse/MP-1514 MP-1514], [https://bits.nictiz.nl/browse/MP-1515 MP-1515], [https://bits.nictiz.nl/browse/MP-1516 MP-1516], [https://bits.nictiz.nl/browse/MP-1517 MP-1517], [https://bits.nictiz.nl/browse/MP-1520 MP-1520], [https://bits.nictiz.nl/browse/MP-1526 MP-1526], [https://bits.nictiz.nl/browse/MP-1529 MP-1529],[https://bits.nictiz.nl/browse/MP-1531 MP-1531], [https://bits.nictiz.nl/browse/MP-1532 MP-1532], [https://bits.nictiz.nl/browse/MP-1513 MP-1513]
 +
* Wijzigingen in documentstructuur en verscheidene tekstuele, niet-inhoudelijke wijzigingen of aanvullingen
 
|-
 
|-
 
| style="background-color: white;vertical-align:top;"| 4
 
| style="background-color: white;vertical-align:top;"| 4
 
| style="background-color: white;vertical-align:top;"| 3 maart 2023
 
| style="background-color: white;vertical-align:top;"| 3 maart 2023
 
| style="background-color: white;vertical-align:top;"| Versie t/m sessie 14 februari 2023 van werkstroom Migratie/hybride situatie
 
| style="background-color: white;vertical-align:top;"| Versie t/m sessie 14 februari 2023 van werkstroom Migratie/hybride situatie
* [https://bits.nictiz.nl/browse/MP-831 MP-831] Toegevoegd: generieke MBH-id op basis van HPK indien PRK niet bekend is (zie [[#Specifieke vs. generieke MBH-id|Specifieke vs. generieke MBH-id]])
+
* [https://bits.nictiz.nl/browse/MP-831 MP-831] Toegevoegd: generieke MBH-id op basis van HPK indien PRK niet bekend is (zie [[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]])
 
* [https://bits.nictiz.nl/browse/MP-870 MP-870] Toegevoegd: afspraken voor PGO's voor migreren en beschikbaarstellen (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 
* [https://bits.nictiz.nl/browse/MP-870 MP-870] Toegevoegd: afspraken voor PGO's voor migreren en beschikbaarstellen (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
* [https://bits.nictiz.nl/browse/MP-1025 MP-1025] Toegevoegd: afspraken voor PGO's voor specifieke vs. generieke MBH-id (zie [[#Specifieke vs. generieke MBH-id|Specifieke vs. generieke MBH-id]])
+
* [https://bits.nictiz.nl/browse/MP-1025 MP-1025] Toegevoegd: afspraken voor PGO's voor specifieke vs. generieke MBH-id (zie [[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]])
* [https://bits.nictiz.nl/browse/MP-1027 MP-1027] en [https://bits.nictiz.nl/browse/MP-873 MP-873] Toegevoegd: afspraken voor PGO's voor verwerking van medicatiegegevens (zie [[#Raadplegen/ontvangen en reconciliëren|Raadplegen/ontvangen en reconciliëren]])
+
* [https://bits.nictiz.nl/browse/MP-1027 MP-1027] en [https://bits.nictiz.nl/browse/MP-873 MP-873] Toegevoegd: afspraken voor PGO's voor verwerking van medicatiegegevens (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]])
 
* [https://bits.nictiz.nl/browse/MP-893 MP-893] en [https://bits.nictiz.nl/browse/MP-894 MP-894] Toegevoegd: afspraken voor eTDR's voor migreren en beschikbaarstellen (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 
* [https://bits.nictiz.nl/browse/MP-893 MP-893] en [https://bits.nictiz.nl/browse/MP-894 MP-894] Toegevoegd: afspraken voor eTDR's voor migreren en beschikbaarstellen (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
* [https://bits.nictiz.nl/browse/MP-895 MP-895] Toegevoegd: afspraken voor eTDR's voor specifieke vs. generieke MBH-id (zie [[#Specifieke vs. generieke MBH-id|Specifieke vs. generieke MBH-id]])
+
* [https://bits.nictiz.nl/browse/MP-895 MP-895] Toegevoegd: afspraken voor eTDR's voor specifieke vs. generieke MBH-id (zie [[#Specifieke en generieke MBH-id|Specifieke en generieke MBH-id]])
 
* [https://bits.nictiz.nl/browse/MP-872 MP-872] Gewijzigd: bewoordingen bij flowcharts voor verwerking van medicatiegegevens (zie [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie])
 
* [https://bits.nictiz.nl/browse/MP-872 MP-872] Gewijzigd: bewoordingen bij flowcharts voor verwerking van medicatiegegevens (zie [https://informatiestandaarden.nictiz.nl/wiki/mp:Vdraft_RaadplegenReconcilieren Raadplegen en reconciliëren in de hybride situatie])
 
* Wijzigingen in documentstructuur en verscheidene tekstuele, niet-inhoudelijke wijzigingen of aanvullingen
 
* Wijzigingen in documentstructuur en verscheidene tekstuele, niet-inhoudelijke wijzigingen of aanvullingen
Regel 556: Regel 759:
 
* [https://bits.nictiz.nl/browse/MP-545 MP-545] Gewijzigd: raadplegen en reconciliëren vinden plaats bij interactie met patiëntdossier (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 
* [https://bits.nictiz.nl/browse/MP-545 MP-545] Gewijzigd: raadplegen en reconciliëren vinden plaats bij interactie met patiëntdossier (zie [[#Beschikbaarstellen van gemigreerde medicatiegegevens|Beschikbaarstellen van gemigreerde medicatiegegevens]])
 
* [https://bits.nictiz.nl/browse/MP-704 MP704] Toegevoegd: nadere beschrijving van afspraken omtrent einddatum in medicatiegegevens bij migratie (zie [[#Einddatum in medicatiegegevens|Einddatum in medicatiegegevens]])
 
* [https://bits.nictiz.nl/browse/MP-704 MP704] Toegevoegd: nadere beschrijving van afspraken omtrent einddatum in medicatiegegevens bij migratie (zie [[#Einddatum in medicatiegegevens|Einddatum in medicatiegegevens]])
* [https://bits.nictiz.nl/browse/MP-703 MP-703] Toegevoegd: werkwijze verwerking van MP6.12-TA's door MP9-systemen (zie [[#Raadplegen/ontvangen en reconciliëren|Raadplegen/ontvangen en reconciliëren]])
+
* [https://bits.nictiz.nl/browse/MP-703 MP-703] Toegevoegd: werkwijze verwerking van MP6.12-TA's door MP9-systemen (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]])
* [https://bits.nictiz.nl/browse/MP-705 MP705] Toegevoegd: nadere beschrijving van werkwijze ontdubbeling van MBH's bij TA in andere MBH dan MA (zie [[#Raadplegen/ontvangen en reconciliëren|Raadplegen/ontvangen en reconciliëren]])
+
* [https://bits.nictiz.nl/browse/MP-705 MP705] Toegevoegd: nadere beschrijving van werkwijze ontdubbeling van MBH's bij TA in andere MBH dan MA (zie [[#Raadplegen/ontvangen, consolideren en reconciliëren|Raadplegen/ontvangen, consolideren en reconciliëren]])
 
* [https://bits.nictiz.nl/browse/MP-644 MP-644] Toegevoegd: actie voor uitwerking van advies voor NHG Tabel25 doseringen in transitiefase (zie [[#EDIFACT (NHG Tabel25)|EDIFACT (NHG Tabel25)]])
 
* [https://bits.nictiz.nl/browse/MP-644 MP-644] Toegevoegd: actie voor uitwerking van advies voor NHG Tabel25 doseringen in transitiefase (zie [[#EDIFACT (NHG Tabel25)|EDIFACT (NHG Tabel25)]])
 
* [https://bits.nictiz.nl/browse/MP-691 MP-691] Toegevoegd: werkwijze voor vullen van identificaties bij meerdere MP6.12-vooraankondigingen onder één "medicatieafspraak" (zie [[#tabel2|Tabel 2]])
 
* [https://bits.nictiz.nl/browse/MP-691 MP-691] Toegevoegd: werkwijze voor vullen van identificaties bij meerdere MP6.12-vooraankondigingen onder één "medicatieafspraak" (zie [[#tabel2|Tabel 2]])

Huidige versie van 12 aug 2024 om 15:06


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 Leeswijzer

Om de implementatiehandleiding effectief te gebruiken, is het belangrijk om te begrijpen hoe de informatie is gestructureerd. De volgende leeswijzer biedt een overzicht van de hoofdstukken en bijlagen.

Hoofdstukken

  • Hoofdstuk 3 behandelt de verschillen tussen de transitiefase en de uiteindelijke situatie waarin alle systemen over zijn naar MP9. Er zijn aanvullende afspraken nodig om tijdens de transitiefase te komen tot een overzichtelijk medicatiedossier.
  • Hoofdstuk 4 en Hoofdstuk 5 beschrijven de afspraken voor het migreren en het beschikbaarstellen van de gemigreerde medicatiegegevens, het raadplegen en ontvangen van medicatiegegevens en het consolideren en reconciliëren in de hybride situatie.
  • Hoofdstuk 6 geeft een toelichting op enkele overige aandachtspunten gedurende de transitiefase (onder andere de doseerinstructies, doseerverlagingen en combinatiepreparaten).
  • Hoofdstuk 7 beschrijft de aandachtspunten met betrekking tot toedieninformatie.

Bijlagen

Wijzigingen en beheerproces

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, zie Bijlage: Documenthistorie en beheerproces.

Verwijzingen

2 Inleiding

Het implementatieprogramma Medicatieoverdracht zal de komende jaren de richtlijn ‘Overdracht van medicatiegegevens in de keten’ en de informatiestandaard Medicatieproces (MP9) zorgbreed implementeren. Dit proces begint met een beperkte implementatie tijdens de Kickstart Medicatieoverdracht, gevolgd door een brede uitrol. Om een goed begrip te krijgen van de context en uitdagingen van dit implementatieprogramma, starten we met een beschrijving van de migratie en hybride situatie.

2.1 Migratie en hybride situatie

Gezien niet alle systemen tegelijkertijd de informatiestandaard MP9 implementeren, is er sprake van een transitiefase. Deze fase begint met de migratie van het eerste systeem en eindigt wanneer alle systemen zijn overgestapt naar MP9. Gedurende de transitiefase zullen systemen te maken hebben met een hybride situatie: ze moeten zowel MP9 als eerdere berichtenstromen (onder andere MP6.12 en/of EDIFACT) ondersteunen.

Figuur 1. De transitiefase en de bijbehorende sub-processen bij de implementatie van de informatiestandaard medicatieproces 9.

Vanwege de verschillen tussen deze berichtenstromen zijn er specifieke afspraken nodig om een overzichtelijk medicatiedossier te kunnen creëren. In de werkstroom migratie & hybride heeft het programma Medicatieoverdracht samen met leveranciers en zorgverleners technische- en zorgprocesafspraken gemaakt. Deze afspraken, aanvullend op de informatiestandaard MP9, betreffen onder andere de transitie, de hybride situatie, het migratieproces, de co-existentie, het raadplegen van medicatiegegevens en het consolideren en reconciliëren ervan.

  • De transitie (het proces van migreren en co-existentie dat uiteindelijk leidt tot de brede gegevensuitwisseling via MP9).
Figuur 2. Definitie van de transitie bij de implementatie van de informatiestandaard Medicatieproces 9.
  • De hybride situatie (De situatie waarbij een systeem (tijdelijk) zowel MP9 als eerdere berichtenstromen MP6.12/EDIFACT ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen).
Figuur 3. Definitie van de hybride situatie bij implementatie van de informatiestandaard Medicatieproces 9.
  • Het migreren (het omzetten van de reeds beschikbare medicatiegegevens in een systeem naar een datamodel dat ook MP9-bouwstenen ondersteunt).
Figuur 4. Definitie van de migratie bij implementatie van de informatiestandaard Medicatieproces 9.
  • De co-existentie (De situatie waarin binnen de keten de noodzaak bestaat tot het uitwisselen van gegevens in meerdere standaarden).
Figuur 5. Definitie co-existentie bij de implementatie van de informatiestandaard Medicatieproces 9.
  • Het raadplegen (het proces van opvragen van beschikbare medicatiegegevens, uit zowel MP9- als MP6.12-systemen).
  • Het consolideren [1] (het proces waarbij het informatiesysteem beschikbare medicatiegegevens samenvoegt met ontvangen gegevens uit verschillende bronnen. Het doel is om een enkel, uniform en coherent medicatiedossier op te bouwen).
  • Het reconciliëren [1] (het met elkaar in overeenstemming brengen van beschikbare gegevens met de ontvangen gegevens. Dit omvat het vergelijken van gerelateerde informatie uit verschillende bronnen om eventuele discrepanties of tegenstrijdigheden te identificeren en op te lossen. Dit proces kan menselijke interventie of beoordeling vereisen om een overzichtelijk en accuraat medicatiedossier op te bouwen).

Met de complexiteit van de migratie- en hybride situatie in gedachten, is het cruciaal om duidelijke kaders te stellen voor leveranciers tijdens dit proces.

  1. 1,0 1,1 De definities voor de termen consolideren en reconciliëren zijn onder voorbehoud van een landelijke definitie

2.2 Kaders

Deze implementatiehandleiding bevat afspraken voor de leveranciers met betrekking tot migratie en de hybride situatie tijdens de Kickstart Medicatieoverdracht. In de Kickstart beproeft een beperkte groep zorgaanbieders de kwaliteitsstandaard 'Overdracht van medicatiegegevens in de keten' in samenhang met de informatiestandaard Medicatieproces 9. Doel is om eerst op kleine schaal te leren zodat degenen die volgen de implementatie zo efficiënt en vlot mogelijk kunnen doen. Bij aanvang van de Kickstart Medicatieoverdracht worden er procedures opgesteld voor het geval er nieuwe inzichten ontstaan tijdens deze testperiode. Eventuele wijziging aan deze pagina worden volgens deze procedures doorgevoerd.

De huidige versie van deze pagina omvat de afspraken voor het elektronisch voorschrijfsysteem (EVS), apotheekinformatiesysteem (AIS), de persoonlijke gezondheidsomgeving (PGO), het elektronisch toedienregistratiesysteem (eTDR) en het tromboseregistratiesysteem (TRIS).

Dit hoofdstuk heeft de basis gelegd voor het begrijpen van de migratie en hybride situatie tijdens de implementatie van MP9. Met duidelijke kaders en een overzicht van de belangrijkste aspecten, zijn leveranciers goed voorbereid om aan de slag te gaan met de volgende stappen in het proces. De komende hoofdstukken bieden gedetailleerde richtlijnen en specifieke afspraken die essentieel zijn voor een succesvolle overgang naar de nieuwe informatiestandaard.

3 Achtergrond

Tijdens de transitiefase, waarin systemen geleidelijk overgaan naar MP9, zijn er twee belangrijke verschillen ten opzichte van de uiteindelijke situatie waarin alle systemen MP9 gebruiken.

  • In de transitiefase is het niet altijd mogelijk om samenhangende medicatiegegevens via de MP9-systematiek bij elkaar te groeperen. Dit komt doordat het concept van een 'medicamenteuze behandeling' nieuw is in MP9 en niet voorkomt in eerdere standaarden zoals MP6.12 en EDIFACT.
  • Niet alle medicatiegevens zijn tijdens de transitiefase raadpleegbaar als MP9-bouwstenen.

Dit hoofdstuk geeft een toelichting op deze verschillen en de noodzaak van aanvullende afspraken tijdens de transitiefase. Zo kan een overzichtelijk medicatiedossier behouden blijven. Met deze achtergrond in gedachten, richten we ons nu op een cruciaal nieuw begrip binnen MP9: de ‘medicamenteuze behandeling’.

3.1 Nieuw begrip ‘medicamenteuze behandeling’

Het medicatieproces omvat het voorschrijven, ter hand stellen, toedienen en gebruiken van een geneesmiddel. De medicamenteuze behandeling (MBH) bundelt de verschillende medicatiebouwstenen die zo ontstaan. Alle medicatiebouwstenen moeten worden geïdentificeerd met een unieke code, de MBH-id. MP6.12- en EDIFACT-informatie bevat deze MBH-id niet. Wanneer systemen afzonderlijk migreren, genereren ze elk een eigen MBH-id, onafhankelijk van elkaar. 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, kunnen onbedoeld apart worden weergegeven in het medicatiedossier, wat verwarring kan veroorzaken over de dosering. Er zijn daarom afspraken nodig om deze risico’s te minimaliseren. Dit betreffen voornamelijk afspraken voor het toekennen van de MBH-id bij migratie (zie Migreren en beschikbaarstellen). Deze afspraken hebben tot doel om duplicate MBH's zoveel mogelijk te beperken. Echter, volledig voorkomen van duplicate MBH's is niet mogelijk. Deze pagina bevat ook instructies voor het relateren van samenhangende medicatiegegevens en het ontdubbelen van MBH’s (zie Raadplegen/ontvangen, consolideren en reconciliëren).

Met de introductie van de medicamenteuze behandeling en de bijbehorende uitdagingen, is het essentieel om te begrijpen hoe medicatiegegevens tijdens de transitiefase worden uitgewisseld.

3.2 Medicatiegegevens vanuit MP9 en andere berichtenstromen

In de transitiefase worden verschillende berichtenstromen gebruikt voor de uitwisseling van medicatiegevens.

3.2.1 MP6.12/Edifact berichtenstromen

In de transitiefase zullen nog niet alle medicatiegegevens beschikbaar zijn als MP9-bouwstenen.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 XIS’en in de keten. Een gemigreerd MP9-systeem zal tijdens de transitiefase ook de eerdere berichtenstromen (MP6.12 en/of EDIFACT) moeten blijven ondersteunen. Een MP9-EVS moet bijvoorbeeld nog EDIFACT berichten ondersteunen en in staat zijn om een MP6.12 vooraankondiging te kunnen sturen. Een gemigreerd MP9-AIS moet de medicatiegegevens zowel via MP6.12 als MP9 beschikbaar stellen, zodat systemen die nog niet overgestapt zijn naar MP9 de verstrekkingsgegevens kunnen blijven raadplegen. Het uitgangspunt is dat MP9-systemen maar één query nodig hebben. De infrastructuurleverancier zorgt via een transformatiedienst voor de conversie van MP6.12-verstrekkingen naar het formaat van MP9-TA’s (zie Raadplegen/ontvangen, consolideren en reconciliëren). Hoewel de gegevens die zijn geconverteerd vanuit MP6.12 verstrekkingen (MP6.12-TA’s) raadpleegbaar zijn in MP9-TA formaat, moeten ze om verschillende redenen niet op dezelfde manier worden verwerkt als een MP9-TA vanuit een MP9-AIS. Daarom bevat deze pagina afspraken voor de verwerking van deze MP6.12-TA’s in MP9-systemen (zie Raadplegen/ontvangen, consolideren en reconciliëren).

Gedetailleerde documentatie over de transformatiedienst (conversie van MP6.12-verstrekking naar MP9-TA formaat) vanuit het Landelijk Schakelpunt (LSP) zal beschikbaar worden gesteld via VZVZ, zie ook https://bits.nictiz.nl/browse/MP-572.

Naast MP6.12 en Edifact zijn er nog andere berichtenstromen die tijdens de transitiefase een rol spelen.

3.2.2 Overige berichtenstromen

Naast de MP6.12- en Edifact-berichtenstromen worden er in de praktijk ook andere berichtenstromen gebruikt voor de uitwisseling van medicatiegegevens. Dit omvat onder andere de uitwisseling van gegevens op niet digitale manieren, het gebruik van maatwerkkoppeling, en de uitwisseling via een eerdere versie van MP9 (versie MP9.0.7.). Deze berichtenstromen zullen niet allemaal uitgefaseerd worden bij de implementatie van MP9. Waar mogelijk zijn er afspraken gemaakt voor de hybride situatie. Het is daarnaast de verantwoordelijkheid van de leveranciers om de berichtenstromen die niet uitgefaseerd worden bij de implementatie van MP9 te blijven ondersteunen.

In deze transitiefase, waarin systemen overstappen naar MP9, is het cruciaal om duidelijke afspraken en richtlijnen te hebben om de consistentie en nauwkeurigheid van medicatiegegevens te waarborgen. Door de complexiteit van het combineren van verschillende berichtenstromen en het introduceren van nieuwe concepten zoals de medicamenteuze behandeling, is samenwerking en duidelijke communicatie tussen alle betrokken partijen essentieel. Dit zal niet alleen de kwaliteit van de gegevens verbeteren, maar ook de veiligheid van de patiëntenzorg verhogen. De beschreven afspraken en processen zijn daarom van groot belang voor een succesvolle implementatie van MP9.

4 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 hangt onder andere af van de overeenkomsten en verschillen tussen het huidige datamodel van het systeem en het vereiste 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. Leverancier en zorgaanbieder (gebruikersgroep) kunnen hiernaast aanvullende (detail)afspraken maken.

4.1 Beschikbaarstellen van gemigreerde medicatiegegevens

Dit hoofdstuk beschrijft de stappen van migratie tot implementatie van MP9 voor verschillende type informatiesystemen. Voor elk informatiesysteem worden de processtappen migreren, (actief) beschikbaar stellen, raadplegen, registreren, consolideren & reconciliëren en beschikbaarstellen uitgelegd.

4.1.1 EVS en AIS

Voor het EVS en AIS geldt dat na migratie de medicatiegegevens direct beschikbaargesteld mogen worden, inclusief de historische data. Figuur 6 geeft een overzicht van de processtappen migreren, (actief) beschikbaarstellen, raadplegen en reconciliëren voor het EVS en AIS. Raadplegen en reconciliëren vinden plaats wanneer de zorgverlener interactie heeft met het patiëntdossier, zoals bij patiëntcontact of proactief reconciliëren van (deel)populaties.

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

4.1.2 eTDR

In de huidige situatie is een apotheek verantwoordelijk voor het verzorgen van de toedienlijst voor een patiënt. Dit is meestal de apotheek waar de patiënt doorgaans komt (WPDK). Als deze apotheek overstapt naar MP9, kan ook het eTDR voor die patiënt overgaan naar MP9. Omdat de apotheek waar de patiënt doorgaans komt de meeste toedieningsafspraken heeft voor die patiënt, zal het eTDR per apotheek en per patiënt overgaan naar MP9. Deze migratie omvat alle historische gegevens. Voordat medicatietoedieningen in MP9 geregistreerd kunnen worden, moet het systeem de medicatiegegevens uit de keten raadplegen. Deze gegevens worden na consolidatie de toedienlijst voor de patiënt. Er is afgesproken dat de toediener medicatiegegevens niet mag reconciliëren. Zodra medicatietoedieningen zijn geregistreerd in MP9, worden deze gegevens beschikbaar gesteld. Voor apotheken die nog niet zijn overgestapt naar MP9 blijft de huidige werkwijze voor het eTDR van kracht.

Figuur 7. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren en (actief) beschikbaarstellen) voor eTDR.

4.1.3 TRIS

Bij een TRIS zal over het algemeen geen sprake zijn van migratie van gegevens. De medicatiegegevens die momenteel worden vastgelegd, zijn niet of nauwelijks te migreren naar MP9. Het TRIS zal per patiënt overgaan naar MP9. Bij deze overgang zullen de medicatiegegevens uit de keten worden geraadpleegd en geconsolideerd door het TRIS. Aangezien trombosediensten in zeer beperkte mate medicatie voorschrijven, zal reconciliatie waarschijnlijk niet nodig zijn. Als er een MA is ontvangen voor trombosemedicatie en er is een nieuw INR bekend, zal er nieuw wisselend doseerschema (WDS) worden gemaakt. Alleen het nieuwe WDS zal beschikbaar worden gesteld; lopende schema’s en historische schema’s zullen niet beschikbaar worden gesteld.

Figuur 8. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren, (actief) beschikbaarstellen) voor TRIS.

4.1.4 PGO

PGO's zijn bron van medicatiegebruik (MGB) die de gebruiker registreert. Voor PGO’s geldt dat zij na migratie ook historisch medicatiegebruik beschikbaarstellen[1] , maar pas nadat de patiënt de medicatiegegevens heeft geraadpleegd in de PGO en eventueel ook nieuw medicatiegebruik heeft geregistreerd.

Figuur 9. Overzicht van de volgorde van de processtappen (migreren, raadplegen, consolideren&reconciliëren, registreren, (actief) beschikbaarstellen) voor PGO.

Na het beschrijven van de specifieke stappen van migratie tot implementatie in verschillende informatiesystemen, richten we ons nu op algemene migratieafspraken die van toepassing zijn op alle informatiesystemen.

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

4.2 Algemene migratieafspraken

4.2.1 Onderscheid tussen eigen en andermans medicatiegegevens

Bij migratie is het essentieel dat systemen onderscheid maken tussen ‘eigen’ en ‘andermans’ medicatiegegevens. Het systeem fungeert als bron van ‘eigen’ gegevens, terwijl andere systemen bron zijn van ‘andermans’ gegevens. Het uitwisselen van medicatiegegevens vindt onder andere plaats via de transactie voor het raadplegen/beschikbaarstellen (of sturen/ontvangen) van medicatiegegevens. Deze transactie verbiedt het beschikbaarstellen van informatie van anderen. EVS’en, zoals huisarts- en ziekenhuisinformatiesystemen (HIS’en en ZIS’en), moeten, indien mogelijk, achterhalen of het gaat om interne of externe voorschriften. Bijvoorbeeld: als het HIS een verstrekkingsverzoek (VV) heeft uitgestuurd, zal het een eigen voorschrift betreffen. Deze benadering geldt ook voor andere type systemen. Deze afspraak is van belang om te voorkomen dat er onnodig dubbele medicatiebouwstenen worden uitgewisseld wanneer er meerdere systemen betrokken zijn bij een patiënt.

4.2.2 Einddatum in medicatiegegevens

Bij migratie naar MP9 moet, indien bekend, een einddatum voor gebruik worden vastgelegd.

  • MA: Wanneer de lokale database de einddatum van het voorschrift bevat, wordt bij migratie de einddatum in de MA ingevuld. Als 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, als de lokale database een einddatum van het voorschrift bevat. Het toevoegen van een einddatum in MA’s bij migratie zorgt ervoor dat er bij betrokkenheid van meerdere EVS’en bij een patiënt tijdelijk sprake kan zijn van eventuele dubbelingen in MA’s en daarmee dubbelingen in MBH’s. Als er helemaal geen einddatum bekend is in het systeem, blijft de einddatum van de MA open.
  • TA: De einddatum van TA’s kan gebaseerd worden op:
    • therapeutische informatie uit de lokale database. Bijvoorbeeld afkomstig uit het medicatieprofiel of de distributieregels;
    • logistieke informatie. Bijvoorbeeld de 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. Het kan zijn dat de gebruiksperiode van langdurige medicatie mogelijk niet overeenkomt met de therapeutische gebruiksperiode. De einddatum uit de verstrekking kan mogelijk eerder zijn dan het einde van de voorraad. Echter, afspraken over het toevoegen 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 minder vaak handmatige afsluiting van TA’s nodig is. Een einddatum in een TA die niet overeenkomt met de werkelijke therapeutische einddatum brengt vooral risico’s met zich mee voor de toedienlijsten.

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

Tijdens de transitie, waarin systemen onafhankelijk van elkaar migreren, kan het voorkomen dat medicatiegegevens die conceptueel in dezelfde MBH zouden moeten staan, niet dezelfde MBH-id hebben. Desondanks kunnen systemen, indien verstrekkingen verwijzen naar voorschriftgegevens, deze medicatiegegevens toch aan elkaar relateren. Op basis van deze relaties kunnen dubbele MBH's vervolgens worden geïdentificeerd en samengevoegd. Het behouden van bekende identificaties in MP6.12- en/of EDIFACT-berichten tijdens migratie is daarom cruciaal. Tabel 1 biedt een overzicht van de verschillende identificaties in EDIFACT, MP6.12 en MP9, en hun onderlinge relaties. Bovendien is er een pagina beschikbaar met voorbeelden die de informatie in de tabel verduidelijken.
Identificaties en hun onderlinge relaties

Tabel 1. Identificaties en hun onderlinge relaties
EDIFACT MP6.12 MP9
- MP6.12-vooraankondiging-id
(na overgang naar MP9 de id opbouwen met MA-id en VV-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

Met een duidelijk begrip van de algemene migratieafspraken, gaan we nu dieper in op de specifieke aspecten van MBH-identificaties en hun toepassing tijdens de transitiefase, zoals beschreven in de volgende paragraaf.

  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

4.3 Specifieke en generieke MBH-id

Tijdens de transitiefase maken we niet alleen gebruik van de specifieke MBH-id zoals gedefinieerd in de informatiestandaard MP9, maar ook van een generieke MBH-id. Het doel van de generieke MBH-id is om het probleem van meerdere MBH-id’s voor conceptueel dezelfde MBH te minimaliseren. 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). De generieke MBH-id is uniek voor één patiënt, maar niet uniek over verschillende patiënten.

De generieke MBH-id stelt systemen in staat om onafhankelijk van elkaar te migreren, terwijl medicatiebouwstenen toch bij elkaar worden gegroepeerd. Echter, de generieke MBH-id heeft beperkingen. Zo kunnen er bijvoorbeeld onterechte groeperingen van medicatiebouwstenen ontstaan met dezelfde MBH-id die in werkelijkheid onder verschillende MBH’s vallen. Bovendien is er een wens om de MBH niet op PRK te baseren, maar op werkzame stof. Daarom wordt de generieke MBH-id alleen in bepaalde situaties in de transitiefase toegepast (zie Actuele en recent gestopte versus historische medicatie en EVS versus andere systemen (AIS, eTDR,TRIS en PGO)). Het streven 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 beschreven in de informatiestandaard MP9 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, terwijl de extensie een unieke string binnen dit identificatiesysteem bevat.
  • 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. Indien bekend, wordt 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. In dat geval moet de leverancier een generieke MBH-id genereren op basis van de HPK.

4.3.1 Actuele en recent gestopte versus historische medicatie

De informatiestandaard MP9 maakt onderscheid tussen actuele, recent gestopte en historische medicatie; dit onderscheid is van belang bij migratie. Actuele medicatie betreft medicatie waarvan de stopdatum (op het moment van migratie) nog niet is verstreken. Dit omvat zowel huidige medicatie (waarbij het heden tussen de start- en stopdatum ligt) als toekomstige medicatie (waarbij het heden voor de startdatum ligt). 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 per PRK (of HPK) gebundeld in een generieke MBH-id. Hierdoor wordt een verschil gecreëerd in de migratie van actuele en recent gestopte medicatie versus historische informatie. Dit helpt het probleem van meerdere MBH-id’s voor bouwstenen die eigenlijk bij elkaar horen te beperken. 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-richtlijnen. Dit gebeurt niet bij historische informatie, tenzij daar een directe aanleiding voor is. Dit zorgt ervoor dat zorgverleners niet onnodig worden belast met reconciliatietaken (administratieve lasten) voor historische medicatie die vandaag de dag niet meer relevant is.

4.3.2 EVS versus andere systemen (AIS, eTDR,TRIS en PGO)

EVS’en hebben een andere rol dan AIS'en, eTDR's, TRIS’en en PGO's. Dit komt doordat MA’s leidend zijn in een MBH. Daarom gelden er andere afspraken voor EVS’en bij het toekennen van MBH-ids. Systemen anders dan EVS’en genereren in principe géén specifieke MBH-id, tenzij dit onvermijdelijk is, bijvoorbeeld wanneer er geen HPK of PRK beschikbaar is (zie Bijzondere situaties). Hieronder staan de afspraken voor het toekennen van een specifieke versus generieke MBH-id puntsgewijs opgesomd per type systeem. Tabel 2 toont een overzicht van de situaties waarin systemen een specifieke of generieke MBH-id moeten toekennen.

EVS:

  • Bij migratie kent het EVS voor actuele en recent gestopte medicatie een specifieke MBH-id toe.
  • Om ervoor te zorgen dat de generieke MBH-id in de historie verdwijnt, voegt het EVS nieuw aangemaakte MP9-bouwstenen niet toe aan een generieke MBH. In plaats daarvan start het EVS een nieuwe specifieke MBH.

AIS:

  • In de transitiefase kent het AIS generieke MBH-id’s toe.
  • Het AIS creëert in principe alleen medicatiebouwstenen met een specifieke MBH-id wanneer deze vanuit een ander XIS zijn ontvangen.

eTDR:

  • Er wordt bij migratie van een systeem onderscheid gemaakt tussen een los eTDR en een eTDR dat geïntegreerd is met een EVS.
  • Los eTDR:
    • Bij migratie kent het eTDR een generieke MBH-id toe.
  • Geïntegreerd eTDR en EVS:
    • Bij migratie volgen de medicatietoedieningen de MBH-id van de bijbehorende MA.
    • Dit betekent dat medicatietoedieningen die bij historische MA’s horen een generieke MBH-id krijgen en medicatietoedieningen die bij recent gestopte en actuele MA’s horen een specifieke MBH-id krijgen.
  • Hybride situatie:
    • Medicatietoedieningen volgen de MBH-id van de bijbehorende MP9-bouwsteen (MA, TA of WDS).
    • Indien het eTDR geen MBH-id kan achterhalen, kent het een specifieke MBH-id toe. Dit geldt bijvoorbeeld voor ongeplande toedieningen in de spoedsituatie of medicatietoedieningen gebaseerd op niet-digitale toedieninformatie.

TRIS:

  • Bij een TRIS zal over het algemeen geen sprake zijn van een migratie van gegevens.
  • Een TRIS volgt altijd het specifieke MBH-id van de MA waarop het WDS is gebaseerd.
  • Als er (nog) geen MA bekend is voor trombosemedicatie, zal het TRIS geen WDS beschikbaar stellen.

PGO:

  • Bij migratie kent een PGO een generieke MBH-id toe voor reeds geregistreerde MGB’s.
  • In de transitiefase wijst de PGO bij het starten van een MBH een generieke MBH-id toe.
  • De PGO creëert alleen MGB met een specifieke MBH-id wanneer deze vanuit het EVS/AIS zijn ontvangen.

Meerdere systeemrollen

  • Sommige systemen vervullen meerdere rollen, zoals EVS en AIS of EVS en eTDR. Dit geldt voor ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken.
  • Sommige systemen vervullen meerdere rollen, zoals EVS en AIS of EVS en eTDR. Dit geldt voor ziekenhuissystemen of systemen voor apotheekhoudende huisartspraktijken.
  • 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 met een specifieke MBH-id, kan de te migreren bouwsteen (TA of MTD) direct aan de juiste specifieke MBH-id worden gekoppeld.

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 Specifiek of Generiek[3] Generiek Specifiek of generiek
Migreren van historische medicatie Generiek Generiek Generiek Generiek Generiek
Starten van nieuwe MBH Specifiek Generiek Specifiek of generiek[4] 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. Afhankelijk of het systeem alleen de rol van eTDR heeft of ook de rol van EVS.
  4. Afhankelijk of de medicatietoediening gebaseerd is op een MP9 bouwsteen en welke MBH-id de medicatiebouwsteen heeft.

De implementatie van MP9 vereist een gestructureerde aanpak voor migratie tot beschikbaarstelling van medicatiegegevens binnen diverse informatiesystemen. Door de specifieke stappen en afspraken in dit hoofdstuk te volgen, kunnen leveranciers en zorgaanbieders binnen de keten op een veilige manier de informatiestandaard MP9 implementeren. Het nauwkeurig hanteren van migratieprocessen en het correct toekennen van MBH-ids dragen bij aan een efficiënte overgang en zorgen ervoor dat medicatiegegevens betrouwbaar beschikbaar zijn voor zorgverleners en patiënten.

5 Raadplegen/ontvangen, consolideren en reconciliëren

In de transitiefase kan een MP9-systeem bij het raadplegen van de medicatiegegevens informatie ontvangen van zowel andere MP9-systemen als van MP6.12/EDIFACT-systemen. Het kan ook voorkomen dat na het raadplegen blijkt dat MP9-medicatiegegevens nog niet correct zijn geplaatst in de juiste MBH. Dit resulteert in dubbele MBH’s die uiteindelijk moeten worden samengevoegd. Dit hoofdstuk beschrijft de systematiek voor de verwerking van medicatiegegevens in EVS’en, AIS’en, eTDR’s, TRIS’en en PGO’s in de hybride situatie. Deze systematiek is ontworpen om te zorgen voor een overzichtelijk medicatiedossier tijdens de transitiefase. Het reconciliëren naar een overzichtelijk medicatiedossier vereist ondersteuning vanuit de systemen aan de gebruiker. Dit hoofdstuk benadrukt deze aspecten. Het is aan de leverancier en zorgaanbieder (gebruikersgroep) om de juiste gebruikersondersteuning verder af te stemmen.

De aandachtspunten met betrekking tot gebruikersondersteuning zijn 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]].

Na de initiële raadpleging van medicatiegegevens door een MP9-systeem, volgt het cruciale proces van verwerken en matchen. Dit omvat het ontvangen van informatie in zowel MP9 als MP6.12 en Edifact formaat. Hierbij trachten systemen samenhangende medicatiegegevens te identificeren.

5.1 Verwerken en matchen van medicatiegegevens

5.1.1 Medicatiegegevens raadplegen

Via de transactie 'raadplegen medicatiegegevens' kan een MP9-systeem in de transitiefase medicatiegegevens ontvangen vanuit zowel MP9-systemen als vanuit MP6.12-AIS'en, via de transformatiedienst van de infrastructuurleverancier. In dit proces negeren eTDR-systemen de vertaalde MP6.12 verstrekkingen voor de toedienlijst (zie voor meer informatie Hoofdstuk 7 Aandachtspunten teodieninformatie). De medicatiegegevens afkomstig uit MP9-systemen kunnen zowel een specifieke als generieke MBH-id bevatten, zoals beschreven in het gedeelte over ‘Specifieke en generieke MBH-id’. Het is echter belangrijk om op te merken dat medicatievoorschriften van MP6.12/EDIFACT-EVS'en, in tegenstelling tot die van MP9-EVS'en, niet zichtbaar zijn voor andere XIS’en in de keten.

Wanneer mogelijk relateren systemen samenhangende medicatiebouwstenen aan elkaar op basis van een match in identificatie, zoals het MP6.12-vooraankondiging id of ‘verrijkt’ EDIFACT-id (zie Tabel 1). Als deze match niet mogelijk is, zoekt het systeem een match op basis van PRK. Een match op basis van PRK is minder betrouwbaar dan een match op basis van een match in identificatie. Daarnaast kan het voorkomen dat er geen match gevonden wordt. In die gevallen is tussenkomst van de gebruiker nodig om de informatie te reconciliëren. Het reconciliatieproces mag echter alleen worden uitgevoerd door een voorschrijver of apotheker. Tussenkomst van een zorgverlener heeft uiteraard niet de voorkeur. Systemen bieden waar mogelijk en waar van toepassing gebruikersondersteuning zodat administratieve lasten tot een minimum beperkt kunnen worden. Het is belangrijk dat medicatiegegevens voor risicopatiënten en toedienpatiënten snel worden gereconcilieerd. In de ambulante setting wordt apotheken dan ook ten zeerste aangeraden om de signaalfunctie van de infrastructuurleverancier te gebruiken, zodat zij worden geïnformeerd wanneer er nieuwe gegevens van een patiënt beschikbaar zijn. Hiermee hebben zij een trigger om de medicatiegegevens voor deze patiënt te reconciliëren. Indien gewenst kan deze signaalfunctie specifiek worden ingesteld om signalen te ontvangen van wijzigingen in het WDS.

Het EVS en AIS informeren de gebruiker over de herkomst van ontvangen AIS-informatie. Dit kan een conversie betreffen vanuit de infrastructuurleverancier (MP6.12-TA), een MP9-TA met generieke MBH-id, of een MP9-TA met specifieke MBH-id. De acties die een gebruiker kan ondernemen op basis van een MP6.12-TA versus een MP9-TA verschillen. Aanpassingen op een MP6.12-TA kunnen niet worden doorgegeven aan MP6.12-systemen via MP9-berichten. Daarnaast is het onderscheid tussen een TA met generieke MBH-id en specifieke MBH-id belangrijk voor de gebruiker. Een (actuele of recent gestopte) TA met generieke MBH-id staat nog niet gegroepeerd in dezelfde MBH als de bijbehorende MA. Daarnaast bevat een TA met generieke MBH-id, gegenereerd bij migratie, mogelijk nog niet alle aspecten van volledige MP9-informatie. Bijvoorbeeld: de TA kan een logistieke einddatum bevatten die niet overeenkomt met de werkelijke therapeutische einddatum (zie Einddatum in medicatiegegevens), of complexe doseerinstructies in vrije tekst (zie Doseerinstructies).

PGO’s kunnen tijdens de transitiefase dezelfde informatie via verschillende routes opvragen. Daarom is het belangrijk dat PGO’s prioriteit geven aan het type gegevens dat binnenkomt vanuit de verschillende systemen. Als er informatie beschikbaar is uit een MP9-versie nieuwer dan MP9.0.7, dan moet die informatie als leidend worden beschouwd. Als deze informatie niet beschikbaar is, wordt gekeken naar MP9.0.7-informatie met een MBH-id, en als laatste alternatief kan gebruik worden gemaakt van MP9.0.7-informatie zonder MBH-id of MP6.12-informatie (zie Bijlage: Early adopters van MP9). Afspraak is dat PGO’s tijdens de transitiefase de medicatiegegevens uit verschillende bronnen geïntegreerd tonen.

5.1.2 Voorschrift ontvangen en identificaties

Tijdens de transitiefase kan een MP9-AIS medicatievoorschriften ontvangen, zowel in MP9 als 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

Na ontvangst en identificatie van medicatiegegevens begint het kritische proces van het ontdubbelen van MBH’s. Dit is van vitaal belang om ervoor te zorgen dat er geen onterecht dubbele MBH’s in het dossier van de patiënt blijven bestaan.

5.2 Ontdubbelen van MBH's

Na raadplegen zijn er soms meerdere MBH-id’s voor conceptueel dezelfde MBH. Systemen zullen de medicatiegegevens indien mogelijk aan elkaar relateren op basis van identificatie of PRK en de gegevens consolideren. Vervolgens hanteren systemen bepaalde criteria om de gebruiker te helpen bepalen welke MBH behouden blijft en welke wordt gestopt. Dit maakt deel uit van het reconciliatieproces. Omdat alleen de voorschrijver en apotheker mogen reconciliëren gaan systemen verschillend om met het consolidatie- en reconciliatieproces.

EVS en AIS: Voor EVS- en AIS-systemen gelden specifieke criteria om te bepalen welke MBH behouden blijft en welke wordt gestopt.

  • Specifieke MBH-id gaat voor generieke MBH-id: Het systeem markeert 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 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 voor kiezen dit voorstel zonder wijziging te accorderen of de voorgestelde stopdatum aan te passen. Op basis van deze reden van wijzigen (‘loopt in andere medicamenteuze behandeling’) wordt de gebruikersinterface zo ontworpen dat voor de gebruiker inzichtelijk is dat er niet daadwerkelijk met de medicatie gestopt moet worden. De medicatiebouwsteen wordt gestopt in het kader van reconciliatie.

eTDR: In het proces van het samenstellen van een toedienlijst worden verschillende procedures gevolgd, afhankelijk van de rol van het systeem. In situaties waarin het systeem fungeert als een eTDR en een EVS, zoals vaak het geval is in ziekenhuizen, wordt de toedienlijst gebaseerd op een geverifieerde medicatielijst. Bij opname voert een voorschrijver of apotheker verificatie uit op het medicatiedossier, samengesteld op basis van zowel interne als externe medicatiegegevens. Op basis hiervan wordt een toedienlijst gegenereerd. Het is ook mogelijk dat de toedienlijst niet gebaseerd wordt op een geverifieerde medicatielijst. In dat geval consolideert het eTDR medicatiegegevens uit verschillende bronnen tot een toedienlijst. Het kan voorkomen dat er meerdere MBH-id’s zijn voor dezelfde MBH. Als het eTDR een relatie kan leggen tussen de MA en de TA op basis van een ID, worden de geplande toedieningen gebaseerd op de meest specifieke medicatiebouwsteen (MA, TA of WDS). Als het eTDR geen relatie kan leggen tussen de MA en de TA op basis van een ID, worden de medicatiegegevens indien mogelijk aan elkaar gerelateerd op basis van de PRK. Als de medicatiegegevens niet aan elkaar kunnen worden gekoppeld, wordt aan de gebruiker getoond dat er een MA is waarvoor geen bijbehorende TA gevonden kan worden. Dit kan bijvoorbeeld door een melding te tonen. De toediener moet vervolgens, in overleg met de voorschrijver/verstrekker, bepalen of er op basis van dit voorschrift toegediend moet worden.

TRIS: In de praktijk schrijft de trombosedienst slechts een beperkt aantal geneesmiddelen voor, meestal van kortlopende aard. Hierdoor is het proces van reconciliatie voor de trombosedienst niet van toepassing, of slechts in zeer beperkte mate. Reconciliatie wordt alleen uitgevoerd voor medicatie die de trombosedienst zelf voorschrijft of aanpast.

PGO: Vanuit PGO's kunnen MBH’s niet ontdubbeld worden. 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’). Bij de registratie van MGB in de MBH die moet blijven bestaan kan (automatisch) eerder geregistreerd MGB worden gestopt met de reden ‘loopt in een andere MBH’.

5.2.1 TA in andere MBH dan MA

In sommige gevallen bevindt een MP9-TA zich in een generieke MBH terwijl er een bijbehorende MP9-MA in een specifieke MBH bestaat. Dit resulteert in dubbele MBH’s die moeten worden ontdubbeld. Een EVS kan een stop-MA maken in de generieke MBH. Een AIS kan dit doen met een stop-TA. In beide gevallen wordt als reden voor het stoppen of wijzigen ‘loopt in andere medicamenteuze behandeling’ gebruikt. Het systeem maakt deze stop-MA of stop-TA beschikbaar en stuurt deze naar het AIS dat het bronsysteem is van de te stoppen MP9-TA, net zoals elke andere stop-MA of stop-TA. Nadat dit AIS de stop-bouwsteen heeft ontvangen, kan het een nieuwe TA in de specifieke MBH aanmaken. Systemen bieden waar mogelijk gebruikersondersteuning.

Er kunnen ook dubbele MBH’s ontstaan met MP6.12-TA’s. In deze situatie kunnen systemen de gebruiker de optie bieden om MBH’s te ontdubbelen. Als een gebruiker een MP6.12-TA stopt, kan elk ander MP9-systeem deze actie gebruiken, waardoor er geen nieuwe reconciliatie nodig is. Deze situatie geldt echter alleen tot het moment van het beschikbaarstellen van een nieuwere MP6.12-TA. Deze MP6.12-TA ontstaat bij elke nieuwe verstrekking vanuit een MP6.12-AIS. Met name bij een geneesmiddelendistributiesysteem (GDS) maken AIS’en vaak nieuwe verstrekkingen aan. In dit geval kan de verstrekkende apotheker geen nieuwe TA in de MBH van de MA aanmaken, omdat het AIS nog niet is overgestapt naar MP9. Als een voorschrijver het gebruik van het betreffende geneesmiddel daadwerkelijk wil stoppen, moet deze de apotheker informeren via andere routes dan MP9, zoals via een stopbericht via EDIFACT, telefonisch of via fax. MP9-systemen die de optie bieden om MP6.12-TA’s te stoppen, wijzen hun gebruikers op deze punten.

Bij het stoppen van een TA vanwege ontdubbeling wordt mogelijk niet direct een nieuwe TA in de specifieke MBH aangemaakt. Voor PGO’s en eTDR’s is dit een aandachtspunt bij het samenstellen van het medicatieoverzicht en de toedienlijst.

5.2.2 Duplicate MA’s

Een duplicaat van een MA kan ontstaan wanneer een EVS per abuis de MA van een ander heeft gemigreerd als zijn eigen MA (zie Onderscheid tussen eigen en andermans medicatiegegevens). Het doel is om deze duplicaat MA, die zich bevindt in een duplicaat MBH, te stoppen. Een EVS zal hiervoor een stop-MA maken, terwijl een AIS een voorstel-stop-MA kan maken. In de stop-bouwstenen wordt als reden voor het stoppen of wijzigen ‘loopt in andere medicamenteuze behandeling’ vermeld. Het systeem zal vervolgens deze stop-MA of voorstel-stop-MA sturen naar het EVS dat het bronsysteem is van de te stoppen MA.

Efficiënte gebruikersondersteuning en duidelijke processtappen zijn van essentieel belang bij het raadplegen, consolideren en reconciliëren van medicatiegegevens in de hybride situatie. Door systematische aanpakken zoals beschreven in dit hoofdstuk te implementeren, kunnen leveranciers en zorgaanbieders ervoor zorgen dat een geordend medicatiedossier behouden blijft gedurende de transitiefase naar MP9.

6 Aandachtspunten gedurende transitiefase

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

6.1 Doseerinstructies

In de transitiefase is het belangrijk om extra aandacht te besteden aan doseringen, vanwege zowel de functionele uitbreidingen in MP9 als de verschillen in technische uitwisseling tussen MP9, MP6.12 en EDIFACT. MP9 maakt gebruik van het FHIR-datatype Timing voor de uitwisseling van toedieningsschema’s, terwijl MP6.12 het HL7v3-datatype GTS (General Timing Specification) hanteert. Daarentegen bevatten doseerinstructies in EDIFACT de NHG Tabel25-standaard. Voor een soepele overgang naar MP9 is het cruciaal om deze verschillen te begrijpen.

6.1.1 MP6.12

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

In het bijzonder bij het omzetten van MP6.12 doseringen naar MP9 kan het soms moeilijk zijn om de exacte dosering te achterhalen. Dit komt door de complexiteit van het HL7v3-GTS model. Op de mapping pagina voor de MedMij gegevensdienst verstrekkingenvertaling is een opzet gemaakt die als leidraad kan dienen, zie bij TA/Doseerinstructie.

Hieronder volgt een beknopte 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 een frequentie van 1x per week om ervoor te zorgen dat de toedieningen op specifieke weekdagen plaatsvinden, wat helpt om de juiste doseringen te bepalen. 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 hierbij de voorkeur omdat deze geen onnodige precisie toevoegt. Daarnaast dienen de dagdelen inhoudelijk te worden opgenomen in tekst, zodat de betekenis niet verloren gaat voor de gebruiker, zoals een zorgverlener of patiënt.

  • Interval: In MP6.12 is er geen onderscheid tussen interval en frequentie, daarom wordt dit onderscheid expliciet in de tekst vermeld. 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: Het is niet mogelijk om ‘isFlexibel’ voor toedientijden gestructureerd te delen, daarom wordt deze informatie alleen in de tekst opgenomen.

6.1.2 EDIFACT (NHG Tabel25)

Er zijn verschillen tussen NHG Tabel25 en het doseringsmodel in MP9, wat vraagt om aandacht voor de migratie van doseringen en de mapping tussen beide modellen. Dit is belangrijk, aangezien MP9-systemen tijdens de transitiefase ook nog berichten via EDIFACT moeten ontvangen of versturen naar systemen die nog niet kunnen 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.

Na het bespreken van de doseerinstructies, verschuiven we nu de focus naar een ander cruciaal aandachtspunt tijdens de transitiefase: doseerverlagingen.

6.2 Doseerverlagingen

Doseerverlagingen worden binnen een MP9-AIS ingevoerd als nieuwe TA in het eigen systeem. Echter, het AIS past een eerdere MP6.12-verstrekking niet aan en genereert ook geen nieuwe ‘nep’-MP6.12-verstrekking. Als gevolg hiervan ontvangt een MP6.12-systeem bij raadpleging alleen de initiële MP6.12-verstrekking,die de doseerverlaging uit de meest recente MA en TA niet bevat. Dit komt overeen met de informatie die het systeem ontving vóór de introductie van MP9.

Een MP9-AIS kan echter anders opereren. Het is mogelijk dat het AIS de MP6.12-verstrekking niet als zodanig vastlegt in het eigen systeem. Het AIS genereert de MP6.12-verstrekking op het moment van raadplegen, op basis van de geldige TA(‘s) op de datum en tijd van de verstrekking. Dit zorgt ervoor dat een reeds gedane MP6.12-verstrekking achteraf inhoudelijk verandert, wat niet is toegestaan in MP6.12.

In het geval dat een EVS nog moet migreren naar MP9, terwijl het AIS al wel MP9 heeft geïmplementeerd, kan het volgende scenario zich voordoen bij een doseerverlaging. Het MP9-AIS heeft een TA aangemaakt op basis van een MP6.12-vooraankondiging. Vervolgens registreert het EVS een doseerverlaging. Omdat er geen nieuwe verstrekking nodig is, ontvangt het AIS geen MP6.12-vooraankondiging met betrekking tot deze verlaagde dosis. Zodra het EVS echter de overstap maakt naar MP9, kan het AIS de MA met verlaagde dosis raadplegen. In dit geval zal de TA een dosering bevatten die niet overeenkomt met de dosering in de MA. Desondanks mag deze TA wel worden opgenomen in de MBH van de MA.

Met een goed begrip van doseerverlagingen, is het tijd om te kijken naar bijzondere situaties die tijdens de migratie naar MP9 kunnen ontstaan.

6.3 Bijzondere situaties

6.3.1 Combinatiepreparaten

Combinatiepreparaten zijn geneesmiddelen waarin werkzame stoffen zijn gecombineerd, terwijl deze stoffen ook afzonderlijk verkrijgbaar zijn als losse geneesmiddelen. Voorbeelden hiervan zijn Exforge HCT of Atozet. Deze combinatiepreparaten kunnen vervangen worden door het gebruik van respectievelijk twee of drie losse geneesmiddelen.

Een voorschrijver kan ervoor kiezen om een dergelijk combinatiepreparaat voor te schrijven met een MA voor één geneesmiddel. Echter, in het vervolg van het medicatieproces kan het voorkomen dat niet het combinatiepreparaat, maar juist de afzonderlijke middelen geleverd worden. Dit kan verschillende redenen hebben, zoals financiële (het combinatiepreparaat is te duur) of logistieke (het combinatiepreparaat zit niet in het assortiment of is niet op voorraad). Dit kan bijvoorbeeld voorkomen in een openbare apotheek, maar kan ook wanneer een patiënt wordt opgenomen in of juist ontslagen uit een instelling. In dergelijke gevallen ontstaan er feitelijk meerdere TA’s met elk een eigen geneesmiddel in dezelfde MBH. Dit kan echter worden afgehandeld volgens de standaard MP9-regels.

Zowel in de transitiefase als bij migratie kunnen specifieke uitdagingen ontstaan die vragen om aanvullende afspraken. Deze worden nader toegelicht in de volgende secties.

6.3.1.1 Transitiefase

Deze passage beschrijft een situatie met combinatiepreparaten tijdens de transitiefase die speciale aandacht vereist. Dit komt doordat systemen die nog niet zijn overgestapt naar MP9 informatie uitwisselen met systemen die dat wel hebben gedaan. Een praktijkvoorbeeld verduidelijkt dit:

Stel, een MBH genaamd “MBH-1” is gestart voor een combinatiepreparaat X door MP9-EVS “ABC”. Dit EVS heeft een MA heeft voor bijvoorbeeld een maand. Later besluit een huisarts om dit recept te herhalen. Deze huisarts heeft echter nog geen MP9-systeem en stuurt vanuit EVS “DEF” een EDIFACT-voorschrift naar MP9-AIS “GHI”. Dit AIS herkent dat het om dezelfde MBH “MBH-1” gaat en splitst het preparaat op in middel XY en middel XZ, wat resulteert in twee parallelle TA’s binnen dezelfde MBH. Als een derde voorschrijver later de huidige situatie van deze MBH raadpleegt, ontvangt deze geen actieve MA (die was immers ‘ooit’ afgelopen na een maand), maar wel twee actieve, parallelle TA’s voor middel XY en middel XZ.

Een MBH vertegenwoordigt één (uitklapbare) regel op een medicatieoverzicht. Eventuele parallelle TA’s die hieraan gekoppeld zijn, kunnen gezamenlijk worden weergegeven onder die regel. Zo kun je deze bijvoorbeeld zien bij het uitklappen. Een voorschrijver stopt of wijzigt per MBH en niet per individuele TA. In het geval van bovenstaand praktijkvoorbeeld kan het systeem een aanvullende query uitvoeren om de PRK uit het MP9-EVS “ABC” (de MA) te achterhalen. De informatiestandaard MP9 kent hiervoor de queryparameter MBH-id. Hierdoor hoeft het systeem niet álle historische gegevens op te vragen, maar alleen voor die MBH waarin deze specifieke situatie zich voordoet. Het systeem kan deze situatie (geen actieve EVS-bouwsteen en actieve parallelle TA’s) herkennen. Vanaf AORTA 8.3 kunnen systemen dergelijke query’s zelfstandig op het LSP uitvoeren bij het raadplegen van gegevens, zonder dat UZI-pas authenticatie nodig is. In dit geval kan de PRK van de MA toch worden achterhaald en kunnen er wijzigingen of stopzettingen worden doorgevoerd volgens de normale MP9-regels.

Voortbordurend op dit praktijkgeval:

Wanneer het systeem niet in staat is geweest om de MA met het combinatiepreparaat te achterhalen én de voorschrijver zich niet bewust is van het combinatiepreparaat, ontstaat de vraag welk geneesmiddel moet worden opgenomen in de stop-MA. Omdat de voorschrijver twee TA’s ziet met middel XY en XZ, maar een stop-MA slechts één geneesmiddel kan bevatten, ontstaat er een dilemma. Voor deze praktijksituatie zijn er twee opties om de parallelle TA’s te stoppen:

1. Een mogelijkheid is om in de stop-MA een ‘magistraal’ geneesmiddel op te nemen met beide ingrediënten, namelijk middel XY en XZ uit de parallelle TA’s. Zelfs als de voorschrijver alleen één van de twee middelen wil stoppen of wijzigen, is de afspraak om:
  • de hele MBH op deze manier te stoppen en;
  • een of meer nieuwe MBH’s te starten met de gewenste eindsituatie voor elk middel.
2. Een andere mogelijkheid is om in de stop-MA het geneesmiddel van een van de twee TA’s op te nemen. Met de stop-MA worden alsnog beide TA’s gestopt. Beide situaties vereisen een nieuw verstrekkingsverzoek naar de apotheek. Een bijeffect van deze aanpak 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. Dit is de beste oplossing voor de medicatieveiligheid.

6.3.1.2 Migratie en ontdubbelen

Na migratie kan een vergelijkbare situatie ontstaan. Stel dat er vóór de migratie een voorschrift was voor combinatiepreparaat X, waarbij de apotheker dit heeft gesplitst in middel XY en XZ. Het migrerende AIS heeft twee mogelijkheden:

  1. Het AIS heeft een relatie naar het oorspronkelijke voorschrift met bijbehorend PRK (van het combinatiepreparaat).
  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). Hierdoor ontstaan 2 parallelle TA's in één generieke MBH. Als de MA nog niet historisch was bij migratie, krijgt deze een specifieke MBH van het EVS (zie paragraaf Specifieke en generieke MBH-id). Vervolgens kunnen er twee MBH’s ontstaan die ontdubbeld kunnen worden volgens 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 zoals eerder 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. Na migratie ontstaan dus 3 verschillende MBH’s die conceptueel eigenlijk één MBH hadden moeten zijn. Deze situatie moet door een zorgverlener herkend en ontdubbeld worden volgens de normale afspraken bij migratie/hybride (zie paragraaf Ontdubbelen van MBH's).

6.3.1.3 Tot slot

Het is belangrijk om te erkennen dat, ondanks de mogelijkheden van MP9, er momenten zullen zijn waarop zorgverleners op een andere manier met elkaar moeten communiceren, vooral bij complexe grensgevallen.

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

De werkwijze voor de migratie van medicatie voorgeschreven in het buitenland en ‘over the counter’-medicatie (zelfzorgmedicatie) hangt af van twee belangrijke factoren:

  1. Heeft het middel een PRK of HPK?
  • Als het middel geen PRK of HPK heeft, kan er geen generieke MBH-id worden gegenereerd. Volgens de afspraak wordt voor deze middelen dan een specifieke MBH-id gegenereerd, zelfs als het historische gegevens betreft. Dit geldt voor het AIS, eTDR en PGO.
  1. Is het geneesmiddel voorgeschreven of is de behandeling overgenomen door een voorschrijver?
  • Als dit niet het geval is, volstaat het vastleggen van MGB.
  • Als de voorschrijver echter verantwoordelijk is voor de behandeling, is het wenselijk om bij migratie een MA aan te maken.

6.3.3 Magistralen

Sinds MP6.12.3 is het verplicht om de ingrediënten van magistrale preparaten gestructureerd uit te wisselen via ingrediëntcodes. Helaas blijkt dat systemen deze vereiste niet altijd naleven. In plaats daarvan wordt de samenstelling van magistrale preparaten vaak als vrije tekst uitgewisseld. Als gevolg hiervan voldoen de gemigreerde historische gegevens mogelijk niet aan de eis van gestructureerde en gecodeerde vastlegging van magistrale ingrediënten. Daarom is deze eis in MP9 versoepeld voor gegevens die in het verleden zijn aangemaakt.

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

Na het behandelen van bijzondere situaties, gaan we nu verder met het verkennen van andere belangrijke overwegingen tijdens de implementatie van MP9.

6.4 Patiëntportalen

Patiëntportalen van XIS’enkunnen patiënten de mogelijkheid bieden om MGB te registreren. Indien het EVS of AIS deze informatie uit het patiëntportaal beschikbaar stelt, zijn de volgende aandachtspunten van belang:

  • Het patiëntportaal dient de patiënt in staat te stellen bij de registratie van MGB gebruik te maken van MP9-bouwstenen, zowel afkomstig uit het betreffende EVS of AIS als uit andere XIS’en. Dit helpt om MGB correct te registreren in de MBH van de bijbehorende MA en/of TA.
  • Het patiëntportaal dient de patiënt de mogelijkheid te bieden om MGB te registreren via G-Standaard coderingen.

In dit hoofdstuk hebben we de cruciale aandachtspunten besproken die leveranciers moeten overwegen tijdens de transitiefase naar MP9-systemen. Van doseerinstructies tot bijzondere situaties met combinatiepreparaten en magistrale preparaten, elke fase van de migratie vereist gedegen planning en afstemming. Door het begrijpen van de technische verschillen tussen MP9 en eerdere berichtenstromen en het implementeren van passende omzettingsstrategieën, kunnen leveranciers een soepele overgang waarborgen voor zorgverleners en patiënten.

7 Aandachtspunten toedieninformatie

Dit hoofdstuk gaat in op een aantal specifieke situaties en afspraken die gelden voor de eTDR-systemen, zoals het negeren van MP6.12 informatie, het omgaan met digitale en niet-digitale toedieninformatie en het gebruik van maatwerkkoppelingen.

7.1 Negeren van MP6.12 verstrekkingen

Tijdens de transitiefase kan een MP9-systeem via de transactie ‘raadplegen medicatiegegevens’ medicatiebouwstenen ontvangen van zowel MP9-systemen als van MP6.12-AIS'en, via de transformatiedienst van de infrastructuurleverancier. Omdat MP6.12 verstrekkingen niet alle aspecten van een volledige MP9-TA bevatten, is het niet mogelijk om MP6.12-informatie te integreren met MP9-informatie op een toedienlijst. Zodra een eTDR voor een patiënt overgaat naar MP9, worden de vertaalde MP6.12 verstrekkingen die via het LSP beschikbaar zijn genegeerd.

Het negeren van de vertaalde MP6.12 verstrekkingen is gebaseerd op de HL7:id/@root. Een voorbeeld van de root oid is: concat('1.3.6.1.4.1.58606.1.', @root). Dit betekent dat een TA/id/@root die begint met 1.3.6.1.4.1.58606.1. is geconverteerd vanuit MP6.12.

Na het behandelen van het negeren van MP6.12 verstrekkingen, richt dit hoofdstuk zich nu op het onderscheid tussen digitale en niet-digitale toedieninformatie binnen het toedienproces.

7.2 Digitale en niet-digitale toedieninformatie

Wanneer de apotheek (WPDK) de overstap maakt naar MP9, kan het bijbehorende eTDR voor die patiënt ook overgaan naar MP9. Echter, het kan voorkomen dat de patiënt medicatie ontvangt vanuit een andere apotheek. Dit kan bijvoorbeeld medicatie betreffen die is verstrekt door de poliklinische apotheek of tijdens de avond-, nacht- en weekenddienst (ANW) door de dienstapotheek. Het kan zijn dat deze apotheek nog niet is overgestapt naar MP9. Alleen als de apotheek (WPDK) de volledige verantwoordelijkheid voor de verstrekte medicatie overneemt, kan deze een MP9-TA aanmaken die door het eTDR kan worden gebruikt voor de toedienlijst.

Deze werkwijze kan resulteren in de beschikbaarheid van zowel digitale als niet-digitale toedieninformatie voor de toediener. Het kan echter ook voorkomen dat er helemaal geen digitale toedieninformatie beschikbaar is voor de toediener.

7.2.1 Geen digitale toedieninformatie

In bepaalde situaties kan het gebeuren dat de toediener niet over digitale toedieninformatie (MA/TA) beschikt. Wanneer er geen digitale toedieninformatie beschikbaar is, kunnen medicatietoedieningen alsnog digitaal worden geregistreerd. Deze medicatietoedieningen starten dan een nieuwe MBH - er is immers geen MA of TA beschikbaar – met een specifieke MBH-id. Medicatietoedieningen die niet op MP9-informatie zijn gebaseerd maar wel bij hetzelfde voorschrift horen, worden idealiter in dezelfde specifieke MBH geregistreerd.

Een voorbeeld illustreert een situatie waarin deze werkwijze van toepassing is. Stel, er is een EVS dat een MP6.12-voorschrift stuurt naar een AIS dat nog niet is overgestapt naar MP9. Dit AIS is een andere apotheek dan de apotheek WPDK. Het AIS verstrekt de medicatie en levert een MP6.12 verstrekking op. De apotheek WPDK werkt met een MP9-systeem. Hoewel de MP6.12 verstrekking raadpleegbaar is voor de apotheek WPDK via de transformatiedienst, zal het eTDR deze vertaalde MP6.12 verstrekkingen negeren Er is dan geen digitale toedieninformatie beschikbaar voor het eTDR. De toediener zal de medicatie toedienen op basis van niet-digitale informatie.

Figuur 10. Schematische weergave van de situatie waarbij de toedienorganistatie, in de hybride situatie, niet over digitale toedieninformatie (MA/TA) beschikt.

7.2.2 Digitale en niet-digitale toedieninformatie

In sommige situaties kan het voorkomen dat de toediener beschikt over zowel digitale als niet-digitale toedieninformatie. Tijdens de hybride situatie wordt deels met MP9 gewerkt en blijft de huidige werkwijze (papieren toedienlijst, telefonisch contact tussen zorgverleners, enzovoort) deels behouden. Als er digitale en niet-digitale toedieninformatie beschikbaar is, worden de medicatietoedieningen bij voorkeur geregistreerd op basis van de digitale toedieninformatie (MA/TA).

In het volgende voorbeeld wordt een situatie geschetst waarin deze werkwijze wordt toegepast. In deze situatie is er een EVS dat een MP9 MA beschikbaar maakt. Daarnaast stuurt het EVS een voorschrift aan een AIS dat nog niet is overgestapt naar MP9. Het gaat in deze situatie om een andere apotheek dan de apotheek WPDK. Dit AIS verstrekt de medicatie en stelt een MP6.12 verstrekking beschikbaar. De apotheek WPDK betreft een MP9 systeem. De MP6.12 verstrekking is door de transformatiedienst raadpleegbaar voor de apotheek WPDK. Daarnaast ontvangt de apotheek WPDK een MP9 MA vanuit het EVS. Het eTDR zal de vertaalde MP6.12 verstrekkingen negeren maar ontvangt wel een MP9 MA bij het raadplegen van medicatiegegevens. Tenzij de apotheek WPDK de volledige verantwoordelijkheid voor de verstrekte medicatie overneemt en een TA aanmaakt is er voor het eTDR alleen een MP9 MA digitaal beschikbaar. Daarnaast kan het zijn dat de toediener beschikt over niet digitale toedieninformatie vanuit de apotheek die nog niet overgestapt is naar MP9.

Figuur 11. Schematische weergave van de situatie waarbij de toedienorganistatie, in de hybride situatie, over digitale en niet-digitale toedieninformatie beschikt.

Terwijl we nu begrijpen hoe in het toedienproces omgegaan wordt met digitale en niet-digitale toedieninformatie, kijken we nu naar de impact van maatwerkkoppelingen op de eTDR systemen.

7.3 Maatwerkkoppelingen voor eTDR's

In de praktijk worden verschillende maatwerkkoppeling gebruikt tussen eTDR’s en andere XIS’en. De hybride situatie kan invloed hebben op deze maatwerkkoppelingen. Deze paragraaf beschrijft de afspraken over twee specifieke maatwerkkoppelingen.

7.3.1 Maatwerkkoppeling gebaseerd op MP9

In de huidige situatie bestaan er maatwerkkoppelingen tussen eTDR’s en andere XIS’en. Als het XIS dat de toedieninformatie via de maatwerkkoppeling aanlevert aan het eTDR overgestapt is naar MP9 kan het zijn dat er sprake is van een maatwerkkoppeling gebaseerd op het MP9 datamodel. Er is afgesproken dat leveranciers vrij zijn om in een dergelijke maatwerkkoppeling al dan niet een MBH-id op te nemen. Als er in de maatwerkkoppeling een MBH-id wordt meegegeven, moet het eTDR deze gebruiken bij de registratie van medicatietoedieningen.

7.3.2 Maatwerkkoppeling voor het tromboseschema

In de huidige situatie bestaan er maatwerkkoppelingen tussen eTDR’s en TRIS’en. Het TRIS stuurt een tromboseschema naar het eTDR of stelt deze beschikbaar. Totdat er in MP9 een MA en WDS beschikbaar zijn, zal het eTDR / de toediener het tromboseschema op de gebruikelijke wijze ontvangen. Dit kan gebeuren via een maatwerkkoppeling of op een niet-digitale manier. Wanneer het eTDR een tromboseschema ontvangt via een maatwerkkoppeling en er tegelijkertijd MP9-gegevens beschikbaar zijn(MA/TA), worden het tromboseschema en de MP9 gegevens samengevoegd. De samenvoeging kan worden uitgevoerd op basis van het Burgerservicenummer (BSN) en het geneesmiddel. Medicatietoedieningen kunnen worden geregistreerd onder de MA en/of TA. Hierbij worden de uitgangspunten voor het toekennen van een MBH-id vanuit een eTDR gevolgd, zoals beschreven in paragraaf 3.3.2. Om het tromboseschema samen te voegen met MP9-gegevens, moeten de geneesmiddelcodes van het TRIS worden gekoppeld aan de codes zoals gebruikt in MP9. Aangezien TRIS’en momenteel nog niet met de G-standaard werken, verschillen deze geneesmiddelcodes van die in MP9. Het is de verantwoordelijkheid van de leveranciers om de eventueel benodigde koppeltabellen te maken, gebruiken en onderhouden. Het eTDR bepaalt tot welk moment een maatwerkkoppeling nodig is voor de doseerinformatie vanuit de trombosedienst. Op het moment dat het eTDR zowel een MP9-WDS als informatie via de maatwerkkoppeling ontvangt van dezelfde bron-TRIS, kan het eTDR aangeven dat de maatwerkkoppeling voor die patiënt niet langer nodig is.

Concluderend biedt dit hoofdstuk inzicht in essentiële aspecten van toedieninformatie voor eTDR-systemen tijdens de transitie naar MP9. Door het negeren van MP6.12 verstrekkingen, de variabiliteit tussen digitale en niet-digitale toedieninformatie, en de flexibele omgang met maatwerkkoppelingen, kunnen leveranciers effectief MP9 implementeren voor het toedienproces.

8 Bijlage: Verrijken EDIFACT id en vullen MP6.12 prescription/id en MP6.12 vooraankondiging-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 wanneer er gebruik wordt gemaakt van unieke identificaties. Relaties vastleggen tussen EDIFACT-, MP6.12- en MP9-informatie helpt (geautomatiseerde) ontdubbeling en reconciliatie. Dit vermindert de administratieve lasten voor zorgverleners met betrekking tot het krijgen van een actueel medicatiedossier. Hieronder volgen gedetailleerde uitleg en richtlijnen voor het verrijken van het EDIFACT-id en het vullen van de relatie naar het voorschrift in de MP6.12-verstrekkingen en de MP6.12 vooraankondiging.

8.1 Huidige situatie

De huidige situatie is als volgt: een voorschrijver stuurt één of meer voorschriften via EDIFACT naar de apotheker met een MEDREC-AAN (aanvraag-) bericht. Nadat de apotheker het medicijn heeft verstrekt, stuurt hij een MEDREC-AFL (aflever-) bericht naar de huisarts van de patiënt, waarin indien mogelijk een verwijzing naar de voorschrift-ID’s van het MEDREC-AAN bericht wordt opgenomen. De huisarts ontvangt op deze manier ook AFL-berichten voor door specialisten voorgeschreven medicatie. Echter, deze AFL-berichten hebben géén relatie naar een MP6.12-vooraankondiging.

De huisarts kan aan de hand van het al dan niet aanwezige voorschrift-id bepalen of het een aflevering van een eigen voorschrift betreft of van een andere voorschrijver. Deze koppeling is niet afhankelijk van het medicament, waardoor het ook mogelijk is wanneer de apotheker iets anders aflevert dan voorgeschreven.

Om de effectiviteit van ontdubbeling en reconciliatie te verbeteren, is het belangrijk om de huidige situatie te begrijpen waarbij voorschrift- en afleverberichten via EDIFACT worden uitgewisseld. Daarnaast streven we naar een situatie waarin identificaties consistent gematcht worden tussen EDIFACT, MP6.12 en MP9.

8.2 Gewenste situatie en uitgangspunten

De gewenste situatie is om ontdubbelen en reconciliatie zoveel mogelijk te vergemakkelijken, zelfs met eerdere versies van de standaard zoals EDIFACT en MP6.12, door identificaties te matchen. Het vermijden van aanpassingen aan (legacy) EDIFACT-implementaties die dit proces verder kunnen vereenvoudigen, is echter van cruciaal belang.

In principe bevatten verstrekkingen altijd een verwijzing naar de identificatie van het bijbehorende voorschrift, ongeacht of deze beide in hetzelfde berichtformaat zijn verstuurd.

8.2.1 MP6.12: relatie leggen vanuit verstrekking naar 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 bevat een prescription/id. Dit prescription/id moet verplicht opgenomen worden in de MP6.12-verstrekking.

Na migratie van een EVS naar MP9 wordt bij het verzenden van een MP6.12 vooraankondiging het prescription/id gevuld met het id van de MA en, indien mogelijk, de id van de VV. De opbouw van de MP6.12 vooraankondiging-id is als volgt:

  • in de prescription-id een @root met de oid van de MA, geprefixt met ‘1.3.6.1.4.1.58606.1.3.’
  • in de extension een unieke identifier, opgebouwd als volgt:
    • de MA-id @extension
    • een '|'
    • een string om de identifier uniek te maken. Als de totale lengte binnen de 64 karakters (AORTA-restrictie) blijft, kan dit een VV-id @extension zijn. Als de lengte de 64 karakters overschrijdt (bijvoorbeeld wanneer beide extensions een uuid bevatten), kan een volgnummer of een datum/tijd worden gebruikt. De eis blijft dat deze identifier eeuwig wereldwijd uniek moet zijn.

8.2.2 Verrijkt EDIFACT-id

Wanneer het voorschrift via EDIFACT is ontvangen, kan het zijn dat de referentie tussen voorschrift en verstrekking niet is ingevuld. De EDIFACT-identificatie is niet wereldwijd uniek, maar alleen uniek binnen een organisatie. Bovendien kan deze identificatie niet rechtstreeks worden gebruikt in MP9- of MP6.12-berichten vanwege het ontbreken van ondersteuning voor de OID-systematiek in EDIFACT. Het EDIFACT-id veld heeft een maximale lengte van 35 posities, wat te beperkt is voor het invoeren van een volledige OID. De overeengekomen methode om het EDIFACT-id te ‘verrijken’ voor gebruik in HL7v3 / FHIR communicatie kan als volgt worden samengevat:

  • 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, gescheiden door een pipe separator.
    • Het voorschrift-id wordt verkregen uit het EDIFACT S05 LIN segment.
    • De AGB-code van de verzender wordt verkregen uit het EDIFACT S01 NAD+MS segment.

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

8.2.2.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"/>
    

In de gewenste situatie streven we ernaar om ontdubbeling te vergemakkelijken door goede relaties te leggen tussen EDIFACT-, MP6.12- en MP9-informatie. Dit heeft directe impact op XIS-leveranciers, die moeten zorgen dat alle systemen correct zijn geconfigureerd om deze relaties te ondersteunen.

8.3 Impact voor de XIS-leveranciers

8.3.1 AIS

Het is belangrijk om het MP6.12-verstrekking/prescription id correct in te vullen: te weten met het prescription/id uit de MP6.12-vooraankondiging. Bij een EDIFACT-voorschrift gebruikt het AIS hiervoor het verrijkt EDIFACT-id.

8.3.2 Alle systemen

Zie het overzicht van identificaties in de paragraaf Samenhang van identificaties in EDIFACT, MP6.12 en MP9:

  • Gebruik dit overzicht bij migratie om relaties in MP9-bouwstenen te leggen.
  • Herken en maak gebruik van deze identificaties om te consolideren én gebruikers te ondersteunen bij het reconciliëren, bijvoorbeeld door de medicatie-informatie te ordenen bij de juiste MBH.

Het verrijken van EDIFACT-id's en het vullen van MP6.12-voorschrift-id's zijn essentieel voor het ondersteunen van reconciliatie in de hybride situatie. Door consistente identificatiemechanismen te implementeren, kunnen zorgverleners makkelijker een medicatiedossiers opbouwen en worden de administratieve lasten verminderd. XIS-leveranciers spelen een cruciale rol in het ondersteunen van deze processen door ervoor te zorgen dat hun systemen deze identificaties correct verwerken en integreren.

9 Bijlage: Early adopters van MP9

Op dit moment zijn er verschillende systemen die al informatie uitwisselen via MP9 (versie MP9.0.7). Dit hoofdstuk belicht de ‘early adopters’ van MP9. Deze early adopters zijn aangesloten op specifieke aspecten van MP9 vanuit verschillende trajecten. Als gevolg daarvan passen sommige early adopters de MBH-id al toe, terwijl anderen dit nog níét doen.

Early adopters MP9 met (mogelijk) MBH-id In MP9.07 bestaat er geen generieke MBH-id. Als een early adopter van MP9 al medicatiebouwstenen met een MBH-id beschikbaar heeft gesteld, zijn dit altijd specifieke MBH-id’s. Deze medicatiebouwstenen kunnen dus worden beschouwd 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: Bij het programma VIPP GGZ (VIPP 3) worden MBH-id’s gebruikt, wat de overgang naar MP9 3.0.0 (of latere versie) waarschijnlijk probleemloos maakt, omdat het programma gericht was op EVS’en.
  • BgZ: Bij de BgZ is het waarschijnlijk dat er nog geen gebruik gemaakt is van MBH-id’s.
  • Ketenzorg: Voor ketenzorg geldt dat de MBH-id geen vereiste is én waarschijnlijk nog niet wordt ondersteund.
  • MedMij:
    • Dienstverlener zorgaanbieder (DVA-)BgZ en DVA-huisartsgegevens: Bij de DVA-BgZ en DVA-huisartsgegevens is het onwaarschijnlijk dat er al MBH-id’s zijn gegenereerd, gezien dit geen onderdeel was van de kwalificatie.
    • DVA-verstrekkingenvertalingen: Bij DVA-verstrekkingenvertalingen worden MBH-id’s momenteel gevuld met MP6.12-verstrekking id’s, met als doel een relatie te leggen tussen de TA en MVE. Deze id is niet geschikt voor MP9 3.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 worden genegeerd, vooral als deze informatie al beschikbaar is via een andere route, zoals MP6.12. In sommige gevallen kan een systeem ervoor kiezen om informatie uit deze bron weer te geven aan de gebruiker, maar er vindt geen reconciliatie plaats op basis van id of PRK.

De variatie onder early adopters van MP9 in het gebruik van de MBH-id illustreert de diversiteit en complexiteit van de implementatie van deze nieuwe standaard binnen de gezondheidszorg. Terwijl sommige systemen al profiteren van de voordelen van gestandaardiseerde medicatie-identificatie, blijft voor anderen de integratie van deze id een uitdaging. De voortdurende ontwikkeling en adoptie van MP9 zullen naar verwachting bijdragen aan een meer uniforme en efficiënte informatie-uitwisseling in de toekomst.

10 Bijlage: Afkortingen en definities

Deze bijlage biedt een uitgebreide lijst van afkortingen en definities die cruciaal zijn voor een goed begrip van de context en uitdagingen die komen kijken bij de implementatie van MP9. Het begrijpen van deze termen is essentieel voor het correct interpreteren en toepassen van de afspraken in de praktijk.

Afkortingen

Definities

  • Actuele medicatie: Medicatie waarvan de stopdatum nog niet is verstreken, op een bepaald moment. Dit omvat zowel huidige (waarvan de huidige datum tussen tussen start- en stopdatum ligt) als toekomstige (waarvan de huidige datum vóór de startdatum ligt) medicatie.
  • (actief beschikbaarstellen: Het proces waarbij een systeem zijn eigen MP9-gegevens ter beschikking stelt voor raadpleging door andere systemen en/of het versturen van deze gegevens naar andere systemen.
  • Co-existentie: De situatie waarin binnen de keten de noodzaak bestaat tot het uitwisselen van gegevens in meerdere standaarden.
  • Consolideren: Het proces waarbij het informatiesysteem beschikbare medicatiegegevens samenvoegt met ontvangen gegevens uit verschillende bronnen. Het doel is om een enkel, uniform en coherent medicatiedossier op te bouwen.
  • Generieke MBH-id: De generieke MBH-id wordt gegeneerd op een zodanige manier dat systemen onafhankelijk van elkaar dezelfde identificatie kunnen maken voor medicatiebouwstenen met dezelfde prescriptiecode (PRK) of, als de PRK niet bekend is, de handelsproductcode (HPK). De generieke MBH-id gebaseerd op PRK bestaat uit een algemene OID-root genaamd ‘generiekeMBHIdPRK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.2), samen met de PRK in de OID-extension. De generieke MBH-id gebaseerd op HPK bestaat uit een algemene OID-root genaamd ‘generiekeMBHIdHPK’ (uitgegeven door Nictiz: 2.16.840.1.113883.2.4.3.11.61.3), samen met de HPK in de OID-extension. Een generieke MBH-id is uniek binnen een patiënt, maar niet uniek over verschillende patiënten heen. Deze variant van de MBH-id is uitsluitend bedoeld als tijdelijke oplossing tijdens 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 eerdere berichtenstromen ondersteunt om uitwisseling van medicatiegegevens gedurende de transitiefase te kunnen waarborgen.
  • Migreren: Het omzetten van de reeds beschikbare medicatiegegevens in een systeem 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 het opvragen van beschikbare medicatiegegevens, zowel gegevens die conform de MP9-standaard zijn als gegevens met het MP6.12-formaat. (raadplegen en reconciliëren zijn nauw aan elkaar verwant en vormen samen met het gesprek met de patiënt/ cliënt een onderdeel van de verificatie).
  • Recent gestopte medicatie: Medicatie die in de afgelopen twee maanden is geëindigd of gestopt.
  • Reconciliëren: het met elkaar in overeenstemming brengen van beschikbare gegevens met de ontvangen gegevens. Dit omvat het vergelijken van gerelateerde informatie uit verschillende bronnen om eventuele discrepanties of tegenstrijdigheden te identificeren en op te lossen. Dit proces kan menselijke interventie of beoordeling vereisen om een overzichtelijk en accuraat medicatiedossier op te bouwen.
  • Specifieke MBH-id: Een specifieke MBH-id is wereldwijd en eeuwig uniek. In de MP9-standaard is de MBH-id beschreven als specifiek. Deze MBH-id bevat een OID-root en -extensie, waarbij de root een OID voor een uniek ‘identificatiesysteem’ van elke uitgevende organisatie bevat, terwijl de extensie een unieke string binnen dat systeem bevat. Bij migratie wijst het EVS specifieke MBH-id’s toe aan alle actuele en recent gestopte MP9-bouwstenen. Systemen behalve het EVS genereren over het algemeen geen specifieke MBH-id’s aan, maar gebruiken ontvangen specifieke MBH-id’s van het EVS indien beschikbaar.
  • Transformatiedienst: De transformatiedienst wordt aangeboden door de infrastructuurleverancier bij het raadplegen van medicatiegegevens via MP9 op het Landelijk Schakelpunt (LSP). Deze dienst converteert MP6.12-verstrekkingen vanuit MP6.12-AIS'en naar een MP9-TA formaat. Dit betekent dat bij een MP9-query van andere MP9-systemen het MP9-systeem de MP9-bouwstenen ontvangt zoals in een volledige MP9-situatie, en dat vanuit MP6.12-AIS'en de geconverteerde gegevens (MP6.12-TA's) beschikbaar zijn.
  • Transitie: Het proces van migreren en co-existentie dat uiteindelijk leidt tot de brede gegevensuitwisseling via MP9.
  • Transitiefase: De transitiefase, die begint met de migratie van het eerste systeem, omvat de periode waarin systemen de informatiestandaard MP9 implementeren. Deze fase eindigt wanneer alle systemen volledig overgestapt zijn naar MP9.
  • Prescription/id in MP6.12-verstrekking: Dit is de identificatie van het voorschrift waarop de MP6.12-verstrekking is gebaseerd. De prescription/id kan verschillende typen waarden hebben, 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). Deze identificatie kan worden gebruikt 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 kan worden gebruikt. Om deze id uniek te maken, kan een ‘verrijkt’ EDIFACT-id worden samengestekd. Hierbij wordt een vaste OID-root gebruikt, samen met een OID-extension die bestaat uit het EDIFACT-id en de organisatie-id (hash).

11 Bijlage: Documenthistorie en beheerproces

De wijzigingenhistorie van de implementatiehandleiding wordt bijgehouden in deze bijlage. Wijzigingsverzoeken worden geregistreerd binnen het project Medicatieproces, onder epic MP-431 Hybride situatie, zie filter Project = MP AND “Epic Link” = MP-431. Elk van deze wijzigingsverzoeken wordt gerelateerd aan epic MP-431 Hybride situatie. De releasenotes verwijzen naar deze wijzigingsverzoeken.

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 Aandachtspunten gebruikersondersteuning, zie filter Project = MP AND "Epic Link" = MP-693. Elk van deze de wijzigingsverzoeken wordt gerelateerd aan epic MP-693 Aandachtspunten gebruikersondersteuning.

Versie Datum Releasenotes
5 4 juli 2024 Versie t/m sessie 07 maart 2024 van werkstroom Migratie/hybride situatie
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