Referat fra teknikermøde vedr. FNUX-PLO formatet

Transkript

1 Dato: Vor ref.: IJO Referat fra teknikermøde vedr. FNUX-PLO formatet Dato: Torsdag den 1. februar 2012 kl Sted: Deltagere: MedCom Rugårdsvej 15, 3. sal, 5000 Odense C Dan Stege, EMAR Tom Sørensen, EMAR Allan Kim Eriksen, NOVAX Paul Samsig, WinPLC Truc Huynh, MedWin Jan Winther, Tandlægernes Data Kristian Foged, DataGruppen MultiMed Kristian Kvist, DataGruppen MultiMed Christian Ulrich, CompuGroup Jan Magnussen, CompuGroup Ove Frost Sørensen, Arch-Insight Jacob Glasdam, MedCom Michael Due Madsen, MedCom Ib Johansen, MedCom Gitte Henriksen, MedCom (referent) Afbud fra Docbase/Lægernes EDB-central. Referat: Ad 1) Velkomst, baggrund for mødet Baggrunden for mødet er at vi skal have FNUX-formatet ud at rulle. Vi har aftale med PL-forum, at det skal være klart til april. Der skal måske justeres på standarden. Det kigger vi på i dag. Ib gennemgik kort dagsordenen. Herefter var der en kort præsentationsrunde. Tom repræsenterer PL forum i dag og de har initieret opstart af teknikergruppen. Ib fortalte kort omkring ny release af sundhed.dk, og som følge heraf så virker linkene til lab.svarportalen, e-journal og lab.vejl. ikke mere. Det kommer de ikke til det før 1. april. Ib har skrevet ud til jer leverandører her til morgen. Oplysningerne bliver også lagt på hjemmesiden og der sendes også brevinformation ud til alle læger her i løbet af ugen.

2 Ad 2) Gennemgang af FNUX hvor er det, der skal strammes op? Ove tog udgangspunkt i de kommentarer/spørgsmål til standarddokumentationen, som vi har fået fra Novax. De er nedenfor markeret med fed og kommentarnummeret fra Allan. Ove spurgte til om leverandørerne så småt havde taget hul på FNUX-formatet? Der blev svaret positivt fra nogle enkelte. PLOFormatStruktur [N1]: Er stemningen at der kun sendes en og kun en patient pr. fil. Hvis der er flere patienter bliver de zippet sammen. Zip-filen er defineret i MEDBIN og den er også defineret som en PLO. En MEDBIN må kun fylde 10 mb efter aftale med VANS. Skal der ikke laves aftaler om at megafiler sendes på en anden måde eller at der lægges referencer ud til hvor man kan finde dem. Hvor stort er problemet? Der er mange læger som scanner alle dokumenter og lægger ind i journalen. Det er svært at regelsætte. Hellere sende så meget som muligt i stedet for at lægge begrænsninger på. Lad os se om det bliver et problem. Man kunne godt have et statement som siger max. 1 Gb. KMD og Evenex skal spørges til, hvad de siger til filer som er større end 10 mb. Er der en max. grænse? Lad os zippe det og se hvad der sker. Og hvis det er en hel praksis som lukker og som skal aflevere til SST må det ske på et andet medie. Der kan godt sendes delvise udtræk af journalen. MedCom har efterfølgende spurgt KMD og Evenex og max. grænsen for MEDBIN er i dag 50 mb. PakkeIdentifikator [N2]: Forslag om GUID/UUID er en rigtig god ide og alle tilslutter sig. Man skal skemavalidere om det er den GUID. SekvensNummerIdentifikator [N3]: Er den ikke redundant i en eller anden forstand? Denne fjernes også. UdtraekAntal [N4]: Vi fjerner UdtraekAntal, da det er reminiscens fra gamle dage og da det er vedtaget, at der kun sendes 1 patient pr. fil. UdtraeksIdentifikator [N5]: I PLO header er der en UdtraeksIdentifikator her bruger vi også en GUID. UdtraeksVersionIdentifikator [N6]: Hvis man laver noget som ikke kræver en skemaændring, her kunne man måske bruge UdtraeksVersionIdentifikator. Der var delte meninger om ovenstående og om hvor meget bøvl det ville give kun at skemavalidere. Men beslutningen blev at man fjerner den og så må man se hvordan det går. SystemIdentifikator [N7]: Her kan man skrive sit systemnavn, det er en fri tekst. Der skal måske være en begrænsning på og MedCom skal teste det ved godkendelse. Her skal angives leverandørnavn og versionsnummer. Måske en begrænsning på 70 karakterer. StartDatoTid og SlutDatoTid [N8, N9]: Er tidsrummet hvor man har forsøgt at lave udtrækket i. Hvorfor er den mandatory? Der skal være en klar definition til hvordan man skal fortolke det. Lang diskussion omkring journalføring og hvad der skal sendes med til næste læge. Hvis alle notater har en GUID og man retter eller tilføjer en diagnose, så får notatet en ny GUID. 2

3 Er der nogen som vil savne det hvis vi ændrer mandatory til optionel. StartDatoTid og SlutDatoTid ændres til at være optionelle i PLO-header. Hvis datoerne er sendt med bliver de højst sandsynligt ignoreret. Så til sidst endte det med at vi blev enige om at StartDatoTid og SlutDatoTid bliver slettet. PatientUdtraekStruktur [N10]: I PatientUdtraekStruktur er egne sektioner ikke tilladt mere. Allans anke er, at man kunne godt have brug for andre samlinger som: Refraktion (øjenlæger), Audio (ørelæger), Undersøgelse, Behandling (SEI ligger her). KommuneKode [N11]: 4 cifre, ændres ikke, det beholder vi. RegionsKode [N12]: 4 cifre, ændres ikke, det laves heller ikke om. SygesikringsgruppeIdentifikator [N13]: Vi holder fast i værdierne, da det er rart at få oplysning om hvilken gruppe patienten tilhører, da man ikke nødvendigvis har patienten, men man kan så ud fra oplysningen indplacere dem rigtigt. BehandlerIdentifikator[N14]: Indikerer, at patienten er tilknyttet den her læge. Allan synes det er bedre med en reference, som skal pege ned i BehandlerSamling. Den gøres optionel i stedet for mandatory. GenerelCaveTekst [N15]: GenerelCaveTekst fjernes. I Paaroerendestruktur: PersonNavnStruktur [N16]: Vi holder fast i opdelingen. BehandlerStruktur: BehandlerIdentifikator [N17]: Gøres optionel og med en pegepind ned i BehandlerSamling. Vi sletter BehandlerInitial choice igennem strukturerne. StillingsbetegnelseNavn [N18]: Begrænsning på StillingsbetegnelseNavn vil være godt. An..70 vil være godt så det ligner de andre. CaveStruktur: KommentarlinieSamling [N19]: Der skal være en begrænsning på 5 linier a 70 tegn. Skal fremgå af beskrivelsen. LabSkemaStruktur: EndeligtSvarIndikator [N20]: Er der behov for at det er et mandatory felt? Bibeholdes. BoerneUndersoegelsesKode [N21]: Laves om til optionel i stedet for mandatory. Skal kun udfyldes, hvis man følger de officielle børneundersøgelseskoder. BoerneSkemaAnalyseKode: ResultatTekst [N22]: Skal den ikke være mandatory? Det giver god mening når der er lavet en måling. Slås sammen i en struktur: BoerneUndersoegelsesKode og ResultatTekst gennemføres på lab.delen også. Anbefaling af SI-enhed, men de valideres ikke. Enhed 12 tegn, resultat 13 tegn fordi større end og mindre end tegnet er med og det er en tekststreng. MedicinEnkeltOrdinationStruktur: SlutDatoTid [N23]: Der holdes fast i et felt i forhold til seponering og dosisdispensering. BinaerIndholdKode [N24] [N25]: Holder fast i at den er mandatory. 3

4 Diskussion omkring hvor mange forskellige typer og formater af binære filer som man skal kunne vedlægge. Der kunne evt. skæres i listen. Der var en del diskussion frem og tilbage om at man skulle have en filtype med som kan indeholde LÆblanketter her i første hug eller om det skal ligge i en senere version. Det bliver i en senere version. InterventionSamling [N26]: Ja er tiltænkt tandlæger. ObservationsSamling [N27]: Ja er tiltænkt tandlæger. Ad 3) Tidsplan for rettelserne Ove kan have rettelserne skrevet ind i løbet af næste uge. MedCom laver testeks. og testprotokol så snart rettelserne er lavet fra Oves side. Ved spørgsmål til om der er behov for kursus eller yderligere møder blev svaret, at nogle af tingene vil man først opdage hen ad vejen, når man gennemgår standarden og går i gang med at programmere. Det kan godt være at man skal have et tilbageløb på et tidspunkt. Afhængig af tidsplanen skal det være hurtigt i processen. Mange af de tidl. problemer er løst med tidsangivelser. Der er valgfrihed mellem tidsangivelser. I xml-en er det angivet som en choice, så man skal vælge om det er det ene eller det andet. MedCom tester og godkender for dette. Ad 4) Validering af FNUX inden afsendelse Hvordan sikrer vi os, at man ved hvilket schema der gælder? MedCom påtager sig den rolle og vi vil publicere seneste release på MedComs Release Repository. I skal bare være opmærksomme på, at I ikke bare kan bruge subversion til drift. I skal hente schemaet ned i eget system og bruge det der. Schemaet vil komme til at ligge her: Indtil standardarden er fastlagt vil dokumentation og schemaer kunne downloades herfra: Vi har yderligere lavet et sagshåndteringssystem, hvor vi samler sammen, hvad der kommer ind af ønsker, rettelser, fejl. Alle kan indberette rettelser, fejl og ønsker, også anonymt. Man kan også bare skrive til MedCom. Der var ønske fra nogen om at lave et forum. Det kan sikkert laves, hvis der er behov for dette. Der var opbakning til et sådant værktøj og man vil gerne bruge det. Linkadressen er: Der er også lagt testeksempler på vores subversion som kan indlæses og vises i testværktøjet. Testværktøjet, hvor man kan teste sine FNUXfiler, kan tilgås her: MedCom vil teste og validere leverandørerne og vi vil lave testeks., som I kan tage udgangspunkt i under programmeringen samt en testprotokol hvor der vil stå, hvad vi gerne vil teste jer for. Ad 5) Udviklings og implementeringsplan. Skal der intensivt kursus til? Der var en del snak om, hvordan man skal styre versionering af notater. PL-forum fik opgaven med hjem og de vil tage hånd om dette og komme med forslag til løsning. 4

5 Der var ønske om et midtvejsmøde, hvor lægesystemerne har kigget så meget på formatet, så de har udviklet en mockup. Vi forventer, at I har kigget så meget på det og lavet så meget, at I kan komme med rettelser/uhensigtsmæssigheder til standarden, som vil være showstoppere i forhold til at kunne lave programmeringen færdig til dette møde medio marts. Vi forventer at uhensigtsmæssigheder registreres i af de enkelte programmører. Man må også gerne sende det på mail til Jacob Glasdam, jag@medcom.dk. Ad 6) Evt. Forslag til midtvejsmøde fredag den kl hos MedCom. 5