Vragen en antwoorden vragenuurtje Validatieloket Medicatieoverdracht

Uit informatiestandaarden
Versie door Victor van Hagen (overleg | bijdragen) op 21 okt 2022 om 09:45 (/* De reden van stoppen is informatie opgeschreven en verwerkt in Z-index en G-standaard tabellen. De tabellen en taalgebruik van reden van stoppen die zij genoteerd hebben sluit niet aan wat in de MP9 informatiestandaard staat (verschil ligt met name...)
Ga naar: navigatie, zoeken


Toelichting

In het inhoudelijk vragenuur wordt de gelegenheid gegeven aan de ontwikkelaars en testers van de leverancier om inhoudelijke vragen te stellen. Ook is dit een mogelijkheid voor de ontwikkelaars en testers om onderling met elkaar te sparren over vraagstukken. Vraagstukken worden ter plekke besproken, maar kunnen ook vooraf gestuurd worden naar validatie@medicatieoverdracht.nl. Via deze wiki-pagina worden de antwoorden op de vragen teruggekoppeld aan vraagstellers en overige geïnteresseerden.


Inhoud

1 Vragenuurtje 12 augustus 2022

1.1 Moeten niet PGO leveranciers die deelnemen aan de Kickstart, net als de PGO leveranciers, een MedMij gegevensdienst / aparte koppeling met MedMij implementeren?

Antwoord: Nee, niet-PGO leveranciers hoeven hier geen aparte koppeling voor te maken. Als bron leverancier ben je niet verantwoordelijk voor het PGO, maar wel dat je een ontsluiting hebt naar een DVZA. De huidige koppeling die gebruikt wordt bij de zorgaanbieder aan zorgaanbieder communicatie kan rechtstreeks gebruikt worden om via LSP+ of een andere DVZA een PGO aan te sluiten. De patiënt zal in zijn PGO een gegevensdienst van een bepaalde zorgaanbieder selecteren, dit kan via LSP+ of een andere DVZA.


2 Vragenuurtje 19 augustus 2022

2.1 Waar is praktische informatie met betrekking tot het inbouwen van de standaarden te vinden?

Antwoord: Deze is te vinden op de landingspagina: daar staat alle informatie met specificaties. Mocht je daar nog informatie missen, neem dan contact op met het Validatieloket, zij kunnen je verwijzen waar overige documentatie te vinden is.

2.2 Zijn de zaken aangegeven in de checklist vrijblijvend of een vereiste om in te bouwen (zoals MITZ en de signaalfunctie)?

Antwoord: MITZ en de signaalfunctie zijn optioneel in te bouwen. Wij hadden voor ogen met de checklist een handreiking te geven welke onderwerpen er in de voorbereidingsfase 0 van toepassing zijn en wat er wordt verwacht van de deelnemende leverancier, maar daar zijn we niet in geslaagd. De huidige Checklist komt te vervallen en er komt een voorzet voor aanpassing die bestaat uit: 1) Een overzicht van de 0-status, wat wordt van de leverancier verwacht te bouwen bij aanvang van de Kickstart. Dit overzicht kan worden toegevoegd aan de template overeenkomst. 2) Opnemen van criteria voor het Plan van Aanpak en Ontwerp als onderdeel van de Wiki. 3) Omzetting van de klikbare Excel naar een wikipagina en toevoeging stap 0. Wij zullen alle partijen informeren zodra dit beschikbaar is.

2.3 Waar is de nadere invulling van het resultaat overzicht (zoals in het plan van aanpak staat vermeld) te vinden?

Antwoord: Dit is te vinden op de Medicatieoverdracht Kickstart – documentatie leveranciers pagina: https://informatiestandaarden.nictiz.nl/wiki/mp:Medicatieoverdracht_Kickstart zie 1.2 (verzamelbestand MP9 of deze link: https://informatiestandaarden.nictiz.nl/images/8/83/10stappenplan_resultaten_documentatieMP9_Kickstart_v2.2.zip). Daarbij wordt er nog een 0-status overzicht geleverd aan alle leveranciers.

2.4 Zijn ‘voorstel MA en VV’ in scope van de Kickstart?

Antwoord: Ja, en ook het antwoord AVVV en AVMA. Zie ook het “Verzamelbestand in Excel met functionele, technische en infrastructurele documentatie Medicatieproces 9 t.b.v. Kickstart (download als zip)” de wiki pagina Medicatieoverdracht Kickstart - documentatie leveranciers (https://informatiestandaarden.nictiz.nl/wiki/mp:Medicatieoverdracht_Kickstart)

2.5 Valt het verwerken van een vanuit een PGO binnenkomende MGB binnen de scope van de Kickstart?

Antwoord: Het medicatiegebruik vastgelegd door een patiënt in een PGO is geen onderdeel van de Kickstart. Wel is er de optie om MGB vast te leggen in bijvoorbeeld een patiënten portaal. Echter dat is geen verplichting. Dit betekent overigens wel dat je als ontvanger hier rekening mee moet houden: De auteur kan een patiënt zijn, of een zorgverlener namens de patiënt. Deze moeten op andere wijze worden afgehandeld.

2.5.1 Zo ja, dan vragen we ons af hoe zich dat voor een HIS verhoudt tot de MedMij kwalificaties / gegevensdiensten.

D.w.z. medicatie valt voor het HIS tot nu toe onder de HEPD (Huisartsgegevens) en daaronder wordt alleen gesproken over actuele MA. Gaat dit nog wijzigen Daarnaast is er het Medicatieproces. Dienen we dan daarvoor bij MedMij te kwalificeren? Dus ook voor andere bouwstenen zoals TA?

Antwoord: Er zijn aparte gegevensdiensten voor een PGO voor het opvragen van medicatiegegevens. Het opvragen door een PGO in het kader van Huisartsgegevens en de bijbehorende gegevensdienst is gebaseerd op MP907 en kan niet voor de Kickstart worden gebruikt of later in de brede uitrol. Er wordt nog besproken of medicatie nog onderdeel zou moeten zijn van de gegevensdienst Huisartsgegevens. Als PGO en als DVZA zul je dus moeten herkwalificeren voor MP9. En er zal ook na de Kickstart een MedMij label aan worden gekoppeld.

2.6 Als HIS maken we tot nu toe voor gebruikseenheden gebruik van tabel 25 van de NHG. Er wordt overgestapt op GS basiseenheden. Helaas worden 50 NHG eenheden daarbij vertaald naar NVT in GS. Niet prettig voor de gebruikers, mn ook bij conversie van bestaande gegevens. Kunnen NHG-eenheden echt niet meer gebruikt kunnen worden?

Antwoord: Het is geen probleem om de standaard NHG eenheden te gebruiken voor de lokale applicatie en er zal dan ook geen probleem moeten ontstaan voor de conversie. Echter in de communicatie zullen deze eenheden moeten worden vertaald naar standaard GS eenheden. Dat gebeurt feitelijk altijd al in het kader van 6.12 en is daar geen probleem gebleken, en zelfs voordelen te hebben. Je hebt ook te maken met derden die geen beschikking hebben over de NHG eenheden in hun eigen applicatie en daar dan ook niets mee kunnen. Wel is er nog een impact analyse met het NHG over een aantal relevante b-codes die wél therapeutische impact hebben en niet kunnen worden gecommuniceerd. We zullen daarbij deze eenheden ook meenemen en bepalen of er een impact in de communicatie is te verwachten en of er specifieke maatregelen (bijv extra info in de g-standaard) nodig zijn.

2.7 Wat zijn de afspraken met abonnement Z-Index (met name de trombose diensten zijn hier niet bekend mee)?

Antwoord: Wij kunnen je in contact brengen met Z-index, indien je dit wenst kun je contact opnemen met het Validatieloket.

2.8 Hoe gaat signaalfunctie precies werken? Hoe werkt dit dan zo dadelijk per bouwsteen. Wens is dat alleen relevante wijzingen signaal op komt. Verder in ambulante zorg is signaalfunctie onhandig en voor toediening ook niet handig. Is signaalfunctie dan per bouwblok aan of uit te zetten?

Antwoord: Informatie (nog op aorta 8.2, maar werkwijze ongewijzigd in 8.3

Het wordt mogelijk om een abonnement te nemen op context ipv gegevenssoort. De specifieke context-codes worden nog gepubliceerd. De signalen zijn per bouwsteentype en kunnen bij ontvangst gefilterd worden. Meer informatie volgt nog bijvoorbeeld in de vorm van best practices.

2.8.1 Aanvullend op eerdere vraag: is er ook iets als een query waarmee je check kan doen of er iets verandert is in een dossier.

Antwoord: Dit kan op 2 manieren worden opgelost:

  • Die is er in de vorm van de actualiteitscontrole. https://decor.nictiz.nl/pub/vzvz/aorta-vzvz-html-20200821T140325/sc-2.16.840.1.113883.2.4.3.111.3.9.3.5-2016-12-12T124816.html. Ook hier zal het mogelijk zijn om op context-code de ac uit te voeren. Merk op dat met het gebruik van de conditionele query het nut van het gebruik van de AC vervalt, aangezien de primaire functie van de ac is het kunnen checken zonder uzi-pas.
  • Inhoudelijk filteren op de wijzigingen in een bron systeem is een volgende wens, namelijk de “What’s new”. Dan wordt aan het bron systeem gevraagd om alleen de wijzigingen t.o.v. een bepaalde datum/tijd. Dat zal in aorta 9 verder worden uitgewerkt (ook in combinatie met FHIR)

2.9 In welke volgorde (logische volgorde) moet je de bouwblokken inbouwen om te voldoen aan de planning van de Kickstart?

Antwoord: zie Verzamelbestand met functionele, technische en infrastructurele documentatie Medicatieproces 9 t.b.v. Kickstart

2.10 In de scope van de eerste fase wordt niet gesproken over het ontvangen van TA en MVE. We concluderen dat we MP9 MA+VV gaan versturen aan AIS en dan edifact berichten terugkrijgen, die we koppelen aan onze VV. Wordt er ook naar de verwerking van de verstrekkingen in ons systeem bij kwalificatie van de eerste fase verder niet gekeken?

Antwoord: Het kan inderdaad voorkomen dat een MA+VV wordt verstuurd naar een AIS die aan de Kickstart mee doet, maar die nog geen TA/MVE oplevert, omdat die in de volgende fase opgeleverd zal worden. Op de pagina hybride situatie (https://informatiestandaarden.nictiz.nl/wiki/mp:Vkickstart_MigratieHybride#Bijlage_1:_Verrijken_EDIFACT_id_en_vullen_MP6.12_prescription.2Fidstaat) staat ook beschreven hoe (zeker door de MP9 partijen) het edifact ID verrijkt zou kunnen worden om de terugkoppeling te vereenvoudigen. Los daarvan is er sprake van een hybride situatie met MP9 en niet MP9 deelnemers.

2.11 Moet de functionaliteit voor het registreren van wisselende doseerschema’s ingebouwd worden

Antwoord: Ja, dit moet ingebouwd worden

2.12 Medicatieverificatie wordt redelijk vaak in het FO genoemd. Toch is ons niet helemaal duidelijk hoe dit zou moeten werken.

  • Dat je zaken in MGB kan vastleggen is duidelijk, en dat dat niet verplicht is ook.
  • Verificatie vindt plaats per MBH, maar er staat nergens dat dat ook op dat niveau vastgelegd moet worden. Ook lijkt dit een beetje te knellen met MBH als alleen maar een technisch begrip, dat we eigenlijk voor de gebruiker verborgen willen houden.
  • Tenslotte zien we op het MO ook geen verificatie-indicatie per MBH, maar wél op het niveau van het MO zelf. Hoe die] indicaties daar terecht zouden moeten komen is niet duidelijk.
  • Onze implementatie zou bijvoorbeeld zijn: op het moment van het versturen c.q. beschikbaar stellen van het MO geeft de geeft de huisarts aan of de medicatie geverifieerd (patiënt!) en gecontroleerd is (arts!).
  • Of kunnen we deze indicatie sowieso als niet verplicht beschouwen op dit moment, gezien de MO hoe dan ook e.e.a. dient te worden verstuurd?

Antwoord: Dit komt vooral uit de documentatie uit de gebruikers ‘eisen’. Daarin staat hoe je een verificatie uitvoert (door het vastleggen van een MA, of MGB). Er is geen methode om een complete verificatie te ondertekenen


3 Vragenuurtje 2 september 2022

3.1 Bij de mapping in SNOMED zag je 1 ICPC meerdere SNOMED resultaten opleveren, hoe ga je daar mee om?

Antwoord: Er is bij SNOMED geen 1 op 1 relatie, dus zul je moeten kiezen.

3.1.1 Moet je kiezen of kan je alles meegeven?

Antwoord: Bij de meeste onderdelen die we gebruiken binnen medicatieproces geven we aan welke code (en codesysteem) je moet hebben. In de waardelijst staat de code die je moet gebruiken en de termen die gebruikt worden hebben een code, dus dan weet je precies welke je moet gebruiken. Op een paar plekken mag je meerdere codesystemen gebruiken en dan moet je kiezen. Bijvoorbeeld bij ‘Reden van voorschrijven’.

3.2 Als ontvangend systeem moet je dan alle codes ondersteunen en vertalen zonder verlies van informatie?

Antwoord: Je hebt een code en een omschrijving (die verplicht is), als je code niet begrijpt toon je de omschrijving aan de gebruiker en als die akkoord is dan is het goed. Als ontvangend systeem hoef je de reden van voorschrijven die je van een ander hebt ontvangen nooit meer op te leveren.

3.3 Als een recept wordt aangepast, bij wijziging of als je de code niet kan verwerken, verlies je de code. Als je de code niet begrijpt en een nieuw recept stuurt met aangepaste info dan is de code weg. Als je ICPC kan vertalen naar 2 SNOMED codes welke kies je?

Antwoord: Als je de code niet begrijpt dan moet je gebruik maken van de tekstuele omschrijving. Als je wijzigt maak je nieuwe medicatieafspraak en dan moet je reden van voorschrijven weten. In de start zit een nieuwe reden van voorschrijven die hoort bij het nieuwe recept. De arts kan kiezen welke van de 2 SNOMED codes hij nodig heeft. De laatste voorschrijver is verantwoordelijk voor de medicatieafspraak. Deze reden van voorschijven zit wordt bepaald door de voorschrijver.

3.4 Als je ICPC hebt ontvangen in de originele medicatieafspraak, dan wissel je ook ICPC in de kopie MA uit (bij VV odner andermans MA), moet je dan de code opslaan?

Antwoord: Als je een verstrekkingsverzoek maakt onder de MA van iemand anders, dan moet je een kopie-MA meesturen. Je moet de originele code dus onthouden. Het kan zijn dat dit niet lukt en er een andere vertaalde code (bijvoorbeeld SNOMED ) meegestuurd wordt. De ontvanger weet dat het een kopie-MA betreft en kan altijd de originele MA opvragen bij de bron. Een systeem kan ook een letterlijke kopie bijvoegen door de MA op te vragen op dat moment en die bij het verstrekkingsverzoek voegen. Je moet allerlei soorten codes kunnen ontvangen en opleveren.

3.5 Is er een subselectie van alle SNOMED codes die worden gebruikt voor MO?

Antwoord: Nee, deze selectie zit niet in SNOMED. De meeste van onze waardelijsten hebben SNOMED codes. Een groot gedeelte van de waardelijsten zullen via Z-index gepubliceerd worden. De informatiestandaard publicatie bevat ook de waardelijsten.


4 Vragenuurtje 9 september 2022

4.1 Medicatie overzicht transactie is vervallen, maar moet je nog wel medicatie overzicht maken?

Antwoord: Medicatie overzicht staat wel als transactie benoemd in het FO omdat het heel breed is, maar voor de implementatie passen we het nu niet toe. Met de medicatie overdracht transactie dan kan je met 1 vraag alle bouwstenen die jouw systeem heeft opleveren inclusief de kopie bouwstenen die je van andere mensen hebt gekregen. Op dit moment gaan we kijken of we met die losse bouwstenen / interacties zelf je medicatie overzicht kan maken.

4.2 Wat betekent dat voor de verificatie, hangt erg met medicatie overzicht samen, dat je het gedaan hebt en duidelijk is voor alle partijen, is dat dan nu minder belangrijk?

Antwoord: Nee, in de eisen staat dat je per regel dan gebruik moet vastleggen als je verificatie hebt gedaan. Die gebruikersregels zou je moeten opleveren als bouwsteen die je hebt gemaakt daarmee kan je per regel zien wie wanneer dat geverifieerd heeft.

4.3 In het FO staat boven medicatie overzicht staat een vlaggetje ‘geverifieerd door de zorgverlener’, klopt dat?

Antwoord: Het Medicatie overzicht, dat nu in FO gepubliceerd is, beschrijft welke onderdelen op een medicatieoverzicht zouden kunnen staan. Het vlaggetje ‘geverifieerd’ betekent dat alle medicatie gebruik bouwstenen zijn geverifieerd met de patiënt en is voornamelijk bedoeld voor gebruikers binnen het eigen systeem en kan niet worden gecommuniceerd met andere systemen. Deze vlag kan natuurlijk wel op een eventueel medicatieoverzicht (AMO) dat aan de patiënt wordt overhandigd worden weergegeven.

4.4 Waarom moet medicatieverstrekking (MVE) pas in stap 5 gebouwd worden?

Antwoord: MVE wordt nu in 6.12 uitgewisseld, dus voegt nu weinig toe behalve dat je daar een stukje therapietrouw mee zou kunnen doen maar zelfs dat is arbitrair. De keuze is gemaakt om in eerste instantie MA en MGB gaan doen en daarna pas de verstrekkers. Bij de hybride situatie wordt uitgebreid uitgeweid hoe we omgaan met de generieke en specifieke MBH ID’s.


5 Vragenuurtje 16 september 2022

5.1 In de nulpunt documentatie wordt Lab2Zorg genoemd; het uitwisselen/weergeven van laboratoriumgegevens. Voor zover ik zie is dit voornamelijk in de context van Voorschrijven. Voorschrijven is voor nCare niet in scope tijdens de Kickstart. Maar ik zie dat ‘Afwijkende nierfunctiewaarden plus datum van bepaling’ wel in de Basisset medicatiegegevens moet worden weergegeven. Moet Lab2zorg tijdens de Kickstart worden geïmplementeerd voor het weergeven van de nierfunctiewaarden in de Basisset medicatiegegevens?

Antwoord: Voor de Kickstart wordt de nierfunctie meegestuurd met de MA + VV van voorschrijver naar verstrekker. De nierfunctie waarde is nog niet opvraagbaar voor zorgverleners, dat zal in het algemeen (inclusief andere labwaarden) worden opgepakt bij de invoering van lab2zorg. Er is nog discussie over de vorm van het meesturen van de INR waarde bij een tromboseschema middels de WDS. In versie MP9 2.0 is dat echter slechts gespecificeerd als vrije tekst optie.

5.2 Stel het ontvangende systeem heeft een recentere nierfunctiewaarde dan wordt meegestuurd, gaat die dan voor? In hoeverre moeten we altijd op de gegevens in de berichten afgaan versus de gegevens die al in het systeem staan?

Antwoord: De labwaarden die de voorschrijver bij de behandeling heeft gezien moet hij meesturen. Op basis van die informatie is de voorschrift bepaald. De nierfunctiewaarde is een verplichting bij de voorschrijvers. Indien je een recentere labwaarde hebt terwijl je het voorschrift hebt verstuurd heb je een informatieplicht, die gaan we ondersteunen met de Lab2zorgstandaard niet door PVMV. We verwijzen dan naar stap 7 dat we in Lab2zorg ervoor moeten zorgen dat de meest recente nierfunctiewaarde bij de andere zorgverleners terecht komt. Hoe weet het lab dat de apotheker daar een afschrift van heeft gekregen? Je kan de patiënt aanmelden via de lab2zorg standaard, dan kan apotheker die waarde weer ophalen. Dit proces moet nog uitgewerkt en gecommuniceerd worden.

5.3 De reden van stoppen is informatie opgeschreven en verwerkt in Z-index en G-standaard tabellen. De tabellen en taalgebruik van reden van stoppen die zij genoteerd hebben sluit niet aan wat in de MP9 informatiestandaard staat (verschil ligt met name in de verwoording. Het ligt in lijn met elkaar, maar komt niet overeen).

Antwoord: De lijst van de informatiestandaard uitleveren via G-standaard is gaande en afgestemd in afgelopen 2 Werkgroepen techniek. De lijst die nu te vinden is in de G-standaard is de NHG lijst, welke dus inderdaad iets anders is en niet bedoeld is voor uitwisseling in MP9 2.0.0.

5.4 Hoe gaat het werken met 90 miljoen nummers in de use cases, deze wordt gegenereerd door de instellingen zelf met eigen artikelbeheer. In hoeverre zegt dit iets in de uitwisseling?

Antwoord: Deze moeten in de eigen route van de zorgaanbieder worden gecommuniceerd. Is een uniek nummer. Je zou het als ontvanger kunnen groeperen / herhalen. Er wordt nu getoetst dat het een uniek is, je mag geen ZI-nummer gebruiken.

5.5 Hoe gaat het praktisch werken, een nummer wijst een eigen artikel aan maar over paar jaar wordt het hergebruikt voor een ander artikel.

Antwoord: Mag niet, je moet zorgen dat het nummer uniek blijft. Als ontvanger moet je het ZI-nummer in combinatie met de route opslaan.

5.6 In hoeverre moeten we 90 miljoen uitsluitlijst hebben, productgroep koppelen aan 90 miljoen nummers? Dit zal niet in de Kickstart worden meegenomen. Wel is er een verzoek voor aangemaakt. In de specs staat dat zodra je de PRK verandert je een nieuwe MBH moet aanmaken, terwijl je alleen de dosering aanpast, klopt dat?

Antwoord: Ja, bij sterkte wijzigingen waar de PRK veranderd moet je nieuwe MBH aanmaken, bij doseerwijzigingen (wijze van dosering) kan je dezelfde MBH ID gebruiken. Als je het voorschrift van de dokter behoudt mag je dezelfde MBH behouden. Als de huisarts het doet moet hij wel een nieuwe MBH starten.

5.7 Wat wordt er van de apotheker verwacht als hij de toedieningsweg wijzigt (bijv. van pil naar poeder)?

Antwoord: het kan zijn dat hier lokale regionale afspraken voor zijn gemaakt, dat je als apotheker binnen bepaalde marge bewegingsvrijheid hebt om zelf te acteren. Als het een eenmalige wijziging is, dan hoef je geen VMA aan te maken. Als het vaker zal voorkomen dan moet je een VMA aanmaken. Eerst een TA aanmaken, verstrekking doen en VMA daarna aanmaken. TA moet je dan weer aanpassen bij de volgende verstrekking ivm andere MBH ID.

5.8 Zijn MITS en Zorgadresboek verplicht of optioneel?

Antwoord: MITS is optioneel. Zorgadresboek is voor alle versturende systemen verplicht.


6 Vragenuurtje 22 september 2022

6.1 Welke inhoudelijke eisen worden gesteld aan de kopie gegevens? Moeten alle kopie-velden exact overeenkomen?

Antwoord: Ja, zoveel als mogelijk overnemen wat kan en waar het echt niet lukt moet de essentie van de informatie bewaard blijven. Altijd zo dicht mogelijk bij het origineel blijven, sommige zaken moeten heel duidelijk zijn zoals het afgesproken geneesmiddel, startdatum en identifiers (zodat je de medicatieafspraak kan herkennen).

6.2 Lopen we ten gevolge van een stop niet het gevaar dat we door niet volledig / goed gemaakte kopieslagen informatie missen in het medicatieoverzicht?

Antwoord: Ja, daarom moet stop MA moet zoveel mogelijk intact blijven, om geen informatie te verliezen.

6.2.1 Wordt dit in het validatietraject getoetst?

Antwoord: Ja en op het moment dat er een afwijking is zal dit besproken worden en gezamenlijk naar een oplossing gezocht worden.

6.3 Wat wordt bedoeld met ‘toekomstige medicatieafspraken blijven bestaan’?

Antwoord: Voorbeeld: bij een opbouwschema, kunnen binnen dezelfde MBH ID meerdere medicatieafspraken zijn (je mag serieel meerdere medicatieafspraken na elkaar plannen binnen dezelfde MBH ID), geen overlappende periodes. Als een specifieke medicatieafspraak stopt heeft dat geen gevolgen voor medicatieafspraken die in de toekomst liggen. Elke medicatieafspraak moet apart worden gestopt. Als er een medicatieafspraak wilt stoppen moet je altijd een verwijzing maken naar de medicatieafspraak. Er is alleen geen verwijzing als er alleen medicatiegebruik is vastgelegd, dan kan je niet verwijzen naar een medicatieafspraak en daarmee stop je de hele MBH ID. Medicatieafspraken die gestopt moet worden, maar nog niet zijn gestart zijn krijgen de stoptype; ‘geannuleerd’. Deze hebben nog niet plaats gevonden dus komen niet in het actuele medicatieoverzicht.

6.4 Mag je wanneer een MBH als kapstok beëindigd is als voorschrijver geen nieuwe ma openen, omdat MBH ten einde is?

Antwoord: Nee, dit is niet expliciet gecodeerd, als er een stop ma is gemaakt is hij definitief gestopt. Het kan zijn dat de medicatie nooit meer gegeven mag worden, daar moet altijd een reden voor opgegeven worden.

6.5 Binnen welke periode kan dezelfde medicatie weer starten onder dezelfde MBH ID? Als de medicatie hetzelfde is moet de MBH ID dan hetzelfde zijn?

Antwoord: Antwoord volgt. Dit gaan we opzoeken in het FO en schriftelijk beantwoorden. Antwoord zal ook op deze wiki worden geplaatst.

6.6 Is het toegestaan om het stoppen van een MA te corrigeren?

Antwoord: Nee, er zijn regels opgesteld voor correctie en annulering. Als een medicatieafspraak nog niet gecommuniceerd is kan deze intern door de voorschrijver in het eigen systeem nog gecorrigeerd worden. Als de stop ma is gemaakt, gedeeld en verwerkt kan het niet meer gecorrigeerd worden en moet er een nieuwe medicatieafspraak gemaakt worden. Bij het per ongeluk stoppen van een ma, moet je in het stappenplan van corrigeren de stap ‘foutieve herstellen’ overslaan. Als de ma eerder moet stoppen dan volgens de stopafspraak bekend is, dan is de stop wel aan te passen, maar de ma kan je niet verlengen. Er is dan sprake van een dubbele stop: je krijgt een nieuwe stop op de stop die je hebt gemaakt hebt en daarna weer een nieuwe ma. Zal nader worden uitgewerkt in voorbeelden

6.7 Wordt de zorgverlener die de ma (per ongeluk) heeft gestopt ook de ma owner?

Antwoord: Ja, dit is niet wenselijk, maar mocht het vaak voorkomen zal het een bespreekpunt voor aanpassing worden.


7 Vragenuurtje 30 september

7.1 Doel is via waardenlijsten informatie direct goed vast te leggen in systemen. Hoe gaat dit als er later nieuwe versies bijkomen of nieuwe waarden worden toegevoegd of verwijderd? Moet de gegevens historisch worden aangepast of wordt elke aanpassing een nieuwe versie van de waardenlijst. In het kort hoe moet er omgegaan worden met verschillende (toekomstige) versies van waardenlijsten?

Antwoord: Antwoord volgt.


-