10. maj 2011 Referat af møde i MiBas IT-arbejdesgruppe. Tid: 10. maj kl. 11-16 Sted: SSI bygn. 202, 2. sal ITP-mødelokalet Deltagere Ellen Larsen, SafirLIS, Hillerød Elly Kristensen, ADbakt, Hvidovre Henrik Schønheyder, ADbakt, Ålborg (afbud) Tina Proft Larsen, ADbakt, Herlev (afbud) Thøger G Jensen, Mads, Odense Ram Dessau, Mads, Region Sj (afbud) Charlotte Nobel, SSI, LIMS Michael Mortensen, SSI, LIMS Peter Steenberg, Autonik Jens K Møller, Mads (afbud) Flemming Christensen, Mads Hans Busk, Mads Kenn Schultz Nielsen, SSI, MiBa Lars Anker Knudsen, SSI, MiBa Marianne Voldstedlund, MiBa - referent Dagsorden 11:00-11:15 11:15-11:40 11:40-12:00 12:00-12:45 12:45-13:45 13:45-14:15 14:15-14:30 14:40-15:00 15:00-15:50 15:50-16:00 Velkomst, præsentation af gruppens medlemmer. Diskussion af kommissorium Diverse informationer Frokost Overordnet tolkning af svar Præsentation af guide til brug af XRTP05 Næste møde / Emner og ønsker til fremtidige møder? Plan for/ ideer til revision af håndteringen af CRP numre i MiBa. Ideer til tekniske løsninger for differentieret visning af svar oplysninger ved opslag i MiBa SuperXRPT05? Blå emner til næste møde? MiBa IT-arbejdsgruppe 10/5 2011 Marianne Voldstedlund
Referat Marianne (MAV) bød velkommen og takkede alle for at ville deltage i et samarbejde omkring de IT-tekniske aspekter af MiBa. Gruppen består af IT-system interesserede repræsentanter fra KMA (+LIMS/SSI), leverandører af MADS og ADBakt/MiBa, Epi-MiBa-udviklere fra SSI og projektleder for MiBa. Gruppens deltagere præsenterede sig kort for hinanden. Konstituering af gruppen. Der var enighed om at IT-arbejdsgruppen er underlagt Mibas repræsentantskab. Det er ikke relevant at blande DSKM ind i det. Gruppens ideer og forslag kan have både juridiske, praktiske og økonomiske konsekvenser. Alle tiltag der har sådanne principielle konsekvenser, skal forelægges og besluttes i repræsentantskabet. Der skal dog være en bred ramme for hvad gruppen skal kunne beslutte og føre ud i livet uden at repræsentantskabet skal høres først. Specielt skal gruppen frit kunne vælge hvilke emner og problemstillinger de vil diskutere og arbejde med. Der var få kommentarer til kommissorium og flere kommentarer modtages gerne (mail til mav). Foreløbigt ser kommissoriet således ud: Kommissorium for IT-arbejdsgruppen: IT-arbejdsgruppen er konstitueret under MiBas repræsentantskab og består af repræsentanter fra KMA (+LIMS/SSI), leverandører af MADS og ADBakt/MiBa, IT-udviklere fra SSI og projektleder for MiBa. IT-arbejdsgruppen er et forum til diskussion og løsning af fælles MiBa relaterede problemstillinger af IT-teknisk karakter. IT-arbejdsgruppen er et forum, hvor man kan udveksle erfaringer og gode ideer. Det kan også være ideer til fælles kodning og registrering i den lokale KMA. Gruppen kan frit vælge hvilke problemstillinger, der tages op. Alle beslutninger vedrørende MiBa, som har større praktisk eller økonomisk betydning, skal forelægges og godkendes af repræsentantskabet. (Epi-MiBa er overvågningsdatabasen, der henter data fra MiBa) Når den nye MiBa hjemmeside er klar, kommer præsentation af IT-gruppen, kommissorium og møde referater, m.m. til at ligge her. Peter fremførte at leverandørene naturligvis gerne ville deltage i udviklingen af Miba og tilhørende infrastruktur for udveksling af mikrobiologiske data, men at det ikke er deres rolle at være sponsorer for denne udvikling. MiBa har et meget lille driftsbudget, der kun lige dækker de faste udgifter. Hvem skal betale for alle de strålende ideer denne IT-gruppe finder på? Peter: kunne man indføre en lille brugerbetaling (= rekvirenten) for indberetning til MiBa, som kunne bruges til udviklingsformål. Patobanken får ca. 180 kr. om året (eller er det måned?) fra hver lægepraksis (ydernummer). MAV: hvis Patobanken kan, er det ikke utænkeligt at MiBa også kan. Men det er måske ikke en farbar vej at gå. Den stadige udvikling af Miba vil givet kræve velvilje fra brugere på alle niveauer, når ændringer i rutiner skal implementeres. Det vil ikke være befordrende, hvis de samme mennesker bliver pålagt en afgift.
Omvendt hvis lægerne pålægges en afgift, som de efterfølgende kunne få refunderet over deres overenskomst, så fik man skabt en ny indtægtskilde til MiBa. Vi (MiBa) venter spændt på svar på ansøgning hos ABT-fonden. Denne ansøgning går hovedsageligt på udvikling af elektroniske meldeblanketter, men der er indregnet et betydeligt beløb til udvikling af MiBa. Der er nedsat et nyt Antibiotika Råd. Det er tænkeligt at MiBa kunne få del i deres midler til udvikling af funktioner, der ville muliggøre overvågning af resistensudvikling. Det er et problem at der ikke er indregnet midler til udvikling af MiBa i bevillingen fra ISM. Anmodning om afsendelse af foreløbigt (tomt) svar til MiBa ved registrering af rekvisition i KMA. Repræsentantskabet har vedtaget at MiBa skal indeholde information om hvilke prøver, der er rekvireret. Dette kan måske forhindre at der bliver taget unødige prøver i forbindelse med overflytning af patienter og når der kan være tvivl om, hvor en given prøve er sendt hen. Foreløbigt er det frivilligt for KMA en at implementerer dette. I det tomme svar til MiBa ønskes oplysninger sv.t headeren, rekvirent oplysninger og oplysninger om hvilken/hvilke undersøgelser, der er bedt om. I nogle tilfælde ændrer KMA en på de undersøgelser, der er rekvireret, eller tilføjer/sløjfer analyser. Det er ikke tanken, at der skal sendes nye opdateringer af det foreløbige svar i disse tilfælde. KMA en finder det tidspunkt efter primær registrering af prøven, hvor det er praktisk at sende et svar. Ellen (Hillerød): hvem betaler for de ændringer i den lokale opsætning dette ville kræve? MAV: lige nu er der ingen penge. Det er heller ikke et krav til KMA en. Alle opfordres til at finde ud af hvad opgaven indebærer og hvad det vil koste. De KMA er der kan løse opgaven inden for deres eget budget opfordres til at implementere funktionen. MiBa s testmiljø MiBas testmiljø er blevet opdateret og er et tilbud til dem der har lyst til at bruge det. Der er flere KMA, der løbende sender testsvar til databasen. Testdatabasen ligger på samme server som MiBa og adgangen er således også via SDN. Url: http://195.80.251.49/csp/mibatest/loginmain.csp MiBa E-mails. Det er nu muligt for brugere af MiBa, der har en personlig adgangskode at sende E-mails til hinanden. Det er desuden muligt at sende vedhæftede filer til brugere med systemadgang altså Peter og MAV. Dette giver en længe ønsket mulighed for at udveksle personfølsomme oplysninger på en sikker måde. E-mailen kan anvendes til at udveksles eksempler på svar med fejl og når MAV har anmodet om lokale dataudtræk med cpr.numre til brug for kvalitetssikring. Det er selvfølgelig MiBa brugere / brugernavne man kan sende emails til de findes ved tryk på en gennemse knap. E-mail funktionen har ikke noget med almindelige email adresser at gøre. Test af Miba brugerlog.
Der er og der kommer flere forskellige måder at tilgå MiBa-svar på. Vi (Peter og MAV) ønsker at teste om log-oplysningerne ved disse opslag vises korrekt og om de er fyldestgørende. Om kort tid vil log-oplysnínger fra Miba blive eksporteret til MinLog på Sundhed.dk, så borgen har mulighed for at se hvem der har fremsøgt borgerens svar i MiBa. Vi anmoder om at I udfører følgende test: 1. I skal logge på Miba med egen bruger-adgang og slå Nancy op. 2. I skal slå Nancy op i eget system og logge på MiBa via MiBa-knap. 3. Herefter sender I en mail til mav@ssi.dk eller med Miba post til MAV med oplysninger om ca. tidspunkt for opslag og jeres initialer. 4. Skal gøres inden 24/5 2011. Nyt login til MADS-KMA er Vi vil gerne kunne styre bruger-rettighederne afhængigt af hvilken form for login, der er tale om. Aktuelt har MADS-KMA er kun én adgang, som de bruger både til svarafgivelse og til login via Miba-knap. Vi vil gerne tildele jer et nyt login til MiBa knappen. MAV når ikke at oprette de nye bruger ID før 17/5 2011. I modtager de nye Bruger ID + PW d 17 /5. MADS-KMA kan med fordel vente med at udfører deres brugerlog-test til efter de har skiftet deres bruger ID til knap-funktionen. Overordnet tolkning af svar i MiBa. Tolkningen skal bruges i svar-oversigten (både i MiBa og i labportal på sundhed.dk), men kan også blive relevant i andre sammenhænge. MEN: Hvornår er et prøvesvar positivt? Hvor mange/hvilke kategorier skal vi inddele svarene i? Hvordan med svar med flere analyse resultater? Hvilket felt i XRPT05 er relevant at bruge til dette? Hvilke tekniske udfordringer er der her? Vi blev enige om at svarene skal inddeles i 3 (eller 4) kasser: positiv / negativ / se tekst / og evt en kasse der kunne hedde pos/neg til svar med flere analyser, hvor der både er pos og negative resultater. Der blev nævnt mange eksempler på svar, hvor det er vanskeligt at tolke svaret entydig som positivt eller negativt. MAV: Det er ikke en tolkning, der skal bruges til videnskab. Det er for at gøre oversigterne mere overskuelige. Alle svar, der oplagt er enten positive eller negative, rubriceres som sådanne, resten ryger i kassen se tekst eller evt i kassen pos/neg. Det er den lokale KMA, der angiver tolkningen. Hvor i XRPT man skal angive tolkningen? Der er et felt der hedder summary i XRPT05, men det er for overordnet, da svar med flere undersøgelser, bliver delt op i delsvar i Miba. Vi blev enige om at vi ville angive tolkning på flere niveauer: Dels bør man kunne angive en tolkning knyttet til hver analyse og dels bør man kunne angive en samlet tolkning knyttet til hver undersøgelse. f.eks.
US: Influenza PCR (se tekst) o Analyse: Influenza A (pos) o Analyse: Influenza H1N1 (neg) o Analyse: Influenza B (neg) Det vil være tolkningen knyttet til undersøgelsen (influenza PCR), der vises i svar oversigt. Hjemme i KMA skal der laves nogle tabeller, hvor de forskellige svar muligheder mappes til en tolkningstabel. Nogle KMA har allerede noget lignende. Flemming vil lave et oplæg til løsninger. Det kræver en udvidelse af XRTP05. Det er muligt at disse tolkninger er noget alle brugere af XRPT05 er interesseret i. Flemming, Peter og Busk vil diskutere sagen med MedCom. Guide til XRPT05. Peter og MAV har følt at der var behov for en supplerende forklaring til XRPT05 til brug for MiBa. MedCom s XRPT05 Det nye gode XML mikrobiologisvar beskriver hvad der skal puttes i de forskellige felter. Peter har nu lavet en guide, der beskriver hvor information fra de forskellige XRPT felter havner i Miba-svaret. Se vedlagte: XRPT05 mapping guide MiBa Indlægget gav anledning til mange gode diskussioner. Undervejs blev det også udtrykt at det er ærgerligt at denne form for vejledning til KMA-systemansvarlige og etableringen af dette forum i det hele taget ikke fandt sted før Miba gik i drift. Jeg tror vi alle var enige, men vi må nøjes med at glæde os over at det nu er sket Det kan være svært at gennemskue præcis, hvor de mange forskellige slags kommentarer, growth value, referenceintervaller osv havner i Resultat-feltet. Vi blev enige om at hver KMA laver et testsvar på Nancy, hvor man udfylder så mange XRPT felter som muligt. (MedCom har faktisk nogle test eksempler på deres hjemmeside, de er bare ikke helt så detaljerede som vi ønsker, vores nye testsvar kunne dels ligge på MiBas hjemmeside og dels hos MedCom). Vi blev enige om at growth value nu bliver vist til venstre for microorganism i resultatfeltet. MAV ønsker prompter og tilhørende koder med i XRTP05 svaret til MiBa. Som det er nu, kommer kun teksten fra evt promptsvar med under kliniske oplysninger, hvorfra der ikke kan trækkes data. KMA erne modtager prompter med tilhørende koder i deres rekvisitioner. Så informationen er tilgængelig. MAV ønsker at standardisere brugen af et lille udvalg af prompter, f.eks. vedr. udlandsrejse, rejseland, smittemåde. På sigt kunne disse prompter blive obligatoriske ved bestilling af udvalgte typer undersøgelser. Peter m fl: det vil ikke være en svær opgave. Kræver ændring i XRPT05? MADS har svartyper, hvor selve de udførte analyser ikke medsendes i svar, hvor kun undersøgelsen (MDS koden) og en overordnet tolkning af resultater er angivet. F.eks. klamydia svar. Det er ikke muligt at mappe disse tolkninger i Miba, fordi koden (fx 1, 2, 3, 4) ikke er entydigt defineret i Miba. Peter: Kunne MADS knytte MDSu koden til alle tolknings koder.
F.eks.: i stedet for 1 så 12250@1 ved et klamydia svar? Flemming vil tænke over det. Peter: arbejder på at en mulighed for at få vist paraply-svar samlet, som ét svar. Thøger: vi skal beholde mulighed for visning af delsvar, da det kan være mere overskueligt i nogle situationer. Peter og MAV har overvejet at ændre det generelle svarlayout. Det blev designet til test tidligt i MiBas udvikling. Det er pænt og simpelt at gennemskue. Men det udnytter ikke skærmbilledet særligt godt. Selv ved relativt korte svar skal man scrolle ned for at se hele svaret. MAV viste et relativt gammeldags forslag til nyt layout. MAV vil specielt gerne have MiBas logo på svaret. Busk viste webmads nye svar layout. Vi blev enige om at lave en lille gruppe som kunne kigge på det. Busk, MAV og Peter ville gerne være med. Det blev anført at dette ikke skal være en opgave med høj prioritet. Det er andre ting i Miba, der haster mere. MDS-koder. Hvidovre (og Herlev?) har nu fået indført mapning til MDS-koder på næsten alle svar. Dette gælder fremadrettet. MAV ønsker også MDS-koder på de svar, der allerede er i MiBa. Peter: Det er ikke umuligt der findes jo en mapningstabel på Hvidovre. Peter vil se på det. SSI svar er rekvireret i biokemi-del af webreq og kan ikke tilknyttes MDS-koder i LIMS. Nogle svar har NPU koder og andre har lokale SSI-svar koder. Der pågår aktuelt et forsøg på at mappe SSI lokal koder og NPU koder til MDSu koder. For udvalgte NPU-koder vil det også være muligt at mappe til MDS-m koder. Der udføres mange special-undersøgelser på SSI, for hvilke der ikke findes en MDS-kode. I takt med at vi får afklaret behovene vil der blive anmodet om nye MDS-koder. Håndtering af CPR-numre. Der mangler en protokol for hvordan man sletter et svar i MiBa. MiBa kan ikke modtage svar med tomt cpr-nr felt. Hvis man ønsker at slette et svar i MiBa, f.eks. et svar, der er sendt på et galt cpr-nr, er der aktuelt følgende nødløsning: Man sender et korrigerende svar til Miba, hvor cpr-nummeret er ændret til Nancy s. Man skal huske at ændre rekvirenten og evt kopimodtagere inden man sender, da de jo ikke skal have dette svar. Det er således vigtigt at man ikke sletter et svar oprettet på forkert cpr hjemme i KMA en før et evt korrigerende svar er sendt til MiBa. Peter har et forslag til en protokol, som gør det muligt at slette svaret rigtigt, i stedet for at overføre det på Nancy. Der fulgte en diskussion om det var mest rigtigt at slette svaret eller bibeholde svaret med angivelse af, at der er tale om en fejl. Vi blev enige om ikke at beholde fejlsvar i MiBa. I tilfælde af en UHT, ville det være muligt at rede trådene ud ved hjælp af log-oplysninger og oplysninger fra afsender KMA. Man kunne overveje at gemme fejlsvar i en helt separat tabel i MiBa. MAV vil kontakte datatilsynet og spørge hvad de anbefaler. Der var enighed om at det lå uden for Mibas område at kontrollere cpr-nr ved opslag i CPR register og ikke relevant at angive vital status på MiBa-svar. I relation til overvågningen vil den
slags opslag i cpr-registeret alligevel blive foretaget på et senere niveau i dataflowet. Det vil ske på Epi-Miba eller MIS-2 niveau. Det ville være ønskværdigt, hvis man kunne håndtere erstatnings-cpr og skiftende CPR. Men dette er en problemstilling der bør blive løst på nationalt plan ikke i MiBa regi. MiBa skal nøjes med at finde ud af hvordan vi kan håndtere 9-ciffrede færøske cpr-nr. Færøerne er ved at implementerer MADS. Når det er på plads, er det planen at de skal være med i MiBa. Emner til næste møde Dette punkt udgik og alle opfordres til at sende en mail til MAV, hvis man har gode ideer. Vi fik heller ikke aftalt nogen ny mødedato. Herefter forlod de fleste grønnes medlemmer mødet. Differentieret visning. MAV ønsker at der bliver udviklet muligheder for differentieret visning i MiBa. MAV forestiller sig at det skal være muligt at gøre adgangen til forskellige oplysninger afhængig af hvilken bruger-kategori brugeren tilhører. F.eks. bruger-kategorierne: Klinikere Mikrobiologer og lign Overvågning. Oplysninger hvor det typisk ville være relevant: Resistens undersøgelser Typningsdata Oplysninger, hvor videregivelse er nægtet. Eksempler: Klinikeren ser kun resistensoplysninger, der er relevante for behandling (bestemt af afsender KMA), mens mikrobiologer vil få vist et større udvalg af udførte resistens undersøgelser (bestemt af afsender KMA). Oplysninger til overvågningen, som ikke skal med på svar til klinikere. Oplysninger, som patienten ikke vil have at andre skal se, skal ikke vises til hverken Klinikere eller mikrobiologer. Men de skal overføres til MiBa, hvis omfattet af lov om overvågning. Det skal være den lokale KMA, der angiver hvilke oplysninger der skal være tilgængelig for de forskellige bruger-kategorier. Det kan sættes op som regler, så det er ikke planen at bioanalytikeren skal sidde og vinge af på de enkelte svar før afsendelse. Emnet har været diskuteret før. Her er vi nået til at man nok ikke kan få sådanne funktioner til at fungere blandt alle brugere af XRPT05. Derfor er der foreslået at vi laver en superxrpt05, der kun bruges mellem KMA/SSI og MiBa. En SuperXRPT05 er en protokol, hvor der findes en række ekstra felter/tabeller, der kan bruges til at sende data mellem KMA og Miba. Når man sender svar til andre (fx Cosmic) er det kun data i den rene kerne-xrpt05, der sendes.
Der er en del, der skal afklares, inden egentlige løsninger kan udtænkes. F.eks. skal det afklares om bruger-kategorierne er simpelt hirakisk ordnet eller om det skal være muligt at have en række forskellige brugerkategorier, hvor nogle har adgang til det ene, men ikke det andet, mens en anden kategori har adgang til det andet, men ikke det ene. Diskussionen gav anledning til at diskutere XRPT05 i det hele taget. Der var mange af dagens emner, der kræver en ændring af den nuværende XRPT05. Alle ændringsforslag skal samles til bunke og tages med til MedCom med henblik på at få udviklet en ny version af XRPT05. MEN, hvor mange ændringer skal der til, for at man kalder det ny version af XRPT05 og hvilke/hvor mange ændringer skal der til, før man skal oprette en XRPT06? Disse svære spørgsmål gjorde os alle pludseligt meget trætte og opmærksomme på at det var tid til at slutte et langt og udbytterigt møde. Opgaver: Hver KMA laver et testsvar på Nancy, hvor man udfylder så mange XRPT felter som muligt. MADS skal have nye bruger ID til knappen (MAV). Test af bruger log. Afsendelse af svar ved primær registrering af rekvisition. Mapning af MDS-koder på gamle Hvidovre/Herlev svar? (Peter) Kontakt til datatilsyn (MAV). Sammenknytning af tolknings kode og MDS-u kode på svar hvor analyse ikke medsendes på svar Klamydia eks. (Flemming) Mulighed for samlet visning af paraplysvar (Peter). Growth value rykkes til venstre (Peter) Ting til XRPT05: Angivelse af tolkning til brug for svaroversigter (Flemming/Peter). Gøre tolkningskoder entydige i Miba og dermed mulige at mappe (Peter/Flemming). Promt koder/tekster (Peter?) Protokol til sletning af svar (Peter?) Super XRTP05?