Zib issues (deel 3 : issues 1000 - 1499)
ZIB-1004
links/referenties in zib wilsverklaring zijn niet meer actueel
| Aangemaakt op: | 06-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
bij checken op de wiki viel mij op de de referenties outdated zijn (2015). In ieder geval die van NPCF en NPV kloppen niet meer. NPCF is nu https://www.patientenfederatie.nl/themas/wilsverklaring/wat-hoe en NPV is nu https://npvzorg.nl/levenswensverklaring/
Besluit:
ZIB-1006
Typo Toedieningsafspraak stop type: een 'g' teveel
| Aangemaakt op: | 07-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Er staat : Toedien*{color:#FF0000}g{color}*ingsafspraakStopType
[https://zibs.nl/wiki/Toedieningsafspraak-v1.0.1(2019NL)#13341]
Besluit:
ZIB-1009
Aanvullingen zib druggebruik: waardenlijst middelen
| Aangemaakt op: | 11-11-2019 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Vanuit GGZ NL willen wij graag een uitbreiding van de de waardenlijst middelen
TypeOfDrugOrMedicationCodelist
Valueset OID: 2.16.840.1.113883.2.4.3.11.60.40.2.7.4.1
Met de volgende rubrieken:
Opiaten
4FA
Oxicodon
En graag in overleg met verslavingsdeskundigen om de indeling nader te specificeren.
Contact via Jeroen Wisselink, jeroen.wisselink@sivz.nl
Stichting InformatieVoorziening Zorg.
Besluit:
ZIB-1011
Omschrijving bij 'Aantal herhalingen"
| Aangemaakt op: | 11-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De omschrijving bij 'aantal herhalingen' in het Verstrekkingsverzoek blijkt nog niet volledig te zijn. De zorgpartijen hebben aangegeven dat het aantal herhalingen ook mag slaan op de verbruiksperiode duur.
Hierdoor is een aanvulling op de tekst nodig en wordt deze als volgt:
Het aantal additionele keren dat verstrekt mag worden ná de eerste verstrekking.
In geval van een opgegeven _Te verstrekken hoeveelheid_: De totaal te verstrekken hoeveelheid is: (Aantal herhalingen + 1) x te verstrekken hoeveelheid.
In geval van een opgegeven _Verbruiksperiode Duur_: De totaal te verstrekken duur is: (Aantal herhalingen + 1) x verbruiksperiode duur.
Besluit:
ZIB-1016
Monsternummer kan niet 0..* zijn
| Aangemaakt op: | 18-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib LaboratoriumUitslag v4.1 t/m v4.4 staat Monsternummer 0..* en daarnaast staat Monstervolgnummer 0..1 met als toelichting:
_Het monstervolgnummer wordt toegepast, als het verzamelde materiaal uit de oorspronkelijke buis of container verdeeld wordt over meerdere buizen. In combinatie met het monsternummer biedt het volgnummer de mogelijkheid de buis of container uniek te identificeren._
Als er meerdere Monsternummers zijn, dan is niet meer te achterhalen op welke daarvan het monstervolgnummer van toepassing is. De zib is op dit punt ook niet in lijn met de transacties op basis van e-Lab waarin Monsternummer 0..1 of 1..1 is.
*Voorstel*: wijzig Monsternummer van 0..* naar 0..1.
Besluit:
ZIB-1020
Zib Gewicht en Zib Lengte uit Zib Medicatieafspraak halen
| Aangemaakt op: | 21-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Momenteel is de Zib LichaamsGewicht en Zib LichaamsLengte bínnen de Zib Medicatieafspraak opgenomen.
Daar waar Gewicht of Lengte van belang is voor de medicatie, is vanuit Medicatieproces programma (vanuit Leveranciers en Zorgvertegenwoordigers) de vraag gekomen om deze gewoon als losse ZIBs te kunnen behandelen. Dat betekent dat deze bij medicatieproces búiten de Medicatieafspraak los meegestuurd zullen worden indien van toepassing.
Hierbij het wijzigingsverzoek om deze 2 zibs uit de medicatieafspraak te halen.
Besluit:
ZIB-1021
Element 'Geannuleerd indicator' uit MA verwijderen
| Aangemaakt op: | 21-11-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De projectgroep (zorgvertegenwoordigers) ziet geen toegevoegde waarde in de geannuleerd indicator.
In het geval van een fout/correctie wordt de foutieve afspraak gestopt en niet de geannuleerd indicator gebruikt.
Besluit:
ZIB-1028
Verwijzing naar NHG tabel aanpassing
| Aangemaakt op: | 03-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Momenteel staat er in de omschrijving bij diverse elementen: _tijdseenheden, keerdosis / maximale keerdosis_ de volgende zin:
'Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25)'
Voor de keerdosis is echter de G-standaard thesaurus basiseenheden verplicht en voor tijdseenheid UCUM.
Het is wel toegestaan om *daarnaast optioneel ook* een NHG ** tabel waarde mee te geven.
Voorstel: Tekst aanpassen bij keerdosis en bij tijdseenheden de zin verwijderen.
Nieuwe tekst:
'Daarnaast mág ook een waarde uit NHG tabel Gebruiksvoorschriften (tabel 25) meegegeven worden.'
Besluit:
ZIB-1029
Patient Geboortedatum en Geslacht verplichting onterecht
| Aangemaakt op: | 03-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib Patient stelt de concepten geboortedatum en geslacht verplicht. Dit lijkt een overblijfsel te zijn vanuit een perspectief op uitwisseling tussen zorgverleners tijdens de ontwikkeling van deze zib. In andere contexten kan het zeer goed voorkomen dat deze concepten niet voorkomen / geregistreerd worden of nodig zijn. Uitwisseling binnen een patient context zijn deze gegevens niet altijd relevant / nodig.
Aangezien de zib use case onafhankelijk is en een generiek basis model moet voorstellen zou de cardinaliteit hier beter aangepast worden naar 0..1. Dit sluit dan ook beter bij het internationale patient informatiemodel in FHIR.
Besluit:
ZIB-1032
Omschrijving bij doseerduur (zin verwijderen)
| Aangemaakt op: | 05-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
GebruiksInstructie > Doseerduur
Als er maar één dosering is binnen de gebruiksinstructie wordt de doseerduur feitelijk bepaald door de gebruiksperiode en is de doseerduur dus redundant. Het heeft dan zelfs de voorkeur om deze weg te laten.
Daarom graag de volgende zin verwijderen uit de omschrijving:
"Leeg laten van doseerduur mag alleen bij medicatie voor onbepaalde duur."
|NL-CM:9.12.22506| | |!https://zibs.nl/images/thumb/0/0b/Arrowright.png/10px-Arrowright.png|width=10,height=11! Doseerduur|0..1|De beoogde tijdsduur voor deze doseerinstructie, bjivoorbeeld 5 dagen of 8 weken.Bij medicatie voor onbepaalde duur wordt in de laatste doseerinstructie de doseerduur leeg gelaten. Leeg laten van doseerduur mag alleen bij medicatie voor onbepaalde duur.|
Besluit:
ZIB-1050
Total score codering voor GCS
| Aangemaakt op: | 13-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij uitwerken van Glasgow Coma Scale voor de ISO standaard als voorbeeld kwam ik er achter dat de LOINC of SNOMEDCT code voor de GCS totaal score ontbreken.
Wijzigingsverzoek is om dat aan te vullen voor publicatie 2020:
De juiste waarden zijn
LOINC: 9269-2 Glasgow Score Total
SCT:: 386560004: Glasgow coma score (Type:= clinical finding)
Waarbij de SCT keuze consistenter lijkt tov de overige waarden van ogen, verbaal en motoriek.
Deze waarden zijn indertijd voor de Nictiz projecten CVA ketenzorg en Acute zorg al uitgezocht en in datasets opgenomen
http://decor.nictiz.nl/pub/acutezorg/acutezorg-html-20190418T175310/ds-2.16.840.1.113883.2.4.3.11.60.55.1.1-2012-09-26T000000.html.
Echter in de dataset acute zorg overdracht wordt de observable entity code gebruikt voor de GCS totaal score met code "248241002" (Glasgow coma score (observable entity)) uit codesysteem 2.16.840.1.113883.6.96 SNOMED CT) .
Gezien de score een bevinding is, gelijkwaardig aan de score op de drie variabelen en waarvoor een clinical finding codes is gebruikt zou hier consistentie van toepassing moeten zijn. In de CVA ketenzorg is er waarschijnlijk geen implementatie, maar in de acute zorg is er wel sprake van. In dien zin zou de al gebruikte code, ook al is die niet ideaal, wellicht toch gebruikt kunnen worden.
In de ISO standaard gebruik ik de LOINC code LOINC: 9269-2 Glasgow Score Total nu als voorbeeld om niet dit issue over welk van de SCT's moet ik gebruiken tegen te gaan komen.
Besluit:
ZIB-1052
Wijziging definitie Behandelaanwijzing
| Aangemaakt op: | 13-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
NHG: De definities verschillen, het aspect van acute situatie is niet verwoord (wel beschreven) en de connotatie van “afspraak” is niet verwoord in het HIS-Referentiemodel.
Redenatie: wilsverklaring wordt in de praktijk gezien als een document of andere schriftelijk uitgedrukte verklaring, een mondelinge wilsverklaring (conform RadB ZIB) voldoet daar niet aan.
Daarbij komt dat de zorgverlener ook op diens initiatief het gesprek over bijvoorbeeld reanimatie kan aangaan, en dat daarmee de basis van wilsverklaring (in de definitie van de RadB ZIB) niet per se van toepassing is.
“een afgesproken beperking” is ook niet altijd van toepassing. Het kan evenzeer van belang zijn om uit te drukken dat het uitvoeren van een behandeling wèl gewenst is.
RadB-zib wijzigingsvoorstel: Een afgesproken besluit van de eindverantwoordelijk arts en de patiënt (of diens vertegenwoordiger) waaruit blijkt of een bepaalde behandeling, zoals een reanimatie, wel of niet uitgevoerd moet worden indien de acute situatie zich aandient.
#NHGHarmonisatie
Besluit:
ZIB-1053
Behandelingcodelijst - 'Opname in Ziekenhuis', NHG tabel 62 en cardinaliteit
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Verzoek van de NHG om de waarde 'Opname in ziekenhuis' toe te voegen als keuzeoptie in de behandelaanwijzingen. Daarbij wordt verzoek om de NHG tabel 62 als geheel toe te voegen aan de behandelcodelijst.
Een gerelateerd issue van de NHG is dat 'Behandelcodelijst' een optie bevat om OTHER in te voeren indien de keuzewaarden in behandelaanwijzingen niet voldoen. Daarmee kan het veld Aard.beschrijving in het HIS-referentiemodel vervallen. Echter, de cardinaliteit van Aard.beschrijving is 1; aldus zou men willen dat de cardinaliteit van Behandelcodelijst op 1 wordt gezet.
#NHGHarmonisatie
Besluit:
ZIB-1054
BehandelingToegestaan, -Codelijst en Beperking: aanpassingen
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Vanuit de NHG zijn er meerdere wijzigingsvoorstellen als issue benoemd met betrekking op het concept BehandelingToegestaan, de BehandelingToegestaanCodelijst en het concept Beperkingen. Deze zijn allen aan elkaar gerelateerd en in BITS alhier als één issue samengevoegd.
Hieronder de uiteenzetting van de NHG issues:
- naamgeving BehandelingToegestaan veranderen in Behandelbesluit. Reden hiervoor is dat in beide modellen (HIS-ref en ZIBs) dit attribuut aangeeft dat de patiënt wenst dat de, in het attribuut “behandeling” gekozen behandeling, wel of niet uitgevoerd wordt.
De term ‘besluit’ maakt duidelijker dat het om een gezamenlijk met de patiënt genomen besluit gaat, dat bovendien positief of negatief kan zijn ten aanzien van een bepaalde behandeling.
- Subtiel verschil in waardelijstinhoud van BehandelingToegestaanCodelijst. Zowel een positief als een negatief besluit kan in de praktijk gepaard gaan met aanvullende voorwaarden. Dit pleit voor de constructie waarbij zowel bij Ja, als bij Nee, aanvullende voorwaarden een rol kunnen spelen. Van groot belang is dat er geen verwarring kan ontstaan bij de registratie dan wel de presentatie van het besluit aan de opvrager. Vandaar dat gekozen wordt voor een duidelijk ja en nee. Mocht er sprake zijn van een besluit onder voorwaarden, dan wordt altijd de derde optie ‘Onder voorwaarden’ gekozen.
- Verschil naamgeving: Besluit.voorwaarden (His-ref) en Beperkingen (ZIBs). Het object beperkingen wordt in de RadB zib gebruikt om aanvullende opmerkingen te maken bij een al dan niet toegestane behandeling (= besluit ten aanzien van een behandelgrens). Bv voor een behandeling “opnemen”, het besluit “JA maar alleen na overleg met de echtgenote”. De voorwaarde “alleen na overleg met echtgenote” wordt dan vastgelegd in tekst als voorwaarde. Dat lijkt synoniem met de relatie tussen het attribuut Voorwaarden en het attribuut Besluit van de klasse Behandelgrens. De voor de RadB zib gekozen term beperkingen is verwarrend omdat er op basis van de titel een handicap of een beperkende behandeling verwacht wordt en niet de aanvullende voorwaarde aan de behandelgrens. In beide modellen gaat het alleen om aanvullende informatie wanneer er sprake is van mitsen en maren oftewel voorwaarden bij een besluit.
#NHGHarmonisatie
Besluit:
ZIB-1055
Toelichting - naamswijziging naar Aanvullingen
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De uitleg en redenering van de NHG: Aanvulling voegt iets extra’s toe aan de behandelgrens die is vastgesteld. Toelichting kan als minder belangrijk worden geïnterpreteerd. Aanvulling voegt iets extra’s toe aan de behandelgrens die is vastgesteld. Toelichting kan als minder belangrijk worden geïnterpreteerd.
#NHGHarmonisatie
Besluit:
ZIB-1056
Toevoegen Reden Beëindigd
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
NHG: Bij de uitwisseling van gegevens is het relevant om de reden van afsluiten mee te zenden. De reden van afsluiten zou eventueel in het RadB –Zib attribuut Toelichting kunnen worden beschreven. Echter, dan komen er wel veel verschillende typen informatie in 1 veld Toelichting terecht. Dat levert wellicht extra risico’s op bij uitwisseling van deze bouwsteen en verwerking in informatiesystemen. Daarbij tevens de naam wijzigen in ‘Reden beëindigd’.
#NHGHarmonisatie
Besluit:
ZIB-1057
Einddatum - naamswijziging en géén vage datum
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De NHG-issues over 'Datum afsluiten - vage datum' en 'Datum afsluiten' (ook in deze volgorde) hebben direct verband met elkaar en gaan vooral over het feit dat de NHG ziet dat de beëindiging van een BehandelAanwijzing alleen een geregistreerd feit kan zijn en niet een nog uit te voeren actie in de toekomst.
Hieronder de verdere redenatie van de NHG over de vage datum:
- In het HIS Referentiemodel is het een datum die automatisch bij het afsluiten van de behandelgrens wordt bepaald. Bij de RadB zib mag het ook een vage datum zijn, omdat deze in de toekomst kan liggen. In de tweede lijn wordt er rekening mee gehouden dat er vooraf een afspraak gemaakt kan worden over de duur van de behandelbeperking, bijvoorbeeld “tot aan ontslag uit het ziekenhuis”, waardoor een vage datum noodzakelijk kan zijn, vergezeld van een opmerking bij het daarvoor bestemde attribuut.
De behandelgrens is een afspraak tussen zorgverlener en patiënt, en wordt altijd tijdens het maken van de afspraak vastgelegd, bijgewerkt of afgesloten. Wanneer er sprake is van een afsluitdatum onder voorwaarde, zoals “tot aan ontslag uit het ziekenhuis” zoals hierboven, dan wordt dit als voorwaarde genoteerd in het element “voorwaarden”.
Daarnaast is de houdbaarheidstermijn vooraf niet goed vast te stellen, ook niet in bovengenoemd voorstel. Het is eenduidig en dus veiliger om het wel of niet geldig zijn van een behandelgrens vast te stellen in een gesprek met een patiënt en daarna met een concrete datum vast te leggen op het moment van afsluiten.
Met andere woorden, een behandelgrens ontstaat of verandert alleen van waarde in een gesprek tussen patiënt en zorgverlener dat op een bepaald moment plaats vindt, en dan door betreffende zorgverlener vastgelegd wordt.
En over de term 'Einddatum zelf:
- Einddatum geeft teveel ruimte voor interpretatie, bijvoorbeeld dat er een datum in de toekomst wordt gepland. Dit wordt hier niet bedoeld. Met dit attribuut wordt de datum bedoeld waarop de arts de behandelgrens heeft afgesloten. Echter, met de term afsluiten wordt over het algemeen ook wel een soort creatie aangeduid, bv ‘een contract afsluiten’. De projectgroep komt daardoor uit op een voorkeur voor de term ‘beëindigen’, ofwel ‘Datum beëindigd’, wat duidelijker maakt dat het besluit nu genomen is.
#NHGHarmonisatie
Besluit:
ZIB-1058
Geverifieerd, GeverifieerdBij en Verificatiedatum - aanpassingen
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Dit issue omvat meerdere NHG wijzigingsissues en zijn alhier samengebracht omdat deze direct verband houden met elkaar. Hieronder zijn elk van de NHG issues verder toegelicht:
* Verificatiedatum en Laatste Bespreekdatum.
NHG: Verificatie is niet compleet expliciet gemodelleerd in het HIS referentiemodel. Dit lijkt ook niet noodzakelijk, op een expliciete laatste bespreekdatum na; in principe moeten behandelgrenzen periodiek geactualiseerd worden.
Op dit moment is binnen het HIS Referentiemodel een verificatiemoment gemodelleerd als laatste Bespreekdatum. Deze attributen lijken hetzelfde doel te hebben, namelijk aangeven wanneer de behandelbeperking voor het laatst besproken en dus verifieerd is. Laatste bespreekdatum dekt daarbij beter de lading. Verificatiedatum kan suggereren dat dit alleen om een verificatie na een initiële vaststelling gaat. Ook geeft verificatie onvoldoende aan wat geverifieerd wordt. Daarbij wordt in sommige contexten verificatie gebruikt om een eenzijdige verificatie te duiden. Dit wordt hier expliciet niet bedoeld.
Deze informatie wordt dusdanig belangrijk geacht voor de interpretatie van de behandelbeperking, dat de cardinaliteit 1 moet zijn.
* GeverifieerdBij
NHG: De term doet nu vermoeden dat het om een verificatie gaat na de initiële vaststelling. Dit is echter niet hoe dit attribuut bedoeld is. In dit attribuut wordt aangegeven met wie de afspraak van de behandelbeperking is gemaakt. Dit is van belang omdat het niet in alle gevallen de patiënt zelf zal zijn en in tussen een verandering opgetreden kan zijn in de bewindvoering. De cardinaliteit is 0..1 omdat voorzien wordt dat zorgverleners niet geneigd zullen zijn om het attribuut in te vullen wanneer de afspraak met de patiënt zelf is gemaakt. Tot slot wordt het attribuut een vrij tekstveld, zodat de zorgverlener zelf aan kan geven met wie de behandelgrens afgesproken is. De reden hiervoor is dat de huidige codelijst te beperkt is, nuance van belang wordt geacht, het kan voorkomen dat een zorgverlener zowel rol als persoon wil kunnen duiden en tot slot wordt verwacht dat een keuzelijst een extra hobbel bij implementatie kan opleveren.
* Geverifieerd
NHG: Tot een behandelgrens wordt gezamenlijk door de eindverantwoordelijk arts en de patiënt (of diens vertegenwoordiger) besloten. Dit betekent dat een behandelgrens niet wordt genoteerd, voordat dit besproken en besloten is met de patiënt of diens vertegenwoordiger. Het attribuut “geverifieerd” is overbodig.
#NHGHarmonisatie
Besluit:
ZIB-1059
Wilsverklaring; relatie met BehandelAanwijzing
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
NHG: In de RadB zib wordt een relatie gelegd tussen wilsverklaring en behandelaanwijzing. In het HIS referentiemodel niet.
Het verschil tussen een schriftelijke wilsverklaring en een behandelgrens is dat een behandelgrens een afspraak is tussen een zorgverlener en patiënt omtrent zijn of haar wensen ten aanzien van bepaalde behandelingen, en de wilsverklaring een document is van de patiënt waarin hij diezelfde en meer wensen eenzijdig kan vastleggen – in zijn of haar eigen woorden.
Een wilsverklaring wordt nu meestal als document door de patiënt naar de huisarts (of andere zorgverlener) gestuurd. In een HIS komt dit document terecht in correspondentie (zie HA-ZIB correspondentie-item). Het format van wilsverklaring is nog niet uitgehard.
In sommige gevallen beschrijft de patiënt in die wilsverklaring één of meerdere (op een behandelgrens gelijkende) aanwijzingen in zijn of haar wilsverklaring, +maar dit hoeft niet+, en gebeurt meestal niet, en dan meestal ongestructureerd.
In zulke gevallen lijkt het logisch om de wilsverklaring mee te sturen bij een overdracht van behandelgrenzen. In het geval een behandelgrens ondersteund wordt door een wilsverklaring, dan kan de zorgverlener terugvallen op de wilsverklaring voor eventuele extra informatie.
Aangezien de wilsverklaring een document is, lijkt het raadzaam om de wilsverklaring als correspondentie-item op te nemen in het dossier. Om het correspondentie-item als een wilsverklaring te herkennen moet het item als zodanig gemarkeerd kunnen worden.
Een directe link tussen behandelgrens en wilsverklaring is ongewenst omdat dit betekent dat een arts altijd iets ten aanzien van de registratie van een meestal afwezige wilsverklaring zal moeten ondernemen bij het vastleggen van een behandelgrens, wat ongewenst is. Naast het feit dat de inhoud van een wilsverklaring niet over dezelfde behandelingen hoeft te gaan als de vastgelegde behandelgrens. Ook kan de patiënt ten alle tijden een nieuwe versie van zijn wilsverklaring als document sturen, waardoor een behandelgrens vanaf dat moment niet vanzelf naar de juiste versie verwijst.
Alles bij elkaar genomen is er niet gekozen voor een directe link tussen de twee bouwstenen.
In de RadB zib is de cardinaliteit voor wilsverklaringen oneindig. Het is niet ondenkbaar dat een patiënt bij meerdere zorgverleners verschillende wilsverklaringen heeft, of zelfs meerdere wilsverklaringen bij 1 zorgverlener. Wanneer dit het geval blijkt, dan prevaleert de meest recente wilsverklaring.
Er wordt geen directe relatie gelegd tussen de ZIB behandelgrens en de wilsverklaring, enerzijds omdat de inhoud van de wilsverklaring niet bij de betreffende behandelgrens hoeft te passen, anderzijds omdat een directe relatie zou betekenen dat een zorgverlener bij het vastleggen van een behandelgrens altijd deze relatie zou moeten registreren. De werkgroep is van mening dat het raadzaam is om, bij het versturen van een behandelgrens, ook de wilsverklaring mee te sturen, wanneer deze er is. Dit kan geregeld worden in de informatiestandaard of door dit in te bouwen in het bericht.
NB. Er is een aparte analyse gemaakt voor de wilsverklaring om te onderzoeken of deze gemodelleerd kan worden als een correspondentie-item, zodat een wilsverklaring als zodanig geïdentificeerd kan worden en kan worden meegestuurd met de behandelgrens, zoals hierboven beschreven.
#NHGHarmonisatie
Besluit:
ZIB-1060
Begindatum laten vervallen
| Aangemaakt op: | 16-12-2019 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
NHG: In de RadB zib komt begindatum voor. In het HIS referentiemodel niet.
De begindatum en de datum laatstebespreekdatum bevatten initieel beiden de datum vanaf wanneer de behandelbeperking geldt. Op het moment dat een bestaande behandelbeperking opnieuw besproken wordt, kunnen de data van elkaar verschillen. Dit kan verwarrend werken, terwijl de begindatum geen extra informatie levert. De begindatum is ook ambigu. Dit heeft te maken met duidelijke afspraken over wanneer een behandelgrens afgesloten wordt en er een nieuwe wordt gestart. Bijvoorbeeld wanneer de voorwaarden worden aangepast, geldt het dan als een nieuwe behandelgrens, met een nieuwe begindatum? Of kun je dat zien als een mutatie met behoud van de begindatum? Deze onduidelijkheid is er niet bij LaatsteBespreekDatum.
Resumerend: de begindatum levert geen informatie en kan onduidelijkheid in de hand werken en dus zorgen voor onveilige situaties; aldus 'Begindatum' laten vervallen.
#NHGHarmonisatie
Besluit:
ZIB-1067
Toevoegen "Titel" aan subbouwsteen Naamgegevens
| Aangemaakt op: | 07-01-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
#NHGHarmonisatie
<<Om de patiënt in de correspondentie op de gewenste wijze aan te schrijven, is de titel van de patiënt nodig.
Er is gekeken naar de mogelijkheid van een gestandaardiseerde lijst (ISO, BRP) maar deze blijken niet geschikt om diverse redenen
* Lijst voldoet niet
* Is niet vrij beschikbaar
Echte codering lijkt ook niet nodig aangezien het gaat om hoe de patiënt graag zelf aangeschreven wil worden.
Ook bij andere personen dan de patiënt kan het relevant zijn om de titel van de persoon vast te leggen, zodat je weet hoe je die persoon aangeschreven wil worden. De titel past bij de naamsgegevens.>>
Besluit:
ZIB-1070
Verplichting Telecomtype weghalen + aanpassen codelijsten TelecomType en NummerSoort
| Aangemaakt op: | 07-01-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
#NHGHarmonisatie
Controle op structuur van de input zit er niet achter en het zijn geen verplichte velden.
Daarbij komt dat de volgende codelijsten van RadB niet praktisch lijken:
RadB: TelecomTypeCodeLijst
· Vast telefoonnummer
· Fax
· Mobiel telefoonnummer
· pieper
RadB: NummerSoortCodeLijst
· Telefoonnummer thuis,
· tijdelijk telefoonnummer,
· Zakelijk telefoonnummer
Voor nummersoortcodelijst kan bijvoorbeeld gedacht worden aan “zakelijk”, “privé” en “tijdelijk”. Telefoonnummer thuis doet meer denken aan “vast telefoonnummer” van de telecomtypecodelijst.
Besluit:
ZIB-1072
Labtest / interpretatievlaggen
| Aangemaakt op: | 09-01-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Labtest / interpretatievlaggen staat 0..* in de zib, maarrrr:
* FHIR kent er maar max 1
* IHE PaLM kent er maar max 1
* huisartsen kennen er max 1
Wat is de use case voor meer dan één interpretatievlag?
Gerelateerd aan MM-617.
Besluit:
ZIB-1085
aanpassen en actualiseren codelijsten GCS (o.a. voor baby en peuter)
| Aangemaakt op: | 29-01-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
{quote}Goedemorgen!
Wij zijn bezig om de GCS te herzien en te bouwen in Epic.
Nu met de VIPP richtlijnen kwamen we uit bij de verplichte tekst die we moeten gaan gebruiken voor de GCS van een baby en kleuter.
Over het algemeen prima en duidelijk maar deze zin :
*Huilt en is onpasselijk* vinden wij zo geen betrekking hebben op een baby.
Is deze nog aan te passen aan een leeftijdsadequate omschrijving?
{quote}
Besluit:
ZIB-1087
Naamswijziging zib Verrichting naar zib Behandeling
| Aangemaakt op: | 30-01-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Gerelateerd aan ZIB-842 (NHG): naamswijziging zib Verrichting naar zib Behandeling
Besluit:
ZIB-1088
Toevoegen tabel 49 aan zib Verrichting
| Aangemaakt op: | 30-01-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Gerelateerd aan ZIB-842: toevoegen tabel 49 aan zib Verrichting
Besluit:
ZIB-1089
Kardinaliteit reden contact losser maken naar 0..*
| Aangemaakt op: | 30-01-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In [https://nictiz.atlassian.net/browse/ZIB-822|https://nictiz.atlassian.net/browse/ZIB-822] is gevraagd om eea aan te passen in de mapping naar FHIR. Dat is geadresseerd.
Maar de vraag om de cardinaliteit voor reden contact op 0..* te zetten lijkt niet geadresseerd.
GGZ Nederland wil via de redactieraad graag deze wijziging doorgevoerd hebben. Wij kunnen niet altijd een reden voor een contact aangeven.
Besluit:
ZIB-1094
rolkode advocaat toevoegen aan ZIB Contactpersoon
| Aangemaakt op: | 04-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Graag de volgende toevoeging op de waardenlijst in zib contactpersoon.
De rol van Advocaat wordt gemist. De ggz kan wel ‘Anders’ gebruiken, maar dat is een onbenoemde rol. Advocaat is een formele rol die van belang is bij bijv. de WVGGZ, Forensische zorg, etc.
Besluit:
ZIB-1095
Verrichting geschikt maken voor behandeladvies
| Aangemaakt op: | 04-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De _zib verrichting_ is nu alleen bedoeld voor verrichting die uitgevoerd zijn of gaan worden.
In het oncologie zorgproces (en ook andere zorgdomeinen) wordt alvorens een behandelplan wordt vastgesteld eerst multidisciplinair een behandeladvies opgesteld. In het behandeladvies worden, net als in een behandelplan, verrichtingen vermeldt. Grootste verschil is echter dat deze verrichtingen worden geadviseerd en nog met de patiënt doorgenomen moeten worden. Ze hebben dus nog lang niet de status dat ze uitgevoerd gaan worden.
Daarmee passen ze dus niet in de definitie van de bestaande zib. Echter informatietechnisch passen geadviseerde verrichtingen zeer goed in het informatiemodel van de zib verrichting. Als het behandeladvies omgezet wordt naar een behandelplan, dan zou je ook de verrichtingen daaruit (waar van toepassing) willen overnemen. Dit pleit voor het gebruik van dezelfde onderliggende zib.
Is het mogelijk om de huidige zib dusdanig aan te passen dat deze ook gebruikt kan worden voor geadviseerde verrichtingen? (Bijv. door een status aan de verrichting mee te geven (is onze eerste gedachte). Dit biedt ook het voordeel dat je bijvoorbeeld kunt aangeven dat een patiënt afziet van een geadviseerde verrichting)
Besluit:
ZIB-1096
Zib opleidingsniveau
| Aangemaakt op: | 05-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Voor de verslavingszorg is er behoefte om de categorie ' speciaal onderwijs' te kunnen gebruiken bij deze zib.
het is technisch niet een opleidingsniveau, maar opleiding soort, maar wel relevant.
graag overleg hoe dit kan worden uitgewerkt.
Besluit:
ZIB-1100
Woonsituatie (2017)
| Aangemaakt op: | 07-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Is het mogelijk om voor de ggz aan de Zib Woonsituatie op de waardenlijst
- woontype: asielzoekerscentrum toe te voegen?
(Dit zal zal nu ws onder ‘ander’ vallen, maar speelt in de ggz bij cliënten met Post Traumatische Stress Stoornis):
Besluit:
ZIB-1104
Contact versus opname
| Aangemaakt op: | 11-02-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Vanuit de eerste lijn bezien is het verwarrend dat een gehele opname onder deze bouwsteen kan vallen, terwijl een opname ook gezien kan worden als een opeenvolging van (intramurale) contacten.
Er kan overwogen worden om een specifieke ZIB Opname uit te werken, die een specialisatie is van de generieke ZIB Contact, zodat het semantisch verschil duidelijker is en specifieke attributen kunnen worden opgenomen
#NHGHarmonisatie
Besluit:
ZIB-1108
BETALER
| Aangemaakt op: | 19-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Van een leverancier kreeg ik de vraag of in de zib Betaler ook ruimte is om, indien de zorgverzekeraar niet de financier is, waar deze gegevens dan moeten worden geregistreerd. Vaak wordt in o.a. de VVT, VGZ & GGZ, zorg verstrekt op basis van de WLZ of WMO. Ook komt het voor dat er meerdere financiers zijn. Nu is in deze zib alleen plaats voor 1 naam van de zorgverzekeraar.
AL EERDER ingediend onder eOverdracht EOVDR-32
Besluit:
ZIB-1110
Laten vervallen Omaha en NOC
| Aangemaakt op: | 26-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de huidige zibs (o.a. Probleem en FunctioneleOfMentaleStatus nog een verwijzing staat naar waardenlijsten van NOC en Omaha. Deze worden alleen gebruikt voor de verpleegkundige beroepsgroep en in het IB van maart 2018 is afgesproken alleen SNOMED CT te gebruiken voor de verpleegkundige beroepsgroep. SVP deze laten vervallen.
Besluit:
ZIB-1112
Contactpersoon
| Aangemaakt op: | 27-02-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
Dit document beschrijft de bouwsteen 'Contactpersoon'. Het is één van de resultaten van het project 'Zorginformatiebouwstenen voor nieuwe generatie informatiestandaarden huisartsoverdrachten'.
#nhgharmonisatie
Het vraag is om dit voorstel te behandelen.
Besluit:
ZIB-1113
datatype CO wijzigen in CD Zib mobiliteit
| Aangemaakt op: | 27-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij het uitwerken van deze zib in een patient journey voor de ggz constateer ik dat het datatype van de diverse data elementen waar een codelijst bij hoort niet correct is weergegeven. Er zijn alleen nominale waarden in de codelijsten opgenomen waaruit gekozen moet worden. Dat is datatype CD.
Echter in de UML staat CO als voor coded ordinal. Maar de ordening is niet in de vorm van een cijfer opgenomen / toegelicht.
Graag zie ik dat het datatype wordt gecorrigeerd. (Het is natuurlijk ook mogelijk alle waardenlijsten wel coded ordinals te maken door een score in cijfers toe te voegen).
Besluit:
ZIB-1114
uiterlijke verzorging taalcorrectie en Coded Data als datatype, geen CO
| Aangemaakt op: | 27-02-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Dag,
Bij uitwerken van de patient journey 2 voor de ggz werken we een aantal zibs in detail uit. Bij uiterlijke verzorging mist het woordje haar in onderstaande zin. Verzoek om 'haar' toe te voegen.
Uiterlijke verzorging omvat het verzorgen van hoofd- en gezichtshaar, zoals het met de kam in model brengen **van het haar** en het scheren en/of trimmen van de gezichtsbeharing; het verzorgen van de huid, zoals het aanbrengen van make-up; het verzorgen van de nagels.
Daarnaast is onjuist een CO datatype toegekend. Er is geen ordinale score aanwezig. Dit moet een CD zijn om de juiste waarde te kunnen kiezen. Ook zou hier wel een score aan de drie opties kunnen worden toegekend, maar in dat geval is ook weer een afspraak nodig wat welke score dan voorstelt. CD is eenvoudiger.
Besluit:
ZIB-1115
Serie zibs vermogen tot datatype CO klopt niet
| Aangemaakt op: | 27-02-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De serie zibs "Vermogen Tot" hebben naar waarschijnlijkheid allemaal een verkeerd data type voor de geassocieerde waardenlijsten. Alle vermogen tot wordt via een keuzelijst met waarden bediend. Daar moet dus b.v. volledig afhankelijk uit gekozen worden. Er is op geen enkele manier sprake van een score, hetgeen de cruciale voorwaarde is voor een Coded Ordinal.
Graag tijdig herstel van deze fout ivm op gang komende implementaties en publicatie 2020.
Besluit:
ZIB-1120
Typo medisch hulpmiddel
| Aangemaakt op: | 09-03-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In [medisch hulpmiddel|https://zibs.nl/wiki/MedischHulpmiddel-v3.3(2019NL)] staat een typo:
bq.De zorgaanbieder waar het gebruik van het hulpmiddel geïnitieerd werd of waar het hulpmiddel gïmplanteerd werd.
gïmplanteerd -> geïmplanteerd
Besluit:
ZIB-1126
Behandelaanwijzing code voor reanimatie
| Aangemaakt op: | 13-03-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de codelijst is de code voor specifieke reanimatie gebruikt, namelijk die voor "Cardiopulmonaire resuscitatie 89666000". We kregen wat verwarring, omdat als je zoekt naar "reanimatie" in de SCT browser, dan krijg je de meer algemene "reanimatie 439569004" [https://terminologie.nictiz.nl/terminology/snomed/viewConcept/439569004]
Zou het niet logischer zijn om de algemenere code te gebruiken. Immers in de wilsbeschikking staan de details, zoals met en zonder beademen e.d. of er staat NIET REANIMEREN op geen enkele manier, en dus is de algemenere code logischer.
N.B. We kregen deze vraag in het Citrien Regionale Oncologie programma en dan specifiek in de Palliatieve Zorg Dataset.
Besluit:
ZIB-1127
Codelijst JuridischeStatus is achterhaald
| Aangemaakt op: | 18-03-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De codelijst JuridischeStatus in niet meer up-to-date. Deze codelijst is gebaseerd op de BOPZ wet. Per 1 januari 2020 is de nieuwe wet verplichte GGZ (WvGGZ) ingegaan. Graag codelijst up-to-date maken zodat deze ZIB ook gebruikt kan worden voor de WvGGZ.
Besluit:
ZIB-1133
Graag toevoegen van de ggz-diagnose lijst als geldig codestelsel bij zib probleem
| Aangemaakt op: | 31-03-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
GGZ Nederland ggz-diagnose lijst graag toevoegen aan de zib probleem.
De naam is ggz-diagnose lijst
De OID hiervoor van GGZ Nederland is 2.16.840.1.113883.3.3210.14.2.2.35
Volgens communicatie GGZ Nederland VIPPGGZ programma moeten geen hoofdletters en wel een koppelteken worden gebruikt.
Besluit:
ZIB-1135
referentie naar codesysteem UNSPSC in issue verwijderen.
| Aangemaakt op: | 31-03-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Referentie naar een codesysteem UNSPSC staat nog in de zib bij issues. Deze moet worden weggehaald, volgens mij is de codelijst al eerder aangepast. Zie ook verder notes
Besluit:
ZIB-1136
zib vrijheidsbeperkende maatregelen en zib juridische situatie
| Aangemaakt op: | 01-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Best zib team,
Vanuit een van de ggz leveranciers krijgen we nog een detailvraag over de zib juridische status die alweer enige tijd geleden is afgesplitst van vrijheidsbeperkende maatregelen. Het gaat om per 1 januari 2020 relevante nieuwe statussen die toegevoegd zouden moeten zijn voor de nieuwe publicatie 2020. Maar omdat in de 2017 versie het niet aanwezig was en ook de 2019 pre-publicatie het nog niet heeft omdat die is gebaseerd op 2017 komt het volgende als urgent verzoek aan de orde:
in de codelijst juridische status zijn de waarden voor
- zorgmachtiging,
- crisismaatregel
- voortgezette crisismaatregel nodig.
Deze vallen onder de juridische situatie van de cliënt en sinds de invoering van verplichte zorg in de ggz en dwang in de zorg binnen de VVT zijn dit de meest gebruikte statussen.
De vrijheidsbeperkende maatregelen bevatten dan de maatregelen volgens de wet vggz en zorg en dwang zoals deze uit de zorgmachtiging, crisismaatregel en voortgezette crisismaatregel voortkomen.
Een aanvulling op de codelijst / aanpassing van de ZIB’s is dan nodig om actuele gegevens te ontsluiten naar het PGO en binnen de diverse zorgketens.
Besluit:
ZIB-1142
Toevoegen element Geslacht aan ZIB zorgverlener
| Aangemaakt op: | 15-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
#nhgharmonisatie
Voeg het geslacht toe aan ZIB Zorgverlener
Voor communicatie met zorgverleners (bijvoorbeeld de aanhef in een brief) en persoonlijke benadering is het zinvol om het geslacht te kennen.
Besluit:
ZIB-1146
nieuwe datums toevoegen aan zib Probleem ivm onderliggend lijden
| Aangemaakt op: | 24-04-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Uit de analyse van de door de NHG ingebrachte wijzigingsvoorstellen en nieuwe zibs (met name ZorgEpisode) is naar voren gekomen dat er behoefte is om een onderscheid te maken tussen begin-/eind- datum van de diagnose (probleem) en begin-/eind- datum van onderliggend lijden
Besluit:
ZIB-1147
Toevoegen bij Probleem extra gegevenselement (ivm precisering Probleem)
| Aangemaakt op: | 24-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Soms (o.a. vanuit 1e lijn) is het nodig om, naast de codering van het Probleem in ProbleemNaam een nadere precisering op te nemen.
Besluit:
ZIB-1148
Specifieke definitie ZIB LaboratoriumUitslag: InterpretatieVlaggen
| Aangemaakt op: | 24-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De definitie van Interpretatievlaggen is niet eenduidig. zie ook [https://nictiz.atlassian.net/browse/ZIB-1017|https://nictiz.atlassian.net/browse/ZIB-1017]
Voor de definitie van het interpretatievlaggen staat geschreven: 'Attentie codes die aangeven of de uitslag boven of onder bepaalde referentiewaarden ligt of anderzinds een .interpretatie van de uitslag geven (Resistent)'.
Vragen/antwoorden
* Wanneer gebruik je een attentievlag? Interpretatievlaggen worden in de praktijk gebruikt. Ze zijn een hulpmiddel voor de aanvragers om sneller te selecteren waar resultaten afwijken van de referentie-intervallen. Dit is alleen van toepassing op kwantitatieve testresultaten. Er zijn ook rapporten of tekstuele rapporten die afwijkende bevindingen kunnen bev
* Waarom staat er een punt voor .interpretatie? Een typo.
Vraag 1 (definitie):
De definitie van Interpretatievlaggen moet specifieker en dat ook duidelijk is dat het alleen maar gaat om alleen de afwijkende gevallen. Aangegeven moet worden waar de waarden voor gelden. Zo geldt het resultaat boven of onder bepaalde referentiewaarden voor klinische chemie. Het resultaat R,S, I geldt alleen voor microbiologie.
Besluit:
ZIB-1149
AlertTypeCodelijst uitbreiden voor contra-indicatie
| Aangemaakt op: | 28-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De "AlertTypeCodelijst" bevat nu geen duidelijkheid dat het om een contra-indicatie gaat waarop medicatiebewaking gedaan moet worden. Contra-indicaties zijn een specifieke Alert. Bij het Alert zou direct duidelijk moeten zijn dat het gaat om een contra-indicatie voor medicatiebewaking en niet zomaar een conditie waar rekening meegehouden moet worden bij het evalueren van de behandeling. Niet elke conditie is voor medicatiebewaking relevant. De code die toegevoegd moet worden moet duidelijk maken dat het om een contra-indicatie voor medicatiebewaking gaat.
Code is aangevraagd bij terminologieteam.
Besluit:
ZIB-1150
CI opnemen in AlertNaam i.p.v. Probleem
| Aangemaakt op: | 28-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
CI wordt op dit moment in de zib Alert gemodelleerd als Probleem. In de zib Alert is AlertNaam de typering van de Alert. De huidige CI uit thesaurus 40 zijn geen problemen of diagnoses maar contra-indicaties voor medicatiebewaking en bevatten ook patientkenmerken waarvoor medicatiebewaking nodig is. Als je een contra-indicaties (CI) aangeeft dan hang je niet een extra label aan een bestaand probleem maar er ontstaat een nieuw concept. <Bijvoorbeeld de CI zwangerschap bij de diagnose zwangerschapsdiabetes (voorbeeld nog aanpassen)> Bovendien is het verwarrend dat als een contra-indicatie ook op een andere manier gerelateerd is aan een probleem (bijv. een episode), om de codering van de contra-indicatie zelf ook via de zib Probleem te laten verlopen. De CI worden aangegeven met een codering uit thesaurus 40 en hoort dus thuis bij de AlertNaam en niet in het huidige Probleem. In zib Probleem kan dan de onderliggende aandoening aangegeven worden net als bij andere Alerts.
Voor het model betekent dit dat de choicebox kan verdwijnen en dat er een gesloten wiebertje voor AlertNaam en Open wiebertje voor Probleem (probleem bestaat ook los van Alert) geldt. In de AlertNaamCodelijst dient ook thesaurus 40 opgenomen te worden.
Besluit:
ZIB-1151
Andere zibs relateren aan Alert in plaats van zib Probleem
| Aangemaakt op: | 28-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De relatie van een contra-indicatie met een gezondheidsprobleem gaat over het relateren van andere zibs aan een contra-indicatie. Er is een document opgesteld met mogelijke zibs (zie Excel bestand in Teams). In dit document zijn aan de hand van de NCI-lijst een aantal zibs gepresenteerd die mogelijk aan een contra-indicatie gerelateerd kunnen worden. Hierbij is de relatie met de zib Probleem buiten beschouwing gelaten, dat zijn eigenlijk de items met in de eerste kolom een I (=indicatie). Om inzicht te geven in welke zibs in aanmerking zouden komen voor een relatie met een CI zijn twee kolommen toegevoegd die gaan over het toelichtingen veld bij de zib Alert. Mogelijke zibs die naast het onderliggende zib Probleem aan een contra-indicatie gerelateerd kunnen worden zijn: zib verrichting (komt een aantal keren voor), labuitslag (komt een aantal keren voor), lengte en gewicht.
Niet alles wordt nu uitgewisseld en daarnaast heeft/mag een zorgverlener niet altijd toegang tot de achterliggende informatie die in deze zibs is opgenomen. Je mag de CI zwangerschap uitwisselen maar mag je ook informatie over die zwangerschap delen? Daarnaast zijn er heel veel verbanden tussen zibs die niet allemaal in de zibs worden vastgelegd.
Uit de analyse komt dat het in sommige gevallen nodig is om achterliggende informatie te ontvangen om een juiste interpretatie van de CI te doen. Denk bijvoorbeeld aan nierfunctie of andere labwaarden. Het is niet nodig om dit allemaal in de zib Alert te modelleren. Hoe deze informatie dan in een uitwisseling wordt opgenomen is een vraag aan het architectuurteam: welke relaties neem je wel of niet op in een concept?
Besluit:
ZIB-1154
Wijzigen kardinaliteit naar VerpleegkundigeInterventie
| Aangemaakt op: | 30-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In zib UitkomstvanZorg staat bij verwijzing naar interventie 0..1. Dit graag veranderen in 0..* Want er kunnen meerdere interventies hangen aan 1 probleem; en uitkomst zorg evalueert alle interventies die aan 1 probleem zijn gekoppeld.
Besluit:
ZIB-1156
Verwijzing naar NOC en Omaha verwijderen uit FunctioneleofMentaleStatus
| Aangemaakt op: | 30-04-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
in de huidige zib nog een verwijzing staat naar waardenlijsten van NOC en Omaha. Deze worden alleen gebruikt voor de verpleegkundige beroepsgroep en in het IB van maart 2018 is afgesproken alleen SNOMED CT te gebruiken voor de verpleegkundige beroepsgroep.
Besluit:
ZIB-1158
uitkomst van zorg
| Aangemaakt op: | 01-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib UitkomstvanZorg is een verwijzing toegevoegd naar 2 zibs, te weten AlgemeneMeting en FunctioneleofMentaleStatus. Maar uitkomst van zorg kan worden geregistreerd in heel veel verschillende zibs, zoals zibs die zijn opgenomen onder de groep zelfzorg, klinische context, metingen en scorelijsten. Kan er ipv de huidige verwijzing ook een verwijzing naar een groep zibs worden opgenomen?
Met vriendelijke groet namens V&VN
Erna Vreeke & Renate Kieft
Besluit:
ZIB-1160
Typo in wiki zib Alert 4.0
| Aangemaakt op: | 06-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Typo in de "Example Instances" (Prpbleemnaam) in wiki zib Alert *= Probleemnaam*
Typo in "Concept" onder Revision History in wiki zib Alert (spatie te veel tussen gebracht en komma) --> (... de klinische systemen wordt gebracht , om er bij het vormen ... meestal wegens een veiligheidsrisico) *= ... gebracht, om ...*
Typo in wiki zib Alert 4.0 (uitgdrukt) *= uitgedrukt)*
Typo in wiki zib Alert 4.0 in AlertTypeCodelijst (Alert [type] in ^patiënt) *= Alert*
Drager van vancomycineresistente enterokok staat er 2x in codelijst *= 1 is voldoende*
Besluit:
ZIB-1163
Alert.begindatum aanpassen
| Aangemaakt op: | 07-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het project Huisartsenoverdrachten stelt voor om Alert toe te voegen als voorvoegsel aan de datumvelden om zo onderscheidt te maken in de verschillende datumvelden in o.a. Probleem. Dit is niet meer relevant als de CI wordt opgenomen in de AlertNaam en de zib Probleem het achterliggende probleem is (zie eerder issue). Er ontstaat wel discussie over de omschrijving van begindatum. Het betreft hier het moment dat er bewaking nodig is op de contra-indicatie. De contra-indicatie kan niet met terugwerkende kracht worden bewaakt, daarom kan de begindatum dus ook verschillen met die van het onderliggende probleem. Het is wenselijk om in de beschrijving op te nemen dat voor een contra-indicatie een exacte datum (met of zonder tijdstip) wordt gebruikt en niet een globale aanduiding zoals nu in de definitie is aangegeven.
Besluit:
ZIB-1165
Basiselementen opnemen in zib Alert
| Aangemaakt op: | 07-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
* *Informatiebron* (hoe kom je tot de informatie) = niet opnemen; leidt tot onduidelijkheid in de praktijk. Dit is namelijk procesafhankelijk en hierdoor kan de definitie anders geïnterpreteerd worden (vb. patiënt geeft aan dat hij/zij van internist gehoord heeft dat hij/zij een contra-indicatie heeft). Daarnaast als auteur bekend is, is de informatiebron voor de CI irrelevant. Dit hangt ook samen met separaat issue dat door project Huisartsenoverdrachten is ingediend.
* *Identificatienummer* = uiteraard opnemen
* *Auteur* = alleen één zorgverlener opnemen
* *DatumTijd* = niet toevoegen, de reeds opgenomen BeginDatumTijd en EindDatumTijd zijn voldoende
* *Onderwerp* = opnemen; hierbij is alleen de patiënt het onderwerp van een CI.
Besluit:
ZIB-1166
Zibnaam Alert wijzigen
| Aangemaakt op: | 07-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Uit de analyse komt naar voren dat we ons houden aan de huidige modellering van CI in de zib Alert. Een betere naam die de lading dekt van alle verschillende toepassingen is niet gevonden.
Besluit:
ZIB-1167
Accordatiestatus in ZIB AllergieIntolerantie
| Aangemaakt op: | 08-05-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Vanuit een implementatietraject komt de vraag naar voren om een veld voor de AccordatieStatus (o.i.d.) aan de ZIB AllergieIntolerantie toe te voegen.
In diverse ziekenhuizen blijkt een relatief grote groep medewerkers allergieën te kunnen registreren, die dan nog door een arts geaccordeerd moeten worden. Artsen uit de betrokken ziekenhuizen achten het wenselijk eventuele nog niet geaccordeerde allergieën wel uit te kunnen wisselen om er dan in ieder geval rekening mee te kunnen houden dat de patiënt de betreffende allergie mogelijk heeft. Daarbij is het echter wel van belang dat dan ook kan worden aangeduid dat de betreffende allergieën nog niet geaccordeerd zijn om wel duidelijk te maken dat deze nog niet door een arts bevestigd zijn en ook de waarde die wordt toegekend aan wél geaccordeerde allergieën niet te laten afnemen.
Besluit:
ZIB-1171
Zorgaanbieder: waardelijst OrganisatieTypeCodelijst
| Aangemaakt op: | 18-05-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Voor de geboortezorg mis ik de kraamzorgorganisatie in de waardelijst bij OrganisatieType. Kan deze worden toegevoegd?
En voor de palliatieve zorg ontbreekt hospice in dezelfde waardelijst
Besluit:
ZIB-1173
Wilsverklaring: Orgaandonatie verder specificeren
| Aangemaakt op: | 03-06-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Orgaandonatie is nu gerelateerd aan de zib Wilsverklaring-v3.1; WilsverklaringType - Verklaring donorschap 2.16.840.1.113883.2.4.3.11.60.40.4.14.1.
In de huidige versie lijkt dit alleen algemeen gedefinieerd. Er zijn 2 typen orgaandonatie (orgaandonatie vs lichaam ter beschikking stellen voor de wetenschap). Bij orgaandonatie is een verdere specificatie mogelijk, bijv. alles doneren behalve hoornvlies/huid/etc.. Verder zal dit jaar de regelgeving van orgaandonatie veranderen van opt-in naar opt-out (zie ook [donnorregister|[https://www.donorregister.nl/uw-keuze-maken/welke-keuzes-heeft-u]]). Graag zouden wij zien dat de zib (of evt. een nieuwe kandidaat (sub)zib) deze opt-out en ook de bijbehorende specificaties gestandaardiseerd ondersteunt. Is dat mogelijk?
Deze vraag is eerder ingediend via de mail voor de consultatie publicatie 2020 door Marijke Dermois, op verzoek nu ook in bits.
Besluit:
ZIB-1174
DefintionCode niet meer actueel en referentie naar zib AlgemeneMeting verwijderen.
| Aangemaakt op: | 08-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Deprecated term vervangen en verwijzing naar zib die in 2020 publicatie gaat verdwijnen verwijderen.
Besluit:
ZIB-1175
tabel 40 contraindicaties verwijderen uit ProbleemNaam ivm nieuwe zib
| Aangemaakt op: | 08-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Doordat er een nieuwe zib is gemaakt voor ContraIndicatie verhuist de tabel 40 en kan deze uit de waardelijst van ProbleemNaam worden verwijderd (deprecated)
Besluit:
ZIB-1179
DCM::DefinitionCodes voor zib Hartfrequentie
| Aangemaakt op: | 16-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
bij aanpassen van zib voor publicatie 2020 afgesproken indien mogelijk ook de DCM:DefinitionCodes toe te voegen en gebruikte terminologie in waardelijsten.
Besluit:
ZIB-1180
Nieuwe rollen toevoegen aan ZIB Contactpersoon
| Aangemaakt op: | 17-06-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
Graag de volgende toevoeging op de waardenlijst in zib contactpersoon.
Voor de GGZ worden de volgende rollen gemist: Docent, ketenpartner, zaakwaarnemer, patientvertrouwenspersoon, gezaghebbende ouder. Graag deze toevoegen. Bij RelatieRolCodelijst graag ex-familieleden (zoals partners, opa's, oma's etc.) toevoegen. Dit speelt voornamelijk bij echtscheidingen en in jeugd en gezinssituaties.
Besluit:
ZIB-1181
DefinitionCodes zib drugGebruik
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
uitbreiding defintioncodes voor de zib.
Besluit:
ZIB-1184
DefinitionCodes Lichaamsgewicht
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/Lichaamsgewicht-v3.1(2019NL)]
iig rootconcept
Besluit:
ZIB-1185
DefintionCodes zib nl.lichaamslengte
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/Lichaamslengte-v3.1(2019NL)]
iig het rootconcept
Besluit:
ZIB-1186
DefintionCodes zib Lichaamstemperatuur
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/Lichaamstemperatuur-v3.1.1(2019NL)]
iig rootconcept
Besluit:
ZIB-1187
DefinitionCodes zib Nl.zorg.tekstuitslag
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/TekstUitslag-v4.3(2019NL)]
iig rootconcept
Besluit:
ZIB-1188
DefintionCodes zib nl.vochtbalans
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/Vochtbalans-v1.0(2019NL)]
Besluit:
ZIB-1189
DefinitionCodes alle administratieve zibs
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
wenselijk om in ieder geval een goeie SNOMED CT term te hebben voor de rootconcepts van deze zibs.
|[Betaler-v3.1|https://zibs.nl/wiki/Betaler-v3.1(2019NL)]|[Contactpersoon-v3.3|https://zibs.nl/wiki/Contactpersoon-v3.3(2019NL)]|[Zorgaanbieder-v3.3|https://zibs.nl/wiki/Zorgaanbieder-v3.3(2019NL)]| |
|[Contact-v4.0|https://zibs.nl/wiki/Contact-v4.0(2019NL)]|[Patient-v3.1.1|https://zibs.nl/wiki/Patient-v3.1.1(2019NL)]|[Zorgverlener-v3.4|https://zibs.nl/wiki/Zorgverlener-v3.4(2019NL)]|
Besluit:
ZIB-1190
DefinitionCodes zib Nl.zorg.behandelaanwijzing
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
bij de wijzingen svp ook de gebruikte definition codes bekijken. Er zitten er een paar bij waarvan ik twijfel of deze kloppen.
Besluit:
ZIB-1192
DefinitionCodes zib Nl.zorg.taalvaardigheid
| Aangemaakt op: | 17-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/Taalvaardigheid-v3.1(2019NL)]
Besluit:
ZIB-1195
Medicatieverstrekking AanschrijfDatum verkeerde Id
| Aangemaakt op: | 25-06-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib Medicatieverstrekking heeft het concept AanschrijfDatum de Id NL-CM:9.9.2250. De Medicatie-zibs concept id's zijn afgeleid van de MP-dataset. Het zou fijn zijn om dit consistent te houden. De id zou dus NL-CM:9.9.22500 moeten zijn [volgens de dataset|http://decor.nictiz.nl/pub/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.102-2016-03-23T163243.html#_2.16.840.1.113883.2.4.3.11.60.20.77.2.3.22500_20160407102348].
Besluit:
ZIB-1196
Nadere specificatie zib betaler einddatum verzekering vaak niet aanwezig
| Aangemaakt op: | 29-06-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Momenteel zijn wij bezig met de implementatie van VIPP GGZ, en dan specifiek met de implementatie van zib Betaler ([https://zibs.nl/wiki/Betaler-v3.1(2017NL])).
In deze zib is EindDatumTijd een verplicht veld (cardinaliteit = 1):
In ons EPD hebben nu geldige verzekeringen (verkregen via COV check of bij handmatige registratie) doorgaans geen einddatum. In de praktijk is een verzekering voor onbepaalde tijd geldig, tenzij deze bewust gestopt wordt.Volgens onze stakeholders is een verzekering zonder einddatum vrij gangbaar.
In ons EPD vullen wij doorgaans de oneindige datum 31-12-9999 in (in de database wel te verstaan) indien een datum (tbv een interface) verplicht is maar niet vastgesteld of vastgelegd.
De FHIR server geeft echter met een waarschuwing aan dat een einddatum van 9999-12-31 niet geoorloofd is.
Is dit een bekend probleem bij andere softwareleveranciers?
Wij hebben wel wat mogelijke oplossingsrichtingen onderzocht, maar deze zijn géén van allen optimaal:
het weglaten van de startdatum Als men geen periode invult, dan zijn de start- en einddatum niet verplicht. Maar dit is natuurlijk geen oplossing en is bovendien foutgevoelig.
het kiezen van eind van het jaar als einddatum. Dit leidt tot verkeerde conclusies wanneer het jaar afgelopen is.
het kiezen van een andere datum in de toekomst. Dit is technisch gezien ook niet correct, maar misschien iets duidelijker dat het een fictieve datum is.
Kortom, hier komen wij niet uit.
Graag vernemen wij graag een reactie hoe hier mee om te gaan.
Alvast hartelijk dank!
Met vriendelijke groet,
Bernard van Driel
Besluit:
ZIB-1199
Vervangen verouderde Snomed code
| Aangemaakt op: | 06-07-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Code SNOMED 228274009 : Lifetime non-drinker (finding) is deprecated en moet vervangen worden door 783261004 : Lifetime non-drinker of alcohol.
De code is onderdeel van de waardelijst AlcoholGebruikStatusCodelijst
Besluit:
ZIB-1201
Terminologie koppeling Zwangerschap
| Aangemaakt op: | 20-07-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib Zwangerschap heeft op de root de volgende code gebonden: [364320009|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=364320009] Pregnancy observable.
Voor het concept 'Zwanger' dat een indicator is of iemand zwanger is dat de code: [77386006|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=77386006] Zwangerschap.
Wij vragen ons af of deze codes niet omgedraaid hadden moeten zijn.
De vraag onstaat bij ons vanuit het feit dat we de zib Zwangerschap op een FHIR Condition resource hebben gemapt met bij behorende losse Observations waar bijvoorbeeld het concept 'Zwanger' wordt vastgelegd. De terminologie koppeling wordt gebruikt om de Condition en Observation te onderscheiden. Hierbij lijkt de tweede code, 77386006, passender bij de Condition.
Besluit:
ZIB-1202
Beschrijving ProbleemBeginDatum aanpassen ('aandoening' weghalen)
| Aangemaakt op: | 23-07-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Definitie (tekst) van ProbleemBeginDatum aanpassen ('aandoening' weghalen):
_Begin van de klacht, beperking, +aandoening,+ complicatie of het symptoom of de datum van de diagnose waarop het probleem betrekking heeft._
Onderstreepte deel weghalen
Besluit:
ZIB-1206
TabakGebruikStatusCodelijst 'rookt soms' SNOMED code wijzigen
| Aangemaakt op: | 17-07-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Tijdens het testen van de keten blijkt dat onze PGO de waarden uit de SNOMED letterlijk overneemt. Nu zit in de TabakGebruikStatusCodelijst een SNOMED code voor de waarde 'rookt soms'. Deze code is: [230059006|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=230059006].
Nu is die code in de SNOMED gekoppeld aan de waarde 'rookt soms sigaretten'. Dit geeft bijzondere combinaties in het PGO. Waarbij iemand die soms sigaren rookt nu de waardes 'rookt sigaren' en 'rookt soms sigaretten' krijgt te zien.
Nu zou ik voorstellen om de huidige SNOMED code te vervangen met deze: 428041000124106.
Deze SNOMED code staat voor de waarde 'rookt soms tabak'. Deze waarde is een stuk neutraler en leidt minder snel tot vreemde combinaties. Daarnaast zit in de definitielijst van deze laatste code ook de waarde 'rookt soms'.
Dit is gebaseerd op de info zoals hier te verkrijgen:
[https://browser.ihtsdotools.org/?perspective=full&conceptId1=404684003&edition=MAIN/SNOMEDCT-NL/2019-09-30&release=&languages=nl,en]
Besluit:
ZIB-1209
Tekstueel en in voorbeelden aanpassen zib Alert vanwege de nieuwe zib CI
| Aangemaakt op: | 30-07-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Tekstueel en in voorbeelden aanpassen zib Alert vanwege de nieuwe zib CI
Besluit:
ZIB-1213
"AbilityToGroome" moet zijn "AbilityToGroom"
| Aangemaakt op: | 19-08-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib "VermogenTotUiterlijkeVerzorging" is naar het Engels vertaald als "AbilityToGroome". Dit moet zijn: "AbilityToGroom", zonder "e" op het eind.
Besluit:
ZIB-1217
Consistent maken van de zib
| Aangemaakt op: | 27-08-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij het toekennen van SNOMED codes aan de elementen kwam naar voren dat de namen van de elementen onderlng niet consistent zijn. Deel geven de namen aan dat het uitsluitend over perifere saturatie gaat, deel juist niet. Hierdoor is het toekennen van codes niet mogelijk zonder de naamgeving consistent te maken. Er moet een keuze gemaakt worden of de zib alleen perifere saturatie modelleert of algemeen saturatie en daar moet de naamgeving op aangepast worden. Vervolgens kunnen dan SNOMED codes toegekend worden
Besluit:
ZIB-1220
foutje in codingsystem OID in waardelijst Pn_PerineuraleInvasieCodelijst (TNM zib)
| Aangemaakt op: | 08-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het eerste item in deze codelijst mist het cijfer '3' in de oid van het codingsystem.
Besluit:
ZIB-1221
Rare regel bij zib Verrichting (op wiki)
| Aangemaakt op: | 08-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij de zib verrichting staat (alleen op de wiki, niet in de pdf) een ‘rare regel’ bij VerrichtingType’: Ingrepen en behandelingen
Besluit:
ZIB-1224
Fout in ycN_RegionaleLymfeklierenCodelijst omschrijvingen
| Aangemaakt op: | 09-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
in *ycN_RegionaleLymfeklierenCodelijst* vanaf code ycN2c(sn) niet meer kloppen. De omschrijving moet hetzelfde zijn als de code, maar hij begint daar opeens opnieuw bij het begin i.p.v. dat die doorloopt.
Besluit:
ZIB-1225
Spatie in laatste item TNMVersieCodelijst verwijderen
| Aangemaakt op: | 09-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In *TNMVersieCodelijst* moet de laatste waarde de conceptcode UICCTNM8 hebben (i.p.v. UICC TNM8).
Besluit:
ZIB-1226
verwijderen engelstalige tekst uit G_DifferentiatiegraadTumorCodelijst
| Aangemaakt op: | 09-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In *G_DifferentiatiegraadTumorCodelijst* staat bij de omschrijving van GX t/m G4 naast de Nederlandstalige tekst ook de engelstalige tekst.
Besluit:
ZIB-1227
aanpassen example instance
| Aangemaakt op: | 09-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij de *Example Instances* ontbreekt bij afwijkingnummer 2, de corresponderende TumorLokalisatie - AnatomischeLocatie daarvan:
Besluit:
ZIB-1229
Fouten/aanpassingen vanuit importscript XMI zibs
| Aangemaakt op: | 10-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Ook gewoon eens een keer het importscript van de XMI’s laten draaien. Ik heb alle directe in het oog springende problemen op mijn omgeving opgelost of eromheen gewerkt (bij iedere error klapt de import eruit) dus ik zit nu op het niveau dat ik volgende week met Jorn/Arianne zinvol naar de data kan gaan kijken. Hopelijk kun jij bewerkstelligen dat onderstaande dingen in de bron worden gefikst:
Omschrijving: error:InternalCodeSystemError CodeSystem "2.16.840.1.113883.6.254" has multiple names across valueSets: ICF, ICD-O-3 [at line 2230, column 25, source: String]
— Deze OID is officieel WHO ICF: [http://oid-info.com/cgi-bin/display?oid=2.16.840.1.113883.6.254&action=display]
— ICD-O-3 is officieel [http://oid-info.com/cgi-bin/display?oid=2.16.840.1.113883.6.43.1&a=display]
Het gaat nu mis in:
<!--nl.zorg.part.AnatomischeLocatie-v1.0_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.20.7.3" name="LocatieICD-O-3Codelijst" displayName="LocatieICD-O-3Codelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<sourceCodeSystem id="2.16.840.1.113883.6.254" identifierName="ICD-O-3”/>
<completeCodeSystem codeSystem="2.16.840.1.113883.6.254" codeSystemName="ICD-O-3”/>
</valueSet>
Deze heb ik in mijn import nu met de hand gerepareerd, maar moet in de bron worden gerepareerd.
——————
{color:#000096}Omschrijving: error:InternalCodeSystemError CodeSystem "2.16.840.1.113883.6.16" has multiple names across valueSets: NOC[DEPRECATED], NOC [DEPRECATED] [at line 2230, column 25, source: String]
{color}
Omschrijving: error:InternalCodeSystemError CodeSystem "2.16.840.1.113883.6.98" has multiple names across valueSets: OMAHA [DEPRECATED], Omaha Systems [DEPRECATED] [at line 2230, column 25, source: String]
{color:#000096}Deze heb ik in mijn import nu met de hand gerepareerd als “NOC [DEPRECATED]” en “OMAHA [DEPRECATED]”. Omaha Systems is de Stichting/het bedrijf achter het “systeem” OMAHA voor zover ik weet{color}
{color:#000096} {color}
{color:#000096}——————{color}
{color:#000096} {color}
Omschrijving: error:InternalCodeSystemError CodeSystem "2.16.840.1.113883.2.4.4.1.902.40" has multiple names across valueSets: G-standaard Contra Indicaties (Thesaurus 40), G-Standaard Contra Indicaties (Tabel 40) [DEPRECATED] [at line 2230, column 25, source: String]
{color:#000096} {color}
{color:#000096}Deze heb ik in mijn import nu met de hand gerepareerd als “{color}G-standaard Contra Indicaties (Thesaurus 40){color:#000096}” en “{color}G-standaard Contra Indicaties (Thesaurus 40) [DEPRECATED]{color:#000096}” en de controle aangepast zodat hij niet meer valt over het ‘achtervoegsel’ [DEPRECATED]{color}
——————
Omschrijving: error:InternalCodeSystemError CodeSystem "2.16.840.1.113883.5.1008" has multiple names across valueSets: nullflavor, NullFlavour, NullFlavors, NullFlavor [at line 2230, column 25, source: String]
{color:#000096}Deze heb ik in mijn import nu met de hand gerepareerd als “NullFlavor”.{color}
{color:#000096} {color}
{color:#000096}—————{color}
{color:#000096} {color}
Omschrijving: error:UnsupportedValue ZIB "nl.zorg.ChecklistPijngedrag-v1.1" DCM::DefinitionCode "ScoreObservaties: 12017006 ChecklistPijnGedrag VerdrietigeBlik#NOTES#OID: 2.16.840.1.113883.2.4.3.11.60.40.4.0.1". Could not determine codeSystem OID from "ScoreObservaties" [at line 1432, column 44, source: String]
{color:#000096}Dit is nieuwe syntax voor de DCM::DefinitionCode. Ik heb de code hiervoor aangepast{color}
{color:#000096} {color}
—————
Omschrijving: error:UnsupportedValue ZIB "nl.zorg.Patientbespreking-v1.0" DCM::ValueSet "PatientbesprekingTypeCodelijst#NOTES#OID: 2.16.840.1.113883.2.4.3.11.60.40.2.15.1.2" holds a different value set id "2.16.840.1.113883.2.4.3.11.60.40.2.15.1.2" than DCM::ValueSetId . [at line 1473, column
<UML:TaggedValue tag="DCM::ValueSet" [xmi.id|http://xmi.id/]="EAID_1FB21CF3_BCDD_4794_948B_66A16E45606F" value="*PatientbesprekingTypeCodelijst*#NOTES#OID: 2.16.840.1.113883.2.4.3.11.60.40.2.*15.1.2*" modelElement="EAID_855D1179_99D2_4e56_9D1C_EEE02CDCDF1C"/>
<UML:TaggedValue tag="DCM::ValueSetId" [xmi.id|http://xmi.id/]="EAID_D4B3827F_4F16_4304_95AE_272BF764BDC9" value="2.16.840.1.113883.2.4.3.11.60.40.2.*15.2.1*" modelElement="EAID_A5478CA5_4147_4d9e_B1D3_F79A8C854BE9"/>
De waardelijst PatientbesprekingTypeCodelijst bestaat niet in het waardelijstbestand en staat ook niet op de wiki. Dat kan ik niet oplossen. Het oogt voor mij als cruft die is blijven hangen nadat een element in EA is verwijderd in de zib aangezien ook geen element PatientbesprekingType bestaat.
—————
Verder nog: in nl.zorg.Medicatieverstrekking, element VerstrekteHoeveelheid heeft een ongeldige omschrijving:
<UML:TaggedValue tag="documentation" value="<languages xml:space="preserve">
<font color="#323333"><nl-NL>Aantal eenheden van het product (gemeten op basis van de </font>relevante productcode) dat is afgeleverd. <font color="#323333">Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25)</font>
</nl-NL>
<en-US>Number of units of the product (measured based on the relevant product code) supplied. Optionally a translation to NHG table Gebruiksvoorschriften(Table 25) is also allowed.
</en-US>
</languages>"/>
{color:#000096}Als je deze brij voldoende “masseert”, dan komt daar ongeldige xml uit:{color}
... <font color="#323333"><nl-NL>Aantal eenheden van het product (gemeten op basis van de </font>
En dat moet zijn:
... <nl-NL><font color="#323333">Aantal eenheden van het product (gemeten op basis van de </font>
Dan kun je je nog afvragen waarom de Nederlandse versie lettertypekleur nodig heeft en de Engelse niet, maar "daar vallen we niet over”
———————
Zoiets zit ook in nl.zorg.part.FarmaceutischProduct bij element ProductHoeveelheid
<UML:TaggedValue tag="documentation" value="<languages xml:space="preserve">
<font color="#323333"><nl-NL>Hoeveelheid van het product. Dit is de denominator in de </font>berekening van de sterkte. <font color="#323333">Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25).</font>
</nl-NL>
<en-US>Amount of the product. This is the denominator for the calculation of the concentration.Optionally a translation to NHG table Gebruiksvoorschriften(Table 25) is also allowed.
</en-US>
</languages>"/>
Ook hier zijn <font.. en <nl-NL> omgedraaid: <font color="#323333"><nl-NL>Hoeveelheid van het product. Dit is de denominator in de </font>
—————
Zoiets zit ook in nl.zorg.Verstrekkingsverzoek element TeVerstrekkenHoeveelheid
<UML:TaggedValue tag="documentation" value="<languages xml:space="preserve">
<font color="#323333"><nl-NL>Dit is het aantal eenheden van het bestelde product per verstrekking. Het aantal herhalingen geeft aan hoe veel keer deze </font>hoeveelheid verstrekt mag worden. <font color="#323333">Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25).</font>
</nl-NL>
<en-US>This is the number of units of the ordered product per dispense.
The number of refills indicates how often this amount is allowed to be dispensed.Optionally a translation to NHG table Gebruiksvoorschriften(Table 25) is also allowed.
</en-US>
</languages>"/>
Ook hier zijn <font… en <nl-NL> omgedraaid: <font color="#323333"><nl-NL>Dit is het aantal eenheden van het bestelde product per verstrekking. Het aantal herhalingen geeft aan hoe veel keer deze </font>
Verder lijkt mij dat “hoe veel” 1 woord is?
Besluit:
ZIB-1230
Medicatie contra-indicatie naam verkeerd gespeld (Engels)
| Aangemaakt op: | 14-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib MedicationContraindication is de Engelse term voor medicatie naam verkeerd gespeld. MedicatieContraIndicationName -> MedicationContraIndicationName
[https://zibs.nl/wiki/MedicationContraIndication-v1.0(2020EN)]
Besluit:
ZIB-1231
attribuut bij intentionele waardlijsten gewenst in xmi
| Aangemaakt op: | 15-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Deze is ook vrij consistent: bij alle intentionele waardelijst mist een attribuut dat zegt op welke wijze het concept wordt geïmporteerd. De designation onder de include is ook dan niet helemaal fris. Voorbeeld:
<!--nl.zorg.VerpleegkundigeInterventie-v3.2_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.14.2.4" name="InterventieSnomedCodelijst" displayName="InterventieSnomedCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<sourceCodeSystem id="2.16.840.1.113883.6.96" identifierName="SNOMED CT"/>
<conceptList>
<include code="71388002" codeSystem="2.16.840.1.113883.6.96" displayName="Procedure">
<designation language="nl-NL" type="preferred" displayName="SNOMED CT - SNOMED CT: <<71388002 | procedure |"/>
</include>
</conceptList>
</valueSet>
Dit zou moeten zijn (<< is *is-a*):
...
<include code={color:#993300}"71388002"{color} codeSystem={color:#993300}"2.16.840.1.113883.6.96"{color} displayName={color:#993300}"Procedure"{color} *op={color:#993300}“is-a"{color}*>
<designation language={color:#993300}"nl-NL"{color} type={color:#993300}"preferred"{color} displayName={color:#993300}"{color}*procedure*{color:#993300}"{color}/>
</include>
...
Dit betreft 11 waardelijsten:
<!--nl.zorg.Wond-v3.3_valuesets.xml--> {color:#000096}—> Let op: hier is het << oftewel is-a, dus *op=“is-a"*{color}
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.19.2.7" name="WondDrainTypeCodelijst" displayName="WondDrainTypeCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final”>
Alle hier onder zijn < dus descendent-of dus *op**="descendent-of"*
<!--nl.zorg.VerpleegkundigeInterventie-v3.2_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.14.2.4" name="InterventieSnomedCodelijst" displayName="InterventieSnomedCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final”>
<!--nl.zorg.LaboratoriumUitslag-v4.6_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.13.1.2" name="AfnameprocedureCodelijst" displayName="AfnameprocedureCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.13.1.9" name="ContainerTypeCodelijst" displayName="ContainerTypeCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.13.1.6" name="MonstermateriaalCodelijst" displayName="MonstermateriaalCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.13.1.13" name="MorfologieCodelijst" displayName="MorfologieCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.13.1.4" name="TestmethodeCodelijst" displayName="TestmethodeCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<!--nl.zorg.part.AnatomischeLocatie-v1.0_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.20.7.1" name="LocatieCodelijst" displayName="LocatieCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<!--nl.zorg.AllergieIntolerantie-v3.3_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.8.2.12" name="WijzeVanBlootstellingCodelijst" displayName="WijzeVanBlootstellingCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<!--nl.zorg.Verrichting-v5.2_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.14.1.4" name="VerrichtingMethodeCodelijst" displayName="VerrichtingMethodeCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">
<!--nl.zorg.MedischHulpmiddel-v3.3.1_valuesets.xml-->
<valueSet id="2.16.840.1.113883.2.4.3.11.60.40.2.10.1.1" name="ProductTypeCodelijst" displayName="ProductTypeCodelijst" effectiveDate="2020-09-10T00:00:00" statusCode="final">at
Besluit:
ZIB-1234
Typos in nl.zorg.part. bereik en verstrekkingsverzoek
| Aangemaakt op: | 16-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Zie [https://zibs.nl/wiki/Bereik-v1.0.1(2020NL)#12229]
De nominale waarde van de hoeveelheid. Dit element kan {color:#ff0000}+*net*+{color} in combinatie met een minimale en maximale waarde gebruikt worden.
=>
De nominale waarde van de hoeveelheid. Dit element kan {color:#00875a}*+niet+*{color} in combinatie met een minimale en maximale waarde gebruikt worden.
Nog een typo bij [https://zibs.nl/wiki/Verstrekkingsverzoek-v1.0.3(2020NL)#13414:]
Dit is het aantal eenheden van het bestelde product per verstrekking. Het aantal herhalingen geeft aan {color:#ff0000}+*hoe veel*+{color} keer deze hoeveelheid verstrekt mag worden. {color:#323333}Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25).{color}
Dit is het aantal eenheden van het bestelde product per verstrekking. Het aantal herhalingen geeft aan {color:#00875a}+*hoeveel*+{color} keer deze hoeveelheid verstrekt mag worden. Optioneel is voor de eenheid in plaats van gebruik van UCUM eenheden ook een vertaling toegestaan naar NHG tabel Gebruiksvoorschriften (tabel 25).
En bij metadata [https://zibs.nl/wiki/Verstrekkingsverzoek-v1.0.3(2020NL)#Metadata:]
{color:#de350b}+*Proejctgroep*+{color} Medicatieproces
{color:#00875a}*+Projectgroep+* {color}Medicatieproces
Besluit:
ZIB-1235
Typos in zip Refractie
| Aangemaakt op: | 16-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Er zitten diverse typos in de zib Refractie:
# DCM::CreationDate "15/05/2020" is niet goed geformatteerd. Dit zou een Nederlandse datum "15-05-2020" moeten zijn of als het echt een Amerikaanse datum is met de maand eerst: "05/15/2020"
# NL-CM:12.20.24 alias SfericRefractiion moet zijn SfericRefraction
# NL-CM:12.20.24 zelfde spelfout in de Engelse definitie van dit concept
# NL-CM:12.20.9 SfericRefractionValue "to correct myopia (myopia)" moet denk ik zijn "to correct nearsightedness (myopia)"
# NL-CM:12.20.5 Prisma Engelse definitie "Container of the Prisma concept.This container contains all data elements of the Prisma containerl." heeft een spatie te weinig na de eerste punt en een 'l' teveel aan het einde.
# NL-CM:12.20.5 Prisma lijkt een probleem in "Waardebereik: 0,00 and 40,00" te bevatten. Bij alle andere waardebereiken staat "Waardebereik: X-Y" als de bedoeling is om van X t/m Y te zeggen. Hier lijkt het net of het bereik bestaat uit alleen die 2 waarden.
Besluit:
ZIB-1237
'BehandelAanwijzing - Definitie Behandelbesluit aanpassen
| Aangemaakt op: | 17-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij de definitie van Behandelbesluit staat nog een oud stukje tekst: "Bij een besluit 'onder voorwaarden uitvoeren' moet het concept Behandelvoorwaarden de voorwaarden in bevatten."
Dit zou moeten zijn:
"Bij een besluit 'Anders' moet het data-item 'SpecificatieAnders' de aanwijzingen bevatten voor het al of niet uitvoeren van de behandeling."
Besluit:
ZIB-1238
Het codesysteem NullFlavor heeft in een aantal zibs een inconsistente naam
| Aangemaakt op: | 19-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het codesysteem NullFlavor heeft in een aantal zibs een inconsistente naam, zoals NullFlavors en NullFlavour. DIt moet geharmoniseerd worden.
De betreffende zibs en waardenlijsten zijn:
Zorgverlener: ZorgverlenersRolCodelijst NullFlavour -> NullFlavor
MedicatieAfspraak: RedenMedicatieafspraakCodelijst NullFlavour -> NullFlavor
MedicatieGebruik: RedenWijzigenOfStoppenGebruikCodelijst NullFlavour -> NullFlavor
Naamgegegvens: NaamgebruikCodelijst NullFlavors -> NullFlavor
Patient: GeslachtCodelijst NullFlavors -> NullFlavor
Besluit:
ZIB-1239
Geslacht uitbreiden o.a. met X
| Aangemaakt op: | 21-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
(Mail Wietske Huizenga, Radboudumc)
Beste Pim,
Lang niet gesproken, dat krijg je als er weinig events zijn. Ik benader je even vanwege het volgende:
Wij kregen in het Radboudumc de vraag of we Epic zo kunnen inrichten dat patiënten zelf kunnen bepalen hoe ze worden aangesproken in correspondentie. Op dit moment leiden we dit af van het administratieve geslacht. We hebben toen gekeken naar de [zib Patiënt (2020)|https://zibs.nl/wiki/Patient-v3.2(2020NL)] en hoe hierin het geslacht wordt benoemd. Wat ons toen opviel is dat hier gesproken wordt over een administratief geslacht, maar dat de keuzelijst niet overeenkomt met de opties die er zijn voor op ID-kaart en paspoort, namelijk man, vrouw, X.
Zou jij kunnen uitleggen wat de overwegingen zijn geweest om het administratieve geslacht niet gelijk te trekken met wat er wettelijk gezien als geslacht geregistreerd mag worden? Hierdoor komen wij een beetje in de knoop met onze verplichting om het geslacht van het identificatiemiddel over te nemen icm het voldoen aan de ZIB.
En of er plannen zijn om naast het administratieve geslacht ook een aanduiding toe te voegen over hoe je wilt worden aangesproken en mogelijk ook hoe iemand zich voelt?
Hopelijk kan je ons verder helpen.
Groeten,
Wietske
Besluit:
ZIB-1240
waardelijsten in FunctioneleOfMentaleStatus
| Aangemaakt op: | 24-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Twee lijsten uit FunctioneleOfMentaleStatus.
- StatusnaamSnomedCodelijst moet m.i. gekoppeld worden aan één van de verpleegkunderefsets, maar ik weet niet zeker welke: ik dénk 11721000146100 |simpele referentieset voor patiëntproblemen (metadata)|
- StatusWaardeSnomedCodelijst moet m.i. zijn
< 260245000 |waarde van bevinding (kwalificatiewaarde)|
Besluit:
ZIB-1243
oid codesysteem T en N kloppen niet in ARTDECOR zibs repository
| Aangemaakt op: | 24-09-2020 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
omschrijving (koppeling?) codesystemen voor T en N kloppen niet in upload 2020
Besluit:
ZIB-1244
verwijderen overbodige containers uit informatiemodel
| Aangemaakt op: | 28-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Op de site https://zibs.nl/wiki/TNMTumorClassificatie-v1.0(2020NL)#14178 en op de pdf onderaan de site, staan bij de anatomische locaties nog observable entities. Hier staat het wel goed: https://zibs.nl/wiki/AnatomischeLocatie-v1.0(2020NL) Dus eigenlijk het verzoek op de site en pdf aan te passen :)
Besluit:
ZIB-1246
Naamgeving concepten die naar de zib AnatomischeLocatie verwijzen is niet correct
| Aangemaakt op: | 30-09-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De drie subdiagrammen van de TNM bouwsteen bevatten een verwijzing naar de zib AnatomischeLocatie. De namen van de concepten zijn resp Tumor::AnatomischeLocatie, Lymfeklieren::AnatomischeLocatie , Metastasen::AnatomischeLocatie. Deze namen zijn niet correct. Het deel voor de '::' moet een 'is a' relatie met de bouwsteennaam hebben. In dit geval moet het een locatie aanduiden. TumorLocatie::AnatomischeLocatie zou b.v. een correcte naam zijn. Bij de laatste twee namen is daarnaast de naam voor de '::' meervoud, terwijl de locatie op een enkelvoudig concept slaat, nl Lymfeklier, resp. Metastase. Het gebruik van de NaamInZib::BouwsteenNaam is niet verplicht. Alleen de bouwsteennaam is ook goed, tenzij er een speciale rol aan het element wordt toegekend.
De Engelse aliassen zijn bovendien niet in lijn met de Nederlandse naam. Hier wordt wel alleen de Engelse bouwsteennaam gebruikt.
Tenslotte horen de teksten in het diagram element bij verwijzingen grijs te zijn.
Besluit:
ZIB-1248
DAS NL-CM:12.18.18 Locatie lijkt verkeerde omschrijvingen te hebben
| Aangemaakt op: | 07-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/DAS-v1.0(2020NL)#Information_Model]
NL-CM:12.18.18 Locatie heeft de omschrijvingen van AnatomischeLocatie (zijn patentconcept)
Verwacht iets als:
"Localisatie op/in het lichaam." en "Localisation on/in the body."
Besluit:
ZIB-1252
CLONE - VerpleegkundigeInterventie-v3.2, aanpassing verwijzing codelijst
| Aangemaakt op: | 16-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib VerpleegkundigeInterventie-v3.2(2019NL) staat een verwijzing naar de codelijst van NIC.
Verzoek is om deze verwijzing te verwijderen, omdat in het IB van maart 2018 is afgesproken dat SNOMED CT de taal is voor verpleegkundige beroepsgroep.
Daarnaast staat er in de instructie een verwijzing naar de kernset patiëntproblemen, graag dit wijzigen in een verwijzing naar de SNOMED CT subset kernset interventies, beschikbaar via Nictiz.
Besluit:
ZIB-1253
Voorbeelden in zib MedicatieContraIndicatie aanpassen
| Aangemaakt op: | 16-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Aanpassen use case Zwangerschap:
* Einddatum zwangerschap moet na de begindatum van de zwangerschap zijn
* BeginDatum blijft 08-06-2020
* EindDatum wordt 08-04-2021{color:#de350b} >> 08-03-2021 10 maanden zwangerschap is pijnlijk{color}
Aanpassen use case Sportbeoefening:
* EindDatum leeg laten
* Begindatum actualiseren: 01-08-2015
* Toelichting: Handboogschieten
* Reden van afsluiten verwijderen
Aanpassen use case Morbide Obesitas:
* Reden van afsluiting moet zijn: Heeft gewicht verloren
* Toelichting in dit voorbeeld verwijderen
* Naam van de melder (D. Bakker) wijzigen in T. de Groot (allemaal verschillende namen opnemen)
Kolom toevoegen:
* Instelling/zorgaanbieder wel opnemen (meer gegevens over mogelijke namen van de zorgaanbieder volgt nog) {color:#de350b}>> toevoegen informatie zorginstelling{color}
Besluit:
ZIB-1254
Paragraaf "Concept" aanpassen
| Aangemaakt op: | 16-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Aanpassingen:
* In het paragraaf “Concept”, aanpassen: Het woord “zorgverlener” verwijderen in de eerste zin, kan namelijk ook een patiënt zijn.
* In dezelfde eerste zin "mogen toepassen" wijzigen in “mogen worden toegepast”.
Besluit:
ZIB-1256
Gender heeft een foutieve definition
| Aangemaakt op: | 22-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Op de Engelse versie van de zib zorgverlener staat de volgende Definition bij *gender*:
"Patient’s administrative gender"
Volgens mij moet dit "Health professional’s administrative gender" zijn, omdat het gaat om de zorgverlener en niet over de patient.
Link: [https://zibs.nl/wiki/HealthProfessional-v3.5(2020EN)]
Besluit:
ZIB-1261
Medicatieafspraak waardelijst MedicatieafspraakStopTypeCodelijst bevat vervallen SNOMED CT codes
| Aangemaakt op: | 27-10-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Onder issue 888 zijn in prepublicatie 2019 een aantal 'eigen' medicatie codestelsels vervangen door SNOMED. De SNOMED codes die daarbij voor de codes uit de waardenlijst MedicatieafspraakStopTypeCodelijst zijn gekozen zijn vervallen ( en nooit actief geweest)
Besluit:
ZIB-1268
Engelse omschrijving Melder::Zorgverlener niet correct
| Aangemaakt op: | 09-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De Engelse omschrijving van Melder::Zorgverlener (Reporter::HealthProfessional) is "The healthcare *provider* who takes resposibility for the registering the contraindication."
Dit moet zijn:
"The healthcare *professional* who takes resposibility for the registering the contraindication."
Besluit:
ZIB-1269
LaboratoriumUitslag: verwijderen Aanvrager (niet implementeerbaar)
| Aangemaakt op: | 11-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De NL-CM:13.1.34 LaboratoriumUitslag.Aanvrager is niet implementeerbaar zoals deze nu is. De aanvrager is deel van het Aanvraag object waarvan meer informatie vereist is om deze te kunnen samenstellen. Status, aanvraagcode om maar wat te noemen.
Op dit moment kun je daardoor Aanvrager in zowel in FHIR als Cda niet goed implementeren.
Voorstel: Aanvrager verwijderen of zorgen dat de Aanvraag volwaardig door de zibs wordt ondersteund.
Besluit:
ZIB-1272
Toevoegen van veld Datum/tijd bij zib woonsituatie
| Aangemaakt op: | 17-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Recent kwam in issue [https://nictiz.atlassian.net/browse/MM-1354|https://nictiz.atlassian.net/browse/MM-1354] naar voren dat het veld Datum/Tijd in het kwalificatiemateriaal (van bgz, bgggz en bglz) moest worden toegevoegd bij Woonsituatie
Dit was in eerste instantie vanwege een technische reden met LastN functionaliteit. (en dat dit kon, was omdat het veld ook in de zib basiselementen zit)
Maar zoals terecht werd opgemerkt vanuit HL7team, moet dit ook functioneel duidelijk zijn. Anders kan ieder willekeurige woonsituatie moment opgevoerd worden, terwijl de huidige woonsituatie gewenst is.
Besluit:
ZIB-1274
refsets toevoegen aan zib
| Aangemaakt op: | 18-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
twijfel of deze nieuwe refsets ook aan de zib moeten worden toegevoegd aangezien deze in de NL labcode set zitten. Wel anayse waard.
* Dutch pathology simple reference set (foundation metadata concept) 110851000146103
* (misschien wel/niet onderdeel)
* simpele referentieset met ordinale uitslagen van microscopische bepalingen (metadata) 97801000146108
* simpele referentieset met ordinale uitslagen (metadata) 46231000146109
* simpele referentieset met ordinale uitslagen van bepalingen van antibioticagevoeligheid (metadata) 140301000146101
Besluit:
ZIB-1279
refset implantaten beschikbaar in snomed ct NL editie
| Aangemaakt op: | 19-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Dutch implant registry simple reference set (foundation metadata concept) 14074100014610 is voor de implantaten die aangeleverd moeten worden aan het (landelijk implantaten register) LIR (inclusielijst). Dus veel leveranciers zullen deze lijst gebruiken in de zib, maar de zib kan ook breder gebruikt worden. Vraag is of en zo ja waar deze aan de zib medisch hulpmiddel kan worden toegevoegd.
Besluit:
ZIB-1281
diverse refsets voor verpleegkundige interventies/observaties.
| Aangemaakt op: | 19-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
* Dutch nursing intervention simple reference set (foundation metadata concept) 99051000146107
* simpele referentieset voor verpleegkundige interventies voor thema risico op vallen (metadata) 110881000146108
* simpele referentieset voor verpleegkundige observaties (metadata) 140991000146106
* simpele referentieset voor verpleegkundige interventies voor thema psychosociale zorg (metadata) 110911000146108
* simpele referentieset voor verpleegkundige observaties voor thema risico op delier (metadata) 140961000146101
* simpele referentieset voor verpleegkundige interventies voor thema delier (metadata) 110891000146105
* simpele referentieset voor verpleegkundige interventies voor thema pijn (metadata) 110861000146100
* simpele referentieset voor verpleegkundige interventies voor thema wond (metadata) 110871000146106
* simpele referentieset voor verpleegkundige interventies voor thema risico op suïcide (metadata) 110901000146106
Toevoegen aan verpleegkundige interventie?
Besluit:
ZIB-1282
Zorgteam naam heeft een Nederlandse vertaling in de Engelse versie
| Aangemaakt op: | 20-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de Engelse versie van zorgTeam (Careteam) bevat het element NL-CM:17.3.12 nog een Nederlandse vertaling.
CareTeamNaam -> CareTeamName
Link: [https://zibs.nl/wiki/CareTeam-v1.0(2020EN)]
Besluit:
ZIB-1283
Haakje weghalen bij eerste bullet bij Instructie
| Aangemaakt op: | 26-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Haakje weghalen bij eerste bullet bij Instructie (in de zib MedicatieContraIndicatie versie 2020)
Besluit:
ZIB-1284
Foutieve koppeling van observable entity termen aan container(s)
| Aangemaakt op: | 27-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Op de site https://zibs.nl/wiki/TNMTumorClassificatie-v1.0(2020NL)#14178 en op de pdf onderaan de site, staan bij de anatomische locaties nog observable entities. Hier staat het wel goed: https://zibs.nl/wiki/AnatomischeLocatie-v1.0(2020NL) Dus eigenlijk het verzoek op de site en pdf aan te passen :)
Besluit:
ZIB-1285
TNM zib: Tekstuele aanpassing omschrijving van mAantalprimairetumoren
| Aangemaakt op: | 30-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de omschrijving van dit element staan in zowel de NL als EN tekst nog een paar foutjes, zie de rode tekst en de opmerkingen voor AD:
* Het aantal primaire tumoren. Indien er meerdere primaire tumoren in één orgaan aanwezig zijn wordt de afwijking met de hoogste T-categorie geclassificeerd en de multipliciteit of het aantal primaire tumoren uitgedrukt in een aanvulling op de T-categorie in de vorm van (m) of een (<getal>), bijv. T2(m) of T2(2). Bij één primaire tumor wordt {color:#de350b}-deze- *m* {color}weggelaten uit de ‘GeintegreerdeTNMWaarde{color:#de350b}-overallTNMClassificatie-{color}’.
* In Art Decor is het stukje “(<getal>)” tussen de haakjes weggevallen in de NL tekst.
* The number of existing primary tumors. In the case of multiple primary tumors in one organ, the tumor with the highest T category should be classified and the multiplicity or the number of tumors should be indicated in parenthesis{color:#de350b}*.*{color} If multiple primary tumors are present, this is expressed in an addition to the T category in the form of (m) or a (number), e.g. T2 (m) or T2 (2). In case of one primary tumor, m is omitted from the "IntegratedTNMValue{color:#de350b}-overall TNM Classification-{color}".
* In Art Decor staat in de EN tekst tevens de Nederlandse omschrijving nog vermeldt.
Besluit:
ZIB-1286
Auteur toevoegen bij zib Probleem
| Aangemaakt op: | 30-11-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Auteur (in de betekenis van steller diagnose) toevoegen aan zib Probleem
Besluit:
ZIB-1287
TNM zib: Aanvullende waarden voor prognostisch stadium
| Aangemaakt op: | 01-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Met het tumor specifiek maken van de TNM zib voor Gestational Trophoblastic Neoplasms (een gynaecologische tumor) heb ik de volgende waardenlijst voor Prognostisch Stadium opgesteld aan de hand van de TNM:
[https://decor.nictiz.nl/art-decor/decor-valuesets--onco-tnm-?id=2.16.840.1.113883.2.4.3.11.31.1.77.24.11.602&effectiveDate=2020-10-26T11:12:16&language=nl-NL]
Deze waarden wijken af van de waarden die in de zib zitten. Moeten al deze waarden aan de generieke waardenlijst voor Prognostisch stadium in de zib toegevoegd worden, of kunnen we hier af met 'uitbreidbaarheid'?
Besluit:
ZIB-1292
InterpretatieMethodeCodelijst verbeteren of opheffen?
| Aangemaakt op: | 07-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De ZIB LaboratoriumUitslag bevat al jaren een waardenlijst genaamd InterpretatieMethodeCodelijst met de curieuze koppeling:
Conceptnaam Conceptcode Codestelselnaam Codesysteem OID Omschrijving
EUCAST tbd SNOMED CT 2.16.840.1.113883.6.96 EUCAST
Hiermee wordt niet duidelijk welke waarden zijn toegestaan; SNOMED bevat i.i.g. geen EUCAST-lijst... Is bij het opstellen van de ZIB aangegeven wat voor waarden een/de EUCAST-lijst bevat? Zo ja, dan zou de waardenlijst ofwel een verwijzing naar die EUCAST-lijst incl. vindplaats moeten zijn (en niet naar SNOMED); of een lijst met specifieke elementen, die mogelijk aan SNOMED kunnen worden gekoppeld.
Als bij het opstellen nooit is aangegeven wat het doel van de lijst is, en hij niet gebruikt wordt, kunnen we overwegen hem op te heffen. Ik zal eerst navraag doen bij NVKC en NVMM voor ik het issue naar jullie doorzet.
Besluit:
ZIB-1293
Waardenlijsten voor LaboratoriumTest#TestUitslag
| Aangemaakt op: | 07-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij het concept TestUitslag zijn nu geen waardenlijsten gegeven. Echter, de Labcodeset en SNOMED bevatten een reeks mogelijke uitslagenlijsten, namelijk:
* 2581000146104 |simpele referentieset voor micro-organismen (metadata)|
* 46231000146109 |simpele referentieset met ordinale uitslagen (metadata)|
* 97801000146108 |simpele referentieset met ordinale uitslagen van microscopische bepalingen (metadata)|
* 140301000146101 |simpele referentieset met ordinale uitslagen van bepalingen van antibioticagevoeligheid (metadata)|
Ik wil daar nog een set aan toevoegen met typen mengflora:
145871000146106 |simpele referentieset met typen mengflora (metadata)|
Op termijn zullen er meer uitslagenlijsten bijkomen. De referentiesets bevatten verschillende soorten concepten (bevindingen, kwalificatiewaarden, organismen) dus het is lastig om een specifieke doch duurzame constraint te bedenken. Maar helemaal niets neerzetten lijkt me toch ook niet juist... Hoe kunnen we dit oplossen?
Besluit:
ZIB-1295
correctie en toevoegen SNOMED CT termen in de zib probleem
| Aangemaakt op: | 09-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
de codes van de waarden actief en niet actief zijn niet correct.
Actief 55561003 Actueel
Inactief 73425007 Niet actueel
Deze zouden moeten zijn
15240007 |actueel (kwalificatiewaarde)|
410513005 |in verleden (kwalificatiewaarde)|
Verzoek is deze te wijzigen in de waardelijst van de zib
Besluit:
ZIB-1296
concept BrandwondSoort ontbreekt in zib brandwond
| Aangemaakt op: | 10-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
tussen 2019-2 en 2020 is blijkbaar het item brandwondSoort verwijderd maar dit zit nog wel in het voorbeeld. OF het voorbeeld moet worden aangepast of het item moet weer worden toegevoegd maar ik vermoed dat dit een fout is geweest (het verwijderen)
Besluit:
ZIB-1297
Zib vrijheidsbeperkende interventies pub. 2020
| Aangemaakt op: | 16-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
t.a.v. wilsbekwaamheid graag de volgende wijzigingen:
# (ingetrokken in de intakefase na overleg, zie commentaren) Concept Wilsbekwaam de cardinaliteit op 0..1 zetten. Het mag niet als een altijd verplicht in te vullen veld worden gebruikt.
# Bij de toelichting Wilsbekwaamheid moet de instructie worden aangevuld dat in de toelichting altijd moet staan ten aanzien van wat er sprake is van wilsonbekwaamheid. Het voorbeeld t.a.v. geldzaken is prima en zo hoort het gebruikt te worden.
Verder zijn de example instances niet helemaal consistent met de zib: o.a. begindatum (2020) versus start episode (oud). Graag die ook actualiseren.
Besluit:
ZIB-1302
Uitbreiding DrugsOfGeneesmiddelSoortCodelijst van de zib DrugsGebruik
| Aangemaakt op: | 17-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In het UMC Utrecht wordt de mogelijkheid gemist om expliciet het gebruik van ‘Lachgas’ aan te kunnen geven bij Drugsgebruik. De vraag komt van de anesthesiologie en wordt ondersteund door de Nederlandse Vereniging voor Intensive Care (NVIC), die deze wens als volgt beargumenteerd:
“Lachgas heeft zich inmiddels zeker ontwikkeld tot een volwaardige “drug of abuse”, het lijkt mij zinnig om lachgas APART op te nemen in deze landelijke registraties. In veel registratiesystemen worden “inhalants” op één hoop gegooid, waardoor het onderscheid retrospectief niet meer te maken is, dat heeft niet de voorkeur”.
Ik heb inmiddels al even contact gehad met Linda Mook. Zij heeft aangegeven dat:
111132001 - Nitrous oxide (substance), de meest voor de hand liggende uitbreiding op de lijst is.
Omdat het gaat om een ‘Extensible’ codelijst, heeft het UMC Utrecht het voornemen deze code alvast in gebruik te gaan nemen in afwachting van een reactie op dit wijzigingsvoorstel.
Besluit:
ZIB-1303
Onderscheid maken tussen vrouwelijk en mannelijke familieleden
| Aangemaakt op: | 17-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib familieanamnese kun je per familielid aangeven welke aandoeningen deze al dan niet hebben gehad. De lijst met familieleden maakt echter niet altijd onderscheid tussen de vrouwelijke en mannelijke varianten. Hierdoor kunnen we niet aangeven of het om een grootouder gaat die oma of opa is. Dit geldt ook voor overgrootouder, kleinkind en neef/nicht. Dit is in het oncologische speelveld soms belangrijke informatie om te weten.
Is het mogelijk om deze familieleden toe te voegen?
Besluit:
ZIB-1305
Dagdeel is vertaald naar 'time of day'
| Aangemaakt op: | 21-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het nederlandse dagdeel (ochtend, middag, avond, nacht) is in het Engels vertaald naar '[time of day'|https://zibs.nl/wiki/InstructionsForUse-v1.2.1(2020EN)#13205].
In mijn hoofd is 'time of day' een tijdstip en iets anders dan een dagdeel.
Klopt deze vertaling wel?
Besluit:
ZIB-1306
Toevoegen IC en MC aan Contactypecodelijst
| Aangemaakt op: | 23-12-2020 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij deze nogmaals het verzoek om de IC en ook de MC toe te voegen als contacttype aan de contacttype codelijst. Beide afdelingen zijn namelijk niet door andere parameters te identificeren waardoor opname en ontslag van een IC en MC nu niet zijn te herleiden op basis van de ZIB's .
We begrijpen de reden van afwijzing ZIB-626 maar zien ook dat de ontwikkeling van logistieke zibs die dit probleem moeten oplossen op zich laat wachten terwijl een simpele toevoeging van deze types aande ZIB Contact ervoor zorgt dat afdelingen verder kunnen met de inrichting van de ZIB's
Besluit:
ZIB-1314
GCS_VerbalCodelijstBaby en Kleuter hebben verschillende V10
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de [zib GlasgowComaScale|https://zibs.nl/wiki/GlasgowComaScale-v3.2(2020NL)] staat in zowel GCS_VerbalCodelijstBaby als GCS_VerbalCodelijstKleuter een code V10 uit het systeem 2.16.840.1.113883.2.4.3.11.60.40.4.2.3.
* GCS_VerbalCodelijstBaby heeft V10 = Coos/babbles
* GCS_VerbalCodelijstKleuter heeft V10 = Orientated
Omdat beide de code uit hetzelfde systeem halen, kan dit niet kloppen.
Merk op dat er meer zijn die niet kunnen kloppen zoals V9 _Confused_ versus _Irritatable cries._
De codesystemen in de verschillende GCS_Verbal (en mogelijk ook GCS_Motor) waardelijsten moeten elk hun eigen codesysteem hebben, of de codes moeten overal exact dezelfde semantiek hebben.
Besluit:
ZIB-1316
Mate van kritiek zijn of Beleid/blokkade
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Er is consensus dat de huidige definitie en invulling van Mate van kritiek zijn niet aansluiten bij de gewenste praktijk. De definitie “Mate van kritiek zijn wordt gedefinieerd als "de potentiële ernst van toekomstige reacties" gaat over een voorspelling van de volgende reactie. Deze voorspelling is niet toetsbaar en daar zal een zorgverlener zich niet over willen en kunnen uitlaten. Huisartsenoverdrachten stelt voor om het concept daarom niet te gebruiken en introduceert Beleid/blokkade, net als in de afsprakenset. De tweede lijn stelt voor om aan te sluiten bij het internationale concept criticality want “ 'High Risk' is flagged if the clinician (..) has identified an absolute contraindication to deliberate or voluntary exposure to the substance”.
Het gaat om de beoordeling door de arts met betrekking tot de implicaties van de overgevoeligheid als geheel. Het wijzigen van de naam van het element naar besluit of blokkade leidt tot meer discussie omdat daarmee en verplichting lijkt te ontstaan terwijl een andere zorgverlener altijd zijn eigen afweging maakt in het licht van de situatie.
Voorstel is om aan te sluiten bij het internationale criticality en invulling op een manier dat het advies/de beoordeling van de arts helder is. Dit leidt tot de volgende aanpassing:
* *Definitie*: MateVanKritiekZijn wordt gebruikt om de beoordeling van de zorgverlener weer te geven of de overgevoeligheid een contra-indicatie vormt voor bedoelde of onbedoelde blootstelling aan de stof, groep stoffen of omgevingsfactor waar de patiënt overgevoelig voor is.
* *Waardenlijst*:
## Laag: Blootstelling geeft vermoedelijk wel een reactie, maar blootstelling wordt door de arts niet als absoluut gecontra-indiceerd beoordeeld.
## Hoog: Blootstelling wordt door de arts als absoluut gecontra-indiceerd beoordeeld.
## Geen oordeel: De arts geeft geen advies over het te voeren beleid.
Besluit:
ZIB-1317
Ernst van de reactie
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraagstuk*
Er is onduidelijkheid over de indeling: licht | matig | ernstig. Ernst wordt door allergologen afgeleid uit verschillende vragen. Onderscheid tussen ernstig en licht/matig is makkelijker te maken dan het onderscheid tussen licht en matig. In sommige informatiesystemen is er ook de mogelijkheid om voor "onbekend" te kiezen.
*Analyse*
CIOMS hanteert een tweedeling voor ernst: Licht/matig en Ernstig. In de huidige waardenlijst voldoet ernstig aan de CIOMS-criteria voor serious (ernstig). Alles wat niet ernstig is, valt dan in de categorieën "Licht/Matig". De eerste lijn geeft aan op dit moment de driedeling te hanteren. Wel is er aangegeven dat het voorbeeld "nierfunctiestoornis" verwijderd moet worden. Omschrijving waardenlijst aangescherpt op basis van 1e en 2e lijn en MedDRA; additioneel toestaan toepassingspecifieke codelijsten (bijv. allergenen, oncologie).
*Besluit* werkgroep Overgevoeligheid: Onbekend kan weggelaten worden en de driedeling hanteren (licht | matig | ernstig).
*Besluit* werkgroep Overgevoeligheid: De voorbeelden worden niet meer in de zib weergegeven omdat deze onduidelijk zijn en leiden tot meer verwarring en de volgende omschrijvingen zijn verbeterd en worden gebruikt voor licht, matig en ernstig:
* Licht: De reactie leidt niet tot:
- medisch ingrijpen,
- ziekteverzuim of
- hinder in het dagelijks functioneren.
* Matig: De reactie leidt tot:
- hinder in het dagelijks functioneren of
- medisch ingegrepen zoals het starten, staken of wijzigen van medicatie of een andere behandeling.
* Ernstig: De reactie leidt tot:
- (verlenging van) ziekenhuisopname;
- Congenitale afwijkingen;
- Invaliditeit / blijvende arbeidsongeschiktheid;
- Levensbedreigende situatie;
- Verlenging van ziekte;
- Blijvende gezondheidsschade;
- Overige ernstige aandoeningen.
Besluit:
ZIB-1319
Veroorzakende stof vs Te bewaken stof
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraagstuk*
Wordt de stof zowel bij de reactie als bij de overgevoeligheid vastgelegd? Zijn dit twee verschillende gegevens? Dit is wel het geval, namelijk eerst een handelsproduct als SpecifiekeStof vastleggen en daarna specificeer je de stofnaam code. Maar zit er wel een fijnzinnigheid in het datamodel? Het conceptueel model en procesmodel lijken hier te bootsen. Er zijn afwijkende reacties op een specifieke stof mogelijk. Dit zal tot dubbel registreren leiden en mogelijk fouten. Er zijn gronden dat er op aparte plekken de stof wordt bepaald.
*Analyse*
Het is nodig om de stof op beide plaatsen vast te leggen zoals in het zib model is aangegeven. Bij een reactie kan een stof worden aangegeven die de reactie veroorzaakt. Dit is een objectieve waarneming. Links in het model wordt de overgevoeligheid (stof of stofgroep) vastgelegd waarop je het beleid bepaald en rechts in het model wordt de stof vastgelegd waarom de reactie heeft plaatsgevonden.
*Besluit*: TeBewakenStof is de term die VeroorzakendeStof zal vervangen. Om verwarring te voorkomen is er gekozen voor Te bewaken stof omdat de term VeroorzakendeStof ook kan verwijzen naar de stof waarop de reactie optreed. De term te Vermijden Stof is ook overwogen, maar heeft niet de voorkeur. Te bewaken stof is ook voorgelegd aan de allergologen, omdat bewaken voor allergenen geen gangbare term is, maar zij zijn hiermee akkoord gegaan. Het gaat hier om het rekening houden met in het beleid.
*Besluit*: De term Stof vervangt SpecifiekeStof in het datamodel. Eigenlijk heeft VeroorzakendeStof hier de voorkeur, maar deze is in het oude model al gebruikt voor een ander dataelement aan de linkerkant van het model. Dit zou tot verwarring leiden om het hier her te gebruiken.
*Besluit*: Er kunnen meerdere stoffen bij één reactie worden aangegeven. Wanneer meerdere geneesmiddelen worden gebruikt is niet altijd direct duidelijk welk van deze middelen de oorzaak is. Kardinaliteit van Stof wijzigen van 0..1 naar 0..*.
*Besluit TeBewakenStof*: alle vier geneesmiddelcoderingen (Handelsproduct [HPK], Stof naam + toedieningsweg [SSK], Stof naam [SNK], Stofgroep [geneesmiddelengroep]) toestaan op het niveau van TeBewakenStof en de allergenenlijsten (zib-953).
*Besluit* *Stof*: Omdat het hier een objectieve waarneming betreft worden hier Handelsproduct [HPK], Stof naam [SNK] en de allergenenlijsten toegestaan. De andere geneesmiddelcoderingen komen te vervallen.
*Definitie "TeBewakenStof"*: De stof of groep stoffen waarop bewaakt wordt.
*Definitie "Stof"*: De (vermoedelijke) stof die de reactie heeft veroorzaakt.
Besluit:
ZIB-1321
BeginDatumTijd
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit zib-838: Er is verschil van definitie voor dit data-element. Datum van eerste openbaring van de symptomen. Wie zegt dat deze datum ook echt de eerste is? Het is een inschatting van de datum van de eerste reactie. Datum van vastlegging/vaststelling van de reactie. Wat betekent ‘vastleggen’ en ‘vaststellen’. In FHIR gaat het om “vastgesteld door de zorgverlener”. Dit is de linker datum. De datum van vastlegging zit altijd in de zib en wordt automatisch gegenereerd door het systeem: registratiedatum.
*Analyse*
Moeten we 'voor het eerst' toevoegen aan de definitie van BeginDatumTijd? Ook reactie is belangrijk. Het gaat om de eerste reactie. Maar dat levert verwarring door de verwijzing naar de reactie, dat is een ander onderdeel van het model. Het gaat niet per se over het vaststellen van de reactie want dan gaat het om de diagnose. Die kan jaren later vastgesteld worden, je wilt hier verwijzen naar het eerst bekende moment. Overgevoeligheden kunnen al vanaf de geboorte bestaan dus aangeven van een begindatumtijd is sowieso lastig. Een overgevoeligheid manifesteert zich op een gegeven moment met een reactie en die wil je hier aangeven. Dit kan een exact of vaag moment zijn in de tijd.
Twee voorstellen voor de definitie van BeginDatumTijd in stemming:
# Datum en tijd waarop de overgevoeligheid zich voor het eerst geopenbaard heeft.
# Datum en tijd waarop de overgevoeligheid zich voor het eerst in een reactie geopenbaard heeft.
Voor beide geldt: Dit kan een exacte datum en tijd zijn maar ook een globale aanduiding van de datum (bijvoorbeeld alleen jaar of jaar en maand).
Besluit: Keus valt op optie 2.
Besluit:
ZIB-1322
Kardinaliteit zib Overige overgevoeligheden
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit zib-838: Project Huisartsenoverdracht stelt voor om onderscheidt te maken in Overige Overgevoeligheid en Medicatie-overgevoeligheid.
*Analyse*
De werkgroep ziet vooralsnog geen reden voor separate zibs voor geneesmiddel- en niet-geneesmiddelovergevoeligheden. De gegevenselementen die je bij beide wilt vastleggen zijn vergelijkbaar.
*Besluit*: de volgende categorieën hanteren binnen deze zib (ivm de nieuwe allergenenlijsten zijn de categoriën aangepast):
* Geneesmiddelen;
* Beroepsallergenen;
* Contactallergenen;
* Inhalatieallergenen;
* Insectenallergenen;
* Voedselallergenen.
*Besluit*: Een TeBewakenStof kan van toepassing zijn op meerdere categorieën bijv. een kok die een beroeps- en voedselallergie heeft voor bijv. sojameel. Dit betekent dat de kardinaliteit van AllergieCategorie aangepast wordt naar 0..*.
Besluit:
ZIB-1323
Basiselementen in zib Overgevoeligheid - EersteAuteur
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Nieuw beleid bij zibcentrum is dat basiselementen expliciet moeten worden uitgewerkt in de zib. Wat betekent dit voor de zib AI?
*Analyse*
*Besluit*: hieronder wordt aangegeven welke basiselementen wel en niet in de zib AllergieIntolerantie worden opgenomen:
* Informatiebron – dit is relevant maar niet in deze vorm. Je wilt hiermee aangeven hoe je aan de gegevens bent gekomen, zodat een goede afweging van de gegevens mogelijk is. In de werkgroep Overgevoeligheid is gekozen om twee dataelementen hier aan te wijden, namelijk *ManierVanVaststellen* en *OmschrijvingBron*. Dit sluit ook aan bij de afsprakenset van de beroepsgroepen.
* Identificatienummer – niet opnemen. Wel in de informatiestandaard opnemen.
* Auteur – Wel opnemen, degene die de overgevoeligheid als overgevoeligheid heeft aangemerkt is relevant voor de interpretatie. De naam van dit dataelement wordt wel gewijzigd in *EersteAuteur* zodat ook bij overnemen in een ander systeem deze informatie behouden blijft.
* RegistratieDatumTijd – Deze wordt opgenomen omdat het moment van vastleggen klinisch relevant is voor medicatiebewaking. Daarnaast brengt deze datum meer nuance in de interpretatie van een overgevoeligheid. De naam van dit dataelement wordt wel gewijzigd in *ToevoegingsDatumTijd* omdat het niet alleen een administratief karakter heeft.
* Onderwerp – niet opnemen. Het betreft hier alleen de patiënt.
*Definitie* *ToevoegingsDatumTijd*: Datum en tijd waarop de overgevoeligheid door de eerste auteur is toegevoegd aan het medisch dossier.
*Definitie* *EersteAuteur*: De zorgverlener die verantwoordelijk is voor toevoeging aan het medisch dossier.
*Definitie* *ManierVanVaststellen*: De manier waarop de overgevoeligheid is vastgesteld.
*Waardelijst ManierVanVaststellen* (+SNOMED-code):
* 144501000146103 |toestand van overgevoeligheid gebaseerd op klinisch beeld (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld*
* 144511000146101 |toestand van overgevoeligheid gebaseerd op klinisch beeld en aanvullend onderzoek (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld en aanvullend onderzoek*
* 144491000146108 |toestand van overgevoeligheid gebaseerd op anamnese (bevinding)| met voorkeursterm: *Op basis van de anamnese*
*Definitie* *OmschrijvingBron*: De omschrijving van de wijze waarop de informatie is verkregen, zoals het ontvangen van een brief van een specialist of een gesprek met de patiënt.
Besluit:
ZIB-1324
"Splitsen" zib AllergieIntolerantie
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Zou de container Reactie niet een eigenstandige zib kunnen worden zodat dit ook bruikbaar is voor andere reacties die niet gebonden zijn aan een overgevoeligheid? Zou dit dan een eigen zib moeten zijn of hergebruik van de zib Probleem? En hoe ziet die zib er dan uit?
*Analyse*
De huidige zib AllergieIntoleratie heeft twee kanten:
– container aan de rechterkant voor reactie; dit is een zo objectief mogelijke waarneming van de reactie en de vermoedelijke oorzaak daarvan;
– linkerkant overgevoeligheid; hier wordt het beleid bepaald bijv. dat er bewaakt moet worden op een groep stoffen om blootstelling in de toekomst te voorkomen.
Reacties kunnen nu worden vastgelegd bij een overgevoeligheid. Maar ook bij andersoortige reacties, bijv. bijwerkingen op een geneesmiddel of vaccinatie, worden dezelfde gegevenselementen gebruikt. Dit geldt ook voor bijv. een reactie op straling. Ook wanneer er nog niet bekend is of er een sprake is van een overgevoeligheid kunnen er nu nog geen reacties worden vastgelegd. Met het maken van een zib Reactie kunnen deze use cases worden ondersteund. Omdat reacties breder zijn dan alleen bijwerkingen is het voorstel om de naam Reactie voor deze zib te gebruiken.
De zib Reactie zou ook als zib Probleem kunnen worden benaderd. Hiervoor zijn een aantal voor- en nadelen onderkent.
Argumenten +vóór+ een eigen zib Reactie:
• Reactie/bijwerkingen zijn klinisch herkenbare concepten.
• Het betreft een aparte categorie van symptomen die hun eigen specifieke rol spelen binnen het medisch proces.
• Voor het beschrijven van een reactie zijn specifieke gegevenselementen nodig die nu niet worden ondersteund in de zib Probleem. Om reactie op te nemen in de zib Probleem zijn aanvullende gegevenselementen nodig zoals: Stof (oorzaak), Toedieningsweg, Ernst, ReactieBeschrijving, ProbleemType aanpassen.
• Leveranciers ondersteunen tot op heden de registratie van bijwerkingen en reacties i.h.a. heel anders dan van diagnose- en complicatieregistratie, die wel wordt geassocieerd met probleem.
Argumenten +tegen+ een eigen zib Reactie:
• Een patiënt presenteert zich met een Probleem, nl. de symptomen waarvoor hij hulp zoekt. De arts zal een probleem registreren met bijbehorende DBC.
• Het kan enige tijd vergen alvorens duidelijk wordt dat een Probleem een Reactie is op basis van een Overgevoeligheid of bijv. een Bijwerking van een geneesmiddel.
• Er is meer overeenkomst tussen een Reactie en een Probleem dan je nu op basis van de resp. informatiemodellen zou denken. Bij een Complicatie is het ook wenselijke om een oorzaak vast te leggen net als een Reactie of een Bijwerking.
• Het is niet wenselijk dat bij uitwisseling van gegevens de symptomen die aanleiding hebben gegeven tot de zorgvraag zowel als Probleem én als Reactie worden overgedragen.
De Werkgroep overgevoeligheid heeft op basis van hiervan besloten om een eigen zib voor Reactie voor te stellen en niet de zib Probleem aan te passen. De leveranciers van programma MedicatieOverdarcht hebben aangegeven de zib Probleem een te grote vergaarbak te vinden en reacties niet als probleem te herkennen in de systemen. En gezien de gevraagde uitbreiding van de zib Probleem en de herkenbaarheid als klinisch concept gaat ook de werkgroep voor een eigen zib Reactie.
Bijgesloten een overzicht van hoe de zib Overgevoeligheid en Reactie er dan uit gaan zien met een verwijzing naar alle bits issues. Daarin zijn ook de concept beschrijving, purpose en evidence base te vinden.
Besluit:
ZIB-1326
Naamswijziging zib AllergieIntolerantie
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Kernvraag: Leidt de naam van de zib AllergieIntolerantie tot verwarring? Waar zit de verwarring en wat leidt hierdoor tot onduidelijk?
*Analyse*
Aanbeveling analyse (2019): De term intolerantie niet meer gebruiken vanwege onduidelijkheid in de betekenis. We zouden dus ook niet meer over ICA (Intoleranties, contra-indicaties en allergieën) moeten spreken maar over contra-indicaties en overgevoeligheden (CIO). Hangt ook samen met splitsing AI.
*Besluit*: Naam van de nieuwe zib wordt Overgevoeligheid. Deze naam sluit aan bij de beroepsafspraken zoals beschreven in de afsprakenset Registratie en Overdracht van geneesmiddelovergevoeligheden. De deelnemers van de werkgroep Overgevoeligheid waren het met elkaar eens dat Overgevoeligheid de lading van de zib in Nederland goed dekt. De term intolerantie leidt tot vragen omdat deze niet uniform gebruikt wordt. Voor de zib Reactie en de naamgeving daarvan komt een apart voorstel.
Besluit:
ZIB-1327
ReactieBeschrijving
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit zib-838: Volgens het programma Huisartsenoverdracht is er op dit moment geen 1:1 mapping mogelijk voor de aard van de reactie. Deze kan namelijk uit meerdere dataelementen (ReactieBeschrijving en Symptoom) bestaan. Daarnaast is de codelijst voor de symptomen niet toereikend voor alle specialisme. Het voorstel is om ‘Symptoom’ te handhaven en optioneel te maken, dit element staat nu als verplicht in het datamodel en ‘Omschrijving/ReactieBeschrijving’ te handhaven en verplicht te maken.
*Analyse*
De werkgroep heeft de kardinaliteit van de verschillende dataelementen besproken zijn tot de volgende conclusie gekomen: Symptoom (0..*) was (0..*), ReactieBeschrijving blijft (0..1). Aanvullend is nieuw dat op zijn minst één van beide (verplicht) moet zijn ingevuld, anders kan de aard van de reactie niet zijn aangegeven. Dit is wel noodzakelijk bij het vastleggen van een reactie.
Besluit:
ZIB-1328
RedenVanAfsluiten toevoegen
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Volgens de werkgroep Overgevoeligheid is het toevoegen van de reden van afsluiten zinvol in een gedistribueerd systeem. Er is even getwijfeld of er een code of vrije tekst gebruikt moest worden. Vrije tekst geeft een zorgprofessionals meer mogelijkheid om zichzelf volledig te kunnen uitdrukken. Bovendien wordt de reden van afsluiten niet automatisch verwerkt.
*Besluit*: RedenAfsluiten als vrije tekst toevoegen.
*Definitie RedenAfsluiten*: Reden waarom de overgevoeligheid is afgesloten.
Besluit:
ZIB-1329
DatumAfsluiten toevoegen
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
DatumAfsluiten is een zorginhoudelijke datum is. Dit moet als default de datum van vandaag/registratie zijn, zodat zorgprofessional geen extra registratielast heeft. EindDatum is verwarrend voor een zorgverlener. Het is niet per se de datum waarop de overgevoeligheid is gestopt, die is onzeker maar wel het moment waarop je de overgevoeligheid niet meer hoeft te bewaken.
*Besluit*: Naast een reden is ook de datum van afsluiten klinisch relevant omdat vanaf dat moment de medicatiebewaking wordt gestopt.
*Definitie DatumAfsluiten*: De datum waarop besloten is om niet meer te bewaken.
Besluit:
ZIB-1330
Verwijderen van LaatsteReactieDatumTijd
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit ZIB-838: Huisartoverdrachten stelt voor om LaatsteReactieDatumTijd te verwijderen omdat dit schijnzekerheid geeft, wanneer heeft de laatste reactie daadwerkelijk plaatsgevonden? Het doel is om vooral relevante reacties (rechts in het model) vast te leggen. Stel dat een patiënt wordt opgenomen dan wil je adequaat kunnen reageren.
*Analyse*
LaatsteReactieDatumTijd geeft geen zekerheid over de feitelijke laatste reactie. Bovendien wordt de laatste reactie lang niet altijd vastgelegd als dat geen nieuwe informatie oplevert.
*Besluit*: LaatsteReactieDatumTijd laten vervallen
Besluit:
ZIB-1331
Verwijderen van ReactieTijdstip
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit ZIB-838: Huisartsenoverdrachten stelt voor om ReactieTijdstip te verwijderen.
*Analyse*
Discussie over het vastleggen van een reactie in het verleden: het gaat om een indicatie van de periode waarin de reactie plaats vond zodat de juiste overgevoeligheid kan worden vastgesteld (was je al volwassen, jong volwassen of kind). Had het betrekking op medicatie of een ziekte? Een exacte leeftijd is niet altijd van belang. Het gaat veel meer om volwassenheid of doordat het kind Pfeiffer heeft gehad en als gevolg daarvan een reactie vertoont. Een exact reactietijdstip is zelden te benoemen waardoor de naam ReactieTijdstip misleidend is. Huisartsen hebben een andere informatiebehoefte dan medische specialisten in het ziekenhuis.
Verzoek tot toevoeging van EindDatum van de reactie. Er is nu één datum mogelijk. Wat is de reactiedatum als er gedurende een langere periode een reactie is opgetreden? Duur is klinisch nog relevanter, dit geeft ook IKNL aan. Zowel begin- en/of einddatum als duur moeten mogelijk zijn.
*Besluit*: ReactieTijdstip niet verwijderen, maar de naam ”ReactieTijdstip” veranderen in “ReactiePeriode” met referentie naar de zib Tijdsinterval.
*Begindatum*: Datum en tijd waarop de reactie gestart is. Dit mag ook alleen een datum of een gedeeltelijke datum zijn, indien dit niet nauwkeuriger bekend is.
*Duur*: Duur van de reactie.
*Einddatum*: Datum en tijd waarop de reactie niet meer optrad. Dit mag ook alleen een datum of een gedeeltelijke datum zijn, indien dit niet nauwkeuriger bekend is.
Besluit:
ZIB-1332
WijzeVanBlootstelling
| Aangemaakt op: | 13-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Uit ZIB-838: In het HIS-Referentiemodel is de reactie anders ingericht, waarbij de detaillering van de reactie zoals beschreven in de RadB ook anders uitpakt. WijzeVanBlootstelling is niet relevant voor de HA-zib.
*Analyse*
Dit element is wel klinisch relevant. Wijze van blootstellig is belangrijk voor de geneesmiddelenovergevoeligheid. Wijze van blootstelling is niet relevant voor de overige overgevoeligheden (allergenen) omdat uit het gekozen allergeen de wijze van blootstelling is op te maken. Voor de geneesmiddelenovergezoeligheid kan de wijze van blootstelling ingevuld worden door de toedieningsweg zoals ook vastgelegd is in de medicatiebouwstenen.
*Besluit*: de naam van het dataelement wordt daarom gewijzigd naar "Toedieningsweg" met de codelijst zoals die gehanteerd is in de medicatiebouwstenen.
Besluit:
ZIB-1334
Incorrecte vertaling 'Ambulatory' in ZIB Contact
| Aangemaakt op: | 14-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de ZIB Encounter wordt een vertaling voor de term Ambulatory gegeven voor de valueset ContactTypeCodelist. De gegeven vertaling 'Poliklinisch' is volgens het HL7 team niet correct, dit geeft een te smalle weergave weer van de originele betekenis.
|A comprehensive term for health care provided in a healthcare facility (e.g. a practitioneraTMs office, clinic setting, or hospital) on a nonresident basis. The term ambulatory usually implies that the patient has come to the location and is not assigned to a bed. Sometimes referred to as an outpatient encounter.|
De huidige vertaling 'Poliklinisch' laat zich niet lenen voor gebruik in de 1e lijns zorg waar wel gebruik gemaakt wordt gemaakt van de ZIB. Sommige leveranciers preferen nu om OTH te gebruiken omdat er afgaande op de Nederlandse vertalingen, geen geschikte term beschikbaar is.
Graag zien wij de vertaling aangepast naar een term die de lading beter dekt, zoals bijvoorbeeld 'ambulant'. Deze term omvat 1e lijnszorg en poliklinisch.
Besluit:
ZIB-1337
Specifieke stof veranderen naar Stof
| Aangemaakt op: | 17-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het is nodig om de stof op beide plaatsen vast te leggen zoals in het zib model is aangegeven. Bij een reactie kan een stof worden aangegeven die de reactie veroorzaakt. Links wordt de overgevoeligheid (stof of stofgroep) vastgelegd waarop je wilt bewaken en rechts in het model wordt de stof vastgelegd waarom de reactie heeft plaatsgevonden.
*Besluit*: TeBewakenStof is de term die VeroorzakendeStof zal vervangen. Om verwarring te voorkomen is er gekozen voor te bewaken stof omdat VeroorzakendeStof ook kan verwijzen naar de stof waarop de reactie optreed. De term te Vermijden Stof is ook overwogen, maar heeft niet de voorkeur. Te bewaken stof is ook voorgelegd aan de allergologen en die zijn ook hiermee akkoord gegaan.
*Besluit*: De term Stof vervangt SpecifiekeStof in het datamodel. Eigenlijk heeft VeroorzakendeStof hier de voorkeur, maar deze is in het oude model al gebruikt door een ander dataelement.
*Besluit TeBewakenStof*: alle vier coderingen (Handelsproduct [HPK], Stof naam + toedieningsweg [SSK], Stof naam [SNK], Stofgroep [geneesmiddelengroep]) toe te staan op het niveau van TeBewakenStof.
*Besluit* *Stof*: Handelsproduct [HPK], Stof naam [SNK].
*Definitie "TeBewakenStof"*: De stof of groep stoffen waarop bewaakt wordt.
*Definitie "Stof"*: De (vermoedelijke) stof die de reactie heeft veroorzaakt.
Besluit:
ZIB-1340
Ontkenning van een overgevoeligheid In AllergieIntolerantie
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraagstuk*:
De werkgroep Overgevoeligheid is gevraagd hoe een ontkenning aan te geven. Hiervoor zou ‘refuted’ uit AllergieStatusCodelijst gebruikt kunnen worden. Dit houdt weerleggen/tegenspreken “ik wijs het af”.
*Analyse*:
Is afhankelijk van de werkwijze/het proces van omgaan met overgevoeligheden. Wordt voorgelegd aan de werkgroep Organisatie & Proces.
Besluit:
ZIB-1341
Inhoud AllergieStatusCodelijst
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraagstuk*:
Sluit de huidige AllergieStatusCodelijst (Actief, Niet meer aanwezig, Achterhaald, Foutief) aan in de praktijk en is deze relevant? Leidt deze codelijst tot onduidelijkheid? Zijn dit de redenen voor afsluiten of status van de overgevoeligheid?
*Analyse*:
Er is binnen de werkgroep Overgevoeligheid consensus over VerificationStatus (onderdeel van HL7 FHIR - AllergyIntolerance) dat dit niet hetzelfde is als ‘AllergieStatus’. Daarnaast wordt dit dataelement niet uitgewisseld. Verificatiestatus is de uitkomst van het reviewproces, niet de status van de overgevoeligheid. Als de verificatie nog niet bevestigd is wordt de overgevoeligheid niet uitgewisseld.
Besluit: VerificationStatus niet opnemen in datamodel.
Met betrekking tot AllergieStatusCodelijst is besloten om alleen actief en inactief te gebruiken als klinisch relevante statussen van de overgevoeligheid. Ter nuancering wordt bij inactief wel het synoniem “afgesloten” toegevoegd. In combinatie met RedenVanAfsluiten geeft dit dan een goede interpretatie van het aanbevolen beleid. Eigenlijk is de AllergieStatus niet noodzakelijk. De status is af te leiden uit de aan/afwezigheid van een DatumAfsluiten. Maar vanwege de bestaande historie waarin DatumAfsluiten nog niet geïmplementeerd is, wordt ervoor gekozen om het dataelement AllergieStatus toch te behouden zodat afgesloten overgevoeligheden zonder einddatum toch op inactief kunnen worden gezet.
Besluit:
ZIB-1344
Wijziging van de kardinaliteit van MateVanKritiekZijn
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*:
In de waardelijst van MateVanKritiekZijn staat Geen oordeel. De kardinaliteit is echter ook 0..1. Wat betekent het dan als dit niet ingevuld is? Is dat hetzelfde als Geen oordeel?
*Analyse*:
Geen oordeel wil zeggen dat een arts geen uitspraken doet over toekomstig te voeren beleid. Wanneer hij wel een verwachting wil uitspreken voor toekomstig beleid kiest hij voor Hoog, Laag. Kardinaliteit van MateVanKritiekZijn kan daarmee 1...1 (verplicht) worden.
Besluit:
ZIB-1345
G-Standaard/Pharmabase codering van geneesmiddel
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*:
Is voor geneesmiddelen naast de G-standaard codering ook een codering uit de Pharmabase toegestaan voor TeBewakenStof en Stof?
*Analyse*:
In het veld worden beide codesystemen gebruikt. Bij de uitwisseling dient een keus gemaakt te worden om interoperabiliteit te garanderen. Voorstel: Opnemen van zowel Pharmabase als G-standaard codering in de zib. In de informatiestandaard wordt een keus gemaakt voor de preferente standaard voor uitwisseling.
Besluit:
ZIB-1346
Onderliggende ernstclassificaties toevoegen
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*:
Is het nodig om de onderliggende ernstclassificaties van bijv. de allergenen ook op te nemen?
*Analyse*:
Vanwege interoperabiliteit is het nodig om één waardelijst te hanteren. Hiervoor is de ErnstCodeLijst ontwikkeld. In de praktijk wordt, met name in de tweede lijn, gebruik gemaakt van diverse andere waardelijsten zoals GINA, ARIA, Schaal van Müller. Een mapping van deze waardelijsten naar de ErnstCodeLijst is mogelijk maar andersom leidt tot kwaliteitsverlies. Om kwaliteitsverlies te voorkomen in de klinische setting is het voorstel om +naast+ de ErnstCodelijst ook andere codelijsten toe te staan. De ErnstCodeLijst blijft dus verplicht maar specifieker kan als aanvulling worden opgenomen.
Besluit:
ZIB-1348
Stof in zib Reactie of referentie naar andere zibs Medicatie, Vaccinatie, etc.
| Aangemaakt op: | 18-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*:
Stof opnemen in de zib Reactie of gebruik maken van een verwijzing naar andere zibs zoals medicatie, vaccinatie, etc.?
*Analyse*:
Opties:
1 Stof behouden zoals het nu is (geen extra gegevens beschikbaar bijv. toedieningsduur of
dosering).
2 In de zib Reactie verwijzen naar relevante zibs en allergenenlijsten:
a naast verwijzing ook Stof behouden in de zib Reactie voor de situatie waarin zibs
ontbreken;
b stof laten vervallen, alleen verwijzingen naar relevante zibs (NB. geen verwijzing naar allergenenlijsten mogelijk).
3 Stof laten vervallen en de verwijzing naar relevante bouwstenen en allergenenlijsten in de
informatiestandaard opnemen, i.p.v. in de zib Reactie
Conclusie uit leveranciersoverleg Medicatieproces:
Optie 2a heeft de voorkeur bij de leveranciers. De stof heb je sowieso nodig voor de allergenen en ook voor historische data. Het koppelen naar andere bouwstenen is wel een goed idee. Je kunt overigens ook de Stof overnemen uit die bouwstenen en hier invullen.
Voorstel: In de zib Reactie verwijzen naar de zibs waarop een reactie kan komen.
Besluit:
ZIB-1349
Basiselementen in zib Overgevoeligheid - ManierVanVaststellen
| Aangemaakt op: | 19-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Nieuw beleid bij zibcentrum is dat basiselementen expliciet moeten worden uitgewerkt in de zib. Wat betekent dit voor de zib AI?
*Analyse*
*Besluit*: hieronder wordt aangegeven welke basiselementen wel en niet in de zib AllergieIntolerantie worden opgenomen:
* Informatiebron – dit is relevant maar niet in deze vorm. Je wilt hiermee aangeven hoe je aan de gegevens bent gekomen, zodat een goede afweging van de gegevens mogelijk is. In de werkgroep Overgevoeligheid is gekozen om twee dataelementen hier aan te wijden, namelijk *ManierVanVaststellen* en *OmschrijvingBron*. Dit sluit ook aan bij de afsprakenset van de beroepsgroepen.
* Identificatienummer – niet opnemen. Wel in de informatiestandaard opnemen.
* Auteur – Wel opnemen, degene die de overgevoeligheid als overgevoeligheid heeft aangemerkt is relevant voor de interpretatie. De naam van dit dataelement wordt wel gewijzigd in *EersteAuteur* zodat ook bij overnemen in een ander systeem deze informatie behouden blijft.
* RegistratieDatumTijd – Deze wordt opgenomen omdat het moment van vastleggen klinisch relevant is voor medicatiebewaking. Daarnaast brengt deze datum meer nuance in de interpretatie van een overgevoeligheid. De naam van dit dataelement wordt wel gewijzigd in *ToevoegingsDatumTijd* omdat het niet alleen een administratief karakter heeft.
* Onderwerp – niet opnemen. Het betreft hier alleen de patiënt.
*Definitie* *ToevoegingsDatumTijd*: Datum en tijd waarop de overgevoeligheid door de eerste auteur is toegevoegd aan het medisch dossier.
*Definitie* *EersteAuteur*: De zorgverlener die verantwoordelijk is voor toevoeging aan het medisch dossier.
*Definitie* *ManierVanVaststellen*: De manier waarop de overgevoeligheid is vastgesteld.
*Waardelijst ManierVanVaststellen* (+SNOMED-code):
* 144501000146103 |toestand van overgevoeligheid gebaseerd op klinisch beeld (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld*
* 144511000146101 |toestand van overgevoeligheid gebaseerd op klinisch beeld en aanvullend onderzoek (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld en aanvullend onderzoek*
* 144491000146108 |toestand van overgevoeligheid gebaseerd op anamnese (bevinding)| met voorkeursterm: *Op basis van de anamnese*
*Definitie* *OmschrijvingBron*: De omschrijving van de wijze waarop de informatie is verkregen, zoals het ontvangen van een brief van een specialist of een gesprek met de patiënt.
Besluit:
ZIB-1350
Basiselementen in zib Overgevoeligheid - OmschrijvingBron
| Aangemaakt op: | 19-01-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Vraag*
Nieuw beleid bij zibcentrum is dat basiselementen expliciet moeten worden uitgewerkt in de zib. Wat betekent dit voor de zib AI?
*Analyse*
*Besluit*: hieronder wordt aangegeven welke basiselementen wel en niet in de zib AllergieIntolerantie worden opgenomen:
* Informatiebron – dit is relevant maar niet in deze vorm. Je wilt hiermee aangeven hoe je aan de gegevens bent gekomen, zodat een goede afweging van de gegevens mogelijk is. In de werkgroep Overgevoeligheid is gekozen om twee dataelementen hier aan te wijden, namelijk *ManierVanVaststellen* en *OmschrijvingBron*. Dit sluit ook aan bij de afsprakenset van de beroepsgroepen.
* Identificatienummer – niet opnemen. Wel in de informatiestandaard opnemen.
* Auteur – Wel opnemen, degene die de overgevoeligheid als overgevoeligheid heeft aangemerkt is relevant voor de interpretatie. De naam van dit dataelement wordt wel gewijzigd in *EersteAuteur* zodat ook bij overnemen in een ander systeem deze informatie behouden blijft.
* RegistratieDatumTijd – Deze wordt opgenomen omdat het moment van vastleggen klinisch relevant is voor medicatiebewaking. Daarnaast brengt deze datum meer nuance in de interpretatie van een overgevoeligheid. De naam van dit dataelement wordt wel gewijzigd in *ToevoegingsDatumTijd* omdat het niet alleen een administratief karakter heeft.
* Onderwerp – niet opnemen. Het betreft hier alleen de patiënt.
*Definitie* *ToevoegingsDatumTijd*: Datum en tijd waarop de overgevoeligheid door de eerste auteur is toegevoegd aan het medisch dossier.
*Definitie* *EersteAuteur*: De zorgverlener die verantwoordelijk is voor toevoeging aan het medisch dossier.
*Definitie* *ManierVanVaststellen*: De manier waarop de overgevoeligheid is vastgesteld.
*Waardelijst ManierVanVaststellen* (+SNOMED-code):
* 144501000146103 |toestand van overgevoeligheid gebaseerd op klinisch beeld (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld*
* 144511000146101 |toestand van overgevoeligheid gebaseerd op klinisch beeld en aanvullend onderzoek (bevinding)| met voorkeursterm: *Vastgesteld op basis van het klinisch beeld en aanvullend onderzoek*
* 144491000146108 |toestand van overgevoeligheid gebaseerd op anamnese (bevinding)| met voorkeursterm: *Op basis van de anamnese*
*Definitie* *OmschrijvingBron*: De omschrijving van de wijze waarop de informatie is verkregen, zoals het ontvangen van een brief van een specialist of een gesprek met de patiënt.
Besluit:
ZIB-1357
zib Juridische situatie (2020)
| Aangemaakt op: | 01-02-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Beste collega's, ik gebruik genoemde zib in de nieuwe dataset voor de geboortezorg. Bij het bespreken van de zib kwam naar voren dat bij de JuridischeStatus het ook voor komt dat er voor een ongeboren baby een voorlopige onder toezichstelling (vots) bestaat. Deze mist in de codelijst voor JuridischeStatus. Het gaat om JuridischeStatusCodelijst (2020-09-01): https://decor.nictiz.nl/art-decor/decor-valuesets--peri20-?id=2.16.840.1.113883.2.4.3.11.60.40.2.7.17.1&effectiveDate=2020-09-01T00:00:00&language=nl-NL
Zie https://www.kinderbescherming.nl/voor-kind-en-ouder/problemen-thuis/welke-maatregelen-van-kinderbescherming-zijn-er
Kan dit meegenomen worden in een nieuwe versie van de zib? Dank.
Groet, Anneke
Besluit:
ZIB-1368
HealthProfessional gender kopie fout in definitie
| Aangemaakt op: | 18-02-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib HealthProfessional heeft het gender concept van Patient net iets te letterlijk gekopieerd. Zie de schermafbeelding voor verduidelijking.
!2021-02-18 10_48_09-HealthProfessional-v3.5(2020EN) - Zorginformatiebouwstenen.png|width=868,height=504!
Besluit:
ZIB-1369
vervangen refset snomed in publicatie 2020
| Aangemaakt op: | 18-02-2021 | Status: | Gepubliceerd |
| Onderdeel van: | Publicatie 2020 | Publicatiedatum: | 14-03-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
42931000146101 vervangen naar de nieuwe 98061000146100 refset
Besluit:
ZIB-1370
Verschillende waardenlijsten voor status in zib-problem en zib-allergyintolerance
| Aangemaakt op: | 23-02-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib-problem en zib-allergyintolerance zijn er status waardenlijsten gekoppeld. In de problem zib is de waardenlijst gebaseerd op SNOMED en van allergyintolerance op [http://hl7.org/fhir/v3/ActStatus.]
Wat is de achterliggende gedachte om voor status twee verschillende codesystemen te gebruiken?
HCIM Problem: https://simplifier.net/nictizstu3-zib2017/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.2--20171231000000
HCIM AllergyIntolerance: [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.0.5/files/307394]
Besluit:
ZIB-1371
typfout in ZIB blauwdruk PatientVragenlijst
| Aangemaakt op: | 23-02-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Op de wiki pagina van de ZIB blauwdruk [PatientVragenlijst|https://zibs.nl/wiki/PatientVragenlijst-v1.0(NL)] staat een klein typfoutje in de tabel [TimingLabel]Codelijst. Bij conceptnaam "21 years' is de omschrijving per abuis "12 jaar oud".
Besluit:
ZIB-1374
Code voor WondWeefsel ontbreekt
| Aangemaakt op: | 26-02-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib Wond (2017) zijn de meeste kenmerken gecodeerd, maar dat is niet het geval voor het concept WondWeefsel. Om een FHIR-profiel te maken, hebben we hier een code voor nodig. Is het mogelijk om hier een code voor te krijgen?
Besluit:
ZIB-1375
Organisatie als Contactpersoon
| Aangemaakt op: | 01-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
Via [~accountid:5b5afdfccee8472cde7b21f3]: - ook als [ART-DECOR Ticket|https://decor.nictiz.nl/art-decor/decor-issues--zib2017bbr-?id=2.16.840.1.113883.2.4.3.11.60.7.6.50&language=nl-NL]
Hoewel dit in de praktijk niet heel veel voor lijkt te komen, liep een van mijn collega's er bij wat testen met onze BgZ uitwisseling tegenaan dat van een instantie die dienst doet als contactpersoon van een patiënt, de naam niet wordt uitgewisseld (maar alleen de adres- en contactgegenves). Uiteraard is dat onwenselijk, maar toen ik mij hier in verdiepte, vond ik wel een verklaring. In het CDA template voor de ZIB contactpersoon (een participant in de header), zit alleen een name-element, binnen een associatedPerson-element (wat volgens mij niet gebruikt zou moeten worden voor instantie, maar echt alleen voor een natuurlijke persoon) en bovendien is hier een profiel voor een persoonsnaam op toegepast.
Is het de bedoeling dat van instanties als contactpersonen geen naam uitgewisseld wordt? Zie ik dit verkeerd en kan het name-element binnen de associatedPerson ook voor de naam van een instantie worden gebruikt? Of is dit wellicht een tekortkoming in het template en zou ook een (andere) constructie moeten zijn toegestaan om (namen van) organisaties als contactpersonen uit te wisselen? Of is dit misschien geen CDA specifiek probleem en is de ZIB contactpersoon (nog) niet geschikt voor instanties die als contactpersonen van patiënten fungeren en kan ik het feit dat dit i.i.g. in HiX wel geregistreerd kan worden, beter eens bij het ZIB-centrum ter sprake brengen?
Mijn antwoord:
Wat is een contactpersoon in deze? Is dat een wettelijk vertegenwoordigende instantie via Patient Guardian of is dat een losse Participant?
Bij Guardian wordt inderdaad alleen van personen gerept (guardianPerson) waar ook best ruimte is voor organisaties (guardianOrganization).
Guardian is aanpasbaar. De zib Contactpersoon echter lijkt niet erg voorbereid op organisaties, dus we doen dan wel iets buiten de zib 2017 en 2020:
https://zibs.nl/wiki/Contactpersoon-v3.1(2017NL)
https://zibs.nl/wiki/Contactpersoon-v3.4(2020NL)
_Een contactpersoon is een persoon anders dan zorgverleners, die betrokken zijn bij de zorg voor de patiënt, zoals familieleden, mantelzorgers, geestelijke verzorgers, voogden en wettelijkelijk vertegenwoordigers._
*Vraag aan het zibcentrum is dan ook*: is Contactpersoon ook bedoeld geweest voor voogdijorganisaties en andere situaties waarbij een organisatie contactpersoon is?
Noot: CDA _Guardian_ heeft een voogdij-component aan zich en is dus meer dan een willekeurige contactpersoon. Willekeurige contactpersonen zouden in CDA als losse Header Participants opgevoerd moeten worden.
Besluit:
ZIB-1377
enkele typos in SNAQ65+
| Aangemaakt op: | 01-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hieraan toegevoegd wil ik 2 kleine typos doorgeven op de SNAQ65+ pagina.
1) The SNAQ was developed foe adults admitted to hospital => foe moet fore zijn
2) de partialScores comment in het information model refereert naar 3 partial scores, waneer er 4 zijn.
Besluit:
ZIB-1378
RolCodelijst heeft numerieke codes (1,2,3,..) in plaats van strings (01,02,03,...)
| Aangemaakt op: | 03-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://www.vektis.nl/standaardisatie/codelijsten/COD821-VEKT] zegt dat de codes 01,02,03,04,05,06 etcetera zijn.
De [zibs Contactpersoon|https://zibs.nl/wiki/Contactpersoon-v3.4(2020NL)#RolCodelijst] uit 2015-2020 zeggen allemaal dat de codes 1,2,3,4,5,6 etcetera zijn.
In ART-DECOR stond al die jaren ook al een losse representatie van het codesysteem COD821-VEK met de juiste codes uit dit codesysteem. Als je op dit moment aan de Terminologieserver.nl (waar de officiële versie van het codesysteem ook staat) vraagt om de expansion van de waardelijst RoleCodelijst dan krijg je dus de 01,02,03 etc. wat afwijkt van wat op zibs.nl staat.
CC: [~accountid:5e2596d5c55f580c9fc8fb95] - Zie RolCodelijst -
[http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.2]–20200901000000
Waarom heeft de zib andere codes dan de Vektis bron en wat gaan we hier aanpassen? Het kan in elk geval niet zo blijven.
Besluit:
ZIB-1379
zib JuridischeSituatie; codering van concept "Vertegenwoordiging"
| Aangemaakt op: | 03-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib JuridischeSituatie zijn er twee concepten waaruit gekozen kan worden: JuridischeStatus en Vertegenwoordiging. De eerste is gecodeerd met SNOMED 303186005, voor de tweede is geen code beschikbaar.
Voor het maken van een FHIR-profiel zouden beide concepten gecodeerd moeten worden. Is er ook een code beschikbaar voor het concept Vertegenwoordiging? Of is SNOMED 303186005 geschikt voor beide concepten?
Besluit:
ZIB-1380
Aanpassing omschrijving codetabel
| Aangemaakt op: | 04-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De codetabel zelf (screenshot) staat nog tabel 25 in. Dit moet aangepast worden.
Besluit:
ZIB-1384
Codesysteem OID range moet gewijzigd worden
| Aangemaakt op: | 11-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de TNMTumorClassificatie-v1.0(2020NL) zib zitten nu 7 OIDS opgenomen onder V_VeneuzeInvasieCodelijst en Pn_PerineuraleInvasieCodelijst welke gewijzigd moeten worden:
De range moet naar 60.40.4.** ipv van de huidige 60.40.5.**
Besluit:
ZIB-1394
Codelijst ProbleemType in zib Probleem
| Aangemaakt op: | 31-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij de review van gebruikte terminologie in de nieuwe dataset (waarin zibs worden gebruikt) is feedback gegeven op genoemde waardelijst.
'deze waardelijst bevat een observable entity; diagnosis en functional limitation zijn onjuist gekoppeld. Zijn 64572001 |aandoening (aandoening)| voor diagnose en 21134002 |beperking (bevinding)| voor beperking misschien goede vervangers?'
Former user kun je dit met zib centrum opnemen?
Besluit:
ZIB-1398
Voorbeeld van UitkomstVanZorg bevat nog Algemene Meting
| Aangemaakt op: | 31-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In het voorbeeld van [UitkomstVanZorg |https://zibs.nl/wiki/UitkomstVanZorg-v3.2(2020NL)]staat nog een voorbeeld van de vervallen zib AlgemeneMeting.
Besluit:
ZIB-1401
Voorbeeld incorrect bij MedicatieContraIndicatie
| Aangemaakt op: | 02-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het zwangerschaps voorbeeld bij MedicatieContrraIndicatie is niet correct. Het heeft een eerdere EindDatum dan de BeginDatum. Volgens mij zou de EindDatum 18-03-2021 moeten zijn ipv 18-03-2020
https://zibs.nl/wiki/MedicationContraIndication-v1.0(2020EN)
Besluit:
ZIB-1403
Terminologie code ontbreekt voor het element SoortTabakGebruik
| Aangemaakt op: | 08-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Voor het element *SoortTabakGebruik* is er geen terminologie code beschikbaar. In FHIR versie STU3 werd er gebruikt gemaakt van SNOMED code 53661000146106. Echter is deze code niet terug te vinden in de zib.
Welke SNOMED code moeten we toepassen voor het element *SoortTabakGebruik*?
Besluit:
ZIB-1404
DASMethodeCodelijst verwisselt termen
| Aangemaakt op: | 08-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de [DASMethodeCodelijst|https://zibs.nl/wiki/DAS-v1.0(2020NL)#DASMethodeCodelijst] lijken SNOMED CT concepten [117691000146105|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=117691000146105] en [117691000146108|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=117691000146108] niet juist in de zib te zitten.
De omschrijvingen in de laatste kolom (en dus ook in ART-DECOR) zijn van plek gewisseld.
!image-2021-04-08-23-12-33-669.png!
Besluit:
ZIB-1408
Apgarscore: onderliggende observaties
| Aangemaakt op: | 12-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Beste collega's, ik gebruik de genoemde zib in de dataset voor de geboortezorg. Echter, op niveau van de zib en de dataset worden de afzonderlijke waarden in de codelijsten (voor de afzonderlijke observaties, zoals Ademhaling, Huidskleur etc) in het Engels weergegeven (concepten en codes uit LOINC). Door het gebruik van de functionaliteit 'concepten' heb ik de NL termen opgenomen uit de codelijsten. Deze zijn in de codelijsten opgenomen in kolom benamingen en zijn voorkeurstermen. Op deze manier is op het niveau van de dataset de NL term te zien voor zorgverleners.
Echter, in de voorbeelden bij de codelijsten worden NL termen gebruikt die niet overeenkomen met de voorkeursterm in de codelijst. Ik heb deze zelf nu aangepast in de dataset, maar dit zou moeten op niveau van de zib.
Kunnen jullie hier naar kijken? Dank
Anneke
Besluit:
ZIB-1409
In de excel van woonsituatie staat een verkeerde constraint
| Aangemaakt op: | 13-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de excels van zibs woonsituatie is er een constraint opgenomen van een deprecated term (AWBZ instelling).
dit moet gewijzigd worden. Indien het meerdere zibs betreft zal dit ook daar gewijzigd moeten worden
Besluit:
ZIB-1411
Verkeerde Engelse vertaling voor MaximaleDosering
| Aangemaakt op: | 20-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib vertaald
|MaximaleDosering|0..1|Een maximale dosering maximaliseert (in tijd) het gebruik van een middel in een 'zo nodig' voorschrift.|
naar
|MaximumDose|0..1|A maximum dose indicates the maximum duration a product can be used with an ‘as needed’ prescription.|
De Engelse vertaling lijkt hier iets wat fout te staan aangezien het nu stelt dat de de MaximumDose de max duur/tijd vassteld.
Besluit:
ZIB-1412
zib Visus - code 'Anders, specificeer'
| Aangemaakt op: | 21-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Hallo!
In de nieuwe zib Visus komt in diverse codelijsten de code 'OTH' voor die af en toe de conceptnaam 'Other, specify' en de vertaling 'Anders, specificeer' heeft. Er is volgens mij geen concept aanwezig om daadwerkelijk iets in vrije tekst te kunnen specifieren. Dient hier niet een extra element voor te zijn?
Besluit:
ZIB-1418
Terminologiekoppeling SOAPReport
| Aangemaakt op: | 28-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Omdat er in FHIR niet direct een vergelijkbare model is voor SOAPReport hebben we een terminologie code nodig om een algemener model te definieren. Bestaat er een terminologiekoppeling voor deze zib?
Voor een eerder soort gelijk profiel maakte wij gebruik van LOINC code 67781-5.
Besluit:
ZIB-1420
zib Refractie definition code SfericalEquivalent
| Aangemaakt op: | 29-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Goedemiddag!
Tijdens het mappen van de zib Refractie loop ik tegen de volgende punten aan (gebundeld in 1 ticket als vraag, maar als ik het beter kan splitsen hoor ik het graag).
# Voor het concept SfericalEquivalent mist een DefinitionCode die wij nodig gaan hebben om het concept te mappen. Zou die toegevoegd kunnen worden?
Besluit:
ZIB-1421
Zib Refractie vertaling
| Aangemaakt op: | 29-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Goedemiddag!
Tijdens het mappen van de zib Refractie loop ik tegen de volgende punten aan (gebundeld in 1 ticket als vraag, maar als ik het beter kan splitsen hoor ik het graag).
# Er lijkt in het vertalen van de conceptnamen naar Engels een en ander misgegaan te zijn. Binnen container CilindricalRefraction wordt 'Cilindrisch' zowel met 'Cilindric(al)' als 'Cylindrical' vertaald (volgens mij dient dit met 'y' vertaald te worden). Daarnaast wordt 'Prisma' met 'Prisma' vertaald (ik zou 'prism' verwachten) en 'Sferisch' met 'Sferic'/'Sferical' (ik zou 'spheric'/'spherical' verwachten).
Besluit:
ZIB-1422
Veld TestUitslag in LaboratoriumUitslag
| Aangemaakt op: | 30-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Ik ging vragen om een refset hier toe te voegen, nl. 145871000146106 |simpele referentieset met typen mengflora (metadata)|. Maar nu zie ik dat er nog geen enkele waardenlijst bij het veld staat. Mogelijk vanwege deze zin:
"Afhankelijk van de soort test bestaat de uitslag uit een waarde met eenheid of uit een gecodeerde waarde (ordinaal of nominaal)."
Toch zou je denk ik wel iets concreter kunnen zijn. Een waarde met eenheid is een numerieke waarde met UCUM-eenheid; een gecodeerde waarde zou altijd uit SNOMED moeten komen. Het opsommen van alle uitslagenlijsten zal lastig bij te houden zijn en raad ik daarom bij nader inzien af. Maar is het mogelijk om bij dit veld aan te geven dat ofwel een UCUM-eenheid + waarde, ofwel een SNOMED-concept verwacht wordt?
Besluit:
ZIB-1425
zib Patientbespreking Wikitabelrijvolgorde
| Aangemaakt op: | 30-04-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoi!
Op de NL en EN pagina's van de zib Patientbespreking staan de rijen na de container Beleid in een vreemde (volgens mij verkeerde) volgorde:
|!https://zibs.nl/images/thumb/a/a4/Folder.png/16px-Folder.png|width=16,height=16!|NL-CM:15.2.10| |!https://zibs.nl/images/thumb/c/c4/Arrowdown.png/10px-Arrowdown.png|width=10,height=10! Beleid|0..1|Container van het concept Beleid. Deze container bevat alle gegevenselementen van het concept Beleid.|
|[423134005|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=423134005] Gedeelte betreffende behandelplan in status|
| |
|!https://zibs.nl/images/f/fe/Verwijzing.png|width=20,height=20!|NL-CM:15.2.12| | |!https://zibs.nl/images/thumb/0/0b/Arrowright.png/10px-Arrowright.png|width=10,height=11! VoorgesteldeBehandeling::Verrichting|0..*|Voorgestelde behandeling.| |
|[!https://zibs.nl/images/4/48/Block.png|width=22,height=22!|https://zibs.nl/wiki/Verrichting-v5.2(2020NL)]|[Verrichting|https://zibs.nl/wiki/Verrichting-v5.2(2020NL)]|
|
|!https://zibs.nl/images/f/fe/Verwijzing.png|width=20,height=20!|NL-CM:15.2.7| |!https://zibs.nl/images/thumb/0/0b/Arrowright.png/10px-Arrowright.png|width=10,height=11! Aandoening::Probleem|0..1|De aandoening of probleem van de patietn dat aanleiding is voor de bespreking.|
|[71388002|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=71388002] Verrichting|
|
|[!https://zibs.nl/images/4/48/Block.png|width=22,height=22!|https://zibs.nl/wiki/Probleem-v4.4(2020NL)]|[Probleem|https://zibs.nl/wiki/Probleem-v4.4(2020NL)]|
|
|!https://zibs.nl/images/thumb/7/79/CD.png/16px-CD.png|width=16,height=16!|NL-CM:15.2.11| | |!https://zibs.nl/images/thumb/0/0b/Arrowright.png/10px-Arrowright.png|width=10,height=11! IntentieBehandeling|0..1|Bedoeling of intentie van de voorgestelde behandeling. bijvoorbeeld conform de richtlijn of het protocol, curatief, palliatief, trial etc.|
|[395077000|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=395077000] Treatment intent|
|
|[!https://zibs.nl/images/4/4e/List2.png|width=17,height=20!|https://zibs.nl/wiki/Patientbespreking-v1.0(2020NL)#IntentieBehandelingCodelijst]|[IntentieBehandelingCodelijst|https://zibs.nl/wiki/Patientbespreking-v1.0(2020NL)#IntentieBehandelingCodelijst]| |
|
Uit de Information Model concludeer ik dat IntentieBehandeling ook onder Beleid zou moeten vallen.
Besluit:
ZIB-1426
locatie primaire tumor ontbreekt in TNMTumorClassificatie
| Aangemaakt op: | 03-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib TNMTumorClassificatie is het niet mogelijk om de lokalisatie van de primaire tumor aan te geven. Het is alleen mogelijk om per afwijking een lokalisatie vast te leggen. Maar je kunt niet weten welke afwijking qua lokalisatie correspondeert met het begrip primaire tumor.
Verzoek is om ook aan de container "PrimaireTumor" een gegevenselement PrimaireTumorLokalisatie::AnatomischeLocatie toe te kennen.
Besluit:
ZIB-1428
"Contact" is niet consistent vertaald naar "Encounter"
| Aangemaakt op: | 05-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De zib Contact heet in het Engels "Encounter". In de Engelse beschrijving van de zib wordt er echter consistent gesproken over "contacts" ipv. "encounters". Dit leidt tot veel verwarring; "contact" in het Engels is eerder een contactpersoon dan een contactmoment; binnen de Engelstalige FHIR-profielen wordt de term "contact" ook voor dat doel gebruikt. Daarnaast refereert de beschrijving zo niet naar de zib. Voorstel is dan ook om het in de tekstuele beschrijving van de zib over "encounters" te hebben.
Besluit:
ZIB-1430
Vertaalfoutje in beschrijving zib AnatomicalLocation
| Aangemaakt op: | 06-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de Engelse beschrijving van zib AnatomicalLocation staat:
{quote}An anatomical location specifies the location (e.g. foot) and laterality (e.g. links) of a bodypart.
{quote}
De vertaling van "links" is hier vergeten.
Besluit:
ZIB-1433
Problem on multiple AnatomicalLocations
| Aangemaakt op: | 11-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Beste,
Binnen Problem is er een referentie naar AnatomicalLocation met cardinaliteit 0..1. Als het echter gaat om een infectie waarvoor men wil specifiëren welke body structures geïnfecteerd zijn (vb. intervertebral discs, epidural space, paravertebral region ...) , is het dan niet mogelijk om meerdere instantiaties van de AnatomicalLocation te hebben voor ProblemName= infection? Of adviseren jullie een andere aanpak?
Besluit:
ZIB-1436
Conceptnamen corrigeren in EmailSoortCodelijst, NummerSoortCodelijst en TelecomTypeCodelijst
| Aangemaakt op: | 14-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Nav. ZIB-1399 dat enkele conceptnamen in de waardelijsten van zib ConcactGegevens niet overeen komen met de waarden uit het codestelsel. In eerste instantie gaat het om _MC_ uit codestelsel {{http://terminology.hl7.org/CodeSystem/v3-AddressUse}} in TelecomTypeCodelijst. Dit staat in de zib gedefinieerd als "Mobile Phone", maar zou volgens het codestelsel "mobile contact)" (sic) moeten zijn.
Daarnaast staan alle conceptnamen met hoofdletters geschreven, terwijl ze in de codestelsels met kleine letters geschreven worden. Je kan erover twisten of het hier problematisch is, maar hoofdlettergebruik _kan_ in andere situaties significant zijn. Daarom zou het logisch zijn om hier niet vanaf te wijken tenzij expliciet door de opstellers van het codesysteem is aangegeven dat dit kan.
Besluit:
ZIB-1438
RelatieCodelijst
| Aangemaakt op: | 04-03-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Goedemorgen,
In de RelatieCodelijst worden de waardes 'Zuster' en 'Schoonzuster' gebruikt. Dit is volgens ons redelijk ouderwetse spelling. Is het mogelijk om hier 'Zus' en 'Schoonzus' van te maken?
Bij de waardes 'Neef, zoon van broer/zus' en 'Nicht, dochter van broer/zus' wordt ook de waarde zus in plaats van zuster gebruikt.
De wijziging zorgt dus ook voor consequent gebruik van dezelfde naam.
VIPP-team Spaarne Gasthuis
Besluit:
ZIB-1440
Omschrijving BeginDatum verbeteren, +bijkomende verbeteringen elementen
| Aangemaakt op: | 18-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2024-1 | Publicatiedatum: | 25-04-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Nav. ZIB-1413 blijkt de omschrijving van het BeginDatum-concept in zib MedicatieContraIndicatie niet geheel toereikend.
De huidige omschrijving is:
{quote} De datum en eventueel tijd waarop de contra-indicatie voor medicatiebewaking is vastgesteld.
{quote}
Deze formulering is gekozen omdat de bewaking voor bestaande contra-indicaties pas kan starten als de contra-identificatie geïdentificeerd is. Het houdt echter geen rekening met mogelijke contra-indicaties in de toekomst.
Daarnaast is de Engelse vertaling niet volledig:
{quote}The date and possibly time when the contra-indication for medication was identified
{quote}
"medication" zou hier aangevuld moeten worden tot "medication safety monitoring".
Besluit:
ZIB-1441
zib Visus definitiecode AfstandTotKaart
| Aangemaakt op: | 19-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoi!
Voor het mappen van de zib Visus op FHIR hebben we een SNOMED-code nodig voor AfstandTotKaart. Is het mogelijk deze te krijgen? Alvast bedankt
Groet,
Jorn Duwel
Besluit:
ZIB-1442
zib Visus AnatomischeLocatie en Lateraliteit
| Aangemaakt op: | 20-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoi!
In de zib Visus wordt verwezen naar AnatomischeLocatie, uit de definitie blijkt dat het specifiek zou moeten gaan om AnatomischeLocatie::Lateraliteit.
Het lijkt ons dat uit de zib-Visus danwel specifiek naar AnatomischeLocatie::Lateraliteit moet verwijzen, danwel duidelijk moet maken dat AnatomischeLocatie::Locatie in dit geval naar het oog zou moeten verwijzen. In het laatste geval ontvangen wij graag de code die we hiervoor zouden kunnen gebruiken.
Groet,
Jorn
Besluit:
ZIB-1443
zib Refractie twee concepten met dezelfde definitiecode
| Aangemaakt op: | 20-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Binnen de zib Refractie hebben zowel Refractie als geheel als het concept LeesAdditie dezelfde SNOMED code 251718005 meegekregen. Hiermee kunnen wij het onderscheid tussen deze concepten niet maken. Kunnen er onderscheidende codes aangebracht worden?
Besluit:
ZIB-1444
Procedure.ProcedureMethod description nog in verleden tijd geschreven
| Aangemaakt op: | 25-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De Procedure.ProcedureMethod description is nog geheel in het verleden geschreven, terwijl de zib ook gebruikt kan worden voor toekomstige of geadviseerde procedures.
Besluit:
ZIB-1445
zib Visus zelfde DefinitieCode voor verschillende concepten
| Aangemaakt op: | 26-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoi!
De zib Visus [https://zibs.nl/wiki/Visus-v1.0(2020NL)] geeft voor zowel VisusMetingType als DecimaleVisusWaarde dezelfde definitiecode ([363983007|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=363983007]). Hierdoor kunnen wij deze twee concepten technisch niet onderscheiden van elkaar. Het lijkt ons dat VisusMetingType een andere code zou moeten krijgen (andere metingen volgend waar de daadwerkelijke meetwaarde de meer algemene code heeft gekregen), maar dat is natuurlijk aan jullie.
Groet, Jorn
Besluit:
ZIB-1447
Referentie naar Zorgaanbieder ontbreekt in zib Vaccinatie
| Aangemaakt op: | 27-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 09-11-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib Vaccinatie (ik refereer hier naar zowel publicatie 2017 als 2020) staat bij concept NL-CM:11.1.6 een verwijzing naar de zib Zorgverlener.
Echter, de definitie vermeldt:
De zorgverlener en/of *organisatie* waar of door wie de immunisatie werd of zal worden uitgevoerd.
Gezien hier ook organisatie genoemd is, zou ik naast de verwijzing naar Zorgverlener ook een verwijzing naar Zorgaanbieder verwachten.
Besluit:
ZIB-1449
zib Refractie diopter-eenheid (en UCUM-eenheden algemeen)
| Aangemaakt op: | 31-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoi!
Bij het uitwerken van zib Refractie lopen we tegen het volgende aan:
PQ heeft een UCUM-unit, maar er staat eigenlijk alleen in de definitie-tekst weergegeven wat deze unit zou moeten zijn. Is er geen eenduidigere manier om dit weer te geven?
Concreet toegepast op zib Refractie: er zijn in UCUM twee typen diopters: '[diop]' (diopter) en '[p'diop]' (prims diopter). Kunnen jullie aangeven welke eenheid bij welk concept hoort?
In jullie datatype referentie ([https://zibs.nl/wiki/Beschrijving_en_gebruik_datatypes] ) staat overigens als het op UCUM aankomt overigens alleen een link die niet (meer) werkt.
Besluit:
ZIB-1452
Duplicate tekst in zib concept omschrijving en definitie op de root
| Aangemaakt op: | 31-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/PharmaceuticalProduct-v2.1.2(2020EN)] heeft zo goed als dezelfde tekst in de concept omschrijving als in de definitie op de root (NL-CM:9.7.19926).
Dat lijkt me niet handig omdat je zou de kans krijgt dat dit uit de pas gaat lopen. Wat ook het geval is: de concept omschrijving heeft het over "Magistral prescriptions" terwijl de root definitie het heeft over 'Prescriptions to be prepared by the pharmacy'.
Besluit:
ZIB-1453
PharmaceuticalProduct IngredientCodeSSKCodelist 'Extensible' binding
| Aangemaakt op: | 31-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Hoe moet de 'Extensible' binding van IngredientCodeSSKCodelist binnen worden geinterpereerd in PharmaceuticalProduct? Het is de enige waardelijst bij SubstanceCode die niet Required is maar Extensible.
Als alles Required is kan dit nog gemakkelijk vertaald worden naar gebruik één van deze waardenlijsten. Door deze mix wordt nu in feite alle binding strengths op extensible gezet.
Of is dit toevallig een foutje?
Besluit:
ZIB-1454
Onduidelijkheid codes bij StopType codelijsten
| Aangemaakt op: | 31-05-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Het gebruik van terminologie bij de StopType codelijsten is mij niet helemaal duidelijk en wijkt van elkaar af terwijl het in de MP dataset allemaal één codelijst betreft.
Verder is het mij nu vanuit de zib wiki niet duidelijk welke codes er gelden. Bij de zwarte gekleurde staat alleen in de Description dat het om een DEPRECATED code gaat. Terwijl de andere code (degene die voglens mij wel geldig zijn) de Conceptname in het rood staat én als je de link volgt ([https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=112171000146100]) staat daar dat de code deprecated is.
* MedicationUseStopTypeCodeList - [https://zibs.nl/wiki/MedicationUse2-v1.1.1(2020EN)#MedicationUseStopTypeCodeList]
* MedicationAgreementStopTypeCodeList - [https://zibs.nl/wiki/MedicationAgreement-v1.2(2020EN)#MedicationAgreementStopTypeCodeList]
wijkt af van:
* AdministrationAgreementStopTypeCodeList - [https://zibs.nl/wiki/AdministrationAgreement-v1.0.3(2020EN)#AdministrationAgreementStopTypeCodeList]
Besluit:
ZIB-1457
Verwijderen woord 'voorlopig'
| Aangemaakt op: | 07-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://nictiz.atlassian.net/browse/MP-202|https://nictiz.atlassian.net/browse/MP-202]
Een aantal G-standaard thesauri hadden in de omschrijving het woord 'voorlopig', maar deze zijn inmiddels definitief opgenomen in de G-standaard. Het woord 'voorlopig' kan daarom worden verwijderd uit voor deze codesystemen. Dit speelt bij de elementen aanvullende informatie (MA, TA, MVE) en aanvullende wensen (VV).
Besluit:
ZIB-1458
Verwijderen sectie 'Instructions' bij MedicationAgreement
| Aangemaakt op: | 07-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*MedicationAgreementAdditionalInformation* heeft een instructions paragraaf ([https://zibs.nl/wiki/MedicationAgreement-v1.2(2020EN)#Instructions]). 'AdditionalInforamtion' concepten in andere medicatie bouwstenen bevatten dit niet.
Het is niet duidelijk waarom deze informatie in de instructions paragraaf terrecht is gekomen. Daarnaast lijkt de tekst in tegenspraak te zijn met de codelijst van het betreffende concept omdat dat voorbeeld met omeprazol/pantoprazol daar niet in past.
Als er extra informatie nodig is lijkt het logischer om dit in de definitie van het concept te plaatsten.
Besluit:
ZIB-1460
Zib TijdsInterval concept omschrijving niet correct
| Aangemaakt op: | 09-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
De concept omschrijving van TijdsInterval-v1.0(2020NL) is niet correct. Het stelt namelijk dat je de keuze hebt uit:
# Start + Eind
# Start + Duur
# Eind + Duur
Het moet echter mogelijk zijn om een Duur te geven zonder Start of Eind. Zeker in de gevallen van de medicatie zibs die deze zib gebruiken, bijv. bij MedicationAgreement.PeriodOfUse. Te denken aan een malaria kuur gedurende x dagen vanaf een nog onbekende startdatum (twee dagen voor betreden malaria gebied).
Overigens kunnen in de opties 2 en 3 ook de ontbrekende concepten worden berekend om de gehele zib compleet te geven.
Besluit:
ZIB-1462
Concept naam PeriodOfUse geen goede vertaling in zib Verstrekkingsverzoek
| Aangemaakt op: | 10-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
De vertaling van Verbruiksperiode, PeriodOfUse, binnen de zib Verstrekkingsverzoek is geen goede vertaling en zelfs verwarrend omdat deze lijkt op 'gebruiksperiode' en dat is het absoluut niet en daar mag het niet mee verward worden.
Een mogelijk betere vertaling voor verbruiksperiode in verstrekkingsverzoek zou zijn: 'ValidityPeriod'.
Bij verstrekking spreken zorgverleners het liefst over 'voorraad tot'
Besluit:
ZIB-1465
Meldingen terminology report bij overlijdensIndicator en BronMonster
| Aangemaakt op: | 16-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij het draaien van het terminology report voor de release van MP, kwamen twee meldingen die betrekking hebben op de terminologiekoppeling bij elementen die geërfd zijn vanuit de zibs (zie afbeelding).
Besluit:
ZIB-1468
AdministrationAgreement.supplier verkeerde vertaling
| Aangemaakt op: | 17-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[https://zibs.nl/wiki/AdministrationAgreement-v1.0.3(2020EN)] heeft een verkeerde vertaling in het Supplier::HealthProfessional concept. Er staat nu namelijk HealthProfessional, dit zou HealthcareProvider moeten zijn.
In de NL versie staat het wel goed.
Besluit:
ZIB-1470
Codering voor Mantelzorger
| Aangemaakt op: | 17-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Zoals aangestipt in ZIB-629 hebben we in overleg met TC (Former user een SNOMED codering voor mantelzorger toegekend.
Echter in [zib-2020 Contactpersoon rolcodelijst|https://zibs.nl/wiki/Contactpersoon-v3.4(2020NL)#RolCodelijst] zie ik een lokale codering voor mantelzorger?
Besluit:
ZIB-1471
CLONE: Nederlandse vertaling van een element in de Engelse versie van CareTeam
| Aangemaakt op: | 18-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de Engelse vertaling van de Wikipedia pagina bevat een element nog een Nederlandse vertaling.
CareTeamNaam -> CareTeamName
[https://zibs.nl/wiki/CareTeam-v1.0(2020EN)]
Besluit:
ZIB-1473
SOEP is SOAP in het Engels: vertaling klopt niet
| Aangemaakt op: | 18-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In het Engels, zoals ook in de zib omschrijving te lezen is, wordt voor SOEP gebruikt: *S*ubjective, *O*bjective, *A*ssessment, *P*lan. Dit wordt ook normalerwijs afgekort naar *SOAP* en niet SOUP.
In de Concept-paragraaf staat het in zin 2 ook nogmaals foutief als "evaluation" in plaats van "assessment"
{quote}A SOUP report is a textual report of (part of the consult) according to the SOUP structure. SOUP (acronym for subjective, objective, -*evaluation*-, plan) is a method used by health professionals to structurally record information that comes up during contact between the patient and a health professionals in the patient's record.The following standardized format is used for reporting:
{quote}
Bron: https://en.wikipedia.org/wiki/SOAP_note, https://www.soapcr.com/, http://www.mtinformation.com/medical-reports/soap-note-samples
Besluit:
ZIB-1474
SOEPVerslag = Contactverslag of Deelcontactverslag
| Aangemaakt op: | 18-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
[SOEPVerslag release 2020|https://zibs.nl/wiki/SOEPVerslag-v1.0(2020NL)] heeft momenteel geen relatie met het contact waarin deze is gemaakt en ook geen relatie met een episode die meer zou kunnen vertellen over de context. Verder is nergens een begrenzing op hoeveel S-O-E-P regels in het verslag kunnen staan.
Je kunt bij de huisarts komen met meerdere ingangsklachten. Vanwege episodegericht registreren worden de journaalregels die bij een episode horen verbonden met die episode.
Zo ontstaan onder 1 contact/consult mogelijk meerdere 'bundeltjes' met journaalregels. Deze hebben de naam "deelcontactverslag" gekregen. Het huidige MedMij alsmede het huidige Ketenzorg implementeren ieder SOEPVerslag als een "Deelcontactverslag" waarbij onder 1 contact dus meerdere SOEPVerslagen kunnen bestaan.
Uit de zib is mij niet duidelijk of dat hier ook de bedoeling is. Door geen koppeling met contact of episode te ondersteunen kun je er alle kanten mee op en dus dienen we hier de interoperabiliteit niet mee.
Kan de zib expliciet worden over hoe deze te gebruiken en dan bij voorkeur zoals de staande praktijk is in Ketenzorg, MedMij en zelfs Professionele Samenvatting?
cc: [~accountid:999854:be83f482-e02b-44c7-81ee-7e8c52a21f48]
Besluit:
ZIB-1475
TNM-zib: Verkleinen toegestane zet voor Regionale Lymfeklieren
| Aangemaakt op: | 21-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de TNMTumorClassificatie zib wordt de bouwsteen "AnatomischeLocatie" gebruikt voor o.a. de lokalisatie van de regionale lymfelieren. Hier zijn nu alle locaties toegestaan, ook niet-lymfkelieren. Zouden we de toegestane selectie kunnen verkleinen naar
* SCT: < 59441001 | Structuur van lymfeklier |
* ICD-O-3: C77 en alles wat daaronder valt?
Per Classificatie zijn er uiteraard slechts een paar lymfeklieren die als regionaal beschouwd worden. Op deze manier kunnen er in elk geval voorkomen dat geen niet-lymfeklieren in deze velden meegegeven worden.
Besluit:
ZIB-1476
DefinitionCode voor ExtraOxygenAdministration
| Aangemaakt op: | 22-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Om een FHIR-profiel te maken van zib O2Saturation hebben we een DefinitionCode nodig voor het concept ExtraOxygenAdministration. In 2017-versie hebben we daarvoor LOINC 74206-4 gekregen. Kunnen we deze code opnieuw gebruiken voor de (ongewijzigde) 2020-versie?
Besluit:
ZIB-1477
Nanda status deprecated in zib Probleem
| Aangemaakt op: | 23-06-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Graag in de zib Probleem onderdeel probleem naam codelijst NANDA op de status Deprecated zetten
Besluit:
ZIB-1480
juridische situatie; toevoeging waardenlijst vertegenwoordiging
| Aangemaakt op: | 05-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
*Request For Change inzake registratie wettelijke vertegenwoordiging*
Via deze weg vragen wij graag een uitbreiding aan van de *zib juridische situatie* en de onderliggende codelijsten “Juridische vertegenwoordiging”
* Toevoegen van “Volmacht zorg & behandeling”
* Toevoegen van “Vertegenwoordiging op basis van relatie”
_Achtergrond:_
SDB Groep is, in het kader van het project InZicht, volop bezig om wijzigingen in haar ECD door te voeren ten bate van een nog meer gestructureerde gegevensopslag en daaruit voortvloeiende de mogelijkheid om bij te dragen aan betere informatie-uitwisseling in de langdurige zorg. Dit alles gebaseerd op Zorginformatiebouwstenen (ZIB’s) en HL7 FHIR.
_Aanleiding_
In dit kader is besloten om bij de registratie van juridische status in SDB ECD doch ook bij het vastleggen van rollen en relatie van een contactpersoon t.o.v. de cliënt/patiënt exclusief gebruik te maken van de codelijsten zoals in de ZIB’s benoemd (ZIB “Juridische situatie” resp. “Contactpersoon”).
Onze klanten (zorgaanbieders Care sector) registreren van een cliënt/patiënt van welke wettelijke vertegenwoordiging er sprake is en wie een bepaalde rol in dat kader op zich neemt.
Uitgaande van de codelijst “Juridische vertegenwoordiging” (ZIB “Juridische situatie”) en de codelijst “Rol” (ZIB “Contactpersoon”) worden ze daar echter geconfronteerd met 2 beperkingen:
* Het niet kunnen registreren van een volmacht dan wel gevolmachtigde
* Het niet kunnen registreren van een vertegenwoordiging op basis van relatie dan wel vertegenwoordiger op basis van relatie
Wettelijk gezien is het zo dat er 3 vormen van wettelijke vertegenwoordiging zijn:
# Door een extern iemand (bijv. mentor, curator, bewindvoerder)
# Door een gevolgmachtigde
# Door een vertegenwoordiger op basis van relatie (partner, kinderen, …)
De laatste 2 vormen van wettelijke vertegenwoordiging worden dus in de betreffende codelijsten gemist.
Hiermee bereiken we dat:
* Zorgaanbieders completere registratie kunnen doen van de wettelijke vertegenwoordiging.
* Zorgaanbieders deze informatie eenduidig (eenheid van taal) kunnen uitwisselen met cliënt (of diens vertegenwoordiger) via bijvoorbeeld een Persoonlijke Gezondheidsomgeving (PGO).
* Zorgaanbieders deze informatie eenduidig (eenheid van taal) met andere zorgprofessionals (bijv. Cure) kunnen uitwisselen.
Besluit:
ZIB-1481
contactpersoon; uitbreiding waardenlijst onder rol
| Aangemaakt op: | 05-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
Via deze weg vragen wij graag een uitbreiding aan van de *zib contactpersoon* en de onderliggende waardenlijsten bij "rol'
* Toevoegen van "Gevolmachtigde zorg & behandeling"
* Toevoegen van "Vertegenwoordiger op basis van relatie"
Dit wijzigingsverzoek hangt samen met wijzigingsverzoek 'juridische situatie, toevoegen waarden onder codelijst wettelijke vertegenwoordiging.
_Achtergrond:_
SDB Groep is, in het kader van het project InZicht, volop bezig om wijzigingen in haar ECD door te voeren ten bate van een nog meer gestructureerde gegevensopslag en daaruit voortvloeiende de mogelijkheid om bij te dragen aan betere informatie-uitwisseling in de langdurige zorg. Dit alles gebaseerd op Zorginformatiebouwstenen (ZIB's) en HL7 FHIR.
_Aanleiding_
In dit kader is besloten om bij de registratie van juridische status in SDB ECD doch ook bij het vastleggen van rollen en relatie van een contactpersoon t.o.v. de cliënt/patiënt exclusief gebruik te maken van de codelijsten zoals in de ZIB's benoemd (ZIB "Juridische situatie" resp. "Contactpersoon").
Onze klanten (zorgaanbieders Care sector) registreren van een cliënt/patiënt van welke wettelijke vertegenwoordiging er sprake is en wie een bepaalde rol in dat kader op zich neemt.
Uitgaande van de codelijst "Juridische vertegenwoordiging" (ZIB "Juridische situatie") en de codelijst "Rol" (ZIB "Contactpersoon") worden ze daar echter geconfronteerd met 2 beperkingen:
* Het niet kunnen registreren van een volmacht dan wel gevolmachtigde
* Het niet kunnen registreren van een vertegenwoordiging op basis van relatie dan wel vertegenwoordiger op basis van relatie
Wettelijk gezien is het zo dat er 3 vormen van wettelijke vertegenwoordiging zijn:
# Door een extern iemand (bijv. mentor, curator, bewindvoerder)
# Door een gevolmachtigde
# Door een vertegenwoordiger op basis van relatie (partner, kinderen, ...)
De laatste 2 vormen van wettelijke vertegenwoordiging worden dus in de betreffende codelijsten gemist.
Hiermee bereiken we dat:
* Zorgaanbieders completere registratie kunnen doen van de wettelijke vertegenwoordiging.
* Zorgaanbieders deze informatie eenduidig (eenheid van taal) kunnen uitwisselen met cliënt (of diens vertegenwoordiger) via bijvoorbeeld een Persoonlijke Gezondheidsomgeving (PGO).
* Zorgaanbieders deze informatie eenduidig (eenheid van taal) met andere zorgprofessionals (bijv. Cure) kunnen uitwisselen.
Besluit:
ZIB-1482
decubituswond; toevoegen van waarden aan 'categorie'
| Aangemaakt op: | 05-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 26-01-2024 |
| Het betreft de bouwstenen: |
Omschrijving:
Wijzigingsverzoek namens de redactieraad V&VN:
Dit jaar is er een nieuwe richtlijn decubitus opgeleverd. In de richtlijn wordt nu een onderscheid gemaakt in 6 categorieën ipv de 4 die in de zib worden vermeld.
Graag toevoegen aan de DecubitusCategorieCodelijst:
* Ongeclassificeerd (Verlies van een volledige huid- of weefsellaag waarbij diepte onbekend)
* Vermoedelijke diepe weefselbeschadiging (Diepte onbekend)
https://www.venvn.nl/media/wqiljxu4/20210211-richtlijn-samenvattingskaart-v-vn.pdf
Besluit:
ZIB-1483
Voorbeelden verpleegkundige interventie niet aangepast
| Aangemaakt op: | 07-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Bij zib-728 is "Activiteit" vervallen. Dit is aangepast in de zib, maar niet in de voorbeeld instances, daar staat de vervallen "Activiteit" nog.
Besluit:
ZIB-1486
Code nodig voor frequentie/interval verpleegkundige interventie
| Aangemaakt op: | 08-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Voor frequentie en/of interval verpleegkundige interventie:
[https://zibs.nl/wiki/VerpleegkundigeInterventie-v3.1(2017NL)]
(zelfde speelt in [https://zibs.nl/wiki/VerpleegkundigeInterventie-v3.2(2020NL))]
is een Snomed codering nodig om deze als Observation toe te kunnen voegen aan de interventie.
Parent (de interventie zelf) heeft al [9632001|https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=9632001] Nursing procedure
260866001 : frequentiepatroon (attribuut)
geeft goed aan wat ik nodig heb, mag die alleen als zijnde attribuut niet direct gebruiken. Lijkt me dus dat een concept nodig is wat deze twee samenvoegt: frequentiepatroon van nursing procedure.
Ik heb maar 1 code nodig, in de template wordt choice (frequentie | interval) gebruikt.
Former user gevraagd deze even snel op te pakken i.v.m. mijn vakantie en beloftes aan Chipsoft.
Als de code er komt, kan issue door zodat code ook in de volgende zibs (pre)release komt.
Besluit:
ZIB-1488
Klopt de kardinaliteit 0..* voor Aanvrager in zib Verrichting
| Aangemaakt op: | 12-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2022-1 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de zib Verrichting heeft het concept Aanvrager een kardinaliteit van 0..*; er kunnen dus meerdere aanvragers voor een verrichting zijn. In FHIR is dit equivalente concept beperkt tot 0..1 keer. Ook het HL7 NL-validatieteam kan zich moeilijk een situatie voorstellen dat er meerdere aanvragers zijn voor een verrichting? Is het inderdaad de bedoeling dat een verrichting door meerdere zorgverleners kan worden aangevraagd?
Besluit:
ZIB-1493
Sectie References bevat een nogal voorlopige tekst. Graag aanvullen of inhoud geheel verwijderen
| Aangemaakt op: | 14-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
Sectie References bevat een nogal voorlopige tekst, namelijk '_volgt n_'. Graag aanvullen of inhoud geheel verwijderen
Besluit:
ZIB-1494
Vertaling Levensovertuiging is niet Life Stance in het engels
| Aangemaakt op: | 15-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De ZiRA vertalen we naar het Engels maar Life Stance wordt niet herkend door engels sprekenden (ook niet door Epic). Alternatief kan zijn: Religion of Philosophy of life.
Besluit:
ZIB-1495
Verbetering vertaling zuster -> zus
| Aangemaakt op: | 20-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
In de ZIB [https://zibs.nl/wiki/Contactpersoon-v3.4(2020NL)]
wordt gebruikt gemaakt van deze termen:
zuster
schoonzuster
Een betere NL vertaling zou zijn
zus
schoonzus
De term "zuster" schept verwarring wanneer het ziekenhuis bij een behandeling betrokken is...
Besluit:
ZIB-1496
Toevoegen nieuwe contactpersonen
| Aangemaakt op: | 20-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2023-1 | Publicatiedatum: | 17-10-2023 |
| Het betreft de bouwstenen: |
Omschrijving:
Kunnen de volgende termen toegevoegd worden aan [https://zibs.nl/wiki/Contactpersoon-v3.4(2020NL)?]
||Naam||zibcode||zibname||
|Buur|19|Buur|
|Vriend(in)/Kennis|20|Vriend(in)/Kennis|
|Stiefdochter|STPDAU|Stepdaughter|
|Stiefzoon|STPSON|Stepzoon|
|Stiefbroer|STPBRO|Stepbrother|
|Stiefzus|STPSIS|Stepsister|
LET OP -> De termen: Buur en Vriend(in)/Kennis komen uit de RolCodeLijst in deze zelfde ZIB. Het lijkt erop dat deze termen op de verkeerde plek staan. De RolCodeLijst bevat bijna alleen juridische aanvaarde termen. Maar Buur/Vriend zijn eigenlijk geen rollen maar wel contact personen die in de praktijk gebruikt worden!
Besluit:
ZIB-1498
MedicatieToediening2 tabel wordt niet goed weergegeven
| Aangemaakt op: | 20-07-2021 | Status: | Pre-Published |
| Onderdeel van: | Pre-publicatie 2021-2 | Publicatiedatum: | 29-09-2022 |
| Het betreft de bouwstenen: |
Omschrijving:
De tabel op de wiki en in de excel export staat niet goed voor de zib MedicatieToediening2 voor de EN variant.
!2021-07-20 15_58_20-MedicationAdministration2-v1.1.1(2020EN) - Zorginformatiebouwstenen.png|width=997,height=196!
Versus de NL versie:
!2021-07-20 15_58_05-MedicatieToediening2-v1.1.1(2020NL) - Zorginformatiebouwstenen.png|width=998,height=166!
Besluit:
Deze wiki pagina is gegenereerd op 25-4-2024 22:15:30
