mp:Medicatieoverdracht Kickstart Vragen: verschil tussen versies
| (55 tussenliggende versies door 2 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | + | {{DISPLAYTITLE: Vragen en antwoorden vragenuurtje Validatieloket Medicatieoverdracht}} | |
| − | |||
| − | |||
| + | '''<big><big>Toelichting</big></big>''' | ||
| − | + | 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. |
| − | '''Antwoord:''' | + | |
| + | __NUMBEREDHEADINGS__ | ||
| + | |||
| + | = Vragenuurtje 12 augustus 2022 = | ||
| + | === 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. | ||
| − | ==== | + | = Vragenuurtje 19 augustus 2022 = |
| − | '''Antwoord:''' | + | === 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. | ||
| + | === Zijn de zaken aangegeven in de checklist vrijblijvend of een vereiste om in te bouwen (zoals MITZ en de signaalfunctie)? === | ||
| + | '''Antwoord:''' [https://www.mitz-toestemming.nl/ 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. | ||
| − | + | === 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. | '''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. | ||
| − | + | === 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) | '''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) | ||
| − | + | === 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. | '''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. | ||
| + | ==== 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. | '''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. | 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. | ||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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 | ||
| + | * https://www.aorta-lsp.nl/media/downloads/ontwerp-abonnementenregister-aorta-v8200pdf/download | ||
| + | * https://decor.nictiz.nl/pub/vzvz/aorta-vzvz-html-20200821T140325/sc-2.16.840.1.113883.2.4.3.111.3.7.3.1-2016-09-16T115325.html | ||
| + | * https://decor.nictiz.nl/pub/vzvz/aorta-vzvz-html-20200821T140325/sc-2.16.840.1.113883.2.4.3.111.3.7.3.3-2017-03-29T132850.html | ||
| + | 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. | ||
| + | |||
| + | ==== 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) | ||
| + | |||
| + | === In welke volgorde (logische volgorde) moet je de bouwblokken inbouwen om te voldoen aan de planning van de Kickstart? === | ||
| + | '''Antwoord:''' zie [[mp:V2.0.0_Verwijzing_naar_documentatie_Medicatieproces9_tbv_Kickstart|Verzamelbestand met functionele, technische en infrastructurele documentatie Medicatieproces 9 t.b.v. Kickstart]] | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === Moet de functionaliteit voor het registreren van wisselende doseerschema’s ingebouwd worden === | ||
| + | '''Antwoord:''' Ja, dit moet ingebouwd worden | ||
| + | |||
| + | === 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 | ||
| + | |||
| + | |||
| + | = Vragenuurtje 2 september 2022 = | ||
| + | === 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. | ||
| + | |||
| + | ==== 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’. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | |||
| + | = Vragenuurtje 9 september 2022 = | ||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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 [[mp:Vkickstart MigratieHybride|de hybride situatie]] wordt uitgebreid uitgeweid hoe we omgaan met de generieke en specifieke MBH ID’s. | ||
| + | |||
| + | |||
| + | = Vragenuurtje 16 september 2022 = | ||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === Zijn MITS en Zorgadresboek verplicht of optioneel? === | ||
| + | '''Antwoord:''' MITS is optioneel. Zorgadresboek is voor alle versturende systemen verplicht. | ||
| + | |||
| + | |||
| + | = Vragenuurtje 23 september 2022 = | ||
| + | === 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). | ||
| + | |||
| + | === 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. | ||
| + | ==== 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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 | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | = Vragenuurtje 30 september = | ||
| + | === 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:''' We gaan de historische gegevens aanpassen op basis van nieuwe waardenlijsten. De keuze of we gaan opschonen of huidige lijsten blijven aanvullen moet nog gemaakt worden; uitkomst volgt. | ||
| + | |||
| + | === In hoeverre zijn de aanpalende specificaties (bijv. uit de Z-index) voor oa medicatiebewaking verplichte items bij de toetsing? === | ||
| + | '''Antwoord:''' We gaan vanuit de validatie niet toetsen op de medicatiebewaking, dat ligt bij de gebruiker. Als er aanvullende gebruikerseisen komen, moet er wel voldaan worden aan die richtlijnen. | ||
| + | |||
| + | === Wordt alle technische documentatie ook in het Engels aangeleverd? === | ||
| + | '''Antwoord:''' Het TO is in het Engels en het FO wordt in het Engels bijgehouden, aanvullende documentatie niet | ||
| + | |||
| + | |||
| + | = Vragenuurtje 21 oktober 2022 = | ||
| + | === Wat is in scope bij de Kickstart voor bijvoorbeeld de zib Medicatiegebruik. Als er met FHIr gewerkt wordt moeten we dan stap 3 (Sturen), stap 4 (Ontvangen) ontwikkelen, of is het al compleet/voldoende als we alleen stap 1 (Beschikbaar stellen) en stap 2 (Raadplegen) ontwikkelen? === | ||
| + | '''Antwoord:''' Alle LSP interacties moeten worden ontwikkeld en ze zullen allemaal beproefd worden in de praktijktest. | ||
| + | |||
| + | === Waarom is er een wens voor 'Niet in GDS' op de VV? === | ||
| + | '''Antwoord:''' dit is besloten in een kernteam / expertpanel, meer informatie over dit besluit volgt | ||
| + | |||
| + | === Als de voorschrijver geen nierfunctie kan sturen omdat die niet bekend is, moet hij de MA +/- VV sturen zonder nierfunctie? Moet de verstrekker dit dan interpreteren als het gemis van een nierfunctiewaarde? === | ||
| + | '''Antwoord:''' Ja er is op dat moment dan geen recente nierfunctie waarde. Daarom zowel afwijkende als niet afwijkende communiceren. | ||
| + | |||
| + | === Wat betekent de term voorschrijfbeleid? === | ||
| + | '''Antwoord:''' De voorschrijver heeft de zaken vastgelegd op de informatie van dat moment. Is er een nierfunctie bekend wordt die meegenomen, is deze niet bekend dan niet. | ||
| + | |||
| + | === Waarom Verstrekker als onvt op 'Ontvangen Toedieningsafspraak door zorgverlener'? === | ||
| + | '''Antwoord:''' In het geval dat er geen toestemming is moeten medicatiegegevens gepushed kunnen worden, ook bijvoorbeeld bij ontslag na opname, dan worden de MA/TA/MGB verstuurd naar naar vaste apotheek en huisarts (ondermeer). Een ais moet deze dan wel kunnen ontvangen. | ||
| + | |||
| + | === Klopt het dat in het ZORGAB straks is terug te vinden welke versie van MP een AIS gebruikt (Klassiek Edifact / MP6 / MP9). Kortom een plaats waar je centraal kunt uitvinden welke route je op moet bij het versturen van het voorschrift? === | ||
| + | '''Antwoord:''' Klopt voor LSP communicatie en dat is nu reeds beschikbaar zie https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases | ||
| + | Het beschikbaar stellen van edifact staat op de planning. | ||
| + | |||
| + | === Het zou (ook voor de landelijke uniformiteit) prettig zijn als duidelijk is hoe omgegaan moet worden met conversie van ‘klassiek’ (NHG25) naar MP9 en terug. Is er ondersteuning voor? === | ||
| + | '''Antwoord:''' Wij zijn hierover in discussie met het NHG, actie ligt bij hen. Het kan geen kwaad als ook andere stakeholders ’t NHG hierover bevragen. Vraag: in welke usecase zou je ‘terug’ willen vertalen naar NHG? Als een systeem MP9 ondersteunt is de verwachting dat het interne datamodel hierop aansluit. NHG tabel25 zou alleen eventueel nog gebruikt kunnen worden als ‘invoerhulp’, maar niet meer dan dat. Voor terugvertalen zou er daarom geen usecase mogen zijn. | ||
| + | |||
| + | === Waarom moeten we in de Kickstart meenemen dat een huisarts voorstellen voor MA en VV gaat uitzetten (terwijl dit in de praktijk waarschijnlijk niet veel voor zal komen)? === | ||
| + | '''Antwoord:''' In de Kickstart gaan we dit beproeven in de praktijktest ter voorbereiding op de brede uitrol. | ||
| + | |||
| + | === Bevat de MA en TA wel een globale dosering (zonder nadere invulling) of geen dosering? === | ||
| + | '''Antwoord:''' De MA bevat geen doseerinstructie. Dit wordt volledig vastgelegd in het WDS. Ook om eventuele verwarring te voorkomen. | ||
| + | |||
| + | === Bevat de MA wel een relevante (globale) dosering ivm voorschrift (VOS) richting de apotheek? === | ||
| + | '''Antwoord:''' Nee, zowel de MA als de TA bevatten alleen het kenmerk ‘volgens schema trombosedienst’ en geen doseerinstructie. | ||
| + | |||
| + | === Kan de trombosedienst koppeling ook worden gebruikt als de apotheek niet via LSP verbonden is, of is de LSP aansluiting een voorwaarde? === | ||
| + | '''Antwoord:''' In de praktijk zal deze opvraagbaar zijn en dat zal (zeker voor de KS) via het LSP gaan. We gaan er op dit moment van uit dat alles via het LSP opvraagbaar is. Er kunnen straks andere manieren komen om de communicatie mogelijk te maken, maar we proberen de garantie te geven dat deze informatie dan ook altijd via het LSP te communiceren is. | ||
| + | |||
| + | |||
| + | = Vragenuurtje 28 oktober 2022 = | ||
| + | === Het MA / VV model zoals in de Voorschrift-transactie, staat toe om bij één MA meerdere VV te sturen? Hoe zien jullie het gebruik daarvan? === | ||
| + | '''Antwoord:''' Dit is niet als use case opgenomen, hoewel het wel als use case zou kunnen voorkomen, er zijn namelijk geen regels die dit kunnen uitsluiten. | ||
| + | |||
| + | === Hoe past in het Edifact/MEDREC dat 1 MA meerdere VV’s stuurt? === | ||
| + | '''Antwoord:''' Op de wiki pagina van de migratie staat een voorstel hoe je Edifact berichten kan mappen. Edifact moet niet verwijzen naar vv, dus voor elk vv komt er een apart Edifact bericht. Als je MP9 MA + VV maakt maar de apotheek ontvangt dat nog niet verstuur je 2 met rekjes (en de juiste data). | ||
| + | |||
| + | |||
| + | = Vragenuurtje 4 november 2022 = | ||
| + | === De structuur is - MBH > VV - Voorstelgegevens > MBH. Wat is de bedoeling is van de 2de MBH (die in de voorstelgegevens)? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === De Art-Decor toelichting is alleen een algemene toelichting op wat een MBH is, niet hoe deze hier specifiek functioneert. Waar kunnen we daarover meer informatie vinden (niet in het FO zo te zien)? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Het ontbreken van een specifieke toelichting doet zich overigens op meerdere plaatsen voor. Meestal is wel te raden wat de bedoeling is. Kunnen we die informatie ergens terugvinden? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | |||
| + | = Vragenuurtje 11 november 2022 = | ||
| + | === Waarom is er een wens voor 'Niet in GDS' op de VV? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Patiënt kenmerk GDS niet voldoende geautomatiseerd. === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Als we straks gaan werken in de KS gaan we dan de HL7v3 berichten sturen of de FHIR? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Wordt er ondersteuning geboden bij het mappen en vertalen van tabel 25? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Waarom ook terugvertalen naar tabel 25? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Wordt het de taakstelling voor het ontvangende en verzendende systeem om zelf de mapping te doen of wordt dit in het AORTA systeem gedaan? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | |||
| + | = Vragenuurtje 18 november 2022 = | ||
| + | === Welke download kan het best gebruikt worden als basis voor het maken van transport-laag source-code tbv CDA-HL7 voor MP9 via LSP? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Is er beheer op voorkomen van circular dependencies in de schema’s? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Er wordt verwezen naar een NL core encounter. Voor huisartsenzorg zijn die op GP encounter gemaakt. In hoeverre wordt verwacht dat dit hetzelfde encounter object is met een verschillende view. Is een MP9 business nummer dan hetzelfde? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Op dit moment gebruiken we MEDREC RVZ en ARV voor het receptverzoek vanuit de apotheek, en antwoord vanuit de huisarts. Daarbij kan een vrije tekst toelichting worden gegeven die wordt meegestuurd. Klopt het dat mogelijkheid echter in ART-DECOR ontbreekt? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === De voorziening dat iemand een GDS patiënt wordt komt later pas aan bod. Als het uitgesteld wordt heb je dan voldoende aan overrule vak of moet je dan ook optie hebben ‘wel in GDS’ hebben? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Is er al een idee hoe om te gaan met apotheken die een recept niet willen behandelen? Er is een keuze om een recept niet te accepteren. Kan je dat ergens terugkoppelen, bijvoorbeeld door middel van een afwijsbericht? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | |||
| + | = Vragenuurtje 25 november 2022 = | ||
| + | === Hoe moet je de PTO inrichten? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Kan je ART-DECOR vanuit alle werkplekken van de engineers benaderen of alleen gecentraliseerd; gewhiteliste machine? Wat zijn de technische mogelijkheden of belemmeringen? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Wie kan je benaderen bij vragen over tooling of als bepaalde tooling niet werkt? === | ||
| + | '''Antwoord:''' Altijd via BITS een ticket indienen, aanvullend kan een mail gestuurd worden naar het Validatieloket. Je vraag wordt dan doorgestuurd naar de juiste kennishouder om je vraag te beantwoorden. | ||
| + | |||
| + | === Waar kan ik voorbeeldberichten vinden? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Bij ‘het gebruik’ staat dat er bij een eenmalig voorschrift alleen een einddatum ingevuld kan worden. Waarom is dat, normaliter moet er ook altijd een startdatum ingevuld worden, is het verboden om een startdatum mee te sturen? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Als je de validatie behaald krijg je een TKID en wordt dat in het LSP en ZORG-AB bijgewerkt. Hoe weet je welke TKID’s voor welk onderdeel zijn? === | ||
| + | '''Antwoord:''' Hiervoor kan je een mail sturen naar het Validatieloket: validatie@medicatieoverdracht.nl | ||
| + | |||
| + | === Wordt er voor het testen iets voor ZORG-AB ingericht? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Krijgen Kickstart leveranciers een lijst van die partijen zoals ze in het ZORG-AB staan? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Is er voor de testperiode een ander soort ZORG-AB beschikbaar? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| + | |||
| + | === Staat er bij de zorgverlener in het ZORG-AB van welke informatiestandaard zij gebruik maken? === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| − | |||
| − | |||
| + | = Vragenuurtje 2 december 2022 = | ||
| + | === Kan je een TA zonder MA aanmaken? De specs beschrijven enkel een toedieningsafspraak zonder medicatieafspraak voor de papier-recept afhandeling. === | ||
| + | '''Antwoord:''' Antwoord volgt | ||
| − | === | + | === Moet het apothekers systeem de bouwblokken niet publiceren totdat de juiste MA akkoord is? Of publiceren als TA zonder MA? === |
| − | '''Antwoord:''' | + | '''Antwoord:''' Antwoord volgt |
Huidige versie van 7 dec 2022 om 17:51
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.
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
- https://www.aorta-lsp.nl/media/downloads/ontwerp-abonnementenregister-aorta-v8200pdf/download
- https://decor.nictiz.nl/pub/vzvz/aorta-vzvz-html-20200821T140325/sc-2.16.840.1.113883.2.4.3.111.3.7.3.1-2016-09-16T115325.html
- https://decor.nictiz.nl/pub/vzvz/aorta-vzvz-html-20200821T140325/sc-2.16.840.1.113883.2.4.3.111.3.7.3.3-2017-03-29T132850.html
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 23 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: We gaan de historische gegevens aanpassen op basis van nieuwe waardenlijsten. De keuze of we gaan opschonen of huidige lijsten blijven aanvullen moet nog gemaakt worden; uitkomst volgt.
7.2 In hoeverre zijn de aanpalende specificaties (bijv. uit de Z-index) voor oa medicatiebewaking verplichte items bij de toetsing?
Antwoord: We gaan vanuit de validatie niet toetsen op de medicatiebewaking, dat ligt bij de gebruiker. Als er aanvullende gebruikerseisen komen, moet er wel voldaan worden aan die richtlijnen.
7.3 Wordt alle technische documentatie ook in het Engels aangeleverd?
Antwoord: Het TO is in het Engels en het FO wordt in het Engels bijgehouden, aanvullende documentatie niet
8 Vragenuurtje 21 oktober 2022
8.1 Wat is in scope bij de Kickstart voor bijvoorbeeld de zib Medicatiegebruik. Als er met FHIr gewerkt wordt moeten we dan stap 3 (Sturen), stap 4 (Ontvangen) ontwikkelen, of is het al compleet/voldoende als we alleen stap 1 (Beschikbaar stellen) en stap 2 (Raadplegen) ontwikkelen?
Antwoord: Alle LSP interacties moeten worden ontwikkeld en ze zullen allemaal beproefd worden in de praktijktest.
8.2 Waarom is er een wens voor 'Niet in GDS' op de VV?
Antwoord: dit is besloten in een kernteam / expertpanel, meer informatie over dit besluit volgt
8.3 Als de voorschrijver geen nierfunctie kan sturen omdat die niet bekend is, moet hij de MA +/- VV sturen zonder nierfunctie? Moet de verstrekker dit dan interpreteren als het gemis van een nierfunctiewaarde?
Antwoord: Ja er is op dat moment dan geen recente nierfunctie waarde. Daarom zowel afwijkende als niet afwijkende communiceren.
8.4 Wat betekent de term voorschrijfbeleid?
Antwoord: De voorschrijver heeft de zaken vastgelegd op de informatie van dat moment. Is er een nierfunctie bekend wordt die meegenomen, is deze niet bekend dan niet.
8.5 Waarom Verstrekker als onvt op 'Ontvangen Toedieningsafspraak door zorgverlener'?
Antwoord: In het geval dat er geen toestemming is moeten medicatiegegevens gepushed kunnen worden, ook bijvoorbeeld bij ontslag na opname, dan worden de MA/TA/MGB verstuurd naar naar vaste apotheek en huisarts (ondermeer). Een ais moet deze dan wel kunnen ontvangen.
8.6 Klopt het dat in het ZORGAB straks is terug te vinden welke versie van MP een AIS gebruikt (Klassiek Edifact / MP6 / MP9). Kortom een plaats waar je centraal kunt uitvinden welke route je op moet bij het versturen van het voorschrift?
Antwoord: Klopt voor LSP communicatie en dat is nu reeds beschikbaar zie https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases Het beschikbaar stellen van edifact staat op de planning.
8.7 Het zou (ook voor de landelijke uniformiteit) prettig zijn als duidelijk is hoe omgegaan moet worden met conversie van ‘klassiek’ (NHG25) naar MP9 en terug. Is er ondersteuning voor?
Antwoord: Wij zijn hierover in discussie met het NHG, actie ligt bij hen. Het kan geen kwaad als ook andere stakeholders ’t NHG hierover bevragen. Vraag: in welke usecase zou je ‘terug’ willen vertalen naar NHG? Als een systeem MP9 ondersteunt is de verwachting dat het interne datamodel hierop aansluit. NHG tabel25 zou alleen eventueel nog gebruikt kunnen worden als ‘invoerhulp’, maar niet meer dan dat. Voor terugvertalen zou er daarom geen usecase mogen zijn.
8.8 Waarom moeten we in de Kickstart meenemen dat een huisarts voorstellen voor MA en VV gaat uitzetten (terwijl dit in de praktijk waarschijnlijk niet veel voor zal komen)?
Antwoord: In de Kickstart gaan we dit beproeven in de praktijktest ter voorbereiding op de brede uitrol.
8.9 Bevat de MA en TA wel een globale dosering (zonder nadere invulling) of geen dosering?
Antwoord: De MA bevat geen doseerinstructie. Dit wordt volledig vastgelegd in het WDS. Ook om eventuele verwarring te voorkomen.
8.10 Bevat de MA wel een relevante (globale) dosering ivm voorschrift (VOS) richting de apotheek?
Antwoord: Nee, zowel de MA als de TA bevatten alleen het kenmerk ‘volgens schema trombosedienst’ en geen doseerinstructie.
8.11 Kan de trombosedienst koppeling ook worden gebruikt als de apotheek niet via LSP verbonden is, of is de LSP aansluiting een voorwaarde?
Antwoord: In de praktijk zal deze opvraagbaar zijn en dat zal (zeker voor de KS) via het LSP gaan. We gaan er op dit moment van uit dat alles via het LSP opvraagbaar is. Er kunnen straks andere manieren komen om de communicatie mogelijk te maken, maar we proberen de garantie te geven dat deze informatie dan ook altijd via het LSP te communiceren is.
9 Vragenuurtje 28 oktober 2022
9.1 Het MA / VV model zoals in de Voorschrift-transactie, staat toe om bij één MA meerdere VV te sturen? Hoe zien jullie het gebruik daarvan?
Antwoord: Dit is niet als use case opgenomen, hoewel het wel als use case zou kunnen voorkomen, er zijn namelijk geen regels die dit kunnen uitsluiten.
9.2 Hoe past in het Edifact/MEDREC dat 1 MA meerdere VV’s stuurt?
Antwoord: Op de wiki pagina van de migratie staat een voorstel hoe je Edifact berichten kan mappen. Edifact moet niet verwijzen naar vv, dus voor elk vv komt er een apart Edifact bericht. Als je MP9 MA + VV maakt maar de apotheek ontvangt dat nog niet verstuur je 2 met rekjes (en de juiste data).
10 Vragenuurtje 4 november 2022
10.1 De structuur is - MBH > VV - Voorstelgegevens > MBH. Wat is de bedoeling is van de 2de MBH (die in de voorstelgegevens)?
Antwoord: Antwoord volgt
10.2 De Art-Decor toelichting is alleen een algemene toelichting op wat een MBH is, niet hoe deze hier specifiek functioneert. Waar kunnen we daarover meer informatie vinden (niet in het FO zo te zien)?
Antwoord: Antwoord volgt
10.3 Het ontbreken van een specifieke toelichting doet zich overigens op meerdere plaatsen voor. Meestal is wel te raden wat de bedoeling is. Kunnen we die informatie ergens terugvinden?
Antwoord: Antwoord volgt
11 Vragenuurtje 11 november 2022
11.1 Waarom is er een wens voor 'Niet in GDS' op de VV?
Antwoord: Antwoord volgt
11.2 Patiënt kenmerk GDS niet voldoende geautomatiseerd.
Antwoord: Antwoord volgt
11.3 Als we straks gaan werken in de KS gaan we dan de HL7v3 berichten sturen of de FHIR?
Antwoord: Antwoord volgt
11.4 Wordt er ondersteuning geboden bij het mappen en vertalen van tabel 25?
Antwoord: Antwoord volgt
11.5 Waarom ook terugvertalen naar tabel 25?
Antwoord: Antwoord volgt
11.6 Wordt het de taakstelling voor het ontvangende en verzendende systeem om zelf de mapping te doen of wordt dit in het AORTA systeem gedaan?
Antwoord: Antwoord volgt
12 Vragenuurtje 18 november 2022
12.1 Welke download kan het best gebruikt worden als basis voor het maken van transport-laag source-code tbv CDA-HL7 voor MP9 via LSP?
Antwoord: Antwoord volgt
12.2 Is er beheer op voorkomen van circular dependencies in de schema’s?
Antwoord: Antwoord volgt
12.3 Er wordt verwezen naar een NL core encounter. Voor huisartsenzorg zijn die op GP encounter gemaakt. In hoeverre wordt verwacht dat dit hetzelfde encounter object is met een verschillende view. Is een MP9 business nummer dan hetzelfde?
Antwoord: Antwoord volgt
12.4 Op dit moment gebruiken we MEDREC RVZ en ARV voor het receptverzoek vanuit de apotheek, en antwoord vanuit de huisarts. Daarbij kan een vrije tekst toelichting worden gegeven die wordt meegestuurd. Klopt het dat mogelijkheid echter in ART-DECOR ontbreekt?
Antwoord: Antwoord volgt
12.5 De voorziening dat iemand een GDS patiënt wordt komt later pas aan bod. Als het uitgesteld wordt heb je dan voldoende aan overrule vak of moet je dan ook optie hebben ‘wel in GDS’ hebben?
Antwoord: Antwoord volgt
12.6 Is er al een idee hoe om te gaan met apotheken die een recept niet willen behandelen? Er is een keuze om een recept niet te accepteren. Kan je dat ergens terugkoppelen, bijvoorbeeld door middel van een afwijsbericht?
Antwoord: Antwoord volgt
13 Vragenuurtje 25 november 2022
13.1 Hoe moet je de PTO inrichten?
Antwoord: Antwoord volgt
13.2 Kan je ART-DECOR vanuit alle werkplekken van de engineers benaderen of alleen gecentraliseerd; gewhiteliste machine? Wat zijn de technische mogelijkheden of belemmeringen?
Antwoord: Antwoord volgt
13.3 Wie kan je benaderen bij vragen over tooling of als bepaalde tooling niet werkt?
Antwoord: Altijd via BITS een ticket indienen, aanvullend kan een mail gestuurd worden naar het Validatieloket. Je vraag wordt dan doorgestuurd naar de juiste kennishouder om je vraag te beantwoorden.
13.4 Waar kan ik voorbeeldberichten vinden?
Antwoord: Antwoord volgt
13.5 Bij ‘het gebruik’ staat dat er bij een eenmalig voorschrift alleen een einddatum ingevuld kan worden. Waarom is dat, normaliter moet er ook altijd een startdatum ingevuld worden, is het verboden om een startdatum mee te sturen?
Antwoord: Antwoord volgt
13.6 Als je de validatie behaald krijg je een TKID en wordt dat in het LSP en ZORG-AB bijgewerkt. Hoe weet je welke TKID’s voor welk onderdeel zijn?
Antwoord: Hiervoor kan je een mail sturen naar het Validatieloket: validatie@medicatieoverdracht.nl
13.7 Wordt er voor het testen iets voor ZORG-AB ingericht?
Antwoord: Antwoord volgt
13.8 Krijgen Kickstart leveranciers een lijst van die partijen zoals ze in het ZORG-AB staan?
Antwoord: Antwoord volgt
13.9 Is er voor de testperiode een ander soort ZORG-AB beschikbaar?
Antwoord: Antwoord volgt
13.10 Staat er bij de zorgverlener in het ZORG-AB van welke informatiestandaard zij gebruik maken?
Antwoord: Antwoord volgt
14 Vragenuurtje 2 december 2022
14.1 Kan je een TA zonder MA aanmaken? De specs beschrijven enkel een toedieningsafspraak zonder medicatieafspraak voor de papier-recept afhandeling.
Antwoord: Antwoord volgt
14.2 Moet het apothekers systeem de bouwblokken niet publiceren totdat de juiste MA akkoord is? Of publiceren als TA zonder MA?
Antwoord: Antwoord volgt