Migratie en hybride

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 paragraaf 13 in dit document 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