M f E o D l I i D O. Medidoc Gebruikersclub

Transcriptie

1 M f E o D l I i D O a uitgave van de Medidoc Gebruikersclub C

2 34 Parameters aanmaken Recent komt er een beweging op gang om progressief meer parameters te gebruiken, die uitwisselbaar zijn, niet alleen binnen Medidoc maar ook tussen de verschillende gelabelde pakketten. Ook de discussies rond zorgpaden, rond communicaties binnen de eerste lijn (en hoewel ik besef dat dit heel moeilijk ligt worden de tweede en derde lijn hier ten onrechte niet of onvoldoende bij betrokken) brengen dit in een stroomversnelling. Een standpunt is natuurlijk laat ons wachten op de parameters die officieel zullen aangemaakt worden, maar ik vermoed dat deze beweging nog maar op kruissnelheid komt en het dus wel lang zou kunnen duren voor iedereen akkoord is. Denk maar aan de -voor ons op eerste zicht gemakkelijk te standaardiseren- parameters van het labo, waar men al bijna tien jaar de nieuwe versie aankondigt. Gelukkig maar dat onder impuls van Jos Devlies we al een standaard hebben sinds 1987, evident aanvulbaar en verbeterbaar, maar ondertussen zijn we er meer dan 20 jaar mee aan het werk. Vandaar dat ik er in elk geval geen voorstander van ben zomaar af te wachten. Ik ben er van overtuigd dat het er komt, maar wanneer: binnen een half jaar? binnen een jaar? of binnen 10 jaar? En hoe volledig zal deze lijst dan zijn? Bekijken we de mogelijkheden van Medidoc. Eerst hadden we enkele parameters ook al werden ze toen nog niet zo benoemd (denk op BD, pols, ), vervolgens werd ook het zwangerschapsdossier gemaakt, waar gedeeltelijk niet uitwisselbaar binnen het eigen systeem! 42 ook een hele rij parameters aangemaakt werden. Tot slot hebben we sinds enkele jaren de protocol gestuurde schermen, die volledig gebouwd zijn rond parameters en de suggestie van gebruiksfrequentie van deze parameters. In het programmeren van de protocol gestuurde schermen werden veel gegevens in het dossier (zoals de synthesegegevens onderaan het CISscherm) omgevormd tot parameters Parameters zijn uniek technisch gezien: een systolische bloeddruk ingevoerd in een van de syntheses van het CISscherm staat automatisch ook in alle andere syntheses waar BD geïncludeerd is en tevens in het hypertensie-, het COPD- of het diabetesscherm 43. Enkel de frequentie van bevragen / uitvoeren kan van protocol tot protocol verschillen. inhoudelijk bekeken: elke parameter moet op zich duidelijk herkenbaar en identificeerbaar zijn. Ter verduidelijking nemen we een problematisch voorbeeld. Het inhoudelijke onderscheid tussen de unieke numerieke systeemparameter pols en de unieke numerieke systeemparameter hartfrequentie is mij niet duidelijk. Dergelijke onduidelijkheid moeten we absoluut proberen te vermijden, zeker wanneer we met nog veel meer parameters gaan kunnen werken. 42 dus de bloeddruk of het gewicht in het zwangerschapsdossier ingevoerd is niet beschikbaar in de andere delen van het dossier. Het zwangerschapsdossier in Medidoc wordt dan ook o.a. in functie hiervan volledig herschreven en dit is bijna klaar. 43 en dus voor het ogenblik nog niet in het zwangerschapsdossier! Nog even geduld /

3 34.2Systeemparameters versus gebruikersparameters Parameters kunnen ofwel systeem- ( = centraal aangemaakt, beheerd, verdeeld en beschikbaar voor alle gebruikers) ofwel gebruikersparameters (= individueel aangemaakt en enkel beschikbaar binnen het eigen computernetwerk) zijn. Iedereen kan parameters van elke type 44 (behalve formuleparameters) aanmaken. Deze gebruikersparameters zijn binnen het eigen systeem perfect bruikbaar maar zijn om allerhande technische redenen niet uitwisselbaar. Corilus zelf maakt ook parameters aan, deze zijn sterk gecodeerd en hebben gecodeerde antwoorden. Deze systeemparameters 45 zijn wel uitwisselbaar met elke andere medidoc-gebruiker. Ook de gebruikers-eigen-schermen en CISsyntheses 46 waar ENKEL systeemparameters gebruikt werden kunnen uitgevoerd worden en bij een andere gebruiker met alle mogelijkheden ingevoerd worden. Zowel deze uitvoer als deze invoer zijn zeer eenvoudige handelingen. Ik neem het voorbeeld van syntheseverkenner: via extra in de bovenbalk van Medidoc Bestandsonderhoud Syntheseverkenner 44 het type wordt bepaald door het mogelijke antwoord: numeriek, lijst (= keuze uit voorgedefinieerde antwoorden), vrije tekst, datum, tijdstip en formules. 45 ik heb het voor het ogenblik wel degelijk over de uitwisselbaarheid van de parameter en niet (hopelijk moet ik eigenlijk schrijven nog niet ) over de uitwisselbaarheid van de uitslag(en) van deze parameter bij een bepaalde patiënt. 46 parameters zijn de bouwstenen waarvan de uitslagen in de datastructuur van de patiënten bewaard worden. Protocol gestuurde schermen en CISsyntheses zijn maar lay-out gegevens, die niet ingrijpen in die datastructuur van de patiëntgegevens maar wel belangrijk zijn om de gegevens op het scherm te ordenen en op die manier inzicht in de gegevens te verhogen /

4 Open de gewenste synthese via krijgt: in de bovenbalk van dit venstertje. U De eigenaar gebruiker (zie 2 e kolom) duidt enkel aan dat dit een synthese is die door de gebruiker aangemaakt werd. Voor zover enkel systeemparameters gebruikt werden is deze synthese exporteerbaar. Ik selecteer als voorbeeld bloeddruk (waar ook gebruikerseigen parameters in steken!) en klik op ok. Klik vervolgens op bestand in de bovenbalk van dit venster. U kunt een synthese kopiëren, ook wanneer hier gebruikerseigen parameters in steken. Hier blijft u immers in uw eigen computersysteem werken. De bedoeling is een kopie te maken, deze onder een andere naam te bewaren en dan verder te bewerken (parameters toevoegen, weglaten, herordenen, ) dus een nieuwe synthese te maken vertrekkend van een reeds bestaande synthese. U kunt een synthese exporteren : 2010 /

5 Aangezien in deze synthese gebruikerseigen parameters steken krijgt u een weigering! Indien hier enkel systeemparameters in gebruik waren zou u een xml bestand creëren. Dit kunt u aan gelijk welke Medidoc-gebruiker sturen die dit via synthese importeren kan integreren in zijn computersysteem. Klik op synthese importeren, zoek in de bestandstructuur van de computer (zie in de linker kolom) waar u de synthese opgeslagen hebt en klik op open (hier kunt u zelf controleren wat binnen gekomen is) en op opslaan. Het is onmiddellijk als synthese beschikbaar onderaan CISscherm (wel eventueel CISscherm afsluiten en heropenen) 34.3Parameters moeten ook inhoudelijk uniek zijn Elke parameter is sowieso uniek, op zijn minst technisch gesproken. Dit unieke moet echter ook inhoudelijk zo strikt mogelijk bewaakt worden. vooreerst om geen twijfel te zaaien voor de arts gebruiker waar wat kan ingevoerd worden (zie voorbeeld hierboven van pols en hartfrequentie) maar evenzeer om (in de toekomst) de bewakingen hierop te kunnen laten lopen: bv u krijgt een verwittiging in de bewaking wanneer u een betablocker voorschrijft bij iemand waar ooit een pols van 50 genoteerd werd, dan is het natuurlijk essentieel dat de computer en de arts akkoord zijn op welke plaats en hoe polsfrequentie genoteerd staat. Ongetwijfeld zal het probleem van dubbele parameters toenemen bij vermeerderen van het aantal parameters. Het is dan ook een belangrijk project de inhoudstafel van de parameters goed bij te houden en verder uit te werken. Ook het invoeren van een systeem van synoniemen (toekomst!) kan helpen om dubbels te voorkomen, analoog aan het zoeken op diagnoses. 34.4Parameterantwoorden moeten niet-context gebonden zijn 2010 /

6 Dezelfde parameter moet in een verschillende context kunnen gebruikt worden. Bekijken we de parameter kortademigheid van het COPD / Astmascherm. We hebben daar de mogelijke antwoorden gebruikt van de classificatie van de New York Heart Association (aangevuld met niveau 0 = geen dyspnoe) omdat we hier evident niet een reeks antwoorden willen formuleren voor een longscherm en een reeks andere voor een hartscherm (fantaseer bv dat we een scherm maken rond hartfalen ). Technisch zou het perfect mogelijk zijn twee verschillende parameters aan te maken: een parameter kortademigheid (longen) en een parameter kortademigheid (hart), maar in de consultatieplaats zal dit alleen verwarring scheppen. We hebben vergelijkbare pseudo-dubbels wel gebruikt bij de motivatieschalen van Prochaska Di Clementi ivm rookstop, gezonde voeding en beweging: op het eerste zicht dezelfde vraag (= motivatie?) en dezelfde antwoorden maar toch iedere keer aan een ander item gebonden. In de realiteit van de dossierregistratie ziet het er identiek uit op het scherm maar in de gegevensopslag zijn het wel degelijk echt verschillende vragen en antwoorden. 34.5Is een parameter objectief? Natuurlijk is het de bedoeling zo objectief mogelijk de gegevens te capteren en te registreren, waarbij cijfers steeds de indruk van hoge objectiviteit creëren, dikwijls terecht soms ten onrechte. Men kan ook een numeriek antwoord invoeren bij een gegeven dat eigenlijk maar geschat wordt m.a.w. ogenschijnlijk heeft men een zeer objectief numeriek antwoord 47, maar in de werkelijkheid is het een min of meer vage indruk waar men in het dossier een cijfer aan gekoppeld heeft. Vanuit wetenschappelijk oogpunt is het natuurlijk belangrijk dat de vlag wel degelijk de lading dekt! Maar ook niet-numerieke antwoorden kunnen hier in de fout lopen. Kijk naar de antwoorden op de systeemparameter gezonde voeding Eigenlijk kan men op deze manier geen objectief antwoord geven. Wat we zouden moeten hebben is een antwoord vergelijkbaar met het bepalen van het voetrisico uit de diabetespas: 4 of 5 vraagjes (niet meer, anders is het niet meer haalbaar in de consultatieplaats), waar via een soort formule gekeken wordt of de kans groot is dat de voeding gezond is of niet. Dit laatste mag dan wel een hele reeks meer gedetailleerde vragen oproepen. Maar voorlopig hebben we die formule in de wetenschappelijke literatuur niet gevonden. In de mogelijke antwoorden kan men ook niet steeds alles voorzien. Bv bij de parameter bewegen is eenmaal per week een voetbalmatch spelen (= 2 x 45 minuten) hetzelfde als 3 x / week 30 minuten te joggen? Men kan natuurlijk beide mogelijke antwoorden in het lijstje voorzien maar men kan deze antwoordcategorieën 47 en dus kan men daar allerhande statistische bewerkingen op doen /

7 evident niet tot in het oneindige uitbreiden. Dus zal hier steeds een interpretatie aan vast hangen en riskeert de objectiviteit van het cijferantwoord een belangrijke overinterpretatie te zijn van de realiteit. 34.6Normale gegevens registreren? In onze dagelijkse registratie worden heel veel normale gegevens niet geregistreerd. Alles registreren zou ten andere ook onmogelijk zijn. We zien tijdens het patiëntcontact een oneindig (bijna letterlijk te nemen) aantal gegevens die wel meetellen maar niet als apart element in het dossier genoteerd worden. Denk aan een kleuter met koorts, die huppelend de consultatieplaats binnen komt: wie zal dit laatste registreren? Maar het is wel duidelijk dat de diagnose meningitis al ongeveer uitgesloten mag worden. Dus we gebruiken dit gegeven wel, maar expliciet noteren we het zelden 48. Als we met parameters werken, a fortiori wanneer ook een frequentie van bevragen gebruikt wordt zoals in de protocol gestuurde schermen 49, stelt dit wel een probleem. Denk op de rolstoelgebonden diabetespatiënt: zoals de antwoordmogelijkheden in versie 6.5 zijn bij bewegen zal bij deze patiënt ofwel een fout antwoord gegeven worden (wat hier concreet dan nog onderparameters zal oproepen om de motivatie te beoordelen) ofwel zal men het helemaal niet invullen (en dus zal het bolletje rood blijven). Eigenlijk zijn geen van beide een goede oplossing. Vanaf versie 6.6 is bij deze vraag dan ook het antwoord onmogelijk voorzien, evident zonder oproepen van onderparameters, tenzij we ooit een reden hiervan als onderparameter in vrije tekst (?) zouden aanmaken. 34.7Gebruikerseigen parameter Maar wat als men in zijn (groeps)praktijk toch met een specifiek project bezig is dat specifieke parameters vergt (zoals bv bij veel manama s van de HAIO s). Als dit parameters zijn die een min of meer universeel gebruik hebben met eenduidige antwoorden kan men natuurlijk vragen deze als systeemparameters aan te maken. Dat is de eerste keuze omdat ze dan ineens voor alle gebruikers beschikbaar zijn. Als dit echter gegevens zijn die enkel binnen een zeer specifieke context gebruikt worden bestaat nog altijd de mogelijkheid deze zelf aan te maken. Eenvoudig en snel te 48 ik ben er ten andere van overtuigd dat dit een van de belangrijkste elementen is waarom de computer nog niet zo snel diagnoses zal stellen. Hypotheses suggereren misschien wel (maar dit steunt telkens maar op één of op enkele gegevens) maar deze kluwen ontwarren veronderstelt steeds oa. ook inzicht in alle normale gegevens. 49 en nog eens: de context waarin een parameter kan gebruikt worden mag niet veroorzaken dat we verschillende parameters aanmaken voor een zelfde gegeven! 2010 /

8 realiseren, maar met de beperking dat u ze niet aan andere gebruikers kan doorgeven. Ook als dit later een zeer boeiend project blijkt te zijn en men post factum toch beslist deze parameters als systeemparameters aan te maken zal het NIET mogelijk zijn de eigen gebruikersparameters te converteren naar de systeemparameters met dezelfde inhoud en dus de reeds geregistreerde inhoud van de patiënten te behouden. INHOUDSTAFEL: 2010 /