Prosjektrapport. Nasjonal IKTs tiltak 41

Størrelse: px
Begynne med side:

Download "Prosjektrapport. Nasjonal IKTs tiltak 41"

Transkript

1 Prosjektrapport Nasjonal IKTs tiltak 41 Bruk av arketype-metodikk til definisjon, tilgjengeliggjøring og bruk av kliniske informasjonsmodeller i helseinformasjonssystemer ~ Erfaringer og anbefalte oppfølgingstiltak ~

2 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Innhold 1 Innledning Bakgrunn Hovedmål for tiltak Leveranser Gjennomføring Resultater og erfaringer Forslag til oppfølging Valg av referansemodell Valg av verktøy Utredning SNOMED CT Videreutvikling og forvaltning av kliniske informasjonsmodeller Situasjonsanalyse Kort om arketype-metodikken Nasjonal standardisering av EPJ innhold Innledning EPJ innholdsstandarder vs. openehr arketyper Arketype-metodikk i Norge Terminologibinding i arketyper og templater Bruk av arketyper internasjonalt NHS (England) EN13606 association Danmark Sverige Tekniske erfaringer Innledning Arketyper og templater Fra datamodell til faktiske data Persistering og spørring Bruk av eksisterende data Hvordan dele arketyper og templater Forhold til sektorens samhandlingsarkitektur og -plattform Designverktøy Kliniske informasjonsmodeller Avgrensning - utvelgelse av opplysninger Utvikling av arketyper - erfaringer Vedlegg A - Prosjektorganisasjonen Prosjektgruppen Styringsgruppen

3 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Tabeller Tabell 1: Forskjeller i terminologi mellom CKM, AE og Mind map...24 Tabell 2: Oversikt over arketyper som ble utviklet/vurdert utviklet, samt de tilknyttede Cluster..33 Tabell 3: Arketyper av type cluster/element som refereres fra arketypene over...36 Tabell 4: Medlemmer i prosjektgruppen...37 Tabell 5: Medlemmer i styringsgruppen...37 Figur 1: Abstrakssjonskjeden fra arketype til faktiske data (OTI)...18 Figur 2: Oppstartsbildet til Clinical Knowledge Manager (CKM)...20 Figur 3: Samhandlingsarkitekturen v Figur 4: To aktører som benytter en felles samhandlingsplattform for å være archetype enabled...22 Figur 5: Eksempel på en arketype oversatt til norsk bokmål (nb)...23 Figur 6: ADL Workbench...25 Figur 7: Ocean Template Designer med generert skjermbilde av en arketype oversatt til norsk bokmål (nb)...26 Figur 8: LinkEHR - samme arketype som i fig. 5 og Figur 9: Tankekartet for indirekte oksymetri

4 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars 1 Innledning 1.1 Bakgrunn Denne rapporten sammenfatter erfaringer og leveranser fra Nasjonal IKTs tiltak 41, gjennomført i perioden april april. Prosjektet ble initiert av Nasjonal IKT som en oppfølging av Nasjonal IKTs tiltak 27. Tiltak 27 ble gjennomført i perioden , og resulterte i følgende oppfølgingstiltak: 1) et pilotprosjekt for utprøving av arketype-metodikk (gjennomført som tiltak 41) 2) et prosjekt for standardisering av termer og symboler i brukergrensesnitt i kurvesystemer (gjennomført som tiltak 39). Tiltak 41 ble organisert med en ekstern prosjektgruppe med representanter fra helseregionene, samt en KITH 1 -arbeidsgruppe som arbeidet sammen med de eksterne representantene. KITH-arbeidsgruppen har bred kompetanse både på arkitektur, EPJ, helsefag og terminologi som er viktig og nødvendig i arbeidet med arketyper. Samlet benevnes disse to gruppene prosjektgruppen i det følgende. Oversikt over prosjektdeltagerne i vedlegg A. 1.2 Hovedmål for tiltak 41 Følgende hovedmål ble satt for prosjektet i prosjektdirektivet: Prosjektet skal fungere som et pilotprosjekt hvor en skal skaffe til veie erfaringer med bruk av metodikk tilknyttet arketyper innenfor spesialisthelsetjenesten i Norge. Dette skal gjennomføres med utgangspunkt i elektroniske kurvesystemer og ett eller flere utvalgte kvalitetsregistre. Ved prosjektets start var det ikke foretatt en kost-nytte vurdering. Det kan imidlertid nevnes at kostnytte må sees i sammenheng med at dette prosjektet skal prøve ut noe nytt og høste erfaringer med to teknologier som er utviklet internasjonalt. Som sådan vil prosjektet derfor gi begrenset direkte nytteverdi, men kan likevel potensielt bli svært viktig. Det er forhåpentligvis nå som en følge av dette prosjektet tydeligere hva de faktiske gevinster og kostnader er ved bruk av arketype-metodikk. Hvis man beslutter å gå videre med de anbefalte tiltak bør det gjøres en kost-nytte-vurdering i en tidlig fase. 1.3 Leveranser Prosjektet skulle levere følgende (fra prosjektdirektivet): Prosjektet skal realisere et bibliotek av datastrukturer med tilhørende terminologi til bruk i elektroniske kurvesystemer og medisinske kvalitetsregistre. Dette vil bli levert som et sett av tekstfiler og det må avklares hvordan dette resultatet skal publiseres/tilgjengeliggjøres for utprøving. 1 KITH ble fra 1.1. en del av Helsedirektoratet, som Avdeling standardisering. 4

5 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Prosjektet skal utarbeide en erfaringsbasert orientering om hvordan arketyper og templater kan realiseres i tekniske løsninger, rettet mot IT-arkitekter og leverandører. Se kapittel 3 Tekniske erfaringer. 1.4 Gjennomføring KITH har forberedt materiale til prosjektgruppemøtene og fasilitert arbeidet på og mellom møtene. Det har vært dialog med andre land som har prøvd deler av metodikken. De land vi har skaffet oss mest kunnskap om er våre naboland Sverige og Danmark, samt NHS England. Den KITH gjennomførte i starten av prosjektet en informasjonsinnhenting ved å besøke CeHis i Sverige, hvor mye nyttig informasjon tilfløt oss. Vi har også skaffet oss informasjon ved å kontakte personer i andre land og ved å bruke openehr e- post-lister. Vi har også hatt dialog med nasjonale kvalitetsregistermiljø (Hemit/SKDE/Norsk intensivregister). I august 2011 ble det arrangert et todagers kurs i openehr-metodikk i Trondheim. Kursholderne var Thomas Beale og Ian McNicoll fra Ocean Informatics. Deltagere var representanter fra regionene og leverandørene, prosjektgruppen, samt fra ansatte fra KITH. Høsten 2011 ble det initiert en prosess for å involvere leverandørene i utarbeidelsen av den erfaringsbaserte tekniske orienteringen. Det er forskjellig nivå på interessen fra leverandørene. Noen leverandører, som DIPS, virker å være aktivt utprøvende på området. Siemens benyttes også hovedelementer fra metodikken, men kun egne verktøy. Kurveleverandørene (IMDSoft - MetaVision, Philips - ICIP, Draeger/Siemens - PICIS) har det vi vet ikke benyttet metodikken. Det ble invitert til et dialogmøte for leverandører 18. januar, men det kom ingen påmeldinger så møtet ble avlyst. Årsaken til den manglende interessen kan vi kun spekulere i; Det kan være et prioriteringsspørsmål, teknologien kan oppfattes som umoden, eller også så oppfatter de interesserte å ha gitt de innspill som er nødvendig i prosessen. Gjennom prosjektperioden er det blitt gjennomført 8 heldagsmøter med prosjektgruppen. Siste møte var januar, der temaet var terminologibinding. Etter dette har arbeidet bestått i oppsummering, rapportskriving og rapportering. 1.5 Resultater og erfaringer Hovedmålet er oppnådd, forhåpentligvis i den grad og kvalitet som var forventet fra oppdragsgiver. Vår hovederfaring er at det internasjonale arbeidet ikke har nådd kritisk masse ennå, verken på verktøysiden eller på innholdssiden, og det er krefter som drar dette i noe feil retning (nasjonale repositorier/ckm-er, jf. Sverige og Australia), istedenfor å konsolidere den internasjonale utviklingen av arketyper. Det er også noe tett binding mellom openehr og Ocean Informatics, selv om andre enn Ocean kan tilby f.eks. arketype-editor. Prosjektet har levert et sett med 30 arketyper. Antallet er ikke sentralt, det er erfaringene med utviklingen av disse som er viktig. Prosjektgruppen er klar på at arbeidet med arketypene nok må gå i flere runder for å validere arbeidet. Likevel danner de 30 en god basis i det videre arbeidet med kliniske datamodeller for helseinformasjonssystemer. 5

6 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Terminologibindingen i arketypene er ikke komplett, men dette er klarert med styringsgruppen underveis i prosjektet. Det viktige er at terminologibinding som konsept belyses og at man vet hvordan dette skal håndteres i videre arbeid med arketypene. Prosjektet anbefaler at publisering av utkastene til arketyper håndteres av Helsedirektoratet, ved Avd. standardisering. Videreutvikling av innholdet bør håndteres i samarbeid med Nasjonal IKT og etter hvert også andre aktører som har behov for å utarbeide kliniske informasjonsmodeller. De tekniske erfaringer som er gjort i prosjektet beskrives i kapittel 3 - Tekniske erfaringer. Mer om erfaringer fra prosessen med å velge ut, oversette, tilpasse og utvikle arketypene i kapittel 4 - Kliniske informasjonsmodeller - erfaringer. Andre resultater relatert til prosjektet som er verdt å nevne: - Prosess påstartet i Avd. standardisering for å se på framtidig innholdsstandardisering opp mot felles informasjonsobjekter (for eksempel til bruk i Universalmelding ) - Utkast til revidert nasjonal standard for forskrivning utarbeidet av avd. standardisering, Helsedirektoratet. Dette utkastet er i henhold til informasjonsmodellen i eresept der det er relevant. Utkastet lå til grunn for en utarbeidelse av en arketype for forskrivning. 1.6 Forslag til oppfølging Det er etablert konsensus i prosjektgruppen om at det er en god og fornuftig tilnærming med å skille kliniske informasjonsmodeller fra informasjonssystemenes interne datamodeller. For å kunne gå videre med utvikling av kliniske informasjonsmodeller på nasjonalt nivå er flere oppfølgingstiltak nødvendige: - valg av referansemodell - valg av verktøy - etablering av en forvaltningsmodell Oppfølgingstiltakene blir utdypet nedenfor Valg av referansemodell Hvilken referansemodell man i fremtiden faktisk skal knytte disse kliniske domenemodellene opp mot er et valg som må tas i en egen prosess. Ikke minst må man, før et slikt valg tas, finne ut hvilke egenskaper en referansemodell faktisk skal inneha for å kunne uttrykke klinisk domenekunnskap som samtidig er operasjonaliserbart innenfor informasjonssystemer. Dagens EPJ-standard (del 3) må her sees opp mot ulike komplementære/ alternative modeller (ISO ( EHRCOM ), openehr (v.1.0.2), HL7 v3 RIM etc.). Nasjonal IKTs Fagfora Arkitektur / Klinisk IKT er en naturlige samarbeidspartnere til Helsedirektoratet/avd. standardisering i en slik prosess Valg av verktøy Verktøyene vi i all hovedsak har testet er innrettet mot openehr, men andre verktøy skal i følge dokumentasjonen kunne håndtere arketyper som refererer til andre referansemodeller 2. 2 Se for eksempel 6

7 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Gode verktøy anses som svært avgjørende for hvorvidt bruk av arketyper vil kunne fremstå som en arkitektonisk tilnærming til fremtidige kliniske fagsystemer. Her vil det være nødvendig med grundige vurderinger: - verktøyene må være av tilstrekkelig kvalitet, og ha den funksjonalitet som er nødvendig for kollaborativ utvikling av kliniske informasjonsmodeller. - en bør unngå for sterk binding til én enkelt leverandør, mht. pris/kvalitet (en må også vurdere soliditet ift. å kunne forvente support, videreutvikling, mv.). Eksempelvis er det så vidt vi vet kun Ocean Informatics som tilbyr CKM-lignende verktøy Utredning SNOMED CT På nasjonalt plan er vi i Norge avventende til bruk av den internasjonale terminologien SNOMED CT 3. Siden KITH-utredningen i 2009 har organisasjonen som forvalter SNOMED CT økt i størrelse, det er pt. 18 land som er medlemmer av organisasjonen. Det bør vurderes om det skal settes i gang et større nasjonalt utredningsarbeid for å utrede bruk av SNOMED CT og/eller andre internasjonale helsefaglige terminologier i Norge Videreutvikling og forvaltning av kliniske informasjonsmodeller De 30 utviklede arketypene kan danne en basis for videreutviklingen av kliniske informasjonsmodeller til bruk i spesialisthelsetjenesten. Et viktig spørsmål mht. utvikling av kliniske informasjonsmodeller er hvordan prosessen skal organiseres mht. innmelding av behov, beslutning om utvikling, og ikke minst forvaltning av det som blir utviklet. Nasjonal IKTs styringsgruppe bør vurdere om Nasjonal IKTs klinisk IKT-forum kan ivareta roller som igangsetter av aktiviteter for utvikling av arketyper for bruk i spesialisthelsetjenesten. Avd. standardisering i Helsedirektoratet bør kunne inneha et koordinerings-/oppfølgingsansvar, på lik linje med annen standardiseringsaktivitet. 3 Se KITH Rapport nr. 06/09. SNOMED CT: Status for 9 land og anbefaling for videre arbeid i Norge 7

8 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars 2 Situasjonsanalyse 2.1 Kort om arketype-metodikken Kort sagt er arketyper en metodikk som gjør det mulig å kunne skille informasjonssystemenes datamodell fra kliniske informasjonsmodeller. Et slikt skille betyr at helsepersonell kan arbeide med kliniske informasjonsmodellen uten å måtte tenke altfor mye på generelle forhold omkring informasjonsmodell, f.eks. tilgang, signering, endring, etc. For en mer teknisk visualisering av dette, se figur 4 i kapittel 3. Historikken 4 for arketyper innen helse går tilbake til tidlig 90-tall med ulike forskningsprosjekter i europeisk regi (for eksempel Good Electronic Health Record - GEHR). Metodikken ble nedfelt i standarder fra CEN 5 /ISO, senest i ISO (2007) fra ISO, men er senere videreutviklet og forbedret innenfor openehr-rammeverket 6. CEN-standarden fokuserte på informasjonsutveksling ved bruk av arketyper, mens openehr-rammeverket benytter arketyper også for system-intern håndtering av klinisk informasjon. Forskjellene mellom EN13606 og openehr er små, den tydeligste forskjellen er openehrs arbeid med informasjonstyper som har resultert i en spesialisering av ENTRY-classen (i Instruction, Action, Evaluation, Observation). Arketyper har potensial til å bli benyttet også for informasjonsutveksling, men dette betinger en viss utbredelse av metodikken i leverandørsystemene. 2.2 Nasjonal standardisering av EPJ innhold Innledning KITH har i samarbeid med aktørene i helsesektoren utarbeidet en rekke standarder med relevans for EPJ. Den viktigste av disse omtales gjerne som den grunnleggende EPJ-standarden. Den ble opprinnelig utviklet i perioden og revidert i Denne standarden dekker kun helt grunnleggende egenskaper ved EPJ-system. Den inneholder ingen krav til helsefaglig innhold, med den inkluderer innholdsstandarder for mer grunnleggende opplysninger om pasienter, pårørende, virksomheter, organisatoriske enheter, helsepersonell, autorisasjoner, dokumentasjon av tilgang etc. Basert på denne standarden er det senere utarbeidet en rekke standarder for informasjonsinnhold i EPJ samt et antall kravspesifikasjoner som beskriver funksjonelle krav til EPJ-systemer. Utarbeidelsen av den grunnleggende EPJ-standarden skjedde i parallell med det som senere har blitt den europeiske og internasjonale standarden for kommunikasjon av EPJ innhold, EHRCOM 7. Det ble 4 Historikken bak EN13606/openEHR, se 5 European Committee for Standardization / Comité Européen de Normalisation, se introduksjon til openehr-arkitekturen: 7 EHRCOM benyttes i det etterfølgende som en fellesbetegnelse for CEN og ISO-standardene i serien. 8

9 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING derfor lagt stor vekt på at den generiske arkitekturen som ble utarbeidet av KITH, skulle være kompatibel med tilsvarende arkitektur i EHRCOM. Det er imidlertid enkelte forskjeller mellom de to informasjonsarkitekturene, noe som delvis skyldes at formålet med de to standardene er noe forskjellig. Mens formålet med EHRCOM er begrenset til kommunikasjon av utdrag fra elektroniske pasientjournaler (EHR extract), er formålet til den grunnleggende EPJ-standarden mye videre og inkluderer bl.a. bevaring av enhver type EPJ på tvers av teknologiske generasjonsskifter. Som en følge av forskjellen i formål er den grunnleggende EPJ-standarden mer generell enn EHRCOM ettersom den må kunne håndtere enhver opplysning i EPJ, også de som ble registrert før standarden ble utviklet. Standarden inneholder derfor ikke noen obligatoriske krav til innhold som må oppfylles ved registrering av opplysninger. Dette i motsetning til EHRCOM som både inneholder obligatoriske metadata som må registreres, og som er mer restriktiv når det gjelder informasjonsstruktur. En konsekvens av forskjellene er at enhver opplysning som kan håndteres av EHRCOM, vil kunne representeres tapsfritt vha. informasjonsarkitekturen i den grunnleggende EPJ-standarden. En transformasjon motsatt vei vil derimot bare kunne gjennomføres tapsfritt dersom de krav EHRCOM stiller til registreringer er fulgt. For eldre registreringer hvor de påkrevde metadata mv. mangler, vil en under en eventuell transformasjon måtte sette til fiktive metadata og eventuelt også foreta noen justeringer av informasjonsstrukturen. Men også her vil selve meningsinnholdet kunne bevares. Dette innebærer at et EPJ-system som oppfyller informasjonsarkitekturkravene fra den grunnleggende EPJ-standarden prinsipielt sett også bør kunne håndtere alle typer opplysninger som kan kommuniseres med EHRCOM EPJ innholdsstandarder vs. openehr arketyper Den referansemodellen som openehr benytter, er en lett modifisert og videreutviklet versjon av EHRCOM referansemodell. Utgangspunktet for openehr Archetypes er komponenttypen Entry som openehr har utvidet med et antall spesialiseringer, Admin Entry, Observation, Evaluation, Instruction og Action. Entry tilsvarer komponenttypen EPJ fragment i den grunnleggende EPJ-standarden, og det er uten videre mulig å etablere tilsvarende spesialiseringer (Observation etc.) av EPJ fragment som openehr har gjort for Entry. Gjennom en slik tilnærming vil openehr Archetypes rimelig greit kunne omdannes til innholdsstandarder for EPJ fragmenter. Templates benyttes for å sette sammen et antall archetypes for bruk ved en bestemt type registrering. En slik registrering utgjør en Composition, en komponenttype som tilsvarer EPJ dokument i den grunnleggende EPJ-standarden. Gjennom en Template kan det innføres beskrankninger (constraints) på hvordan den enkelte Archetype skal benyttes. Gjennom slike beskrankninger kan en f.eks. fjerne dataelementer som ikke er obligatoriske, og en kan begrense verdiområdet for dataelementer. Men det kan ikke føyes til nye dataelementer eller øke verdiområdet for et dataelement ut over det som den aktuelle Archetype angir. I den grunnleggende EPJ-standarden er det ikke beskrevet noen syntaks for å angi beskrankninger dersom en type EPJ fragment skal benyttes i flere forskjellige typer EPJ dokument. Eventuelle beskrankninger må derfor angis som en kommentar, f.eks. at et bestemt dataelement ikke skal benyttes eller at kun en delmengde fra et kodeverk skal benyttes ved registrering i et dataelement. Å omdanne 9

10 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars en Template til en EPJ dokumenttype bør derfor også kunne gå greit, men her vil det nok kreves noe manuell bearbeiding for å håndtere eventuelle beskrankninger som er angitt. Å omdanne innholdsstandarder for en type EPJ fragment til en Archetype vil kunne gå greit dersom en baserer seg direkte på EHRCOM sin referansemodell. Dersom openehr sin referansemodell med spesialiseringene av Entry skal benyttes, vil det imidlertid kreves en manuell vurdering for å avgjøre hvilken av spesialiseringene som passer for hver enkelt type EPJ fragment og det vil trolig også kunne bli en utfordring å avgjøre hvordan innholdet i den aktuelle typen EPJ fragment best kan representeres vha. openehr referansemodell. Å omdanne innholdsstandard for en type EPJ dokument til en Template vil være problemfritt dersom det først er etablert Archetypes for alle de typer EPJ fragment som inngår. Oppsummert så vil trolig det beste alternativet være å benytte EHRCOM referansemodell som utgangspunkt dersom EPJ innholdsstandarder skal omdannes til Archetypes og Templates. Dette fordi en ved utvikling av EPJ innholdsstandarder ikke har vært underlagt de begrensninger i frihetsgrad som følger av de spesialiseringene av Entry som openehr har tilføyd Arketype-metodikk i Norge Forprosjekt for nasjonal definisjonskatalog for kliniske variabler i elektronisk pasientjournal og tilknyttede fagsystemer (Nasjonal IKT Tiltak 27) foreslo i sin sluttrapport 9 at det skulle etableres et pilotprosjekt for å skaffe erfaring og kartlegge konsekvenser omkring bruk av arketyper/terminologibinding/snomed CT i et kurvesystem. Daværende KITH (nå Avdeling standardisering i Helsedirektoratet) som gjennomførte dette forprosjektet på oppdrag fra Nasjonal IKT hadde fulgt med arketype-aktivitetene internasjonalt, spesielt Danmark, Sverige og England. KITH fulgte også med internasjonalt arbeid rundt SNOMED CT, spesielt også i Danmark og Sverige. I motsetning til våre naboland Danmark og Sverige har Norge vært avventende når det gjelder nasjonal satsing på SNOMED CT. For å kunne oversette SNOMED CT til norsk, må Norge være medlem i IHTSDO. Ettersom Norge ikke er medlem i IHTSDO og heller ikke har besluttet om vi skal bli med, fikk ikke dette prosjektet tilgang/lisens til å kunne oversette de deler av SNOMED CT som er relevant å binde arketypene til. 2.4 Terminologibinding i arketyper og templater Terminologibinding er en formelt uttrykt forbindelse mellom en representasjon av en informasjonsmodell og en terminologirepresentasjon av kliniske uttrykk, registrert i et helseinformasjonssystem (oversatt/tilpasset fra Beale, openehr training material, 2010). Formålet med terminologibinding er: 1) Sikre standardisert informasjonsutveksling av kliniske og administrative opplysninger. Sikre bruk av samme begreper på tvers av ulike arketyper og templater. 8 I sitt arbeid med Archetypes har for øvrig Sverige valgt å ta utgangspunkt i EHRCOM sin referansemodell og bygd den ut etter eget behov

11 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 2) Muliggjøre sekundær bruk av data gjennom spørringer på registrerte data. Spørringer kan da referere til samme terminologi. 3) Sikre lik implementasjon av kliniske informasjonsmodeller i systemer ved at betydningen til begreper i arketyper/templater tydeliggjøres. Dette har vært påpekt som en fordel av leverandører i arketypeutprøvingen i Danmark (se egen seksjon om Danmark nedenfor). Det er ulike måter å binde en arketype eller et templat opp mot en terminologi: - Binde til spesifikt begrep i en annen terminologi (det er mulig å binde til flere terminologier) - Binde til et verdisett i en eller flere terminologier eller til et utvalg verdier fra en eller flere terminologier - Binde til et sammensatt begrep (post-koordinert), dvs. et begrep som lages på basis av eksisterende begrep i en eksisterende terminologi. Dette er mulig mot for eksempel SNOMED CT det er laget en egen syntaks for dette 10. NHS England og HL7 Terminfo har utviklet denne grammatikken noe videre 11. NHS bruker grammatikken sammen med sine datamodeller. Formelt gjøres terminologibinding i arketyper (på generelt plan) og i template-designer (mer spesifikt til et utvalg verdier, eksempelvis). Terminologibinding finnes allerede på det generelle planet i mange eksisterende arketyper fra openehr. Terminologibindingen er en prosess, og pga. kompleksiteten til datastrukturer og terminologier er det mulig å gjøre ulike valg og å velge å gjøre ting på forskjellig måte. Spesielt er dette et moment ved bruk av SNOMED CT. Det er derfor en fordel om bindingene kan være så lite komplekse som mulig. Forutsetninger for knytning til spesifikke begreper: Terminologien må kunne nås gjennom en datamaskinell link til relevant begrep/verdisett Terminologikompetanse man vil måtte anta at terminologibindingen må gjennomgåes i flere runder. Man må ha lisens til å bruke terminologien til det konkrete formålet Terminologien må være lagt inn i listen over tilgjengelige terminologier i arketype-editoren. Hvordan dette gjøres er ikke selvforklarende men vi har funnet en løsning. Se kapittel 3 - Tekniske erfaringer. Volven 12 er en nasjonal metadatabase for helsesektoren. Her ligger mange hundre kodeverk som er utviklet gjennom arbeid med meldinger, EPJ-standarder og kravspesifikasjoner. Det eksisterer i dag webservicer opp mot disse kodeverkene som muliggjør terminologibinding fra arketyper opp mot kodeverk på Volven. Disse webservicer er planlagt revidert for bedre tilgjengeliggjøring av alt innhold om kodeverk. Imidlertid må det skrives et stykke programvare for å integrere arketype-editor og templatedesigner opp mot Volven. Det bør gjøres på en standardisert måte, f.eks. ihht. CTS 2 13 (Common terminology services - 2). Mer om terminologbinding ved bruk av verktøy, se kapittel 3 - Tekniske erfaringer Common Terminology Services

12 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Det er relativt opplagt at det kan lønne seg å bruke så få ulike kilder til terminologi som mulig. Allerede i dag er en relativt homogen kilde i Volven. Selv om løsningen har svakheter, er den en god kilde til standardiserte kodeverk og terminologier til bruk i kliniske informasjonsmodeller. I tillegg er det en rekke nasjonale klassifikasjoner som kan være aktuelle å knytte opp mot arketyper: ICD-10, NCSP, NCMP, NCRP, ICF, NEKLAB, ICPC-2 og Den norske SNOMED. På arketypenivå er det aktuelt å knytte en attributt opp mot en eller flere klassifikasjoner, eller opp mot deler av klassifikasjonene. På templatnivå kan det være aktuelt å avgrense hvilke verdier fra klassifikasjonene som skal være tilgjengelige for bruk. Internasjonalt er terminologien SNOMED CT en kilde til standardisert terminologi som prosjektet hadde ønske om å test ut terminologibinding til. SNOMED CT forvaltes av IHTSDO 14, som er en medlemsorganisasjon med 18 land - Norge er ikke medlem. Etter en prosess i 2011 ble det som nevnt over klart at uten et nasjonalt medlemskap i IHTSDO kunne vi ikke oversette de deler av SNOMED CT som er relevant for dette prosjektet. Prosjektgruppen fikk likevel prøvd seg litt på terminologien gjennom ulike fritt tilgjengelige søkeverktøy 15. Det ble konstatert at det krever erfaring (prøving/feiling) for å kunne gjøre en god terminologibinding av informasjonsmodellene (arketypene). Det ble også konstatert at SNOMED CT har både styrker og svakheter; det virker ikke systematisk gjennomført hvilken bredde og dybde SNOMED CT skal ha. Prosjektgruppen mener det er best at terminologibinding på arketype-nivået gjøres av en internasjonal standardiseringsorganisasjon, for eksempel IHTSDO. Faren ved at nasjonale prosjekter gjør denne bindingen er at det oppstår ulike bindinger i ulike prosjekter (en konsekvens av at prosessen med å binde til terminologi er kompleks og ikke-triviell). Dette vil da kunne føre til at man ikke får ønsket semantisk interoperabilitet i informasjonsutvekslingen. På templat-nivå vil det nok være forskjeller mellom prosjekter pga. ulike nasjonale kontekster, så her bør nasjonale standardiseringsorganisasjoner ha ansvaret for terminologibindingen. 2.5 Bruk av arketyper internasjonalt I følge openehr 16 er det per skrivende stund 10 prosjekter, deriblant nasjonale prosjekt i Danmark og Sverige, som bruker eller er interessert i bruk av openehr. I de fleste land er det frittstående grupperinger, og ikke nasjonale prosjekter som jobber med openehr-baserte løsninger. openehr samarbeider dessuten med andre tilsvarende internasjonale miljøer innen klinisk modellering, deriblant og hvor man kom frem til en felles erklæring 17,18 på at gruppen (kalt CIMI Clinical Information Modeling Initiative) sine spesifikasjoner av helseinformasjonsinnhold skal gjøres fritt og gratis tilgjengelig skal gjøres tilgjengelig i flere ulike formater, og til å begynne med i ADL (Archetype Definition Languange), og UML (Unified Modeling Language)

13 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Det som er interessant er at flere nasjonale helsemyndigheter/-organer også sto bak dette initiativet og denne erklæringen, deriblant Canada Health Infoway, National Institute of Health (USA) og NHS Connecting for Health (CFH, England). 2.6 NHS (England) NHS Connecting for Health (England) hadde i 2007 et prosjekt med å definere opp en hel rekke arketyper. Erfaringer fra dette arbeidet gjorde at de gikk bort fra en ren arketype-tilnærming. Det gikk i flere runder med litt ulike tilnærminger til bl.a. terminologibinding. Nedenfor følger noen av de viktigste erfaringene deres: De erfarte at det var vanskelig å avgrense hva som skal være med i en arketype (ihht. teorien skal de være maksimums-datasett). De erfarte at det var vanskelig å vedlikeholde arketypene spesielt i de tilfellene der man skal kunne gjenbruke definisjoner av strukturer som går igjen i ulike arketyper. De fant også ut at det var vanskelig å forstå/bruke forskjellen mellom typene Observation og Evaluation. Tilnærmingen som de baserer seg på nå er EHRCOM sin referansemodell, som de benytter sammen med arketype-lignende Composition, Entry og Element-modeller 19. UK/CFH har også stort fokus på SNOMED CT og benytter som nevnt egen grammatikk for å kunne bygge opp og analysere kliniske uttrykk som verdier for attributter i modellene. Deler av tiltak 41-prosjektgruppen er skeptisk til en slik tilnærming, da det krever en måte å tolke innholdet i attributter etter en modell som ikke er en del av informasjonsmodellen som sådan. Dvs. det er to ulike modeller som skal operere sammen, og det er gjerne noe man forsøker å unngå sett fra et ITfaglig perspektiv. 2.7 EN13606 association Det er opprettet en stiftelse/forening 20 ved navn EN13606 association for utbredelse og revisjon av EHRCOM. 2.8 Danmark I regi av daværende Digital Sundhed ble det i Danmark gjennomført et utprøvingsprosjekt (proof-ofconcept) på arketyper, i perioden august 2008 til februar Dette var et analyse- og veiviserprosjekt. Det ble kjørt to spor i prosjektet: et helsefaglig spor med fokus på å uttrykke det helsefaglige innholdet ( sundhedsfaglig innhold ) ved hjelp av arketyper, og et leverandørspor med syv leverandører som hadde fokus på teknisk utprøving av utvalgte arketyper i sine EPJ-systemer. Det har så vidt vi vet ikke skjedd noe på nasjonalt plan på dette område i Danmark etter dette utprøvingsprosjektet. Konkrete erfaringer fra utprøvingsprosjektet er publisert på Sundhedsstyrelsen

14 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars sine websider 21. Prosjektet og konklusjoner fra prosjektet ble også presentert på MIE Følgende er de viktigste erfaringer fra dette utprøvingsprosjektet: Fra det helsefaglige sporet: Nesten alt det utvalgte helsefaglige innholdet kunne beskrives ved hjelp av eksisterende arketyper. På et område måtte de lage en egen arketype, basert på den eksisterende palpation -arketypen. På et område var den danske terminologien ulik den som var brukt av NHS/England. De valgte også å utvikle en ny arketype som en del av utprøvingen, og det gikk relativt uproblematisk. Fra leverandørsporet (det tekniske sporet): Leverandørene er enige om at arketyper er velegnet til utveksling av kliniske opplysninger, mens det blir mer problematisk når det handler om utveksling av pasientdata 23. F.eks. pasientens diagnose er sterkere knyttet til den konteksten diagnosen er registrert i enn f.eks. et resultat av en undersøkelse. Da EPJ-systemene har svært ulike logiske modeller, blir det utfordrende å anvende arketyper av andre typer enn OBSERVATION, dvs. EVALUATION, INSTRUCTION og ACTION. Flere leverandører mener at semantisk interoperabilitet av kliniske data vha. arketyper kun vil være mulig hvis systemene anvender den samme referansemodell, og hvis arketyper og referansemodell er modellert i sammenheng. Alternativt skal det skapes enighet om en felles referansemodell som arketypene skal knyttes til. Felles betraktninger: 2.9 Sverige Et arketypebibliotek bør ledsages av nasjonale templater. Det er svært vanskelig å overskue forvaltningsmessige (governance) konsekvenser når det gjelder hvordan nasjonale arketyper og templater kan versjoneres, styres og distribueres, samt hvordan forholdet mellom internasjonal, nasjonal og lokal utvikling kan være. Det vil være nødvendig å sikre klinikerbidrag i utvikling av arketyper. Om behovet er større eller mindre enn ved tradisjonell utvikling av helsefaglig innhold er vanskelig å bedømme. Formålet med anvendelse av arketyper bør avklares, dvs. om det er et modelleringsverktøy for å dokumentere definisjon av helsefaglig innhold, om det er for å strukturere EPJinnhold, eller om det også er å standardisere utveksling av pasientdata. I Sverige og innenfor rammen Nationell ehälsa gjennomførte Center för ehälsa i samverkan (CeHis) i 2010 et prosjekt for Gemensam utveckling av informationshantering för Nationella Kvalitetsregister Det er noe uklart for prosjektgruppen hva som menes i dette kulepunktet, spesielt hva som menes med termen pasientdata. Vi har imidlertid ikke prioritert å undersøke dette nærmere. 14

15 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING som under prosjekttiden ble kalt IFK2. 24 Del 2 av prosjektet gikk ut på å utforme arketyper/templater. Utgangspunktet er V-TIM (Verksamhetsorienterad tillämpad informationsmodell) som angir innhold og struktur på helsehjelpsdokumentasjonen på papir. openehr arketype-tilnærmingen ble brukt til å spesifisere hvordan V-TIM skal kunne programmeres i datasystemene. RiksSviktregistret (Nationellt kvalitetsregister för hjärtsvikt) ble brukt som pilot mot to journalsystemer. Det ble utviklet 12 nye arketyper og 9 templater, og 9 arketyper fra openehr ble gjenbrukt. Vår utredning visar att den väg som vi har slagit in på är framkomlig, att lösningen är hållbar och de framtida vinsterna stora. Men den visar också att det är ett komplext och omfattande arbete. Här finns inga lågt hängande frukter att plocka, säger Peter Furster, projektledare för IFK2 och verksam som IT-chef vid landstinget i Värmland. 25 Viktigste erfaringer fra IFK2 er: Helsefaglig/innholdsmessig: Teknisk: Kvalitetsregisterperspektivet passer ikke eksisterende arketypers kliniske perspektiv. Eksisterende internasjonale arketyper fra openehr var mest ment å brukes til å dokumentere helsehjelpen gitt enkeltpasienter. Når formålet var å representere sekundær informasjon for oppfølging, var man i flere tilfeller nødt til å utvikle egne arketyper fremfor å gjenbruke eksisterende arketyper fra openehr. Arketyper/templater kan ikke håndtere alle regler, f.eks. sammenhenger mellom ulike kliniske opplysninger (f.eks. verdi A skal være større enn verdi B når verdi C er ). Viktig med en stabil nasjonal forvaltning av arketyper og templater. Når det gjelder terminologibinding til SNOMED CT, var ca. 45% av tilfellene gjort med post-koordinering, og i ca. 20% av tilfellene fant man ikke egnede tilsvar i SNOMED CT. IFK2-piloten var vellykket da man fikk kjørbare løsninger ved pilotinstallasjoner hos to landsting samt hos RiksSvikt 26 ved Uppsala Clinical Research Center 27 (UCR). RiksSvikts skjemaer var mulig å uttrykke i openehr-templater som stort sett bygges på gjenbrukbare arketyper med terminologibinding. Interoperabilitet var påvist gjennom at begge journalsystemer og kvalitetsregistret kunne tolke den maskinlesbare spesifikasjonen. Det gjør det enklere med dataregistrering med styrt validering, samt meldingsformat på ulike tekniske plattformer. I begynnelsen av teknisk implementering ble det gjort endringer i arketyper og templater. Felles betraktninger: 24 Sluttrapport fra prosjektet IFK2 - del 2 - Gemensam utveckling av informationshantering för Nationella Kvalitetsregister"

16 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Arbeidet har tydelig vist at dette først og fremst ikke er teknisk anliggende. Den største utfordringen er at en slik gjenbrukstilnærming krever en godt gjennomarbeidet, felles informasjonsstruktur. Det trengs en omfattende forvaltningsorganisasjon med tilstrekkelige ressurser, og et forum for felles beslutning på nasjonalt nivå. En nasjonal termserver må skapes og forvaltes for de koder/klassifikasjoner/terminologi som anvendes. En nasjonal forvaltning av verktøyet for editering av arketyper/templater trengs. 16

17 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 3 Tekniske erfaringer 3.1 Innledning Dette kapitlet er en kort oppsummering av de erfaringer av teknisk og arkitektonisk karakter som prosjektet har gjort rundt de verktøy som finnes tilgjengelig, hvilke forutsetninger som må være på plass i det store arkitektoniske bildet for at en metodikk som dette skal kunne realiseres innenfor sektoren som helhet, samt litt om tekniske forutsetninger for å kunne knytte disse kliniske datamodellene opp mot eksterne terminologiressurser. Det vil føre altfor langt å dokumentere alle detaljer, det har heller ikke vært prosjektets målsetning. Foruten en kort introduksjon av de hovedelementer i metodikken, så vil vi ikke i dette kapitlet gjenta noe som allerede finnes i den offisielle dokumentasjonen. Fokuset er hovedsaklig knyttet til egne betraktninger og funn, noe som også inkluderer dialog og møter med både nasjonale og internasjonale aktører. Målgruppe for dette kapitlet vil typisk være beslutningstakere knyttet til IT-arkitektur og teknologivalg, da særlig hos fagsystemleverandører, men også IT-arkitekter internt i helseforetak evt. helseregioner. Denne tekniske orienteringen er hovedsaklig av interesse om en ønsker å dykke videre ned i materien, det være seg enten å teste mer ut de verktøy som finnes eller sette opp et test-/kjøremiljø for å prøve dette ut i praksis. Referanser til relevant dokumentasjon vil lenkes opp underveis i teksten. Hovedrapporten skisserer noen mulige steg for videre prosess, en forutsetning for gjennomføring av flere av disse er at sektoren og særlig da kanskje Nasjonal IKT er med å legge tilrette for en teknisk infrastruktur i form av et laboratorie e.l. for mer inngående PoC da teori og faktiske realiteter har visst seg å være nokså forskjellig på dette området. 3.2 Arketyper og templater Den kliniske datamodellen blir en arketype i det den formelt struktureres iht. referansemodellen. Representasjonsspråket som benyttes er Archetype Definition Language (ADL, en syntaks som er kongruent med Frame Logic). Representasjonen kan pakkes inn i XML, men uten bruk av Schematron vil relasjoner og type mønstre som if-then-else-kontroller ikke være tilgjengelig. En templat benyttes for å sette en eller flere arketyper inn i en gitt kontekst. En templat har alltid en rot-arketype, men flere arketyper kan settes sammen så lenge rot-arketypen er et cluster e.l. Enkeltelementer i en arketype kan utelates og verdiområde til kodede elementer kan avgrenses. Navngiving (ledetekster) på attributter kan overstyres (verktøy: Oceans Template Designer). Sistnevnte funksjonalitet pågår det diskusjon om hvorvidt det er hensiktsmessig å faktisk tillate, vi har bl.a. sett eksempler på bruk av ulike templater i en kurveløsning hvor ulik navngiving på entydige begreper i det samme skjermbildet vil kunne skape forvirring. Hovedforskjellen på en templat og en operasjonell templat (OPT) ligger i at en templat refererer til de arketyper som inngår, mens en OPT inkluderer arketypestrukturen som en del av selve templaten. En OPT er med andre ord en evaluert og generert templat ut fra Template Definition (sammen med 17

18 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars arketypen(e) og evt. terminologi den refererer til), og fremstår uavhengig av de(n) opprinnelige arketypen(e) (self contained) i den videre prosesseringen. En eksportert OPT kan inneholde flere språk så lenge dette er definert i arketypen(e). OPT er den komponenten som benyttes runtime, bl.a. for autogenerering av skjermbilder til datafangst. 3.3 Fra datamodell til faktiske data Representasjon av arketyper skal teoretisk sett kunne formaliseres ved bruk av ulike referansemodeller. Eksempelvis 13606, openehr, HL7 v3 RIM. Ved bruk av eksempelvis verktøyet LinkEHR skal dette være mulig. Prosjektgruppen har ikke fått testet bruk av arketypemetodikk opp mot andre referansemodeller enn openehr. Operasjonelle templater (OPT) omtalt ovenfor er utgangspunktet for den mer teknologiske prosesseringen av arketyper. Ved bruk av tilgjengelige programmeringsbiblioteker (API - Application Programming Interface, se openehr Service Model) er OPT utgangspunktet for inn-parameter i AOM (Archetype Object Model), og på bakgrunn av denne bygges det opp OTI-er (Operation Template Instance - dvs. de faktiske data) basert på openehr reference Model (RM). Figur 1: Abstrakssjonskjeden fra arketype til faktiske data (OTI) Basert på vår erfaringsutveksling med andre aktører har vi konstatert at de tilgjengelige API-ene er uferdige (det gjelder spesielt.net-utgaven), og tilgjengelig dokumentasjon samt støtte/support generelt er mangelfullt. Det har vært helt nødvendig å måtte modifisere open source-biblioteket med egne tilpasninger for at API-et skal fungere på forventet måte (egen tilleggskode for å få generert opp RM, GastrOS-applikasjonen er av flere benyttet som en slags referanseimplementasjon her). 18

19 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 3.4 Persistering og spørring Oppsummert har prosjektet identifisert tre ulike varianter for persistering av data knyttet til denne metodikken: 19 1) Lagre uendret XML uten ekstra metadata 2) Lagre uendret XML med metadata 3) Plukke ut dataene fra XML og lagre i egen intern datamodell Førstnevnte er openehr sin tilnærming, og gjenfinning er basert på bruk av AQL (Archetype Query Language). AQL er kort fortalt et deklarativt spørrespråk for søking og uttrekk av kliniske data definert i arketypene i henhold til RM. AQL er i dag ikke en standard. I vår dialog med en av aktørene som har prøvd ut dette, så viser det seg at søk vha. AQL direkte mot element-nivå i selve arketypene i praksis ikke fungerer når man når et visst antall instanser (ytelsesproblematikk). Databaseleverandør har i dette tilfettet vært koblet inn for å bistå med å se på evt. optimaliseringsmuligheter uten nevneverdig forbedringer. En løsningstilnærming for denne aktøren har vært å utvide den XML som eksporteres til OPT med et eget sett av metadata som kan spørres på utenfor selve arketypene. En konsekvens av dette er at verktøyet Ocean Template Designer (se Verktøy-kapitlet) ikke kan benyttes til OPT-eksport, videre at det må etableres et eget verktøy (programbibliotek) for å gjennomføre denne prosessen. En annen konsekvens er at AQL ikke lenger er hensiktsmessig å benytte, og den aktuelle aktøren nevnt ovenfor som hadde valgt denne tilnærmingen benytter i dag XPATH mot ovennevnte metadata. Sistnevnte variant for persistering, hvor man plukker ut data fra XML og lagrer dataene enkeltvis mot egen intern datamodell, later til å være den mest utbredte til tross for at man mister mange av fordelene ved å beholde strukturen slik den er da den ble kommunisert (mellom flere aktører) evt. innhøstet (internt hos en aktør). En slik tilnærming (3.variant) fordrer at strukturen på de data som kommer over faktisk er kjent, noe som eliminerer mye av dynamikken bruk av arketyper kan gi i en kommunikasjon. For å kunne drille ned i store datamengder eksempelvis til forskningsformål anbefales eksport av dataene til en datavarehusløsning. 3.5 Bruk av eksisterende data Under FAQ på openehrs wiki, under pkt. What about existing data? skisseres en fremgangsmåte hvorledes gå frem for å importere eksisterende data over til en arketypebasert persisteringsstruktur. Det må imidlertid påpekes at denne fremgangsmåten legger opp til en kopi av data, med dertil hva det måtte føre til av ekstra vedlikehold av samme data flere steder i ulike strukturer. 3.6 Hvordan dele arketyper og templater openehr har etablert Clinical Knowledge Manager (CKM), et felles område (community) hvor nye eller eksisterende (reviderte) arketyper av internasjonal relevans og interesse kan lastes opp, det samme gjelder eksisterende arketyper oversatt til et nytt språk, eksempelvis norsk.

20 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Figur 2: Oppstartsbildet til Clinical Knowledge Manager (CKM) I dette community et finnes egne rutiner for hvordan prosessen skal foregå for at en arketype skal bli godkjent. Svært mange av de arketyper som finnes i CKM i dag har status Draft (kladd). I tillegg til søk/gjenfinning av eksisterende arketyper tilbyr CKM funksjonalitet for fremstilling av data fra AOM i ulike formater (som også automatisk inkluderer samtlige støttede språk): Simple view - i enkel tabellform Tabbed View - tabellform sortert under ulike faner Mindmap (merk! Denne fremstillingen er generert av et proprietært.net-bibliotek og ikke en del av open source-koden) ADL v1.4 XML - med bruk av regelsettet v1 (openehr XML Schema) CKM tilbyr videre funksjonalitet for å kunne validere endrede arketyper opp mot eksisterende arketyper (jfr. Tabell 2: Oversikt over arketyper som ble utviklet/vurdert utviklet, samt de tilknyttede Cluster i kapittel 3 Kliniske informasjonsmodeller, en oversikt over de arketyper prosjektet har jobbet med). Ytterligere funksjonalitet i CKM b2eskrives ikke her, men dette vil være relevant i en prosess med anskaffelse av et nasjonalt repository (lagringsområde). 20

21 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Den enkleste variant for et felles nasjonalt lagringsområde er en webside på internett. For å kunne tilby versjonering av aktuelle datafiler er et versjoneringssystem, eksempelvis SubVersion, et aktuelt valg. Man mister imidlertid da en god del funksjonalitet som brukeradministrasjon, grafisk oversikt ved gjenfinning og ulike visninger, direkteoppslag/integrasjon mot noen verktøy, mv. Mye av dette vil kunne kompenseres ved en tilpasset klient som tilbyr slike ting. 3.7 Forhold til sektorens samhandlingsarkitektur og - plattform Samhandlingsarkitekturen beskriver de ulike arkitektoniske lag som inngår for samhandling mellom virksomheter i sektoren (jfr. Fig. 3). 21 Figur 3: Samhandlingsarkitekturen v2.0 Selv om samhandlingsarkitekturen er teknologiuavhengig, så er selve operasjonaliseringen av den i dag likevel i stor grad begrenset til asynkron meldingskommunikasjon. For å kunne håndtere dagens standardiserte meldinger må hvert enkelt fagsystem implementere og gjennomgå godkjenningsprosedyrer for å kunne ta i bruk en ny type melding evt. endret versjon av en eksisterende meldingstype. Den kliniske domenekunnskapen som skal formidles er tett integrert i det faktiske transportformatet. Ved introduksjon av (standardiserte) arketyper er teorien at kommunikasjonen mellom aktører skal kunne bli mer dynamisk ut fra et gitt klinisk informasjonsbehov. Transportformatet (openehr XML Schema) vil være fast, mens innholdet vil kunne variere (ulike templater for ulike kontekster). En forutsetning er at den kliniske datamodellen er kjent eller tilgjengelig for alle parter i kommunikasjonen. Det er nødvendig med en ensartet implementasjon som ivaretar eksempelvis oppslag mot et sentralt lager (repository, se ovenfor) for å hente ut relevante arketyper og evt. templater til bruk i evaluering i

22 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars de situasjoner hvor det kommuniseres data iht. dette XML Schema. En felles samhandlingsplattform (felles distribuert mellomvare) som benyttes av samtlige aktører kan være en måte å etablere en slik mekanisme. En slik plattform vil også kunne inneholde felleskomponenter med kunnskap om RM og AOM som så tolker (parser) dataene, bygger opp objektstrukturer mv. Figuren nedenfor illustrerer to aktører som kommuniserer ad hoc data basert på kliniske datamodeller ved bruk av arketypemetodikk. Figur 4: To aktører som benytter en felles samhandlingsplattform for å være archetype enabled 3.8 Designverktøy For å kunne realisere bruk av arketyper (og templater) i IT-løsninger er det behov for å ha noen verktøy tilgjengelige: En editor for å kunne formalisere selve arketypen Et designverktøy for å kunne etablere templater basert på en eller flere arketyper Evt. et verktøy for konfigurasjon av autogenererte skjermbilder Prosjektet har ikke prioritert å bruke veldig mye tid på uttesting av verktøyene. Verktøyet som har vært mest i bruk er Arketype-editoren i forbindelse med formalisering av de kliniske datamodellene (se kapittel 4 Kliniske informasjonsmodeller). Nedenfor følger en kort oversikt over de mest sentrale verktøyene og de observasjoner/erfaringer vi har gjort oss underveis i prosjektet. Archetype Editor 22

23 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Figur 5: Eksempel på en arketype oversatt til norsk bokmål (nb) Prosjektgruppen har i all hovedsak benyttet Archetype Editor v Beta. Dette verkøyet er (primært) levert av openehr. Vi har bl.a. funnet ut at tekstene i brukergrensesnittet (menyer, ledetekster, mv.) er konfigurerbart via en separat tekstfil som følger med installasjonen. Det betyr at selve verktøyet kan foreligge i en norsk språkdrakt om noen er villig til å ta på seg oppgaven med å oversette tekstene (samt vedlikeholde dette i nye versjoner). Menyer, skjermbilder og dialoger oppleves som relativt selvforklarende og intuitivt å jobbe i. Når det er sagt, så må det påpekes at vi samtidig har erfart inkonsistens mellom den versjonen som distribueres av openehr og en egen utgave (build) fra Ocean Informatics. Det er også verdt å merke seg at det er noe forskjell i terminologi mellom Arketype-editoren og den tidligere nevnte CKM. Identifiserte ulikheter er satt opp i tabellen nedenfor. 23

24 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Tabell 1: Forskjeller i terminologi mellom CKM, AE og Mind map CKM Archetype Editor Mind map State Data Events Header Description Person state (under Data) Tree (under Data) Events (under Data) Description Activity description Den inkonsistens som er identifisert mellom de ulike build går helt konkret ut på funksjonalitet knyttet til oppslag mot en terminologitjener. Skjermbildene i begge utgaver av verktøyet er helt like, versjonsnummeret til verktøyene er det samme, men kun Ocean-utgaven har implementert faktisk programkode for oppslag (og da kun mot deres egen terminologiserver, OTS). Programbiblioteket som her er valgt for oppslag er et prorietært.net-bibliotek, noe som innebærer at Ocean ikke kan dele denne implementasjonen tilbake til verktøyets open source-tre. Prosjektgruppen fikk etter hvert tilsendt en Ocean build av verktøyet da tjener for nedlasting visste seg å ha vært nede en ukes tid, det er noe betenkelig at kun vi oppdaget akkurat dette. OTS er et kommersielt produkt med dertil lisensiering. Oppslag mot OTS ved bruk av oversendt utgave av verktøyet fungerte bare delvis. Det svenske miljøet har planlagt en anskaffelse. Pga. ovennevnte kom ikke prosjektgruppen stort lengre knyttet til å teste ut oppslag mot eksterne terminologiservere. Slike funn som beskrevet ovenfor finnes ikke i noe offisiell dokumentasjon, og generelt kan en nok konstatere at mye av tilgjengelig dokumentasjon bærer preg av å være både mangelfull og til dels utdatert (eksempelvis vises gamle skjermbilder fra tidligere versjoner av verktøyet). Arketype-editoren oppfattes som inkonsekvent mht. ulike skjermmodus. F.eks. forsvinner struktur fra arketypen ved at man klikker vekk en hake på person state (registrerte strukturer blir borte og må legges inn igjen manuelt). Erfaringer fra oversettelse viser at man er nødt til å registrere strukturen først, dernest oversette terminologien i arketypen. Tilsynelatende er det mulig å oversette direkte i strukturoversikten, men dette fungerer ikke på en forutsigbar måte. ADL Workbench ADL WorkBench har i den senere tid blitt mye promotert, prosjektgruppen har imidlertid ikke prioritert å se nærmere på dette verktøyet. 24

25 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Template Designer Figur 6: ADL Workbench Prosjektgruppen har testet ut Ocean Template Designer v Beta. I motsetning til Archetype Editor er dette verkøyet kun levert av Ocean Informatics. I skjermbildet nedenfor vises Template Designer i en modus hvor et autogenerert skjermbilde kan konfigureres. Aktøren vi snakket med omkring prosessen med å autogenerere skjermbilder har, som nevnt tidligere, etablert et eget programbibliotek for å ivareta skjembildebygging ved bruk av WPF (Windows Presentation Foundation) i stedenfor WinForms som dette verktøyet baserer seg på. 25

26 TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING 13. mars Figur 7: Ocean Template Designer med generert skjermbilde av en arketype oversatt til norsk bokmål (nb) LinkEHR Prosjektgruppen har i noen grad testet ut LinkEHR som leveres av Ibime (Informàtica Biomèdica). Versjonsnummer er ikke angitt i verktøyet. LinkEHR er det eneste arketype-verktøyet vi kjenner til som kan knytte arketypene opp mot ulike referansemodeller (jf. kapittel 3). LinkEHR fremstår for oss som et noe mer stabilt verktøy enn Archetype Editor, bl.a. knyttet til bakoverkompatibilitet til ADL-versjoner. 26

27 13. mars TILTAK 41 RAPPORT MED ANBEFALT OPPFØLGING Figur 8: LinkEHR - samme arketype som i fig. 5 og 7. 27