Referat fra 3. møde om dansk HL7 CDA profil til deling af aftaler

Transkript

1 Forskerparken 10 DK-5230 Odense M Telefon: Dato Referat fra 3. møde om dansk HL7 CDA profil til deling af aftaler Tidspunkt: Onsdag, den 22. februar 2017 kl Sted: MedCom, Forskerparken 10, 5230 Odense M Deltagere: Thor Schliemann, Sundhedsdatastyrelsen (via video) Søren Ærendahl Mikkelsen, Lakeside Michael Christensen, Alexandra Instituttet Lars Simensen, Region Midtjylland Flemming Elbrønd, Region Syddanmark Alexei Mihalchuk, A-Data Hans Christian Lund Clausen, DAK-E Jens Villadsen, CSC (via video) Morten Bruun-Rasmussen, Mediq Jan Petersen, MedCom Michael Due Madsen, MedCom Michael Johansen, MedCom Anders Jensen, MedCom Pia Reinhardt Juel, MedCom (referent) Fraværende: Jane Christiansen, Sundhedsdatastyrelsen Thomas Bo Nielsen, DAK-E Kristian Nielsen Foged, DataGruppen MultiMed Ole Vilstrup, CSC Morten Kyng, Aarhus Universitet Christian Jeppesen, Systematic Torben Mejlvang Hagensen, Systematic Jesper Nielsen, Region Syddanmark Tina Archard Heide, Region Nordjylland Lone Kaalund Thiel, Region Nordjylland Jan Bannebjerg, Region Sjælland Uffe Ross Sørensen, Region Hovedstaden

2 Torben Lage Frandsen, Region Hovedstaden Peter William Nielsen, Region Hovedstaden Maggie Brisson, Københavns Kommune Ralf Klitgaard Jensen, KL Christel Boëtius, RSI Martin Bagger Brandt, PLO Søren Cajus, Dansk Industri Jørgen Granborg, A-Data Michael Munk Jacobsen, NOVAX Lasse Staal Guldborg, KMD Mette Nøhr, KMD Mads Orehoj Sørensen, IBM Jakob Heuch, Capgemini Referat: 1. Velkomst og formål med mødet Michael bød velkommen til mødet. 2. Referat fra sidste møde Referatet blev godkendt. 3. Gennemgang af DK-APD v0.8.doc og DK-APD_Example_1.xml (vedhæftet) Kommentarer til Dansk HL7 CDA profil til deling af aftaler DK APD v.0.8 ønskes. Bemærk at det er version 0.8 og at den bygger på, hvad der blev gennemgået på sidste møde. (HL7 template). Dette er den 4. danske CDA, der er ved at blive udarbejdet. Flere OID er skal ændres i dokumentet, da der er behov for at oprette nye DK OID er. Der er brugt en række templates for at gøre brug at referencen til det internationale arbejde. Målet er at lægge sig så tæt på HL7 templates, uden at man kommer alt for langt væk fra virkeligheden. Application roles: Der er ændret en smule på teksterne. Tekstrettelserne er inspireret af HL7 v Placer application er f.eks. den praktiserende læge. I det øjeblik, der laves en booking, sender filler application et unsolicited appointment document til Auxillary application. Søren syntes, at diagrammet giver fin mening, men vil gerne vide, hvad der menes med application? Er det en person eller en organisation. Det kan være begge dele. Jan tilføjede, at der altid er en person bag og at diagrammet viser et flow på funktionaliteter. Søren vil gerne vide, om vi i relation til samtykketjek har alle roller med. Det har vi ikke og de skal lægges ind i den generiske CDA header. Det er foreslået, at standarden skal kunne håndtere, at en aftale kan aflyses og dette kan gøres i dokumentet. Hvis aftalen skal slettes med markering af et statusflag, kan dette gøres i CDA eren med det samme indhold, blot med oplysning om, at den er annulleret. Jan advarer i den forbindelse om, at lave funktionaliteter og opdateringer i statiske dokumenter. Morten opfatter generel acknowledgement som at kommunikationen er gået godt og ikke at Auxillary applicationen er modtaget. Jan mener, at man skal benytte den funktion der ligger i IHE. Morten oplyste, at aftalen bliver slettet på et tidspunkt og erstattes af et nyt dokument. 2

3 Jens forstår ikke behovet for, at der skal laves et nyt dokument fremfor bare at benytte den funktionalitet, der allerede ligger i repository. Lars mener dog, at der er behov for at fastholde historikken. Jens mener også, at vi har brug for at vide status på dokumentet og i den rigtige version. Enighed om Sørens forslag - hvis der ikke tænkes IHE, så vil det være en god idé at have et statusflag, der indikerer, en aflyst aftale og at der derefter laves et nyt dokument. Appointment content: Gennemgang af hvilke dele der skal med i en aftale. Filler app = appointment registrant. Jens vil gerne vide, om der er behov for præcision af niveauet i forhold til Health Care Organization? Hertil kunne Morten oplyse, at vi lægger os fast på, at benytte strukturen fra den generiske CDA Header. Søren påpeger muligheden for at referere til et vedhæftet dokument fx et statusbrev, da det vil kunne forventes i praksis. Jan mener, at vi skal passe på med vedhæftning af dokumenter, idet sygehusene stadig vil benytte egne indkaldelser etc. og at fejl kan opstå ved redundans. Den information der sendes til patienten fra sygehus skal være fuldstændig det samme som i CDA en og der skal kun kigges et sted. Vi skal forholde os til, at de der indkalder giver information etc. og hvis vi begynder at inkludere noget af indholdet fra CDA en er det vigtigt, at patienten kan finde de oplysninger de skal bruge. Vi kan forvente, at hvis patienten kan finde alle oplysninger her, så bliver der ikke læst i fysiske breve. Hans påpeger også muligheden for, at der kan peges på noget andet i et vedhæftet dokument. Thor gør opmærksom på, at vi skal passe på med scope og at vi på den korte bane bør holde det ret simpelt. Use-casen skal skabe overblik for aftalen med patienten og ikke andet. Morten spørger, om Thor vil prøve at spørge de personer, der sidder med ansvaret for pilotprojektet i Sundhedsdatastyrelsen, om hvad de forventer i forhold til scope. Han spørger dem i næste uge, hvor de har møde. Jan mener, at det er sundheds issuet der er reason og savner hvilken undersøgelse patienten skal til. Det skal forklares bedre. Morten oplyser, at reason er navnet på den sundhedsydelse patienten er indkaldt til og er fri tekst. Der benyttes SKS-koder i Bookingsystemet. Michael Due vil gerne vide, om der er behov for et ekstra tekstfelt. Snak om dokument 4. sj2 aftalepilot side 9: 3.5 output - Departmentname. Morten oplyste, at idéen bygger på SOR. Michael J. påpeger at det er vigtigt, at der kodes korrekt, så der ikke opstår uoverensstemmelser. Michael Due oplyser, at der normalt i MedCom standarder er oplyst, hvad koden betyder og hvor den kommer fra. Morten foreslår, at vi kan prøve at indsætte 2-3 eksempler ind i næste udgave, som vi derefter kan forsøge at slå direkte op i SOR. Kort snak om Appointment Requester og Appointment Registrant. Forklaring på hvordan det mappes findes på s. 8 samt i et bilag på s. 27. DK APD header: Der mangler lidt tekst, men det vil blive opdateret. I kap. 2 er der en beskrivelse af headeren, hvor der er mangler afklaring på enkelte ting. Bl.a. templates. Snak om LOINC kode , som Morten har valgt at benytte. Den kan IKKE benyttes, så Morten forsøger at kigge i SNOWMED-CT. Snak om vi skal benytte LOINC, SNOWMED-CT eller et andet kodesystem? Jan mener, at det kunne være rart, at benytte den samme dokument klassifikation for at lette integrationen og brugen af det. Morten kunne oplyse, at HL7 anbefaler at benytte LOINC til dokumenttypen. 3

4 Søren vil gerne vide, om der er tale om en eller flere aftaler. Det er kun en aftale der skal kunne håndteres. Michael Due vil gerne vide, hvordan det skal styres, hvis der er aftaler med flere organisationer. Søren spørger, om vi skal påvirke signalprofilen og lade den åbne op for håndtering af flere dokumenter, men der er tale om to forskellige templates. Thor mener, at for at gøre det operationelt, vil det være bedst, hvis vi forholder os til en aftale pr. dokument. Recordtarget = patienten Author= den ansvarlige organisation/person for bookningen og som har forfattet dokumentet Custodian = de der er ansvarlige for CDA en Morten oplyser, at samtykke skal adresseres, men at det skal koordineres i forhold til dette. Dokument-level template: Hedder 14.1 til sidst, så den følger nummereringen på de øvrige MedCom templates. Bliver opdateret Section-level template: Ender på I Conf. Statement henviser til den originale template i HL7 til vores egen notation, så vi kan se hvor vi fraviger. Der er ændret i de blanke felter i forhold til den originale. Note om at de er identiske og fra hvilke templates de stammer fra. Søren vil gerne vide, hvad man må skrive i titel. Principielt kan man skrive hvad som helst. Entry-level sættes til APT. Morten tjekker op på om er appointment date. Tidspunktet på hvornår bookningen er gennemført. Morten vil indskrive i dokumentet, at value settet er. Encounter effective time skal indeholde start- og sluttidspunkt Performer assignedentity. Time skal fjernes. Det er aftalt, at location også kan være et telemøde. Alexei spørger om hjemmebesøg også skal være en mulighed. Hvad hvis patienten har adressebeskyttelse? Skal vi gøre noget ved det? Hvad hvis mange har mulighed for at se adressen. Hvis ansvar er det at filtrere det fra? Morten undersøger dette. Søren vil gerne vide om WP ikke skal erstattes med PHYS, så det viser, at det er et fysisk mødested. Gennemgang af eksemplet - Appointment entry example: EntryRelationship der er lagt op til en fritekst. Der kunne udarbejdes en kode som kunne lægges ind, men det vil kræve, at MedCom skal udarbejde en kodeoversigt. Author den organisation/eller person der har henvist. Kommer fra placer application. Derefter var der en kort snak om performer, Custodian og author. Michael C. vil gerne vide, om det kunne være interessant, at det i dokumentet kan ses, hvem der udfører hjemmebesøget? Søren mener ikke, at det behøver at være selve personen, men minimum afdelingen. Morten oplyste, at samtykkeservicen pt. fungerer i forhold til CDA-headeren, og da samtykketjek er på dokumentniveau er det korrekt, at lægge det op i mod CDA-headeren. Identification identifier. 4

5 Code der skal foretages ændringer. 4. Eventuelt Thor har set en del opslag fra forskellige kilder på SNOMED OG LOINC og har derfor sendt link, så de rigtige kilder anvendes: Autoriseret LOINC og SNOMED CT opslag: og gå til dansk browser Næste møde afholdes d. 15. marts hos MedCom i Odense. 5