mp:Medicatieoverdracht Kickstart Vragen: verschil tussen versies
Regel 41: | Regel 41: | ||
=== 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? === | === 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:''' | '''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://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.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 | + | * 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. ==== | ==== Aanvullend op eerdere vraag: is er ook iets als een query waarmee je check kan doen of er iets verandert is in een dossier. ==== | ||
Regel 68: | Regel 66: | ||
=== Medicatieverificatie wordt redelijk vaak in het FO genoemd. Toch is ons niet helemaal duidelijk hoe dit zou moeten werken. === | === 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 | '''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 | ||
Versie van 7 sep 2022 19:40
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
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 MITS en de signaalfunctie)?
Antwoord: MITS 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 Wik. 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.
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)
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.
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.
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?
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: Volgt
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 ICBC 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 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 gebruiken en dan moet je kiezen.
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 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 ICBC kan vertalen naar 2 Snomed codes welke kies je?
Antwoord: Als je de code niet begrijpt dan moet je gebruik maken van de vrije tekst invoer 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 bij de voorschrijver.
Als je ICBC hebt ontvangen in de originele dan doe je ook ICBC in de kopie MA, moet je dan de code opslaan?
Antwoord: Als je een verstrekkingsverzoek maakt moet je een MA meesturen, dit moet kopie zijn en niet een afgeleide. Je moet de originele code dus onthouden of eerst de vorige MA opvragen en die bij het verstrekkingsverzoek voegen. Je moet alle 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 met de snomed code worden in Z-index gepubliceerd. Dit is momenteel nog niet beschikbaar komt in de volgende Z-index.
-