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

Transkript

1 Forskerparken 10 DK-5230 Odense M Telefon: Dato Vor ref. PRJ Referat fra 2. møde om dansk HL7 CDA profil til deling af aftaler Tidspunkt: Onsdag, den 17. januar 2017 kl Sted: MedCom, Forskerparken 10, 5230 Odense M Deltagere: Thor Schliemann, Sundhedsdatastyrelsen Søren Ærendahl Mikkelsen, Lakeside Michael Christensen, Alexandra Instituttet Lars Simensen, Region Midtjylland Flemming Elbrønd, Region Syddanmark Jesper Nielsen, Region Syddanmark Alexei Mihalchuk, A-Data Hans Christian Lund Clausen, DAK-E Christian Jeppesen, Systematic Torben Mejlvang Hagensen, Systematic Jens Villadsen, CSC 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 Tina Archard Heide, Region Nordjylland Lone Kaalund Thiel, Region Nordjylland

2 Jan Bannebjerg, Region Sjælland Uffe Ross Sørensen, Region Hovedstaden 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 og gennemgik dagens agenda. Derefter en kort præsentationsrunde. Der var ingen kommentarer til sidste referat, så det blev godkendt. 2. Opsamling fra sidste møde Baggrundsmateriale Der er oprettet en mappe på SVN en. Der er samme struktur som på PHMR. Principper for profilering Der er modtaget kommentarer fra Lakeside. 1) Profilen bør indledes med et overbliks datadiagram 2) De bærende koncepter i profilen bør forklares og illustreres med figurer 3) Sekvensen i profilens specifikationer bør være den samme som den fysiske XML, kode etc. som profilen specificerer Opsummering af diskussionen fra sidste møde om hvad en aftale er? Hvad er dataindholdet i en aftale og hvem får adgang til borgerens aftaler? Vil kommunernes omsorgs- og træningssystemer også kunne se borgers aftaler på hospital og klinik? Eller er det kun hospitals-systemerne, som får kommunale aftaler ind? Er aftalerne kun tiltænkt en bestemt gruppe borgere? Link fra Thor vedrørende rapport om 'Digital understøttelse af tværgående komplekse patientforløb'. 2

3 3. Begreber Information about a planned meeting may be in the future or past. Describing a single meeting. Examples include a scheduled surgery, at follow-up for a clinical visit, a scheduled conference call between clinicians to discuss a case, the reservation of a piece of diagnostic equipment for a particular use, etc. The visit scheduled by an appointment may be in person or remote (by phone, video conference, etc.). All that matters is that the time and usage of one or more individuals, locations and/or pieces of equipment is being fully or partially reserved for a designated period of time. Patient is a mandatory ressource. Citat fra FHIR, fremsendt af Christian Jeppesen, Systematic Planlagt enkeltstående fysisk eller virtuelt møde i fortiden eller i fremtiden, hel eller delvis reservation af personer og/eller udstyr i en periode. Borgeren er obligatorisk? Søren spurgte, om man ikke bør få et lokale ind, da lokalet er udstyr og at man skal forholde sig til, om det er enkeltstående. Lars og Jan var enige om, at dette vil være en afgrænsning, i forhold til det vi laver nu. 4. User stories Thor gennemgik 3 use cases, hvor rollen var som hhv. patient og/eller pårørende, sundhedsprofessionel eller ansat i hjemmeplejen. Christian ville gerne vide, om det var korrekt fortolket, at oprettelsen er sundhedsorienteret. Hertil kunne Søren oplyse, at den eneste måde at aftalerne kan oprettes på, er via egne systemer og derefter indsendelse af aftalerne. Så hvis en aftale skal kunne ændres af patienten, skal der findes en vej tilbage til bookningen. Al booking foregår i lokale systemer, og dette er der endnu ikke taget hul på, men det kan på sigt blive relevant. Jan gjorde opmærksom på, at aftaler deles via dokumentdelingsservicen og kun den ene vej. Derfor kan der godt ind tænkes nye veje f.eks. via et link. Søren var enig, men mener, at det vil kræve, at der findes noget i den anden ende og det gør der kun enkelte steder. Jens Villadsen ville gerne vide, hvori begrænsningerne ligger? Hertil kunne Jan oplyse, at dokumentet kan hentes ind, men at der derefter ikke kan gøres så meget mere. Søren meddelte, at en eksisterende aftale som slettes vil blive erstattet af en ny. Morten, gjorde opmærksom på at de aftaler der er booket, vil være dem der udstilles til patienten. Det er afgrænsningen, men derfor kan vi godt være opmærksom på de begrænsninger der er. Søren gjorde opmærksom på det fornuftige i at det er eksisterende aftaler, der bliver pushet ud, men at vi skal være opmærksomme på, at aftaler godt kan aflyses/flyttes, så vi derfor skal kunne håndtere ændringer. Thor mener at vi skal kunne synliggøre de aftale der er lavet og at der kan være behov for at vise hvor man kan kontakte redigeringsberettigede. Det er dog måske ikke i denne version, at det skal vises. Christian spurgte, om det er et aftalearkiv vi ønsker. Flemming ville gerne vide, om behovene er afstemt i forhold til f.eks. klinikere. Søren oplyste, at det er undersøgt og at der foreligger en rapport om dette. Rapporten kan ses i her: Jesper gjorde opmærksom på, problematikken omkring hele sikkerhedsaspektet og at vi i profileringen bliver nød til at præcisere, hvem der må se oplysningerne. Hertil kunne Thor meddele, at det er via samtykke- og behandlingsservicen dette skal håndteres og at det også skal håndteres, hvor følsomme oplysningerne er. 3

4 5. Data i en aftale icalendar V2.0 core object se PP Morten mener, at når data i en aftale er fundet, at få det tjekket for at se om det også kan indeholdes i icalandar. FHIR Resource Appointment DSTU2 Morten gennemgik DSTU2. Det kan have interesse for andre klinikere f.eks. i forbindelse med akutte aftaler, at fortiden er med. Hertil oplyste Jan, at det også er godt i forhold til dobbeltundersøgelser. Jens ville gerne vide, hvor en aftale adskiller sig fra en kontakt og om aftalen er rettet mod patienten eller afdelingen? Søren oplyste, at FHIR tager denne problemstilling op (afsnit ) Lars ville gerne vide, hvordan aftalerne kan styres, så borgeren får værdi af disse oplysninger. Thor mener, at vi skal sørge for at ramme noget værdigivende for både borger og sundhedsfagligt personale. Flemming ville gerne vide hvad der skal ske med status på aftalerne. Derefter var der en snak om dette og Morten konkluderede, at vi i specifikationen tillader, at skal der kunne laves aftaler tilbage i tiden. Hertil tilføjede Jan, at vi kun skal have de aftaler med der involvere fysiske aftaler med patienten eller aftaler via video. FHIR Ressource Appointment. Content Morten gennemgik denne. Status ligger på hver eneste participant. Jan ville gerne vide, om der foreligger en header og at det kunne være interessant at vide, hvilke templates man peger på og hvor det vises Søren meddelte, at der findes dokumentation på dette. Bookplan (se PP) SJ2 aftalepilot Vi skal tænke over, hvilken terminologi der benyttes. HL7 v2.x (se PP fra Morten) Er lagt på MedComs Repository. En aftale beskriver overordnet hvorfor, hvem og hvornår og er en service/ressource, de er reserveret i en periode til et specielt formål. HL7 v2.8 begrebsmodel: Placer det system som sender en forespørgsel om en bookning. Filleren det system som udfører selv bookningen. Auxillary application er det vi taler om i dette forum. Når bookningen er gennemført, bliver den lagt over i Auxillary application. I selve standarden findes der en beskrivelse af Filler og Auxillary application. SIU template med 14 forskellige applikation, hvoraf vi skal benytte enkelte af dem. I PP ses beskrivelse af udarbejdelse af SIU template. Morten gennemgik opbygningen af et Schedule Activity information segment. Det indeholder to undertemplate: AIS Appointment Information Service og AIL Appointment 4

5 Information location. Mapning/oversight (se PP fra Morten) Morten har kigget på tværs i de tre dokumenter for at finde eventuelle ligheder. Derefter var der en snak om hvilke element navne, der er bedst at anvende. Christian mener at det er vigtigt at kunne håndtere, at vi skal have en reference til konteksten. Jens tilføjede, at en del ligger i headeren og at det bliver en kamp af få de ting der nævnes ind i standarden. Michael D.M syntes, at det er vigtigt at holde fast i, at det er borgerens aftale og at det er det vi skal tage udgangspunkt i. Hvis det er knyttet til et forløb ved borgeren godt, hvor aftalen er født. Jan oplyste, at vi ikke har forløbsregistrering i det danske sundhedsvæsen, så på sigt skal denne opgave kunne løses. Bare ikke nu og ikke i denne standard. Morten tilføjede, at der findes en minimumsliste, så der er en del af rollerne, som skal med. Thor syntes, at det er vigtigt at vi finder de helt klare og rigtige behov og ikke hvad der er nice-to have. Så må der tages en 2. runde, hvis der bliver behov for yderligere. Søren mener, at vi skal udarbejde et format, der er relevant for alle og ikke kun for borgeren. Hertil spørger Thor om vi så ikke lander på, at mødestedet for patienten skal med, men at klinikeren sandsynligvis vil benytte sit eget system. Discription er borgervendt og reason er sundhedsfaglig vendt. Vi skal starte med, at det er borgervendt for at gøre det så simpelt som muligt. Jan præciserede, at det skal være et redskab til at vise hvor og hvornår patienten har været eller er optaget. Ikke til kliniske overvejelser. Hans ville gerne vide, om det kan håndteres, at patienten skal tale med både en læge og en sygeplejerske på samme tid. Det burde Bookplan kunne håndtere. Søren meddelte, at det kunne være relevant, at der kan linkes til supplerende informationer i en indkaldelse. (Filler supplemental information) Morten vil gerne have tilbagemeldinger på slides vedrørende dataelementer oversigt 1 og HL7 CDA struktur CDA generelt Clinical notes se PP fra MBR Beskrivelse af templates og praktisk erfaring (HL7 implementation _Guide for CDA release 2: consolidate CDA templates for clinical notes) Dokumentet bliver lagt på SVN en. Morten har kigget efter hvilke templates der er i dette dokument. Appointments står ikke i indholdsfortegnelsen, men er beskrevet i dokumentet. I det fremadrettede arbejder indgår der en række dokumenter bl.a. HL7 implementation _Guide for CDA release 2: consolidate CDA templates for Clinical notes og MedComs HL7 Implementation Guide for CDA release 2.0 CDA Header. Jens oplyste, at han har stor gavn af at benytte Art Decor til udarbejdelse af CDA profiler, hvor bl.a. er mulighed for at tilføje semantik. Morten har en video om Art Decor, som han kan vise på et tidspunkt. HL7 RIM v3 Core Classes (se PP fra Morten) RIM en ligger til grund for CDA eren og giver god mening at benytte. Kernen er klassen ACT (procedure observation, pt. encounter, substance adm. Financial act.) 5

6 Morten gav en forklaring på, hvordan ACT virker. HL7 v.3 Scheduling DMIM Skemaet er stadig gældende og er udarbejdet i Jan oplyste, at notationsformen ikke er alment gældende. CDA structure (se PP fra Morten) Morten gav en forklaring på figuren. C-CDA. Planned Encounter (Se PP fra Morten) En template der viser hvilke elementer der skal benyttes. Søren mener at vi sagtens selv kan udarbejde templates med vores egne restriktioner. C-CDA. Planned Encounter. Ex. (se PP fra Morten) Plan of appointments (se PP fra Morten) Hvad nu? Udarbejdelse af CDA Validering 3. møde i gruppen afholdes d. 22. februar 2017 Søren meddelte, at nogle regioner har SOR med i Bookplan og andre har ikke, hvilket godt kan skabe en del udfordringer. Jan mener ikke, at aftaler skal sættes lig med Encounter, idet man sagtens kan have en kontakt og en Encounter, uden at have en aftale. 7. FHIR Diskussion: hvordan koordineres udviklingen og udbredelsen? Morten stillede nedenstående spørgsmål omkring HL7 FHIR profilering i Danmark som oplæg til diskussion: 1. Udviklingen af HL7 FHIR vil betyde, at enhver kan arbejde HL7-FHIR profiler, baseret på core FHIR? Dette er korrekt. 2. Udviklingen vil betyde, at der udvikles forskellige og overlappende profiler med det samme formål. Som publiceres via forskellige kilder, uden forudgående validering? Dette er korrekt. 3. Brugerne vil finde mange forskellige kilder som publicerer HL7-FHIR profiler, uden at vide om et profil opfylder de funktionelle krav eller kravene i lovgivningen. Dette er ikke formålet, men det vil være tilfældet. 4. Situationen vil fremme kaos i stedet for standardisering? Dette er ikke korrekt Ovenstående blev diskuteret og følgende nedenstående kommentarer er trukket ud: Christian mente, at profilerne skal udstilles og at serveren kan gemme en vilkårlig profilering Jens tilføjede, at det kan gøres for alle profiler, men at det bare er lettere med FHIR. Morten mente ikke, at vi har besluttet at køre FHIR i Danmark endnu, så at vi derfor er nød til at træffe nogle aftaler. Jens foreslog, at vi eventuelt kunne kontakte HL7 Danish Affiliate, da de helt sikkert kan svare på mange af vores spørgsmål. Thor foreslog, at det måske vil være en god idé at arrangere en mødedag med de rette parter. 6

7 Morten pilotprojekt på FHIR. Er er nogen som kan begynde at påtage sig rollen med CORE? Christian meddelte, at Bookplan har udarbejdet en FHIR profil. Jan tilføjede, at hovedopgaven i dette projekt er at udarbejde en CDA, der kan indgå i en allerede eksisterende arkitektur og at det kunne være interessant, at få Systematic mere på banen. Jens mener, at det virker modstridende, når det fra NSI ligger beslutninger om, at vi ikke skal læne os op af FHIR. Han ser det ikke som en del af standardkataloget endnu. I gruppen anerkendes det, at der er noget der hedder FHIR og det er derfor, at det inddrages Christian spurgte, om Systematic skal prøve at udarbejde en løsning på en Appointment FHIR profil, som kan vises på næste møde. Det kræver dog at nogle leverer listen med attributter og det skal ligeledes først undersøges, om Systematic har ressourcer til at løse opgaven. Jens forslog, at man kunne gøre det samme med CDA profil for at kunne sammenligne de to løsninger. Thor roste leverandørerne for at sætte sig i de problemer, der har været med CDA erne. 8. Eventuelt Næste møde er d. 22. februar 2017 hos MedCom, Odense. 7