mp:Vdraft MigratieHybride

Deze pagina bevat voorgenomen afspraken betreffende werkproces gedurende transitiefase en hybride situatie.

1 Leeswijzer

Dit document bevat voorgenomen afspraken voor het werkproces in de transitiefase. Systemen hebben dan te maken met een hybride situatie. De transitiefase betreft 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. Systemen die gedurende de transitiefase overgaan naar MP9 hebben te maken met een hybride situatie: de systemen zullen zowel MP9 als MP6.12/ EDIFACT moeten ondersteunen. Er bestaan verschillen tussen MP9 en MP6.12/ EDIFACT. Vanwege deze verschillen zullen er gedurende de gehele transitiefase aanvullende afspraken nodig zijn. Dit betreffen afspraken in aanvulling op de informatiestandaard MP9. Het gaat daarbij om:

• het migreren (het omzetten van de reeds beschikbare medicatiegegevens in een patiëntdossier naar een datamodel dat MP9-bouwstenen ondersteunt),
• het (actief) beschikbaarstellen (het proces van het ter beschikking stellen van MP9-gegevens zodat andere systemen deze informatie kunnen raadplegen en/of het sturen van MP9-gegevens),
• het raadplegen (het proces van opvragen van beschikbare medicatiegegevens, zowel MP9-gegevens als MP6.12-gegevens), en
• het reconciliëren (het samenbrengen en ontdubbelen van beschikbare gegevens met de ontvangen gegevens met als doel een overzichtelijk medicatiedossier op te bouwen).

Het voorgenomen werkproces is uitgedacht in de werkstroom Migratie en hybride situatie, waaraan het programmateam Medicatieoverdracht en een deel van de leveranciers deelnemen. Dit document bevat het beoogde werkproces zoals besproken in de sessies 18-11-2021 t/m 23-02-2022. Eindproduct van deze werkstroom is een implementatiehandleiding voor de transitiefase en hybride situatie. In sectie Definities is een lijst met definities toegevoegd van de termen die in de tekst in deze layout staan.

Bijlage:

• Flowcharts: ‘Raadplegen en reconciliëren in de hybride situatie’, zie Flowcharts Raadplegen en Reconciliëren

2 Achtergrond

Gedurende de transitiefase zijn afspraken nodig voor het probleem van meerdere identificaties (MBH-id’s) voor eenzelfde medicamenteuze behandeling (MBH). De MBH-id is een verplicht onderdeel van MP9-bouwstenen. Via de MBH-id worden alle medicatiebouwstenen die in eenzelfde MBH vallen bij elkaar gebundeld. Uitgewisselde informatie op basis van MP6.12 of via EDIFACT bevat geen MBH-id. Wanneer systemen onafhankelijk van elkaar migreren, genereren zij onafhankelijk van elkaar een MBH-id. Dan ontstaat het volgende probleem: er zullen verschillende MBH-id’s aangemaakt worden voor medicatiebouwstenen, terwijl deze conceptueel horen bij één MBH. Deze situatie kan leiden tot onduidelijkheid, administratieve last en eventueel zelfs tot medicatiefouten. Er dienen daarom afspraken gemaakt te worden om deze risico’s te minimaliseren. Dit gaat om afspraken over de wijze waarop gemigreerd wordt (niet alle data zal bij migratie direct een wereldwijd en eeuwig unieke MBH-id toegekend krijgen), en over de volgorde van de processtappen (wanneer mogen systemen MP9-bouwstenen (actief) beschikbaarstellen, wanneer dient er raadpleging plaats te vinden en wanneer en door wie dient er gereconcilieerd te worden).

3 Verrijken EDIFACT-id en vullen 6.12 prescription/id

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

3.1 Huidige situatie

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

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

3.2 Gewenste situatie

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

3.2.1 Uitgangspunten

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

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

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

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

3.2.3 Verrijkt EDIFACT ID

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

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

3.2.3.1 Voorbeeld 1

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

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

In dit voorbeeld is dat

01023456

.

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

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

In dit voorbeeld is dat

728999

De volledige OID extension wordt dan:

01023456|728999

3.2.3.2 Voorbeeld 2

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

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

• voor Diclofenac:

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

• voor Paracetamol:

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

• voor Oxazepam:

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

3.3 Impact voor de XIS-leveranciers

3.3.1 AIS

MP 6.12 verstrekking/prescription id vullen:

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

3.3.2 Alle systemen

Het overzicht van identificaties in paragraaf 7.1:

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

4 Migratie

4.1 Actuele en recent gestopte medicatie versus historie van medicatie

Gedurende de transitiefase wordt bij migratie onderscheid gemaakt tussen actuele en recent gestopte medicatie versus historie van medicatie. Actuele medicatie is als volgt gedefinieerd: medicatie waarvan de stopdatum (op het moment van migratie) nog niet verstreken is. Dit betreft huidige (heden ligt tussen start- en stopdatum) en toekomstige (heden ligt voor startdatum) medicatie. Recent gestopte medicatie omvat medicatie die in de afgelopen twee maanden is gestopt. Historie van medicatie is medicatie met een stopdatum die meer dan twee maanden in het verleden ligt (ten opzichte van het moment van migratie).

In de transitiefase wordt historische medicatie gebundeld per prescriptiecode (PRK). 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 eenzelfde MBH. Tegelijkertijd draagt dit bij aan een ‘schone start’: actuele en recent gestopte medicatie zal sneller voldoen aan MP9. Actuele en recent gestopte medicatie wordt zorgvuldig gereconcilieerd volgens MP9, terwijl historie niet uitgebreid gereconcilieerd wordt als daar geen directe aanleiding voor is. Dit zorgt er ook voor dat zorgverleners niet belast worden met reconciliatietaken (administratieve lasten) voor historische medicatie die vandaag niet echt belangrijk meer is.

4.2 Eigen vs. andermans medicatiegegevens

Om te voorkomen dat er onnodig dubbele bouwstenen uitgewisseld worden, is het belangrijk om in systemen onderscheid te maken tussen eigen medicatiegegevens, waarvan het systeem de bron is, en andermans medicatiegegevens, waar een ander systeem bron van is. De eigen informatie wordt beschikbaar gesteld in MP9-bouwstenen. Het EVS migreert eigen informatie naar MA’s (en VV’s) en het AIS naar TA’s (en MVE’s). Andermans informatie mag niet vanuit het eigen systeem beschikbaar worden gesteld via de transactie beschikbaarstellen medicatiegegevens (immers, deze informatie dient door het systeem van waaruit is voorgeschreven of verstrekt respectievelijk als MA en TA (en MVE’s) beschikbaargesteld te worden).

Huisarts- en ziekenhuisinformatiesystemen (HIS’en en ZIS’en) dienen maatregelen te treffen om dubbelingen in MA’s en daarmee dubbelingen in MBH’s te voorkomen bij betrokkenheid van meerdere EVS’en:

• Medicatie die op een eerdere datum dan de migratiedatum is voorgeschreven en waarbij in de database een einddatum bekend is, dient gemigreerd te worden naar een MA met een gebruiksperiode met einddatum. Dit zorgt ervoor dat er slechts tijdelijk sprake is van eventuele dubbelingen in MA’s en MBH’s.
• HIS’en en ZIS’en dienen processen ingericht te hebben om, indien mogelijk, te achterhalen of medicatie een intern of extern voorschrift betreft. Bijvoorbeeld: indien er in het HIS tevens een VV bestaat, zal het een eigen voorschrift betreffen.

4.3 Specifieke versus generieke MBH-id

De informatiestandaard MP9 definieert de MBH-id als wereldwijd en eeuwig uniek. Deze MBH-id bevat een OID-root en -extensie. De root bevat een OID voor een ‘identificatiesysteem’ dat verschilt voor elke uitgevende organisatie. De extensie bevat een unieke string binnen dit identificatiesysteem. Dit type MBH-id noemen we een specifieke MBH-id. Daarnaast werken we met een generieke MBH-id: systemen kunnen onafhankelijk van elkaar dezelfde identificatie genereren voor medicatiebouwstenen met dezelfde PRK. De generieke MBH-id bestaat uit een algemene OID-root, en de PRK-code in de OID-extension. Een generieke MBH-id is daarmee alleen uniek voor één patiënt, maar niet uniek over patiënten heen. De generieke MBH-id maakt dat systemen onafhankelijk van elkaar kunnen migreren, maar dat tegelijkertijd de reconciliatie niet nodig is. 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 gedurende de transitiefase toegepast. De intentie is om de generieke MBH-id zo snel mogelijk naar de historie te verdrijven.

4.4 Private versus publieke MBH

In de transitiefase hanteren we de indeling private versus publieke MBH. Bouwstenen binnen een private MBH worden niet uitgewisseld (blijven privé in het eigen systeem). Bouwstenen binnen een publieke MBH worden wel uitgewisseld. De MBH zoals deze in de informatiestandaard MP9 is beschreven, is een publieke MBH.

4.5 Het EVS geeft actuele en recent gestopte medicatie een specifieke MBH-id en historie van medicatie een generieke MBH-id

Een elektronisch voorschrijfsysteem (EVS) kent een specifieke MBH-id toe aan actuele en recent gestopte medicatie. In het EVS krijgt historische medicatie een generieke MBH-id. Aangezien het EVS ook direct de gemigreerde MP9-bouwstenen beschikbaarstelt, zal het ook direct een publieke MBH betreffen.

4.6 Het AIS is vrij in keuze van type MBH-id bij migratie zolang deze privaat is

Het apotheekinformatiesysteem (AIS) stelt de MP9-bouwstenen na migratie niet direct beschikbaar (zie paragraaf 5.3). Zolang de bouwstenen binnen een MBH niet uitgewisseld worden (er is sprake van een private MBH), is het aan het AIS om te beslissen hoe deze MBH-id gegenereerd wordt (type generieke of specifieke MBH-id, of eigen variant). Afhankelijk van de keuze van het type MBH-id dat binnen het AIS wordt gehanteerd, dient de MBH-id op het moment dat de bouwstenen binnen deze MBH wél uitgewisseld gaan worden al dan niet gewijzigd te worden, om te voldoen aan de afspraken rondom uitwisseling.

4.7 EVS en AIS in één systeem

Sommige systemen betreffen zowel EVS als AIS, bijvoorbeeld ziekenhuissystemen of apotheekhoudende huisartspraktijken. Voor het merendeel van de medicatiegegevens zal er voor TA’s uit het AIS-onderdeel van het systeem een relatie bestaan naar een MA (of eventueel MGB) in het EVS-onderdeel. Wanneer er een interne relatie bestaat tussen de TA en MA (of MGB), zal de TA na migratie met de specifieke MBH-id van de medicatiebouwsteen uit het EVS-onderdeel beschikbaargesteld kunnen worden. Wanneer er geen interne link tussen TA en MA (of MGB) uit het EVS-onderdeel blijkt te zijn, wordt er een generieke MBH-id aangemaakt, en zal de TA met deze generieke MBH-id beschikbaargesteld worden.

4.8 Medicatie voorgeschreven in het buitenland en ‘over the counter’-medicatie

Bij de migratie van ‘speciale’ geneesmiddelen is de werkwijze voor migratie afhankelijk van twee factoren:

• Heeft het middel een PRK?
  • Indien het middel geen PRK 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.
• Is het geneesmiddel voorgeschreven of is de behandeling overgenomen door een voorschrijver?
  • Indien dit niet het geval is, kan volstaan worden met het vastleggen van MGB.
  • Wanneer de voorschrijver wel verantwoordelijk is voor de behandeling, is het wenselijk om er bij migratie een MA van te maken.

4.9 Magistralen

Uitwerking volgt, zie https://bits.nictiz.nl/browse/MP-565.

4.10 Experimentele medicatie

Uitwerking volgt, zie https://bits.nictiz.nl/browse/MP-567.

4.11 Combinatiepreparaten

Zorgprocesafspraken omtrent combinatiepreparaten voor MP9 worden momenteel nog afgestemd in de Voorbereidingsgroep/Kernteam Medicatie, zie https://bits.nictiz.nl/browse/MP-528. Werkprocesafspraken voor migratie en de hybride situatie volgen daarom nog.

5 Processtappen na migratie

5.1 Voor elk systeem is migratie de eerste stap

Voor elk systeem geldt dat het migreren van lokale data de eerste stap is (zie Figuur met migratie/hybride processtappen). Met migratie als eerste stap is het voor leveranciers mogelijk om de eigen data te kunnen omzetten naar een datamodel dat MP9-bouwstenen ondersteunt. Migreren gebeurt onafhankelijk van andere systemen in de keten.

Overzicht van de volgorde van de processtappen (migreren, (actief) beschikbaarstellen, raadplegen, reconciliëren) voor het EVS en het AIS. Interactie door een zorgverlener met het patiëntdossier kan plaatsvinden kort voorafgaand aan of op moment van zien van de patiënt, of in het kader van proactief reconciliëren van geselecteerde patiëntgroepen.

5.2 Het EVS stelt de MP9-bouwstenen direct na migratie (actief) beschikbaar

Alleen voor het EVS geldt de volgorde: migreren – (actief) beschikbaarstellen – raadplegen – reconciliëren. Het is wenselijk om na het migreren ook direct MP9-bouwstenen, met name de medicatieafspraken (MA’s), in de keten te kunnen gebruiken. Afspraak is dat het EVS daarom na migratie ook direct de MP9-bouwstenen (actief) beschikbaarstelt aan anderen. Dit sluit aan op de principes van MP9, waarin de MA (en dus het EVS) leidend is in de afleidingsregels.

5.3 Het AIS stelt de MP9-bouwstenen beschikbaar na interactie van zorgverlener met patiëntdossier

Voor een AIS geldt de volgorde: migreren – raadplegen – reconciliëren – (actief) beschikbaarstellen. Afspraak is dat het AIS na migratie niet direct de MP9-bouwstenen (actief) beschikbaarstelt. Dit om te beperken dat er meerdere MBH-id’s in de keten ontstaan voor eenzelfde MBH. In het AIS zal daarom na migreren eerst een interactie door een zorgverlener met het patiëntdossier dienen plaats te vinden, waarbij minimaal geraadpleegd wordt. Na raadplegen én het ontvangen van een MP9-bouwsteen uit een EVS, gaat het AIS de binnengekomen informatie verwerken (reconciliëren), hierna mag het AIS MP9-bouwstenen (actief) beschikbaarstellen. Wanneer er bij raadplegen blijkt dat er vanuit een EVS MP9-bouwstenen beschikbaar zijn gesteld, zoekt het AIS naar een match tussen die MP9-bouwsteen en de toedieningsafspraak (TA) (zie hoofdstuk 7). Indien op deze manier een specifieke MBH-id gevonden is, neemt het AIS deze over in de TA. Wanneer er geen match met een MP9-bouwsteen is, kan de TA beschikbaargesteld worden, met een generieke MBH-id (zie Tabel 1). Als het PRK van het voorschrift bekend is, wordt dit PRK aangehouden voor het genereren van de generieke MBH-id; is deze onbekend, dan mag het PRK van de TA aangehouden worden.

Onderstaande tabel geeft een overzicht van situaties waarin aangegeven wordt of er sprake is van een publieke vs. private MBH, waarbij een specifieke of generieke MBH-id is toegekend. Afspraken omtrent systemen die zowel EVS als AIS betreffen worden in paragraaf 4.7 beschreven. Uitzonderingssituaties worden in paragraaf 4.8 genoemd.

Tabel met overzicht situaties publieke en private MBH voor EVS en AIS

Situatie	EVS	AIS
Migratie actueel & recent gestopt	Publieke MBH met specifieke MBH-id	Private MBH
Migratie historie	Publieke MBH met generieke MHB-id	Private MBH (evt. met generieke MBH-id)
Bij ‘zien’ patiënt	Publieke MBH met specifieke MHB-id	Publieke MBH met gevonden specifieke MBH-id van EVS indien bekend, anders publieke MBH met generieke MBH-id
Bij reconciliatie (indien MP9-bouwsteen uit EVS)	Publieke MBH met specifieke MBH-id van meest recente MA	Specifieke MBH-id van MA indien bekend Generieke MBH-id indien geen MA bekend Alle private MBH’s worden publieke MBH’s
Nieuwe MBH	Publieke MBH met specifieke MHB-id	Publieke MBH met generieke MBH-id AIS initieert in principe géén specifieke MBH-id bij een publieke MBH. Alleen wanneer er geen PRK is, maakt het AIS een specifieke MBH-id aan.

6 Bevragen LSP tijdens de hybride situatie

Dit wordt verder besproken. Uitwerking volgt daarom nog.

7 Matchingsregels

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

7.1 Samenhang van identificaties EDIFACT, MP6.12 met MP9

Onderstaande tabel geeft een overzicht van de verschillende identificaties en hun onderlinge relaties.

Tabel met overzicht identificaties en hun onderlinge relaties

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

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

Tabel met overzicht identificaties en hun onderlinge relaties voor ieder formaat van het medicatievoorschrift

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

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

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

8 Reconciliëren

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

8.1 ‘Ontdubbelen’ van MBH’s

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

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

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

8.2 Controle en correcties bij reconciliatie

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

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

9 Early adopters

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

9.1 Early adopters MP9 met (mogelijk) MBH-id

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

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

9.2 Early adopters MP9 zonder MBH-id

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

10 Doseringen

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

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

11 Patiëntportalen

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

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

12 PGO's

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

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

13 Definities

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