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 ~

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

2

Innhold 1 Innledning ........................................................................................................................... 4

1.1 Bakgrunn ..................................................................................................................... 4

1.2 Hovedmål for tiltak 41 .................................................................................................. 4

1.3 Leveranser ................................................................................................................... 4

1.4 Gjennomføring ............................................................................................................. 5

1.5 Resultater og erfaringer ............................................................................................... 5

1.6 Forslag til oppfølging .................................................................................................... 6

1.6.1 Valg av referansemodell ....................................................................................... 6

1.6.2 Valg av verktøy ..................................................................................................... 6

1.6.3 Utredning SNOMED CT ........................................................................................ 7

1.6.4 Videreutvikling og forvaltning av kliniske informasjonsmodeller ............................ 7

2 Situasjonsanalyse ............................................................................................................... 8

2.1 Kort om arketype-metodikken ...................................................................................... 8

2.2 Nasjonal standardisering av EPJ innhold ..................................................................... 8

2.2.1 Innledning ............................................................................................................. 8

2.2.2 EPJ innholdsstandarder vs. openEHR arketyper .................................................. 9

2.3 Arketype-metodikk i Norge ..........................................................................................10

2.4 Terminologibinding i arketyper og templater................................................................10

2.5 Bruk av arketyper internasjonalt ..................................................................................12

2.6 NHS (England) ............................................................................................................13

2.7 EN13606 association ..................................................................................................13

2.8 Danmark .....................................................................................................................13

2.9 Sverige .......................................................................................................................14

3 Tekniske erfaringer ............................................................................................................17

3.1 Innledning ...................................................................................................................17

3.2 Arketyper og templater ................................................................................................17

3.3 Fra datamodell til faktiske data....................................................................................18

3.4 Persistering og spørring ..............................................................................................19

3.5 Bruk av eksisterende data ...........................................................................................19

3.6 Hvordan dele arketyper og templater ..........................................................................19

3.7 Forhold til sektorens samhandlingsarkitektur og -plattform ..........................................21

3.8 Designverktøy .............................................................................................................22

4 Kliniske informasjonsmodeller ............................................................................................28

4.1 Avgrensning - utvelgelse av opplysninger ...................................................................28

4.2 Utvikling av arketyper - erfaringer ...............................................................................29

5 Vedlegg A - Prosjektorganisasjonen ..................................................................................37

5.1 Prosjektgruppen ..........................................................................................................37

5.2 Styringsgruppen ..........................................................................................................37

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

3

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 v2.0 ....................................................................................21

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 7................................................................27

Figur 9: Tankekartet for indirekte oksymetri ..............................................................................30

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

4

1 Innledning

1.1 Bakgrunn Denne rapporten sammenfatter erfaringer og leveranser fra Nasjonal IKTs tiltak 41, gjennomført i perioden april 2011 - april 2012. Prosjektet ble initiert av Nasjonal IKT som en oppfølging av Nasjonal IKTs tiltak 27. Tiltak 27 ble gjennomført i perioden 2008-2009, 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 KITH1-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 kost-nytte 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.2012 en del av Helsedirektoratet, som Avdeling standardisering.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

5

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 2012, 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 17-18. januar 2012, 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.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

6

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.

1.6.1 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 13606 (”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.

1.6.2 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 referansemodeller2.

2 Se for eksempel http://www.linkehr.com/

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

7

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.

1.6.3 Utredning SNOMED CT

På nasjonalt plan er vi i Norge avventende til bruk av den internasjonale terminologien SNOMED CT3.

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.

1.6.4 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

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

8

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.

Historikken4 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 CEN5/ISO, senest i ISO 13606 (2007) fra ISO, men er senere videreutviklet og forbedret innenfor openEHR-rammeverket6. 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

2.2.1 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 1998 – 2000 og revidert i 2007.

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, EHRCOM7. Det ble

4 Historikken bak EN13606/openEHR, se http://www.openehr.org/about/origins.

5 European Committee for Standardization / Comité Européen de Normalisation, se

http://en.wikipedia.org/wiki/European_Committee_for_Standardization 6 http://www.openehr.org/, introduksjon til openEHR-arkitekturen:

http://www.openehr.org/releases/1.0.1/architecture/overview.pdf 7 EHRCOM benyttes i det etterfølgende som en fellesbetegnelse for CEN og ISO-standardene i 13606-serien.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

9

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.

2.2.2 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

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

10

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.8

2.3 Arketype-metodikk i Norge ”Forprosjekt for nasjonal definisjonskatalog for kliniske variabler i elektronisk pasientjournal og tilknyttede fagsystemer” (Nasjonal IKT Tiltak 27) foreslo i sin sluttrapport9 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. 9 http://www.nasjonalikt.no/filestore/Dokumenter/Sluttrapporter/SluttrapportForprosjektdefinisjonskatalalog.pdf

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

11

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 dette10. NHS England og HL7 Terminfo har utviklet denne grammatikken noe videre11. 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.

Volven12 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 web-servicer 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 template-designer opp mot Volven. Det bør gjøres på en standardisert måte, f.eks. ihht. CTS 213 (Common terminology services - 2). Mer om terminologbinding ved bruk av verktøy, se kapittel 3 - Tekniske erfaringer.

10

http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ 11

http://www.openehr.org/wiki/display/stds/Input+to+terminology+constraint+expression 12

http://www.volven.no/ 13

Common Terminology Services 2. http://informatics.mayo.edu/cts2/index.php/Main_Page

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

12

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 IHTSDO14, 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øy15. 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 openEHR16 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 www.HL7.org og www.IHTSDO.org, hvor man kom frem til en felles erklæring17,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).

14

http://www.ihtsdo.org/ 15

http://www.snomedbrowser.com/, http://snomed.vetmed.vt.edu/SCT/menu.cfm 16

http://www.openehr.org/shared-resources/usage/government.html 17

http://www.openehr.org/mailarchives/openehr-announce/msg00118.html 18

http://wolandscat.net/2011/12/14/cimi-group-goes-with-openehr-archetypes-uml-profile/

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

13

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-modeller19. 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 IT-faglig perspektiv.

2.7 EN13606 association Det er opprettet en stiftelse/forening20 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-of-concept) på arketyper, i perioden august 2008 til februar 2009. 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

19

http://www.connectingforhealth.nhs.uk/systemsandservices/data/lra 20

http://www.en13606.org

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

14

sine websider21. Prosjektet og konklusjoner fra prosjektet ble også presentert på MIE200922. 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 pasientdata23. 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:

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 EPJ-innhold, eller om det også er å standardisere utveksling av pasientdata.

2.9 Sverige 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”

21

http://www.sst.dk/Indberetning%20og%20statistik/Terminologi/Informationsmodeller/Arketypeafprovning.aspx 22

www.hst.aau.dk/~ska/MIE2009/papers/MIE2009p0147.pdf 23

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.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

15

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:

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.

● Teknisk:

IFK2-piloten var vellykket da man fikk kjørbare løsninger ved pilotinstallasjoner hos to landsting samt hos RiksSvikt26 ved Uppsala Clinical Research Center27 (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" 25

http://www.cehis.se/nyhetsarkiv/nationella_kvalitetsregister_ger_stora_vinster/ 26

http://www.ucr.uu.se/rikssvikt/ 27

http://www.ucr.uu.se/sv/

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

16

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.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

17

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

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

18

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).

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

19

3.4 Persistering og spørring Oppsummert har prosjektet identifisert tre ulike varianter for persistering av data knyttet til denne metodikken:

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.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

20

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).

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

21

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).

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

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

22

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

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

23

Figur 5: Eksempel på en arketype oversatt til norsk bokmål (nb)

Prosjektgruppen har i all hovedsak benyttet Archetype Editor v2.2.779 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.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

24

Tabell 1: Forskjeller i terminologi mellom CKM, AE og Mind map

CKM Archetype Editor Mind map

State Person state (under Data)

Data Tree (under Data)

Events Events (under Data)

Header

Description

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.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

25

Figur 6: ADL Workbench

Template Designer

Prosjektgruppen har testet ut Ocean Template Designer v2.6.1214 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å.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

26

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.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

27

Figur 8: LinkEHR - samme arketype som i fig. 5 og 7.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

28

4 Kliniske informasjonsmodeller

4.1 Avgrensning - utvelgelse av opplysninger

Tiltak 41 skulle utarbeide28 opptil 35 arketyper. KITH-gruppen gjorde et forarbeid for å kunne avgrense settet med opplysninger som prosjektgruppen skulle ta utgangpunkt i. Det ble bestemt å ta utgangspunkt i rapporten fra tiltak 2729 og se kurveopplysningene der opp mot flere kvalitetsregistre for om mulig å finne fram til et “snitt” av opplysninger som man kunne avgrense til ca. 35 arketyper. Det ble forberedt en vurdering av følgende kvalitetsregistre hvor det ble antatt å være stor grad av overlapp med opplysningene fra tiltak 27-rapporten: Intensivregisteret, Hjerteinfarktregisteret, Hjertesviktregisteret, Diabetesregisteret. Det ble satt krav til bruk av MRS -løsning30 og til at kvalitetsregisteret skulle være nasjonalt godkjent31.

Spesielt hjerteinfarktregisteret som baserer seg på opplysninger fra innleggelser krevde et detaljeringsnivå som ikke var mulig med de eksisterende arketyper, f.eks. detaljer om infarkt og stenter. ”Poliklinikk-registre” som diabetes og hjertesvikt lot seg lettere å finne passende arketyper for. Prosjektgruppen gikk bort fra Hjertesviktregisteret fordi det ennå ikke hadde status som nasjonalt kvalitetsregister.

Det ble etter hvert bestemt å fokusere på kurve og Norsk intensivregister32 (NIR). Dette kom av at det var et godt sammenfall i opplysningene i kurven og i dette registeret. Det var også slik at begrensningen på 35 arketyper gjorde det vanskelig å dekke opp for diabetes eller hjerteinfarktregisteret. Eksempler på arketyper som ikke ble tatt med/implementert selv om de eksplisitt er nevnt i som kurveopplysning i Tiltak 27:

Liggesår. Dennes finnes imidlertid som arketype Braden scale på openEHR.

Scandinavian stroke scale. Finnes ikke på openEHR.

Euroscore. Dette er en risikokalkulator for pasienter som skal gjennom hjertekirurg, Denne finnes ikke på openEHR.

NYHA. Dette er en klassifisering av hjertesvikt. Denne finnes ikke på openEHR, men er å finne hos NHS.

Eksempler på arketyper som ikke ble tatt med/implementert fra diabetes/hjerteinfarktregistrene:

BMI - finnes som arketype Body mass index på openEHR

Midjemål - finnes som arketype Waist and hip circumference på openEHR

28

For utvikling av arketyper, se http://www.oceaninformatics.com/ocean-informatics-resources/Tutorials.html 29

Se sluttrapport fra tiltak 27 her: http://www.nasjonalikt.no/no/dokumenter/sluttrapporter/ 30

http://www.kvalitetsregistre.no/utvikling/medisinsk-registrerings-system-mrs-article217-175.html 31

For opplegget omkring nasjonale kvalitetsregistre, se http://www.kvalitetsregistre.no/ 32

http://www.intensivregister.no/

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

29

Vibrasjonssans - finnes ikke på openEHR.

Ecco cor – finnes ikke på openEHR

Noen arketyper ble gått bort fra da det pågår nasjonalt standardiseringsarbeid:

medication – i stedet ble det lagd forskrivning basert på FEST/eResept.

Intravenøs væske - utgikk også da denne skulle sees i sammenheng med forskrivning.

adverse event– må vente på nasjonalt standardiseringsprosjekt i forbindelse med kjernejournal

spesifikke lab-arketyper ble i stedet erstattet med én generisk lab-arketype. Denne generiske arketypen må sees i sammenheng med Neklab når denne standarden blir implementert.

4.2 Utvikling av arketyper - erfaringer

Vår erfaring er at det kreves en del modning for å jobbe med arketyper. prosjektgruppen hadde medlemmer med helsefaglig og/eller teknisk bakgrunn. Enkelte av deltakerne arbeidet både klinisk i tillegg til at de hadde god teknisk innsikt. Det viste seg nyttig å ha begge typer kompetanse til stede på møtene. Teknikere hadde gode, prinsipielle innspill rundt det å modellere arketyper. Kompetansen til prosjektgruppen vurderes til å være svært god.

På de første møtene var det nyttig å ha mange deltakere til stede ved oversettelse/modellering av arketypene. Etter som gruppen fikk mer erfaring hadde det antakeligvis vært mulig å dele prosjektgruppen i to mindre grupper for å effektivisere arbeidet. Anbefalingen er likevel heller å starte med en stor gruppe ved modelleringen av de første arketypene. Ved avbud bør sentrale personer få tilsendt gjennomgåtte/oversatte arketyper i ettertid, og kommentere disse. Ellers er det lett at de kan ha viktige innspill som først vil dukke opp et mye senere tidspunkt, og gjøre at arbeidet med allerede godkjente arketyper må tas opp igjen. Det er med andre ord viktig å planlegge hvordan det skal lages konsensus rundt utvikling av arketyper, og hvilke rutiner som skal gjelde.

Det kreves en del arbeid med å bli kjent med hva som ligger i openEHR sitt repository, og andre CKM. Det var også viktig å bli kjent med inndelingen av arketypene – hva det innebærer at arketyper er av de enkelte typene ”instruction”, ”action”, ”evaluation”, ”observation”, ”cluster” og ”structure”. Det viste seg nyttig å ha noen personer som var godt kjent med hva som fantes av arketyper i ulike repository. Eksempelvis fant en person i prosjektgruppen ut at NHS hadde gjort mye arbeid med terminologibinding. Dette hadde ikke blitt registrert på forhånd, og gjorde at prosjektgruppen hadde brukt en del tid på å gjøre arbeid som allerede var gjort av andre.

Etter en vurdering av ulike repositorier tok prosjektet for det meste utgangspunkt i arketypene fra openEHR. Imidlertid virket noen arketyper som diagnose og prosedyre mer gjennomarbeidet med mer kommentarer og konsensusrunder i det australske/NEHTA repository. I noen av disse tilfellene – som for diagnose – tok vi da utgangspunkt i den australske arketypen. OpenEHR bekreftet også at noen arketyper kunne være mer modne i andre repository, og opplyste at helst burde openEHR se om de skulle innarbeide disse i sitt eget repository. For arketype-metodikken er det en utfordring at hvert enkelt land gjør sine egne tilpasninger i arketypene, og det synes ikke som det internasjonalt er et tilstrekkelig apparat for å få til en prosess der nasjonalt utviklete arketyper ”konvergerer”.

Prosjektgruppen foretrakk å starte med de litt enklere arketypene slik som kroppstemperatur og væskeinntak i stedet for å begynne med komplekse som diagnose og prosedyre. Det er viktig for motivasjonen at gruppen klarer å skape enighet rundt noen arketyper etter diskusjon over 1-2 timer. Dette legger grunnlag for metodikk og prinsipielle spørsmål til modellering kan avklares når man

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

30

arbeider med forholdsvis enkle arketyper. Mange av arketyper av type ”Observation” er generelt enklere å modellere enn de andre arketypene. Dette stemmer godt med det man finner på openEHR der alle publiserte arketyper (bortsett fra Clinical synopsis) er av type ”Observation”.

Hvis man ser på hvilke arketyper som prosjektgruppen har gjort strukturendringer i, er alle med unntak av ”EKG” og ”Enteralt væskeinntak” av en annen type enn ”Observation”. Bruksområdet for ”Observation” arketyper er det enklere å forstå, og det er konseptuelt tydeligere hva som skal ligge innenfor arketypen enn for andre typer arketyper. For eksempel må ”Action” arketyper sees mer i sammenheng med de gjeldende rutiner på sykehus/legekontor. Mer konkret gjelder det spesielle, muligens nasjonale, retningslinjer ved blodoverføring og disse forholdene må gjenspeiles i arketypen for Transfusjon. Å lage en riktig arketype krever med andre ord en inngående kjennskap til faktiske rutiner i den daglige klinikken. Dette er en stor forskjell fra arketyper av type ”Observation” som kan sies å være mer av fysiologisk og generell natur. Likeledes må en arketype av type ”Evaluation” som ”Diagnose” også sees mer i sammenheng med rutinene i klinikken, og det er også vanskeligere å gjøre en naturlig avgrensning om hva som skal være med/ikke med i en slik arketype. Det er vanskelig å gi en bestemt anbefaling for utvikling av disse arketypene utover å si at det krever et tett samarbeid med aktive klinikere, og også med EPJ-leverandører, for å se på hva som ligger inne i EPJ-systemene i dag og hvilke muligheter som er påtenkt for nær fremtid. EPJ-leverandører ble eksempelvis kontaktet rundt komplikasjonsregistrering, og deres tilbakemeldinger ble forsøkt ivaretatt både i ”Diagnose”-arketypen og ”Procedure”-arketypen. Det er likevel ikke til å underslå at disse arketypene må vurderes til å være uferdige.

En arbeidsform der man diskuterte ut fra tankekart gav mest fruktbare diskusjoner. Et tankekart er en visuell representasjon av en begrep/informasjonsmengde, i dette prosjektet representerte hvert tankekart et klinisk begrep. Nedenfor er dette eksemplifisert gjennom tankekartet for indirekte oksymentri.

Figur 9: Tankekartet for indirekte oksymetri

Alle arketypene som ble utviklet i prosjektet ble drøftet ut fra slike tankekart.

Det er et stort behov for fysiske møter for å holde diskusjoner. Det er vanskelig å kjøre prosesser/diskusjoner over e-post. Dette skyldes også at deltakerne i prosjektgruppen er opptatt med andre gjøremål i hverdagen. Det fungerte greit å fordele arketyper til hver av deltagerne, og så la hver enkelt deltager lage et utkast til oversettelse/tilpasning til neste arbeidsmøte. Selv om prosjektgruppen består av helsepersonell med bred kompetanse og erfaring, var det behov for å konferere med fageksperter, som vi gjorde med arbeidet med arketypene for EKG og Glasgow Coma Scale.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

31

Generelle kommentarer til utviklingen av arketypene:

● Vi har ikke oversatt filnavnene for arketypene til norsk. Det har vært nødvendig å beholde engelske filnavn for lettere å kunne sammenlikne med openEHR repository, og for å kunne laste de norske oversettelsene opp til dette repository. Ved omtale av arketypene i denne rapporten veksler vi mellom engelsk originalnavn og norske oversettelser etter hva som er best naturlig ut fra konteksten.

● 9 arketyper fikk strukturendringer. For eksempel mente gruppen det for arketypene for sykdomsrisiko var riktig å innføre de kvantitative begrepene absolutt risiko og relativ risiko. OpenEHR har i sin arketype bare lagt opp til en inndeling i fire grupper fra lav til høy risiko som prosjektgruppen oppfattet som utilstrekkelig. For arketypen ”Enteralt væskeinntak” fant gruppen det nødvendig å tilføre elementer for ”Metode” og ”Instrument” i de tilfeller pasienten ikke selv drikker. For ”Transfusjon” var det blant annet nødvendig å introdusere ”Volum” og ”Tappenummer”. For EKG la vi til felter for ”Kroppsstilling” og ”Medikamentell stimulering”. De faktiske strukturendringene i hver enkelt arketype er mulig å finne ved å se nærmere på de utviklete tankekartene og sammenlikne med de fra OpenEHR.

● Det var en del diskusjon rundt hvilke retningslinjer som skulle gjelde for navngiving av termene i arketypene. Det ble vurdert som gunstig å bruke beskrivende termer selv om disse da bestod av flere ord. For eksempel heter det i Væsketap-arketypen ”Tidspunkt uten periodeangivelse” mens det engelske uttrykket er ”Timing.” I ”Goal” er ”Outcome” oversatt til ”Behandlingsmål som skal oppnås". Det ble oppfattet som hensiktsmessig at termene i arketypene var såpass nøyaktig beskrevet at det ikke var stort behov for å lese den mer detaljerte beskrivelsen av dataelementet. Hovedregelen i oversettelsesarbeidet var likevel at den engelske termen var beskrivende nok til at den kunne oversettes direkte.

● Det er en del termer som går igjen i flere arketyper. Det ble lagt vekt på at oversettelsen var lik for disse i alle arketypene. Eksempler på dette var uttrykk som ”anatomisk målested”, ”anatomisk sted”, ”Måleinstrument”, ”Påvirkende faktorer”, ”Kroppsstilling”, ”Tilført oksygen”.

● En generell problemstilling med arketyper er å beskrive en observasjon med stor nøyaktighet samtidig som man ikke angir en diagnose i observasjonsarketypene. Et eksempel er beskrivelse hjerterytme i heart_rate der man skal angi frekvens og mønster, men det skal ikke sies eksplisitt hva slags eventuell rytmeforstyrrelse som foreligger fordi dette er en diagnose. Diagnose skal bare stå i diagnosearketyper. Dette var en kjent problematikk ifølge representanter fra openEHR.

● Bekreftelser fra openEHR viste at rene slurvefeil forekom – for eksempel lå påvirkende faktorer to steder i sentral venetrykk.

● Mange av arketypene var vanskelige/ikke ferdigstilt rent modelleringsmessig fra openEHR sin side. Dette gjaldt i hovedsak alle de som ikke er markert med grønt – ”Published” i repository. Av de publiserte arketypene fra openEHR har vi så langt ikke gjort noen strukturendringer, men det har vært uenighet i prosjektgruppen mht til den publiserte ”Blood pressure”- arketypen.

● Det ble identifisert 11 clustere som ble referert fra vårt utvalg av arketyper. En av disse ble utviklet – fluid – for å vise hvordan dette clusteret ble brukt fra arketypen ”Enteralt væskeinntak”. De resterende 10 ble både av kapasitetshensyn og rammen på 35 arketyper ikke utviklet. Vi fant det helt kurant å opprette/oversette cluster, og har opprettet et 10 talls cluster for å lage forskrivningsarketypen.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

32

● Cluster er en gjenbrukbar arketype som inkluderes i andre arketyper. Hensikten med å opprette clustere er å forenkle modellering og unngå redundans. Et eksempel på et cluster er device som vi har oversatt til instrument eller måleinstrument. I en rekke arketyper er det lagt opp til at opplysningene som finnes i arketypene er registreringer fra instrument. For eksempel et EKG-apparat. I stedet for å modellere detaljer om apparatet i hver arketype er dette trukket ut i en egen arketype – ”device” – der man kan gi en detaljert beskrivelse av instrumentet.

● Generelt er det et problem med arketypene at det er liten mulighet for å lage relasjoner mellom feltene. Det vil si at det i definisjon av arketypene ikke finnes logikk som sier hvilke verdier som er tillatt i et annet felt basert på registreringer andre steder i arketypen. For eksempel skal det i arketypen for blodtrykk normalt registreres både et systolisk og diastolisk blodtrykk. Imidlertid er det slik at ved bruk av et doppler-apparat i stedet for et stetoskop er det bare mulig å fange opp det systoliske blodtrykket. Det skal altså i dette tilfellet ikke registreres et diastolisk blodtrykk. Doppler-apparat er vanlig å bruke når man skal måle systolisk blodtrykk over ankelen fordi det ikke lar seg gjøre å høre pulsasjonen med et stetoskop på dette stedet.

Kommentarer til bruk av verktøy:

● Tankekartene laget i Freemind lar seg ikke på noen måte importere til Arketype-editoren. Dette betød at arbeidet gjort i tankekartene måtte skrives inn på nytt i Arketype-editoren. Dette er ikke et stort problem. Det går bort ca. halvtime per arketype pga. dobbelt skrivearbeid.

● KITH-gruppen gjorde arbeidet med å føre inn arketypene i Arketype-editoren. Dette bød på en del problemer pga. umodne verktøy, men etter hvert fant vi fungerende “workarounds”.

● Problemene i Arketype-editoren gjaldt blant annet at man mistet gjennomført oversettelsesarbeid dersom ikke spesielle rutiner rundt åpning/lagring av ADL-er ble brukt. Et annet problem er at man ikke fikk lagre selve arketypen hvis arketypeeditoren gav beskjed om at det var en eller annen logisk feil i denne. Man fikk ikke klar tilbakemelding om hva som var problemet. Dette kunne medføre at man måtte starte helt på nytt med å lage arketypen. Et tredje problem var at under redigering av definisjonen av arketypene, hang ikke oversatte termer med og termene var da ikke synkronisert med definisjon. Det var da nødvendig å lukke og åpne arketypen på nytt. Etter hvert som man ble klar over disse uhensiktsmessighetene, og man brukte editoren på en konsekvent måte gikk det forholdsvis greit å bruke arketype-editoren. Det er likevel ikke til å underslå at det er stort forbedringspotensial i arketypeeditoren. Blant annet var det et stort savn at det ikke var mulig å generere tankekart ut fra arketype-editoren.

● Arketypene er ikke blitt bundet opp mot terminologier. For eksempel i Forskrivningsarketypen, som referer til en rekke kodeverk, er referansene til kodeverkene ennå ikke blitt definert i arketypen.

Enkelte kommentarer til spesifikke arketyper:

● Det ble lagd fem nye arketyper. CVK, forskrivning, NEMS, NAS, SAPS II. CVK ble ansett som nyttig fordi det er ønskelig å registrere komplikasjoner på en strukturert måte ved bruk av CVK. Forskrivning var interessant å ta med for å illustrere hvordan arketyper kunne brukes for å representere forskrivning i henhold til eResept. NEMS, NAS og SAPS II brukes av NIR, og ved å utvikle disse kan vi tilby et nært komplett sett med arketyper for de medisinske opplysningene som skal registreres i NIR:

● Diagnose, prosedyre og substance_use_summary_tobacco ble basert på de australske arketypene fra NEHTA, men de ble av oss i tillegg modifisert ut fra den australske versjonen.

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

33

● EKG burde ha vært vurdert i forhold til standard for EKG innen 11073-serien fra ISO/IEEE eller andre EKG-standarder. Det har ikke vært ressurser nok i prosjektet til å gjøre en slik vurdering. Det er verdt å merke seg at EKG-arketypen fra openEHR er i utkast, og det er å forvente at man i den videre prosessen vil se denne opp mot ISO/IEEE-standarden.

● Væsketap. Her er det slik at mye må legges i den generiske arketypen ”Bodily output” for slik som svette, oppkast. Det er bare lagd spesialiserte arketyper når væske utskilles ved urinlating og avføring.

● For blodtrykk (en “godkjent” arketype) måtte det til en oppklaringsrunde med openEHR for å få til avgrensning/bruksområde mellom denne og intravaskulært blodtrykk. Det var ved første øyekast vanskelig å forstå at blodtrykk også kunne inkludere intravaskulære målinger. Etter avklaring med openEHR ble det bestemt av blodtrykk også kunne inneholde intravaskulære målinger så fremt disse målingene var ment å skulle reflektere det systemiske blodtrykket, og ikke var ment for andre målinger slik som blodtrykk i lungekretsløpet, (reduserte) perifere arterielle målinger pga. stenoser osv.

● Blodtrykk fikk likevel innvendinger på siste møte når den ble nærmere gjennomgått fra et sykehusperspektiv. Dette til tross for at denne arketypen var tidligere godkjent både i openEHR og av oss uten strukturendringer. For eksempel, ble det påpekt at de to arketypene blodtrykk og intravaskulært trykk ikke klarte å reflektere undersøkelse av et (kjent) perifert redusert blodtrykk (pga. stenose) som ble målt ved hjelp av mansjett (og ikke intravaskulært).

● Prosjektgruppen hadde blant det opprinnelige utvalget av arketyper tatt med puls og sentralt venetrykk – disse har status ”Draft” på openEHR. Disse to arketypene ble etter nærmere gjennomgang og diskusjon med OpenEHR forkastet av oss. OpenEHR var selv i tvil om modelleringen, og om det i det hele tatt var riktig å opprette disse to som spesialiseringer av henholdsvis ”Heart rate” og ”Intravascular pressure”.

● Prosedyre og CVK (innlegging av sentralt venekateter) ble det ikke tid til å gjennomgå i felleskap i prosjektgruppen, og disse to arketypene må anses som uferdige fra vår side.

● Det vil bli nødvendig å lage arketype for instruction og action for Forskrivning. Vi har opprettet Forskrivning som et cluster, men det må opprettes arketyper som angir aksjon som administrering med tilhørende ”pathway” (liknende pathway som for Transfusjon).

Tabell 2: Oversikt over arketyper som ble utviklet/vurdert utviklet, samt de tilknyttede Cluster

Arketype

Ny struktur (Ja/Nei)

”-” betyr ikke relevant

Krever ny versjon? (Ja / Nei / Ikke relevant33)

”-” betyr ikke sammenlignet

Kilde Status i

kilde

action.procedure Ja - NEHTA

NY:cluster.innlegging_cvk - - Tiltak 41

action.transfusion Ja Ja openEHR

33

Ikke sammenlignet pga. at kilde befinner seg på et annet repository.

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

34

Arketype

Ny struktur (Ja/Nei)

”-” betyr ikke relevant

Krever ny versjon? (Ja / Nei / Ikke relevant33)

”-” betyr ikke sammenlignet

Kilde Status i

kilde

evaluation.goal Nei Nei openEHR

evaluation.problem Ja - openEHR

evaluation.problem-diagnosis Ja - NEHTA

evaluation.risk Ja Nei openEHR

evaluation.risk-family_history Ja Ja openEHR

evaluation.substance_use_summary-tobacco Ja - NEHTA

item_tree.gas_administration Nei Nei openEHR

item_tree.intravenous_fluids - - openEHR -

NY: item_tree.medication-formulation Ja - Tiltak 41

observation.blood_pressure Nei Nei openEHR

observation.bodily_output Nei Nei openEHR

observation.bodily_output-defaecation Nei Nei openEHR

observation.bodily_output-urination Nei Nei openEHR

observation.body_temperature Nei Nei openEHR

observation.body_weight Nei Nei openEHR

observation.ecg Ja Nei openEHR

observation.glasgow_coma Nei Nei openEHR

observation.heart_rate Nei Nei openEHR

observation.heart_rate-pulse Ja - openEHR -

observation.height Nei Nei openEHR

observation.indirect_oximetry Nei Nei openEHR

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

35

Arketype

Ny struktur (Ja/Nei)

”-” betyr ikke relevant

Krever ny versjon? (Ja / Nei / Ikke relevant33)

”-” betyr ikke sammenlignet

Kilde Status i

kilde

observation.intravascular_pressure Nei Nei openEHR

observation.intravascular_pressure-cvp Ja - openEHR

observation.lab_test-blood_gases - - openEHR

observation.lab_test-blood_match - - openEHR

observation.lab_test-full_blood_count - - openEHR

observation.lab_test-urea_and_electrolytes - - openEHR

NY: observation.nas - nursing activities score - - Tiltak 41

NY: observation.nems – nine equivalents of nursing manpower use score

- - Tiltak 41

observation.oral_fluid_intake Ja Ja openEHR

observation.respiration Nei Nei openEHR

NY: observation.saps II - simplified acute physiology score ii

- - Tiltak 41

TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING 13. mars

2012

36

Tabell 3: Arketyper av type cluster/element som refereres fra arketypene over34

Cluster Arketype som bruker cluster

cluster.ambient_oxygen indirect_oximetry respiration

cluster.anatomical_location bodily_ouput defaecation intravascular_pressure urination

cluster.cessation_attempts tobacco_use-summary

cluster.device blood_pressure body_temperature bodily_ouput body_weight defaecation ecg heart_rate height indirect_oximetry intravascular_pressure urination

cluster.environmental_conditions body_temperature

cluster.fluid bodily_ouput defaecation urination

cluster.level_of_exertion blood_pressure body_temperature ecg heart_rate indirect_oximetry respiration

cluster.waveform indirect_oximetry intravascular_pressure

element.menstrual_cycle_day body_temperature

procedure details Procedure

anatomical site details Procedure

34

Prosjektet oversatte bare clusteret ”fluid” pga. gjeldende ramme/kapasitetsbegrensninger

13. mars

2012 TILTAK 41 – RAPPORT MED ANBEFALT OPPFØLGING

37

5 Vedlegg A - Prosjektorganisasjonen

5.1 Prosjektgruppen Tabell 4: Medlemmer i prosjektgruppen

Rannveig Woll Hemit/Helse Midt-Norge

Lisbeth Dahlhaug Helse Midt-Norge

Johan Gustav Bellika Helse Nord

Torsten Eken Helse Sør-Øst

Hallvard Lærum Helse Sør-Øst

Arnt Ole Ree Helse Sør-Øst

Lene Cecilie Mathisen Helse Sør-Øst

Silje Bakke Helse Vest

Torbjørn Nystadnes KITH/Helsedirektoratet, Avd. standardisering

Hans-Olav Warholm KITH/Helsedirektoratet, Avd. standardisering

Jim Yang KITH/Helsedirektoratet, Avd. standardisering

Ole-Fredrik Melleby KITH/Helsedirektoratet, Avd. standardisering

Jostein Ven (prosjektleder) KITH/Helsedirektoratet, Avd. standardisering

5.2 Styringsgruppen Tabell 5: Medlemmer i styringsgruppen

Gunnar Jårvik Helse Vest

Bente Saltnes Nedrebø Nasjonal IKT Klinisk IKT Fagforum

Hans Nielsen-Hauge Helse Sør-Øst

Per Olav Skjesol (leder) Hemit/Helse Midt-Norge

Camilla Bjørnstad Helse Nord