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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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:
Deze wiki pagina is gegenereerd op 4-7-2024 13:11:51