mp:MM V9.0.7 kwalificatie medicatiegegevens raadplegen MA

Inleiding

Dit document beschrijft het te doorlopen script bij kwalificatie voor de systeemrol:

• Medicatiegegevens raadplegend systeem - medicatieafspraak

De doelgroep van dit document is de leverancier die wil kwalificeren. De kwalificatie wordt uitgevoerd met de Nictiz kwalificatiesimulator. Deze kwalificatiesimulator kan berichten verzenden en ontvangen.

Algemene voorwaarden voor kwalificatie

Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:

1. Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
2. Kennis en begrip van de Informatiestandaard Medicatieproces 9.
3. Kennis en begrip, en het naleven van de aandachtspunten zoals beschreven in ‘Addenda - Raadplegen medicatieafspraak’
4. De kwalificatiedocumentatie bevat de gegevens die de kwalificerende partij zelf invoert. Onjuist ingevoerde gegevens (ook tijd/datum et cetera) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces.
5. Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.
6. Deze kwalificatie toetst geen infrastructurele eisen.

Uit te voeren stappen

Voer – voor ieder scenario – de volgende stappen uit:

1. Stuur een ‘raadplegen medicatiegegevens’ bericht met filtercriteria ‘Type = medicatieafspraak’, voor de persoon genoemd in Persoonsgegevens. Sommige scenario’s geven aanvullende filtercriteria aan.
2. De kwalificatiesimulator antwoordt met een ‘beschikbaarstellen medicatiegegevens’ bericht. De gegevens in dit bericht vindt u in Addenda - Raadplegen medicatieafspraak.
3. Ontvang en verwerk de medicatieafspraken in het systeem.
4. Maak schermafdrukken van het systeem met de gegevens uit medicatieafspraken, en leg deze vast in het Aanleverformat - Raadplegen medicatieafspraak.

Op te leveren materialen

De op te leveren materialen bestaan voor alle scenario’s uit:

1. de technische uitgaande berichten én
2. schermafdrukken.

De schermafdrukken moeten duidelijk maken dat de medicatieafspraken juist getoond worden aan de eindgebruiker. De inhoud van de medicatieafspraken is gespecificeerd in 'Addenda - Raadplegen medicatieafspraak'.

Leeswijzer

Ieder navolgend hoofdstuk beschrijft een set scenario’s met steeds dezelfde paragraafindeling:

1. Doel en verwacht resultaat
2. Scenario’s
3. Inhoudelijke gegevens

Hieronder volgen een aantal belangrijke aandachtspunten.

Persoonsgegevens

Het onderdeel ‘Persoonsgegevens’ bevat algemene gegevens over de persoon zoals naam, adres en woonplaats, maar ook een (fictief) Burgerservicenummer (BSN). PGO’s mogen echter geen BSN verwerken. Een PGO behoort namelijk tot het persoonsdomein en valt daarom buiten wetgeving voor het zorgaanbiedersdomein. Een XIS mag ook geen BSN naar het persoonsdomein – en dus PGO’s - sturen. Er is wel een fBSN (fictief BSN voor testdoeleinden) in de persoonsgegevens opgenomen, zodat ook een XIS zich voor deze rol kan kwalificeren.

Datum T

T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T-100D betekent dit: 100 dagen eerder dan de afgesproken datum.

Specifieke gegevens

Deze paragraaf bevat specifieke gegevens die de leverancier moet meegeven als Medicatiegegevens raadplegend systeem

Gegevens medicatieafspraak

Het onderdeel ‘Gegevens medicatieafspraak’ bevat de gegevens van de medicatieafspraak, zoals datum, geneesmiddel, gebruiksinformatie, doseerinstructie.

Algemeen

Om medicatieproces goed te kunnen implementeren is kennis en gebruik van het functioneel ontwerp onontbeerlijk. Net als natuurlijk de MedMij invulling daarvan, functioneel en technisch.

Raadplegend systeem

Dit gaat om het verwachte resultaat van de raadpleging. Het gaat er voor een raadplegend systeem (zoals een PGO) om dat alle functioneel relevante informatie in samenhang getoond wordt. Samenhang is in ieder geval belangrijk voor de medicamenteuze behandeling (MBH).

Hoe de gebruikersschermen van een raadplegend systeem, zoals een PGO, er precies uitzien, is vrij in te vullen (immers: juist gebruikersvriendelijkheid is iets waarop PGO's moeten kunnen concurreren), mits alle informatie in de juiste samenhang met de juiste semantiek (betekenis) is terug te vinden. Dit betekent dat bouwstenen behorende bij dezelfde medicamenteuze behandeling als zodanig herkenbaar moeten zijn. Een PGO hoeft niet de (technische) identificatie van een MBH te tonen (noch die van andere bouwstenen), maar wel de uitwerking daarvan: namelijk in samenhang getoonde bouwsteen instantiaties.

Medicatie codering en weergavenaam

Alleen de weergavenaam van het meest specifieke geneesmiddel getoond hoeft te worden (alle andere kunnen hiervan afgeleid worden en zijn voor de gebruiker niet relevant).

In de G-standaard is de volgorde van specifiek naar generiek:

• ZI-nummer
• HPK (Handels Product Kenmerk)
• PRK (PRescriptie Kenmerk)
• GPK (Generiek Product Kenmerk)

De meest specifieke codering is altijd de belangrijkste. Dit kan ook (in FHIR) te herkennen zijn aan het 'user selected' attribuut, maar als deze ontbreekt kan het afgeleid worden uit bovenstaand lijstje.

De reden dat meer generieke coderingen ook meegestuurd worden is dat Z-Index (nog) geen historie uitlevert voor de G-standaard. Dit betekent dat uitgefaseerde geneesmiddelen op een gegeven moment niet meer meegeleverd worden in de distributie vanuit Z-Index. Abonneehouders worden geacht hun eigen historie bij te houden, maar bij 'later' instappen mis je de historie van vóór dat moment. Hoe specifieker de codering, hoe dynamischer (hoe vaker dingen wijzigen / uitgefaseerd worden). Dit kan een probleem opleveren voor medicatiebewaking omdat je dan bijvoorbeeld voor een bepaalde HPK de bewakingsregels niet kunt vinden in jouw (lokale) versie van de G-standaard. Omdat PRK's en GPK's minder dynamisch zijn dan HPK's en ZI-nummers, verlagen we dat risico door deze coderingen mee te sturen.

Aanvullende informatie over het tonen van verschillende bouwstenen in samenhang

Een mogelijke invulling hiervan is ook te vinden in het functioneel ontwerp bij medicatieoverzicht, maar een echt PGO - met oog voor wat eindgebruikers nodig hebben - kan dit waarschijnlijk veel beter. Het ligt voor voorschrijvers bijvoorbeeld voor de hand om altijd vanuit de actuele medicatieafspraak (MA) te redeneren (dat zie je ook terug in het eerdergenoemde voorbeeld in het functioneel ontwerp), overigens geven apothekers vaak aan dat dit ook voor hen de voorkeur heeft. Voor patiënten ligt dit veel minder voor de hand, omdat de geneesmiddelen in medicatieafspraken vaak nog namen hebben die voor patiënten een stuk minder herkenbaar zijn dan het merk (handelsproduct) dat ze mee hebben gekregen bij de apotheek en dat dus in de toedieningsafspraak (TA) staat. Het is ook voorstelbaar dat medicatiegebruik (MGB) - zoals door de patiënt zélf geregistreerd - in een PGO 'voorrang' krijgt boven MA of TA.

Over het algemeen lijkt het wel logisch om bij het presenteren van overzicht opgebouwd uit medicatiegegevens uit te gaan van 1 ingangsregel per medicamenteuze behandeling en bij 'doorklikken' de onderliggende bouwstenen (MA, VV, TA, MVE, MGB) en de detail informatie daarvan (waar je de ingangsregel dus op baseert) te tonen. Eventueel kan zo'n ingangsregel bijvoorbeeld gemarkeerd worden door een rood ! of iets dergelijks als onderliggende informatie onderling conflicteert (dit soort dingen worden vaker genoemd in gesprekken met zorgverleners). Bijvoorbeeld als de dokter zegt 100 mg gebruiken, maar de patiënt neemt maar 50 mg. Het is in ieder geval wél van belang het onderscheid te kunnen zien in MA (door voorschrijver bepaald), TA (door apotheker bepaald) en MGB (bewering geregistreerd door patiënt/zorgverlener/mantelzorger et cetera).

Beschikbaarstellend systeem

Het beschikbaarstellend systeem voert de gegevens uit het addendum in, in het XIS en levert de resulterende berichten op voor kwalificatie. Voor een beschikbaarstellend systeem geldt dat sommige gegevens door dit beschikbaarstellende systeem bepaald mogen worden:

• Zorgverlener, zorgaanbieder (denk aan verstrekker, voorschrijver). Dit mag een eigen (test)zorgverlener en organisatie zijn.
• Identificatie van medicamenteuze behandeling, en andere medicatiebouwstenen (medicatieafspraak, verstrekkingsverzoek, toedieningsafspraak, verstrekking, medicatiegebruik): verwacht wordt dat hier 'eigen' identificaties aan worden toegekend in een eigen identificatiesysteem (eigen OID). De onderlinge referenties moeten natuurlijk wel kloppen (dus een toedieningsafspraak en een verstrekking blijven horen bij dezelfde medicamenteuze behandeling zoals aangegeven in de addenda).

Datum T

T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T – 100 betekent dit: 100 dagen eerder dan die afgesproken datum.

Alle gegevens medicatie

Een overzicht van alle testgegevens voor de bouwstenen (medicatieafspraak, verstrekkingsverzoek, toedieningsafspraak, verstrekking en medicatiegebruik) bij raadplegen / beschikbaarstellen medicatiegegevens vindt u hier.

OID's

De identificaties hebben de volgende root OID’s

Medicamenteuze behandeling	2.16.840.1.113883.2.4.3.11.999.77.1.1
Medicatieafspraak	2.16.840.1.113883.2.4.3.11.999.77.16076005.1
Toedieningsafspraak	2.16.840.1.113883.2.4.3.11.999.77.422037009.1
Medicatiegebruik	2.16.840.1.113883.2.4.3.11.999.77.6.1
Verstrekkingsverzoek	2.16.840.1.113883.2.4.3.11.999.77.52711000146108.1
Medicatieverstrekking	2.16.840.1.113883.2.4.3.11.999.77.373784005.1

Basis: raadplegen, tonen, filtercriteria

Doel en verwacht resultaat

Doel	Verwacht resultaat
Aantonen dat het systeem medicatieafspraken op basis van verschillende filtermogelijkheden kan raadplegen (alle scenario’s)	Het systeem genereert technisch correcte berichten met inhoudelijk correcte parameters.
Aantonen dat het systeem de ontvangen informatie juist toont (alle scenario's)	Het systeem toont ontvangen informatie juist aan de eindgebruiker.
Aantonen dat het systeem kan omgaan met een bericht waarin geen medicatieafspraak is opgenomen (scenario 1.10).	Het systeem ontvangt en toont het (gebrek aan)resultaat.

Scenario’s

Scenario	Beschrijving
1.1	Alle medicatieafspraken van de patiënt, zonder aanvullende filter criteria
1.2 *	Specifieke medicatieafspraken met hun identificaties als filter.
1.3 *	Medicatieafspraken met een filter op meerdere product codes
1.4	Medicatieafspraken met een filter op gebruiksperiode – ingangsdatum
1.5	Medicatieafspraken met een filter op gebruiksperiode – einddatum
1.6	Medicatieafspraken met een filter op gebruiksperiode – ingangsdatum én einddatum
1.7 *	Een specifieke medicatieafspraak met één identificatie als filter.
1.8 *	Medicatieafspraken met een specifieke medicamenteuze behandeling als filter.
1.9 *	Medicatieafspraken met een filter op één product code.
1.10	Een patiënt zonder medicatieafspraken.

* Optionele scenario’s filtercriteria: Bij de scenario's voor filtercriteria zijn diverse scenario's aangemerkt als optioneel. Deze als optioneel aangemerkte filtercriteria zijn veelal van toepassing bij zorgverlener-zorgverlener communicatie en hebben minder toegevoegde waarde bij zorgverlener-PGO communicatie. Een PGO mag deze filtercriteria inbouwen (mochten ze toegevoegde waarde zien voor hun gebruikers om deze filter-functionaliteit te bieden), maar is niet verplicht dit te doen.

Medicamenteuze behandeling

Doel en verwacht resultaat

Doel	Verwacht resultaat
Aantonen dat het systeem kan omgaan met een antwoord met daarin meer dan één medicatieafspraak -ieder in een eigen medicamenteuze behandeling (al getest in scenario 1.1).	Het systeem toont ontvangen informatie juist aan de eindgebruiker.
Aantonen dat het systeem kan omgaan met verschillende medicatieafspraken in dezelfde medicamenteuze behandeling, en deze in samenhang kan tonen (scenario 2.1).	Het systeem toont ontvangen informatie juist aan de eindgebruiker.

Scenario’s

Scenario	Beschrijving
2.1	Patiënt met een medicamenteuze behandeling met 2 of meer medicatieafspraken: een gewijzigde medicamenteuze behandeling met ook een reden voor de wijziging (reden afspraak)

Stop-medicatieafspraken

Doel en verwacht resultaat

Doel	Verwacht resultaat
Aantonen dat het systeem correct omgaat met stopmedicatieafspraken (scenario 3.1)	Het systeem toont ontvangen informatie juist aan de eindgebruiker.Een medicatieafspraak die lang geleden gestopt is, hoeft niet ‘standaard’ getoond te worden. Wel kan de gebruiker deze vinden als die zelf ‘op zoek’ gaat,bijvoorbeeld door aanvullend te filteren op een periode lang(er) terug.
Aantonen dat het systeem correct omgaat met technische stop-medicatieafspraken als onderdeel van een wijziging (al getest in scenario 2.1)	Het systeem toont ontvangen informatie juist aan de eindgebruiker: als een wijziging. De technische stopmedicatieafspraak wordt niet als zodanig getoond aan de eindgebruiker.
Aantonen dat het systeem correct omgaat met ‘tijdelijk onderbreken’ medicatieafspraken (scenario 3.1)	Het systeem toont ontvangen informatie juist aan de eindgebruiker: het onderscheid tussen definitief staken en tijdelijk onderbreken moet duidelijk zijn.Tijdelijk onderbreken medicatieafspraken (die niet daarna definitief gestopt zijn) blijven actueel.

Scenario’s

Scenario	Beschrijving
3.1	Medicatieafspraak met een bijbehorende stop-medicatieafspraak
	Een stop-medicatieafspraak die lang (een jaar) geleden gestopt is
	Een ‘tijdelijk onderbreken’ medicatieafspraak.
	Een ‘tijdelijk-onderbreken’ medicatieafspraak die sinds lang (7 maanden) geleden onderbroken is.
3.2	Een stop-medicatieafspraak op zelfzorg pijnstiller (er is dus geen start MA vanuit een zorgverlener)

Doseerschema’s en magistraal

Doel en verwacht resultaat

Doel	Verwacht resultaat
Aantonen dat het systeem medicatieafspraken met verschillende doseerschema’s correct toont.	Het systeem toont ontvangen informatie juist aan de eindgebruiker.
Aantonen dat het systeem een medicatieafspraak met een ‘magistraal’ geneesmiddel (bereid geneesmiddel met ingrediënten) juist toont.	Het systeem toont ontvangen informatie juist aan de eindgebruiker.

Scenario’s

Scenario	Beschrijving
4.1	Medicatieafspraken met diverse doseerinstructies.
	Medicatieafspraak met een magistraal geneesmiddel.

Specifieke inhoud

Doel en verwacht resultaat

Doel	Verwacht resultaat
Aantonen dat het systeem alle concepten uit de medicatieafspraak correct toont.	Het systeem toont ontvangen informatie juist aan de eindgebruiker.

Scenario’s

Scenario	Beschrijving
5.1	Geannuleerde medicatieafspraak
	Medicatieafspraak met: relatie naar toedieningsafspraak
	Medicatieafspraak met: relatie naar medicatiegebruik reden van voorschrijven
	Medicatieafspraak met: lichaamslengte lichaamsgewicht aanvullende informatie toelichting

Documenthistorie

Versie	Datum	Omschrijving
1.0	15 november 2018	Eerste versie voor MP9.0.6
2.0	1 februari 2019	Update addenda link. Addenda gegevens update naar MP9.0.7
2.1	26 september 2019	Optionele filterscenario’s en kleine tekstuele aanpassing addenda/aanleverformat naamgeving