Semantic Health Integration Architecture (SEHIA)

Transkript

1 Semantic Health Integration Architecture (SEHIA) - en lettere vei til interoperabilitet? Trond Elde Helseinformatikk Innlevert: April 2013 Hovedveileder: Øystein Nytrø, IDI Medveileder: Laura Slaughter, IDI Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap

2

3 Erfaringsbasert Masterstudium i Helseinformatikk Semantic Health Integration Architecture (SEHIA) En lettere vei til interoperabilitet? Masteroppgave (IT 6191) V2013 Trond Elde

4 Innhold 0 Sammendrag Innledning Bakgrunn Begrepsliste Kunnskapsbasert medisin og kliniske retningslinjer Klinisk beslutningsstøttesystem EPJ-system Prosesstøttet EPJ krever integrasjon Forskning innen integrasjon Generelt Dataintegrasjon og ontologier Klinisk beslutningsstøtte og EPJ Generelt Digitale kliniske retningslinjer Integrasjon av digitale kliniske retningslinjer med EPJ Relatert arbeid - Evicare Helsestandardisering Innledning Generelt om standardisering innen Helse-IKT Standardisering av EPJ Standardisering av terminologier Standardisering av integrasjon mellom EPJ- og CDS-systemer Metode Kravspesifikasjon Overordnet brukstilfelle Funksjonelle krav Intro Brukerhistorie F1: Vise klinisk pasientkontekst De andre brukerhistoriene som ikke implementeres i POC Ikke-funksjonelle krav Internett og World Wide Web Innledning Generelt Lenkede Data Representasjonsspråk for vokabularer

5 7.5 Resonnering SPARQL et spørrespråk for RDF-grafer Semantisk webteknologi innen helse- og biovitenskap Semantic Health Integration Architecture Introduksjon SEHIA Webintegrasjon Introduksjon Semantisk annotering av digitale retningslinjer Desktop synkronisering SEHIA Dataintegrasjon Introduksjon Extract-transform and load Virtuelt EPJ-grensesnitt Semantisk integrasjon Arbeidsflyt mellom komponenter Innledning Brukerhistorie F1: Vise klinisk pasientkontekst De andre brukerhistoriene som ikke implementeres i SEHIA POC SEHIA POC med DIPS EPJ Introduksjon Testbatteri DIPS Arena EPJ-system Utviklingsplattform og teknologi Implementasjon av Extract-transform and load (ETL) Semantisk integrasjon Innledning Mapping #1.1: DIPS -> Entity.id Mapping #1.2: openehr ->Entity.id Mapping #2.1: DIPS -> EvaluatedPerson.birthTime Mapping #2.2: DIPS -> EvaluatedPerson.age Mapping #2.3: DIPS -> EvaluatedPerson.clinicalStatement Navigering i OpenEHR hierarkiske strukturer Mapping #2.4: OpenEHR-> EvaluatedPerson.clinicalStatement Mapping #3.1: DIPS -> ObservationBase.ObservationFocus Mapping #3.2: openehr -> ObservationBase.ObservationFocus Mapping #4.1: DIPS -> ObservationResult. ObservationEventTime Mapping #4.2: OpenEHR -> ObservationResult. ObservationEventTime

6 Mapping #5.1: DIPS -> ObservationResult.ObservationValue Mapping #5.2: OpenEHR -> ObservationResult.ObservationValue Mapping mellom terminologier Sammensatte begreper Ulik granularitet i kildeskjema og målskjema Implementasjon av SEHIA EHR Server Implementasjon av SEHIA Guideline Controller (GL CTL) Implementasjon av WGL-CMS Mockup Analyse og evaluering Semantisk annotering med RDFa Mapping Oppsummering av evaluering (bra/dårlig) Drøfting Konsekvenser av og tiltak for håndtering av svakhetene i POCen Sammenligning med lignende arbeid Innledning ActiveGuidelines (2000) KDOM (2008) TransFER (1996) IDAN (2005) MEIDA (2009) TM-vMR (2012) Oppsummering Erfaringer fra et systemutviklingsperspektiv Løser SEHIA det praktiske problemet? Intro Informasjonssikkerhet Pasientsikkerhet (-vern) Integrerbarhet, åpenhet og standarder Terminologistøtte Ytelse Oppsummering, konklusjon og forslag til videre arbeid Oppsummering Konklusjon Forslag til videre arbeid Refleksjon Generaliserbarhet

7 13.2 Kompetanse Kompleksitet Appendiks HL7 Virtual Medical Record (vmr) domain models openehr Reference Model og Archetype Model Bibliografi

8 0 SAMMENDRAG Problemstilling: Sømløs integrasjon mellom EPJ- og kliniske beslutningsstøttesystemer (CDS-systemer) er identifisert som et nødvendig virkemiddel for å oppnå kunnskapsbasert medisin i praksis (prosesstøttet EPJ). Forskning konkluderer med at det har vært vanskelig å oppnå nevneverdig standardisering og utbredelse av integrasjoner mellom kliniske beslutningsstøttesystemer (CDS-systemer) og pasientjournalsystemer (EPJ). Utover de kommersielle og juridiske utfordringene, så er stor heterogenitet mellom systemene og manglende interoperabilitet kanskje den viktigste teknologiske grunnen. Skreddersydde integrasjoner mellom slike systemer blir ofte veldig kostbare og tidkrevende å utvikle og drifte, feilbefengt, proprietære og lite vedlikeholdbare med tradisjonelle teknikker i programvareindustrien. Samtidig har Semantisk Web visjonen i over 10 år resultert i en mengde nye teknologier (OWL, RDF, SPARQL, osv.) som tilbyr en plattform som har potensiale til å forenkle, men som i liten grad har vært anvendt på systemintegrasjon. Kan lenkede data ("linked data") og semantisk web (LD og SemWeb) egne seg til å lette integrasjon mellom EPJ- og CDSsystemer? Hvor passer det best og hvor passer det ikke? Metode: Med utgangspunkt i identifiserte behov i forskningsprosjektet EVICARE forsøkes utviklet en proof-ofconcept løsning Semantic Health Integration Architecture (SEHIA) - som demonstrerer hvordan noen få utvalgte kliniske variabler (eks. labanalyser, medikasjon, prosedyrer) kan utveksles mellom CDS-systemer og EPJ ved hjelp av Semantisk Web-teknologi. Konklusjon: LD og SemWeb passer godt på noen områder, men mindre bra på andre. Passer godt til håndtering av kodeverk, klassifikasjonshierarkier/taksonomier og terminologisystemer og semantisk annotering med RDFa av HTML-basert elektroniske kliniske retningslinjer for statiske websider (Web 1.0). RDFa passer mindre bra for dynamiske websider (Web 2.0). OWL DL og RIF-basert resonnering med regler er ikke tilstrekkelig for å integrere ulike datamodeller fordi «transformasjonsfunksjoner» (eks. kalkulasjoner, strengmanipulering) mangler. Høy kompleksitet var for øvrig et stort problem som sannsynligvis delvis skyldes manglende verktøystøtte. 6

9 1 INNLEDNING Denne masteroppgaven omhandler integrasjon mellom elektroniske kliniske retningslinje-oppslagsverk (eks. Helsebiblioteket.no, NGC, BestPractice, UpToDate, osv.) og EPJ-systemer. Poenget er å etablere kontekstbaserte søk i pasientens journal basert på innhold i kliniske retningslinjer som legene benytter for å få rådgiving ifbm. med diagnostisering- og behandling. Tittelen «Semantic Health Integration Architecture» (SEHIA) er valgt fordi dette er en oppgave som først og fremst handler om programvarearkitektur som kan brukes for å integrere systemer på en ny måte basert på webteknologi. Oppgaven tar utgangspunkt i at kravet om at helsepersonell skal praktisere kunnskapsbasert medisin (EBM) og at det er veldig vanskelig å gjøre uten at denne kunnskapen integreres sømløst inn i EPJ-systemene. Elektroniske retningslinje-oppslagsverk er en type klinisk beslutningsstøttesystem (CDS-system). Kliniske beslutningsstøttesystemer (CDS-systemer) spiller en viktig rolle for å oppfylle forventning om kunnskapsbasert medisin. Det finnes flere typer CDS-systemer i tillegg til elektronisk oppslagsverk. Bl.a. løsninger for varsling ved interaksjon ved forskriving av legemidler, automatiske varsler ved unormale labsvar (eller kombinasjoner) og til mer avanserte systemer med formell modellering av arbeidsflyt (workflow) i det kliniske forløpet. Mye av forskningen innenfor CDS-systemer har dreid seg om det siste, dvs. hvordan man modellerer og eksekvererer kliniske retningslinjer i datamaskiner. Erfaringene har vist at modellering av klinisk kunnskap, retningslinjer og anbefalinger for eksekvering i datamaskin er høyst komplisert. I tillegg er det et krav at CDS-systemer integreres sømløst med helseinformasjonsystemer (i hovedsak EPJ) hvor pasientopplysninger finnes, slik at terskelen for å ta i bruk CDSsystemer blir så lav som mulig i en hektisk hverdag. På grunn av store forskjeller (heterogenitet) mellom systemene, blir integrasjonene komplekse og kostbare å utvikle. Høye ambisjoner i kombinasjon med vanskelige integrasjoner har medført at løsningene er proprietære og systemavhengige innenfor et begrenset fagområde. Resultatet er manglende standardisering og liten utbredelse på verdensbasis. EVICARE (se kapittel 3.4) er et forskningsprosjekt i Norge som forsøker å integrere elektroniske kunnskapsbaserte kliniske oppslagsverk ved å «semantisk matche» narrativ kunnskap med pasientens journal i stedet for å modellere kunnskapen for eksekvering i datamaskiner. På den måten styrer man unna mye av kompleksiteten med modellering som beskrevet ovenfor, og står igjen med utfordringen med integrasjon mellom CDS- og EPJ-system Utfordringene med integrasjon er stor i og med heterogenitet mellom ulike leverandører av EPJ-systemer og CDSsystemer både når det gjelder informasjonsmodeller og terminologi. Full standardisering på verdensbasis av EPJ og CDS-systemer vil høyst sannsynlig ikke skje i overskuelig framtid, kanskje aldri. Mange forskningsprosjekter (se kapittel 11.2) har derfor foreslått ulike «bridge»-løsninger for integrasjon opp igjennom årene, men har ikke blitt standardisert (og trolig lite i bruk). Rundt årtusenskiftet lanserte Tim-Berners Lee «The Semantic Web» [1], og har blitt standardisert i regi av World Wide Web Consortioum (W3C). På samme måte som den ordinære weben muliggjorde verdensomspennende kommunikasjon mellom mennesker, så var målet til den «semantiske weben» en web hvor datamaskiner kunne utveksle meningsfull informasjon uten menneskelig inngripen. Et av de store forskningsområdene innen Semantisk Web miljøene er problemet med semantisk heterogenitet, og utvikling av metoder, teknikker og teknologi for å håndtere dette såkalt ontologiforskning. På tross av at Semantisk Web har eksistert over 10 år, finnes det ingen forskningsprosjekter (kjent av forfatter) som har benyttet Semantisk Web-teknologi for å håndtere integrasjon mellom CDS- og EPJ-systemer, selv om hensikten 7

10 med teknologien er å oppnå semantisk interoperabilitet. Med utgangspunkt i Evicare-prosjektet sitt behov for «matche» retningslinjeinnhold med pasientens journal, foreslås en integrasjonsarkitektur - Semantic Health Integration Architecture (SEHIA) hvor det gjøres et forsøk på integrasjon ved bruk av Lenkede Data og Semantisk Webteknologi. Kan denne teknologien være et bidrag til å forenkle integrasjonsarbeidet? Oppgaven har som mål å finne ut hvorvidt det er praktisk mulig å gjennomføre en slik integrasjon og om Lenkede Data og Semantisk Web (LD og SemWeb) er egnet for formålet, og eventuelt hvor det passer best. Oppgaven avgrenser seg til å se på hvordan relevant pasientinformasjon kan søkes fram basert på innhold i kliniske retningslinjer, med andre ord kontekstbasert semantisk søk i EPJ basert på innhold i retningslinjer. Oppgavens oppbygging er som følger: Kapittel 2 bakgrunn er en kort introduksjon til kunnskapsbasert medisin, kliniske beslutningsstøttesystemer, EPJ og prosesstøtte. Kapittelet inneholder også en begrepsliste med forkortelser benyttet i resten av teksten. Dette kapittelet er spesielt nyttig for de som ikke kjenner til disse begrepene fra før av. Kapittel 3 forskning innen integrasjon introduserer kort forskning innenfor dataintegrasjon og ontologiforskning. Deretter beskrives et par av de viktigste forskningsutfordringene innenfor EPJ og CDS-systemer, nemlig hvordan representere kliniske digitale retningslinjer (DKR) og utfordringen med integrasjon mellom EPJ og CDS-systemer. Tilslutt presenteres FoU prosjektet EVICARE som denne masteroppgaven er en forlengelse av. Kapittel 4 standardisering starter med motivasjonen bak standardisering ut fra behovet om å utveksle informasjon mellom systemer (fra teknisk til semantisk standardisering), standardiseringsprosesser og organisasjoner. Deretter beskrives standarder som er relevante innenfor helse-ikt EPJ, terminologisystemer, kliniske beslutningsstøttesystemer og integrasjonsgrensesnitt. Poenget er å gi et bilde av hvor vanskelig det er å standardisere. Tilslutt beskrives standardisering av Internett, med utgangspunkt web generasjon 1.0, 2.0 og 3.0. Web 3.0 kalles ofte for den Semantiske Weben som er teknologien som anvendes i denne masteroppgaven. I kapittel 5 Metode beskrives prosessen med å besvare forskningsspørsmålet som består av å utarbeide en kravspesifikasjon og utarbeide et testbatteri for SEHIA proof-of-concept (kapittel 6), beskrivelse av løsning og arkitektur (SEHIA) som understøtter kravene (kapittel 8), utvikle en SEHIA POC med integrasjon mot DIPS Arena EPJ (kapittel 9) og tilslutt en analyse av SEHIA POCen (kapittel 10). I kapittel 11 drøftes hvorvidt SEHIA POC oppfyller brukernes (helseforetakenes) krav, sammenligning med lignende forskningsprosjekter og erfaringer som ble gjort fra et systemutviklingsperspektiv under utviklingen av POCen. Kapittel 12 er en oppsummering, konklusjon og forslag til videre arbeid. Oppgaven avrundes med en refleksjon på mulige svakheter i oppgaven og generaliserbarhet (kapittel 13) 8

11 2 BAKGRUNN 2.1 BEGREPSLISTE Oversikt over norske og engelske termer og forkortelser som blir brukt senere i oppgaven. Norsk term Engelsk term Forkortelse i denne oppgaven: Lenkede Data og Semantisk Web LD og SemWeb anbefaling recommendation beslutningsstøttesystem clinical decision support system CDS-system brukstilfelle use case digital klinisk retningslinje Computer-interpretable-Guideline DKR (CIG) elektronisk content management system CMS dokumenthåndteringssystem elektronisk pasientjournal electronic healthrecord EPJ klinisk retningslinje clinical guideline GL kunnskapsbasert medisin evidence based medicine EBM webbasert nettsted med kliniske retningslinjer web based guideline content management system WGL-CMS Termene blir forklart underveis i teksten nedenfor. 2.2 KUNNSKAPSBASERT MEDISIN OG KLINISKE RETNINGSLINJER Historisk sett har legepraksis lagt til grunn egne erfaringer, erfaring og kunnskaper fra toneangivende fagmiljøer og andre spesialister når man tar tatt kliniske beslutninger. I en slik legepraksis mangler det ordentlig dokumentasjon av helseeffekter[2]. Konsekvensen er at en pasient med samme problem kan risikere å få forskjellig behandling avhengig av hvilken lege han/hun møter på, siden leger ikke følger samme anbefalt praksis. I et moderne helsevesen er dette ikke akseptabelt når en samtidig vet at det på verdensbasis gjennomføres mye klinisk forskning for å skaffe til veie nødvendig dokumentasjon, så handler det ofte om systematisere og ta i bruk kunnskapen i praksis. Forsknings- eller kunnskapsbasert medisin («evidence based medicine») er ifølge Sackett et al [3] klinisk praksis hvor man integrerer den beste eksterne vitenskapelige dokumentasjon, individuell klinisk ekspertise og pasientens preferanser for å gi pasienten den beste og mest effektive behandling. Med vitenskapelig dokumentasjon menes randomiserte kliniske forsøk (RCT), kohorte-, kasuskontrollstudier eller tverrsnittstudier («cross-sectional study») som er utført etter anerkjente vitenskapelige metoder. Dersom mange enkeltstudier undersøker identiske sykdomstilfeller, kan man gjøre en metaanalyse. I en metaanalyse slår man sammen tallene fra enkeltstudiene for å få mer presise effektestimater for virkningen av en medisinsk behandling. En grundig og systematisk gjennomgang av all dokumentasjon tilhørende ett tema kalles for en systematisk oversikt. Systematiske oversikter inneholder ofte metaanalyser av dokumentasjonen man har funnet. Det mest kjente publiseringsstedet for metaanalyser er Cochrane Library. Kunnskap i form av artikler er lite egnet for klinisk praktisk bruk. Det utarbeides derfor kliniske retningslinjer hvor denne kunnskapen gjøres tilgjengelig gjennom praktiske anbefalinger som kan brukes «at the point of care». De 9

12 inkluderer modaliteter, evidensgrunnlag for diagnostisering, prognoser, forslag til behandling og annen kunnskap som er viktig for å ta beslutninger rundt pasientbehandling. Retningslinjene må distribueres, og her er webteknologi et uvurderlig hjelpemiddel. På verdensbasis er det amerikanske National Guideline Clearinghouse (NGC), UpToDate, BestPractice, Britiske National Institute for Clinical Excellence (NICE) anerkjente bibliotek for dette formålet. I Norge har Nasjonalt kunnskapssenter for helsetjenesten opprettet nettstedet Helsebiblioteket.no, som samler mye av den nasjonale og internasjonale forskning innen medisin (se tabell i kapittel 2.3). På tross av at retningslinjer foreligger tilgjengelig på internett er det fremdeles en utfordring å få anbefalingene implementert i klinikken, og det kan ta flere år fra kunnskapen foreligger til den er implementert i praksis. Dette er ikke godt nok. Det trengs derfor bedre verktøy og metoder. Det finnes per i dag ingen standard struktur for en klinisk retningslinje, men inneholder ofte en rekke anbefalinger. Organisasjonen GRADE working group har laget standarder for hvordan anbefalingene i retningslinjen kan graderes i forhold til hvor sterk anbefalingen er (sterk, svak), basert på en avveining mellom fordeler, risiko og belastning, og kvaliteten på kunnskapsgrunnlaget (høy, moderat, lav, veldig lav) [4]. Anbefalingene er identifisert ved hjelp av strukturerte spørsmål basert på PICO-spørsmål: populasjon (hvem gjelder anbefalingen for), intervensjon (tiltak), sammenligningsgrunnlag («comparator») og resultat for pasient («outcome») [5]. 2.3 KLINISK BESLUTNINGSSTØTTESYSTEM Klinisk beslutningsstøtte (clinical decision support CDS) er å innarbeide kunnskapsbasert medisin i klinisk praksis, som f.eks. varsler og råd for å forebygge utilsiktede hendelser [6]. Et IKT-verktøy som er laget for å tilby klinisk beslutningsstøtte kalles for klinisk beslutningsstøttesystem (clinical decision support system CDS-system). Det er mange måter klinisk beslutningsstøtte kan manifestere seg på. Klassiske eksempler er kliniske varsler, kalkulatorer, påminnelser, sjekklister, rekvirerings- og forskrivningsstøtte eller online tilgang til kliniske retningslinjer og deklarativ kunnskap på web. Beslutningsstøtten gjelder både situasjoner der klinikeren skal velge det «beste» av alternative tiltak rundt pasienten (eks. ved rekvirering), men også der hvor det er behov for å påkalle oppmerksomhet (eks. mottak av prøvesvar som overstiger terskelverdier). Å velge «rett» tiltak er å velge det tiltaket som, ut fra beste tilgjengelige medisinsk kunnskap og pasientens preferanser, vil gi den beste behandlingen for pasienten. Eksempler er forslag til diagnostisering gitt et problem, forslag til behandling gitt en diagnose, kontroll mot interaksjonsdatabase og CAVE-opplysninger ved forskriving av legemidler, automatisk oppslag i legemiddelhåndbok ved forskriving, «automatisk» oppslag i online kliniske retningslinjedatabaser gitt et problem eller diagnose. På den annen side er det viktig at klinikeren tar beslutninger når det er behov for det. Å motta ulike varsler hvis det er behov for oppmerksomhet f.eks. på prøvesvar og eller kombinasjoner av prøvesvar som overstiger terskelverdier er også karakteristisk for beslutningsstøtte. Ellers nevnes ofte «påminnelser» som en beslutningsstøttefunksjon, f.eks. husk å innkalle pasient til 3- månedskontroll. Selv om dette strengt tatt ikke er en funksjon som primært er rettet mot å forbedre klinikers evne til å ta de riktige beslutninger til rett tid, så handler dette om oppfølging av tidligere besluttede tiltak og forebygging mot avvik ved gjennomføring av disse. Oppsummert kan man si at målsettingen for klinisk beslutningsstøtte er å sørge for at klinisk praksis gjøres i henhold til retningslinjer gitt av den beste kliniske tilgjengelig kunnskap innen et fagfelt. 10

13 En systematisk oversikt fra 2005 [7] viser en betydelig forbedring i pasientbehandlingen i over 90 % av tilfellene hvor beslutningsstøttesystemene var integrert del av pasientbehandlingen og hvor anbefalingene var konkrete kontra uten beslutningsstøttesystem. Det finnes ingen entydig prototype av et typisk klinisk beslutningsstøttesystem (CDS-systemer). Ved en gjennomgang av 74 ulike CDS-systemer konkluderer Berlin et al fra 2005 [8] at CDS-systemer er svært forskjellige (heterogene), og at resultater fra ulike studier ikke uten videre kan anvendes på andre kliniske fagområder eller organisasjoner («workflow setting»). Det eneste som er felles er at systemene innarbeider kunnskapsbasert medisin i klinisk praksis. I de mest avanserte systemene modelleres retningslinjene som formelle kliniske prosessmodeller som kan eksekveres og benyttes i et system med støtte for elektronisk forløpsplanlegging («care pathway») og arbeidsflyt («workflow»). De avanserte løsningene er gjerne proprietære med liten utbredelse. Årsakene er heterogene systemer i kombinasjon med store krav til interoperabilitet, samt kompleksiteten i kliniske vurderinger og variasjoner i pasientpopulasjonen. Enklere løsninger er gjerne funksjoner (moduler) som baseres på enkle regler som trigger varslinger, f.eks. interaksjonskontroll for forskriving av legemidler eller prøvesvar som overstiger terskelverdier. De enkleste løsningene er gjerne støtte for søk og oppslag i narrative webbaserte retningslinjedatabaser og deklarativ kunnskap (Helsebiblioteket, UpToDate, BestPractice, Norsk legemiddelhåndbok - NEL) og er tilgjengelig overalt hvor internett er tilgjengelig og med en nettleser («browser»). Slike nettsteder kalles i denne oppgaven for «guideline content management system» (WGL-CMS) fordi de inneholder en samling narrative retningslinjer i elektronisk form. WGL- CMS er eksempel på passiv beslutningsstøtte som krever at klinikeren aktivt søker og slår opp i dokumentasjonen. Eksempler på slike nettsteder vises i tabellen nedenfor: Tittel (URL) Helsebiblioteket ( National Guideline Clearinghouse (NGC) ( Guidelines International Network (GIN) ( NICE guidance ( UpToDate ( Beskrivelse Norske retningslinjer, prosedyrer, behandlingsanbefalinger og veiledere for forebygging, diagnostikk, behandling og oppfølging «National Guideline Clearinghouse er en database over kunnskapsbaserte retningslinjer etter initiativ fra det amerikanske helsedepartementet. Tjenesten tilbyr lenker til retningslinjer i fulltekst, eller informasjon om hvordan en kan bestille retningslinjen i fulltekst.» *) «Helsebiblioteket gir alt helsepersonell fri tilgang til Guidelines International Network (G-I-N). Dette internasjonale retningslinjebiblioteket inneholder mer enn retningslinjer, kunnskapsoppsummeringer og nyheter fra medlemsland.» *) «Her kan du søke etter retningslinjer godkjent for bruk i Storbritannia. Samtlige retningslinjer i databasen bygger på en systematisk innsamling av vitenskapelig dokumentasjon og kan lastes ned fra nettet i fulltekst.» *) «UpToDate is an evidence-based, physician-authored clinical decision support resource which clinicians trust to make the right point-of-care decisions. More than 5,100 world-renowned physician authors, editors and peer reviewers use a rigorous editorial process to synthesize the most recent medical information into trusted, evidence-based recommendations that are proven to improve patient care and quality» **) 11

14 BestPractice ( «Healthcare professionals need fast and easy access to reliable, up-to-date information when making diagnosis and treatment decisions.. In a single source we have combined the latest research evidence, guidelines and expert opinion presented in a step-by-step approach, covering prevention, diagnosis, treatment and prognosis.» **) *) Sitat hentet fra **) Sitater hentet fra hjemmesiden. Problemet med passiv beslutningsstøtte er at den krever en aktiv handling fra brukeren. Å finne relevant informasjon krever at bruker søker og navigerer til websiden. Deretter må innholdet leser og tolkes. Terskelen for å benytte denne typen kunnskap i en travel arbeidsdag er høyere enn om at kunnskapen aktivt ble «pushet» når det var relevant. I forskningsprosjektet Evicare (se 3.4) og i denne masteroppgaven er målet å se på hvordan man forbedre WGL-CMS med «aktiv beslutningsstøtte». 2.4 EPJ-SYSTEM Et elektronisk pasientjournalsystem (EPJ-system, «EHR system») defineres som et system for administrasjon og oppbevaring av et sett pasientjournaler. En pasientjournal er en samling eller sammenstilling av nedtegnelser/registrerte opplysninger om en pasient i forbindelse med helsehjelp jf. 3a) i Forskrift om pasientjournal 1. For helsepersonell er det altså lovpålagt å føre en pasientjournal. De registrerte opplysningene inneholder både planlagte tiltak (forordninger), hva som er utført (tiltak), hvilke observasjoner som er gjort og hvilke vurderinger (evalueringer) legen eller sykepleieren har gjort seg. Det finnes flere forskjellige journaler for eksempel legejournal, sykepleiejournal, anestesijournal, øyejournal, osv. Mange av opplysningene i pasientens journal er fritekst (narrativ), men supplert med kode fra ulike klassifikasjonssystemer som bl.a. diagnosekoder (ICD10), prosedyrekoder (NCSP), labanalyse-koder (lokale og NEKLAB), legemiddel (FEST), osv. Pasientens journal brukes også som grunnlag for forskning og utdanning. EPJ er et logisk begrep hvor journalopplysninger i prinsippet kan spres i ulike systemer. Dersom et system er klassifisert som EPJ, må opplysningene lagres iht. norske lover og forskrifter ved føring av pasientjournaler. Personvernlovgivingen for behandling helseopplysninger reguleres av et sett av lover og forskrifter, men hovedsakelig av Helseregisterloven 2 og Helsepersonelloven 3. Helseregisterloven er en særlov til Personopplysningsloven 4, og skal sikre at helseopplysninger blir behandlet i samsvar med grunnleggende personvernhensyn, herunder behovet for personlig integritet, privatlivets fred og tilstrekkelig kvalitet på helseopplysninger. Personvernlovgivingen setter både krav til helsepersonell (profesjonskrav) og systemer. Dokumentasjonsplikten er regulert av Helsepersonelloven og Pasientjournalforskriften 5. Denne setter krav til hvordan helsepersonell skal føre journal, dvs. innhold i pasientjournaler, føring, retting, sletting, oppbevaring, overføring, tilgang til og tilintetgjøring av journal LOV nr 24: Lov om helseregistre og behandling av helseopplysninger 3 LOV nr 64: Lov om helsepersonell m.v. 4 LOV nr 31: Lov om behandling av personopplysninger 5 FOR nr 1385: Forskrift om pasientjournal 12

15 Lovverket i Norge gjør det fornuftig å definere ett system som pasientjournalsystemet (EPJ) som ivaretar lov- og forskriftsverk og ulike avdelingsvise kliniske informasjonssystemer eller fagsystemer hvor pasientopplysninger oppstår i og som etter hvert «arkiveres» i EPJ systemet for senere oppslag. Tradisjonelle EPJ-systemer har arvet mye fra papirjournalen når det gjelder støtte for fritekst (narrative) dokumenter (polikliniske notater, epikriser, røntgensvar og andre journalnotater) og innskannede bilder. Dette er ofte kalt «papir til skjerm». Innholdet i fritekstnotater og bilder er av natur «utilgjengelig» for tradisjonell databehandling. Det pågår avansert forskning innenfor naturlig språkprosessering (NLP) som trekker ut meningen med innholdet slik at disse kan inngå som input til beslutningsstøttefunksjoner. Det er også mulig å supplere teksten eller bildet med tagger som klassifiserer innholdet, og kan være en støtte ifbm. søk. Moderne EPJ-systemer har imidlertid stadig mer støtte for strukturert journaldokumentasjon, bl.a. rekvirering og svar av lab, forskriving og medikasjon, klinisk koding, og etter hvert arketyper osv. Dette kaller vi for strukturerte data. Det er data som knyttes opp mot en modell enten datamodell eller skjema som er en klassifikasjon av data. Klassifikasjon av data gjør det mulig å tilby ulike beslutningsstøttefunksjoner f.eks. interaksjonskontroll ved elektronisk forskriving av resepter. EPJ-systemer benytter typisk relasjonsdatabaser (Oracle, SQL Server, etc.) for å lagre strukturerte data i tabeller og kolonner. Siden EPJ-systemer ofte behandler strukturerte dokumenter, er dokumentdatabaser (f.eks. Oracle XML DB, RavenDB) blitt mer aktuell. F.eks. vil alle data i openehr arketype baserte systemer være i form av dokumenter («composition»). Datamodeller og databaseskjemaer er ofte leverandørproprietære, og samme kliniske opplysning vil typisk være representert ulikt i ulike systemer. Terminologier og kodeverk kan variere fra system til system, og noen terminologier er særnorske (eks. Norsk Laboratoriekodeverk - tidligere kalt for NEKLAB). I tillegg til stor variasjon i representasjon av pasientjournal har EPJ-systemene svært ulike teknisk arkitektur. Fra tradisjonelle EPJ-systemer med klient/tjener arkitektur og til moderne webbaserte EPJ-systemer med HTML5 eller «native» applikasjonsklient (Windows 8). Det er altså stor variasjon mellom EPJ-systemer når det gjelder representasjon av pasientjournal og teknisk arkitektur. Det er derfor vanskelig å lage generiske integrasjoner med kliniske beslutningsstøttesystem som er leverandøruavhengig. Etter hvert har det kommet flere standarder som kan avhjelpe dette (se 4.4). 2.5 PROSESSTØTTET EPJ KREVER INTEGRASJON En viktig suksessfaktor for prosesstøtte i helsevesenet er gode integrasjoner. Både det å unngå at informasjon må dobbeltregistreres, og at systemene understøtter samhandlingsprosessene i mellom enheter i helsevesenet er viktig, eks. henvisninger, epikriser og utskrivingsmeldinger. Å lage integrasjoner mellom systemer ansees som vanskelig. Ulike teknologiske plattformer og syntakser, ulike informasjonsmodeller, ulike kodeverk (terminologier) samt ulike versjoner (generasjoner) av disse byr ofte på store utfordringer. I tillegg må slike integrasjoner utvikles og innføres med stor forsiktighet og med mye testing for ikke å være til skade for pasienten. Dette gjør at integrasjoner både tar lang tid og er kostbart å lage. Noen eksempler på problemstillinger: 13

16 - Systemleverandør A tilbyr ingen integrasjonsgrensesnitt for å hente eller oppdatere bestemte data i systemet kun et administrasjonsgrensesnitt for sluttbruker. - Systemleverandør A tilbyr API 6 basert på Microsoft COM 7, mens systemleverandør B tilbyr filbasert integrasjon. - Systemleverandør A tilbyr meldingsintegrasjon på KITH XML-format, mens systemleverandør B tilbyr meldingsintegrasjon basert på HL7v2 melding (ikke-xml). - Systemleverandør A tilbyr integrasjon på KITH XML-format, mens systemleverandør tilbyr HL7v3 XML - Systemleverandør A benytter klient/tjener arkitektur, mens leverandør B benytter tjenesteorientert arkitektur (SOA) - Systemleverandør A benytter Microsoft.Net på brukerflaten, mens leverandør B benytter webgrensesnitt (HTML/Ajax) - Helseforetak A har sitt lokale (proprietære) analysekodeverk, som er forskjellig fra sykehus B. - Internasjonale leverandører benytter LOINC for labanalyser, mens norske helseforetak benytter proprietære kodeverk - Internasjonale leverandører benytter RxNorm for legemiddelidentifkasjon, men norske (skal) benytte FEST. Listen over utfordringer kan gjøres mye lengre enn dette. Listen ovenfor representerer mangler på interoperabilitet mellom systemer. Slike systemer kalles ofte for «applikasjonssiloer» eller «siloarkitektur» hvor systemene er ulike isolerte «øyer» som er vanskelig å integrere. Det er et krav om at klinisk beslutningsstøtte må være integrert i klinikers daglige arbeidsrutiner for at det skal være ekte beslutningsstøtte. Bruk av EPJ systemer for dokumentering av pasientbehandling er en naturlig del av de daglige arbeidsrutinene. Kliniske beslutningsstøttesystemer (CDS-systemer) krever mye av det samme datagrunnlaget som det som allerede dokumenteres i EPJ. Å kreve ekstra registrering av data som allerede blir registrert i EPJ er et hinder for bruk av slike systemer. Beslutningsstøttesystemer må derfor integreres med EPJ for at det skal være ekte beslutningsstøtte. Et EPJ-system med integrerte beslutningsstøttefunksjoner kalles for et klinisk prosesstøttende EPJ-system. En generell illustrasjon av klinisk beslutningsstøttesystem med integrasjon mot EPJ hentet fra [9] i Figur 1. 6 Application Programming Interface

17 Figur 1: Illustrasjon av beslutningsstøttefunksjoner Noen eksempler på prosesstøttet EPJ: Mens kliniker planlegger og dokumenterer pasientforløpet i EPJ, så skal ulike typer hendelser (triggere) - som for eksempel ny legemiddelforskrivninger, nytt labanalysesvar, ny diagnose settes, nye problemer beskrives i journalen sendes fortløpende til et CDS-system. CDS-systemet vil da evaluere disse og evt. komme med ulike varsler, anbefalinger og forslag til forskrivinger/forordninger («order set») som kan hjelpe klinikeren i å gi bedre og mer korrekt behandling iht. kunnskapsbasert medisinpraksis. Er det noen legemiddelinteraksjoner knyttet til forskrivingen som gjøres nå? Hvilke anbefalinger gis i forbindelser med behandling av DVT? Ved forskriving av 1. dose av HPV-vaksinen foreslås det forskriving av 2. dose om 121 dager, og 3. dose om 182 dager. Selv om det på verdensbasis rapporteres om gode erfaringer med prosesstøttende EPJ-system hvor beslutningsstøtte er integrert med EPJ, er dette hovedsakelig skreddersydde integrasjoner med liten utbredelse. I stedet har det dukket opp en mengde store og små spesialistsystemer som fungerer som EPJ for spesialområdet og samtidig integrert beslutningsstøtte for fagområdet. Selv om slike systemer har god prosesstøtte for spesialisten, så må dokumentasjonen arkiveres i foretakets EPJ. Integrasjonen blir gjerne enklere om beslutningsstøtte for fagområdet integreres i EPJ systemet, og dette blir typisk da utført ved hjelp av en PDF eller tekst uten struktur (semantikk). God prosesstøtte er ikke bare noe som gjelder innenfor sykehusets vegger. Den nye helsereformen beskriver mer spesialisering og samhandling mellom sentrale sykehus og mindre helsesenter i distriktene. Dette vil kreve samhandlingsløsninger på tvers av virksomhetsgrenser, og dermed integrasjon mellom systemer. Med internett er det også muligheter for samhandling på tvers av landegrenser og bruk av tjenester i «nettskyen» som leverer beslutningsstøtte (eks. SEBASTIAN [10]). Hovedproblemet er som sagt stor heterogenitet mellom systemene som gjør det vanskelig å integrere. Både teknologi, plattform, arkitektur, datamodeller og kodeverk er ofte forskjellig. Det finnes mange integrasjonsprodukter og arkitekturer (Enterprise Service Bus, Biztalk, etc.) som gjør det forholdsvis enkelt å bygge bro mellom ulike teknologier, plattformer og arkitekturer, men den største barrieren er ofte semantisk heterogenitet. Det at systemene ikke «forstår» hverandre som er analogt med mennesker som snakker ulike 15

18 språk og bruker ulike termer for samme eller lignende begrep. De opererer med ulike inkompatible «datamodeller» og terminologier. På tross av at internettstandardene (TCP/IP, HTTP, HTML) har sørget for på verdensomspennende interoperabilitet på teknisk nivå, så er semantisk interoperabilitet en helt annen og tøffere skål. Å få systemer til å utveksle innhold med mening kalles for semantisk interoperabilitet. Det er hovedsakelig to måter å oppnå semantisk interoperabilitet: 1. dataintegrasjon 2. standardisering Dataintegrasjon består i å etablere «mapping» eller «bridge» teknologier som gjør det mulig å integrere systemer, plattformer, teknologier eller ontologier på tross av at de har forskjellige datamodell. Dataintegrasjon er et forskningsfelt som beskrives i kapittel 3.2. Å etablere standarder for hvordan CDS-systemer kan integreres med EPJ er en alternativ strategi. Standardisering som virkemiddel er beskrevet i kapittel 4. 16

19 3 FORSKNING INNEN INTEGRASJON 3.1 GENERELT Dette kapittelet omhandler først generell teori innenfor forskningsområdet dataintegrasjon (kapittel 3.2) og deretter hvordan dette anvendes i forskning på integrasjon mellom kliniske beslutningsstøttesystemer integrert med EPJ (kapittel 3.3). Tilslutt beskrives FoU prosjektet EVICARE som denne masteroppgaven er en forlengelse av (kapittel 3.4). 3.2 DATAINTEGRASJON OG ONTOLOGIER Systemer eller applikasjoner som er utviklet «uten» tanke på integrasjon kalles ofte for «siloapplikasjoner». I en verden der systemer og databaser etableres uavhengig av hverandre, er det uansett vanskelig å vite når det er behov for standardisering eller ikke. I tillegg er standardisering tidkrevende, og «time to market» er ofte viktigere. Da vil det oppstå heterogenitet mellom systemene som gjør kan gjøre integrasjon utfordrende. En ting er de tekniske forskjellene i teknologi og arkitektur som gjør integrasjon utfordrende, men en annen ting er at data er representert veldig ulikt fra system til system. Det finnes etter hvert mange verktøy, teknologier, metoder, formater for å etablere åpne og interoperable løsninger, f.eks. SOA, Web Services, REST, HTTP, HTML og XML. Med fremveksten av internett og dermed standardiserte kommunikasjonsteknologier har det blitt mye enklere å integrere enn før. Standardisering av kommunikasjonsteknologier og sammenkobling i internett gjør det i prinsippet mulig for enhver datamaskin å kommunisere med hverandre gitt nødvendig tilgang. Internett har bidratt til at mennesker nå fritt kan utveksle informasjon seg i mellom. På tross av all innovasjon med internett er det flere store utfordringer. For det første er mesteparten av data lagret i «legacy» databaser som verken er koblet til eller benytter de tekniske standardene som beskrevet ovenfor. En annen, og større utfordring, er at databasene beskriver de samme tingene ulikt, ulikt begrepsapparat (terminologi) og ulike definisjoner (mening) av det samme objektet i den virkelige verdenen («real world object»). Dette er analogt med kryptering, mottaker skjønner ikke innholdet og derfor ikke meningen med innholdet [11]. Forskjellene i terminologi og mening kalles for semantisk heterogenitet. F.eks. at samme term er brukt i to systemer, men har forskjellig betydning. Å finne metoder som muliggjør integrasjon mellom semantisk heterogene systemer og data kalles for semantisk integrasjon. Databaseforskning har forsøkt å finne «løsninger» på hvordan etablere semantisk integrasjon mellom semantisk heterogene datakilder i flere 10-år. Det samme grunnleggende problemet finnes innenfor forskning på kunstig intelligens («AI») hvor kunnskapsrepresentasjon og resonnering over virkelige data forutsetter at data har en entydig definisjon. Da Tim Berners-Lee lanserte visjonene om den Semantiske Weben [1] på begynnelsen av tusenårsskiftet hvor data i databasene blir tilgjengeliggjort på internett og representert på samme måte som andre webressurser, har det pågått intens forskning på hvordan oppnå interoperabilitet mellom semantisk heterogene data. Innenfor databaseforskning kalles dette for data integrasjon [12] hvor problemet er å kombinere data som finnes lagret i ulike databaser og tilby brukeren en enhetlig visning av disse. Problemet består både av integrasjon av ulike datamodeller («schemas»), men også av at selve datainnholdet («extensions», «individuals») fra ulike kildedatabaser. Figuren under illustrerer problemet. 17

20 MAPPING IT6191 Masteroppgave Semantic Health Integration Architecture (SEHIA) Spørring (query) Global «mellomliggende» skjema Lokalt skjema 1 Lokalt skjema 2 Lokalt skjema n Figur 2 Prinsipp for dataintegrasjon mellomliggende skjema skjuler forskjeller i datakilder Det mellomliggende skjemaet kan enten være en virtuell visning («virtual view») hvor spørringer blir mappet «onthe-fly» til lokale spørringer via «wrappere» mot datakilder, eller at data på forhånd fysisk transformeres og kopieres inn i en sentral database (datavarehus). Uansett arkitektur må det etableres mappinger fra lokale skjemaer til globalt skjema. Det er mange utfordringer som oppstår her, som skyldes forskjeller i syntaks, struktur, semantikk og systemer. Det finnes ingen entydig taksonomi av semantisk heterogenitet, men mange har kommet med ulike forslag til klassifisering av disse [13][14]. Mye av problemet skyldes at «mapping» sjelden kan gjøres uten å kjenne til den konteksten eller domenet som mappingen skal foregå i. Dette er analogt med oversettelse mellom språk som ofte krever en bakenforliggende forståelse av domenet før korrekt oversetting kan gjøres. Behovet for mer presis og formell definisjon av terminologi og begreper på det som mappes og domenet for øvrig er bakgrunn for at ontologier og ontologiforskning er blitt stadig viktigere. En ontologi er en formell beskrivelse av et domene som er delbar («shareable») og kan utveksles mellom ulike systemer, og uttrykt i et språk som er egnet for resonnering («reasoning») [15]. Det finnes mange «språk» for å beskrive en formell ontologi basert på First- Order Logic, Frame based eller Description Logic (DL) med ulik uttrykkskraft. En variant av Semantic Web Ontology Language (OWL) kalt OWL DL er basert på DL. Det er ikke full enighet om hva en ontologi er. Det er også vanlig å skille mellom lettvekts-ontologier og formelle ontologier hvor definisjonen ovenfor er i kategorien formell ontologi. I artikkelen [11] så er ontologier kategorisert utfra formalitetsnivået: 18

21 Figur 3 Ontologispektrum fra lettvekts- (lavere presisjon) til formelle ontologier (høyere presisjon) En viktig observasjon i figuren er at både databaseskjemaer og XML Skjemaer er former for ontologier, men med lavere uttrykkskraft enn f.eks. DL baserte ontologier som f.eks. OWL DL. Ontologier med mindre uttrykkskraft (lettvektsontologier) skal i prinsippet alltid kunne formuleres med ontologier med mer uttrykkskraft (formelle ontologier). Så i prinsippet skal databaseskjema og XML skjema kunne formuleres i OWL DL uten tap. Det er en kostnad knyttet til kompleksitet forbundet med å ta i bruk ontologispråk med høyere uttrykkskraft i form av høyere kompleksitet, og større krav til de som skal bruke dette. Å formulere en ordliste («term list») ved hjelp av første ordens predikatlogikk (First-Order Logic - FOL) er å skyte spurv med kanon dersom ordlisten bare skal leses og tolkes av mennesker. Hvis man derimot ønsker at ordlisten skal bli «computable», dvs. for resonnering i en datamaskin, så kan innsatsen være kostnadsvarende. Det er derfor viktig at formalitetsnivået avpasses behovet. Selv om distribuerbare ontologier kan utveksles og deles globalt, så er det urealistisk med full standardisering. Det må oppfordres til gjenbruk av ontologier. Innenfor helse er The National Center for Biomedical Ontology (NCBO) et eksempel på dette igjennom nettstedet BioPortal 8. Men tross initiativ rundt standardisering, så er mengden «legacydata» så stor at «mapping» er eneste vei. Det forskes mye på (semi-)automatisering av denne mappingen («mapping discovery»). En metode er å etablere såkalte «upper level» ontologier med generelle begreper som fundament for andre domeneontologier, så kan «mapping» forenkles (eks. Basic Formal Ontology [16]). I et dataintegrasjonsscenario med endelig antall ontologier fra kildedatabaser som skal mappes til en felles ontologi (globalt skjema), så kan manuell mapping være akseptabelt. Ontologier som er mappet kan brukes til ulike integrasjonsoppgaver, som å konvertere data representert i ulike ontologier til hverandre, reformulere spørringer mot data representert i en ontologi til å spørre etter data representert ved en annen ontologi. Å representere mapping kan være alt fra enkle «subclassof», «subpropertyof», «equivalence» [17] relasjoner til mer avanserte rammeverk som i rammeverk som OntoMerge [18] og MAFRA [19] hvor mappinger representers mellom to vilkårlige ontologier. I OIS [20] forutsettes at mappinger skjer mot en sentral mellomliggende ontologi (skjema) etter samme prinsipp som Figur 2. I en

22 distribuert arkitektur som semantisk web skalerer OntoMerge og MAFRA bedre enn OIS siden de ikke forutsetter et globalt mellomliggende skjema. 3.3 KLINISK BESLUTNINGSSTØTTE OG EPJ GENERELT Forskning viser at bruk av CDS-systemer har potensialet til å forbedre pasientbehandling, og samtidig standardisere behandlingen og redusere kostnader [21]. En systematisk gjennomgang fra Kawamoto i 2005 [7] konkluderte med at over 90 % av CDS-systemene forbedret pasientbehandlingen betydelig så fremt beslutningsstøtte ble gjort tilgjengelig som en naturlig del av den kliniske arbeidsflyten det betyr i praksis integrasjon med EPJ, dvs. prosesstøttet EPJ. En metastudie av Gooch og Roudsari fra 2011 [22] oppsummerer at, på tross av 15 års forskning på prosesstøttet helseinformasjonsystemer (eks. prosesstøttet EPJ) med forløpsmaler (care pathway), er det fremdeles mye som gjenstår. Med utgangspunkt i 108 studier, ble utfordringer ved implementasjon av prosessorienterte systemer kartlagt. Det ble identifisert 25 underliggende problemområder. Disse ble igjen gruppert sammen i 10 klynger i forhold i forhold til andre relaterte problemområder. I de 3 største klyngene finner vi følgende problemområder: Gjøre kliniske retningslinjer om til digitale kliniske retningslinjer (DKR) er vanskelig på grunn av mange tvetydigheter og implisitt kunnskap (guideline translation/process modeling) Hvordan implementere en kunnskapsbasert klinisk prosessmodell (for eksempel beskrevet DKR) i et konkret arbeidsflytsystem med nødvendig tilgangsstyring (organizational modeling) Behov for fleksibilitet og tilpasningsevne underveis i et forløp mhp. behov for å håndtere unntak, variasjoner, håndtere manglende og tvetydige pasientdata (flexibility and adaptability/exception handling) Mapping av EPJ-opplysninger til ulike arbeidsoppgaver i et forløp og mapping av retningslinjebegreper til terminologier (data mapping) Sammenblanding av kliniske prosessmodeller i kunnskapsbaserte retningslinjer med modellering av arbeidsflyt i organisasjoner (separation of concerns) Valg av en systemarkitektur som understøtter behovene i kliniske prosesser og arbeidsflyt (system architecture) Som nevnt tidligere kan beslutningsstøtte manifestere seg på mange måter, alt fra enkle sjekklister, bestillingsmaler, assistert oppslag i legemiddelhåndbok eller i medisinske kunnskapdatabaser på web, til litt mer utfordrende interaksjonskontroller mot legemiddel interaksjonsdatabase eller varsler når prøvesvar overstiger terskelverdier. I den andre enden av skalaen finnes realisering av avanserte forløpsplanleggingssystemer (care pathway). Utgangspunktet er at alle kliniske retningslinjer som skal inngå i beslutningsstøttesystemer må være tilgjengelig på elektronisk form, dvs. digitale kliniske retningslinjer (DKR, Computer-interpretable-Guidelines CIGs). En DKR kan ha ulike formaliseringsnivå. I forskningen er det gjerne snakk om retningslinjer som er «oversatt» til et sett med maler, regler og arbeidsoppgaver i en bestemt rekkefølge. Men i denne oppgaven inkluderes også vanlige online webressurser (helsebiblioteket.no, BestPractice, UpToDate, etc.) som DKR, bare med liten grad av formalitet, men dog er datamaskintolkbar for NLP-teknikker. Mye av forskningen innenfor beslutningsstøtte [21] har dreid seg om å finne fram til ulike modeller for å: 1. representere kliniske retningslinjer på en presis måte som digitale retningslinjer (DKR, computerizedinterpretable clinical guidelines - CIGs), 20

23 2. hvordan DKR kan tilpasses for implementering i ulike organisasjoner (arbeidsflyt), 3. hvordan integrere DKR med EPJ-systemer, 4. hvordan tilby beslutningsstøtte i daglig praksis («at the point of care») 5. hvordan forvalte DKR på internasjonal nivå, med nasjonale og lokale tilpasninger (spredning, Clinical Knowledge Manager CKM) [23]. Hovedfokus i denne oppgaven er integrasjon med EPJ (punkt 3), men dette avhenger i stor grad av hvordan retningslinjene er representert som digitale retningslinjer (punkt 1) DIGITALE KLINISKE RETNINGSLINJER I denne oppgaven er det hensiktsmessig å kategorisere forskning innenfor beslutningsstøtte i 3 grovkategorier basert på følgende karakteristikker: 1. Dokumentorientert (narrativ) medisinsk kunnskap 2. Mal- eller regelbasert medisinsk kunnskap 3. Prosedyreorientert medisinsk kunnskap («task network model») Kategori 1 - dokumentorientert (narrativ) medisinsk kunnskap består av støtte for søk og oppslag narrative webbaserte retningslinjedatabaser og deklarativ kunnskap (eks. Helsebiblioteket, UpToDate, BestPractice). I denne kategorien havner forskning i systemer som gjør det enkelt å finne fram i havet av medisinsk kunnskap basert på avanserte søk støttet av opplysninger som allerede ligger i EPJ. F.eks. ved bruk av naturlig språkprosessering (NLP) og en viss nivå av annotering (tagging) av retningslinjeinnhold for å assistere søk. Digitale retningslinjer i denne kategorien kalles gjerne dokumentsentriske («document-centric») [24] hvor man tar utgangspunkt i den originale teksten i retningslinjen, og annoterer denne med semantiske elementer («mark up»). Eksempler på dokumentsentriske modeller tilnærminger er HGML, ActiveGuidelines og Semantic PDF Documents og Evicare. For vanlige retningslinjedatabaser er det ingen krav om integrasjon med EPJ, unntatt at søkefelt kan være tilgjengelig fra EPJ. Ellers kan det også være snakk om å bruke elementer som er registrert i pasientens journal for å assistere søket i retningslinjen, som er hovedideen i Evicare-prosjektet. Det kan også være behov for å opprette forordninger i EPJ basert «order sets» som er annotert i retningslinjen som er ideen i ActiveGuidelines. Eller, som i dette prosjektet, hente spesifikke elementer (analysesvar, kliniske målinger, etc.) fra EPJ som er relevante for retningslinjen. Utover disse er det verdt å nevne arbeidet med InfoButton [25] som nå er blitt standarden HL7 Context-Aware Knowledge Retrieval. Poenget er å etablere linker som kan aktiveres fra ulike steder i helseinformasjonsystemet (f.eks. EPJ, LAB, Røntgen) som er koblet til kunnskapsressurser på nett. Det er linker til relevant informasjon basert på symptomer, problemer, diagnoser, labanalysesvar, osv. Linkene med symbolet (i) er visuelt lett synlig og plassert slik at de kan klikkes på for å lese mer om temaet. Det er verdt å merke seg at siden InfoButton har relativt beskjedne krav til integrasjon, har det blitt implementert «infobutton»-lignende funksjonalitet i en viss skala i USA. Kategori 2 - Mal- eller regelbasert medisinsk kunnskap består av medisinsk kunnskap kodet inn som logikk eller regler i systemene som trigges i bestemte situasjoner. Det kan være medikasjonsmaler («order sets»), kliniske varsler trigget av ulike registrerte opplysninger i pasientens journal, utredningsplaner- og forløpsmaler. Eksempel på kliniske varsler er legemiddel interaksjoner, kalkulatorer som beregner CHA 2 DS 2 VASc score eller medisindoser basert på vekt, labanalyse som er utenfor bestemte terskelverdier, tid for å innkalle til ny mammomgrafiundersøkelse, osv. 21

24 I motsetning til dokumentorienterte tilnærmingene ovenfor, er den direkte knytningen til den originale narrative retningslinjen ikke lenger synlig. Når de originale narrative retningslinjene endres, må tilsvarende endringer (hvis nødvendig) også gjøres i malene-/reglene. Malene- og reglene knyttet til utredning eller behandling av et bestemt problem kan knyttes til bestemte kliniske retningslinje eller anbefalinger. Hvorvidt de til sammen kan sies å representere en komplett digital retningslinje (DKR) er avhengig av hvor kompleks retningslinjen er. For retningslinjer som kan representeres som beslutningstrær (decision trees) 9, så kan regler være nok. For mer komplekse retningslinjer (se kategori 3 nedenfor), så vil maler- og regler ikke være tilstrekkelig. Ved slike tilfeller vil det være snakk om å støtte fragmenter av en klinisk narrativ retningslinje, og da snarere være mer et supplement til narrative retningslinjer, enn en erstatning. Arden Syntax [21] er den mest etablert og best kjente innenfor denne kategorien, og var etablert allerede i 1989, ASTM standard fra 1992 og er nå en HL7 standard. Arden Syntax er et regelbasert 10 språk som grupperes regler i såkalte Medical Logic Modules (MLMs). Selv om medisinsk kunnskap kan kodes inn på et systemuavhengig format, er det likevel behov for tett integrasjon mellom spesifikke EPJ-systemer, dvs. at det er relativt høy kobling («high coupling») som er uheldig ut fra et arkitekturståsted det såkalte «curly braces problem» [24]. Chen [26] beskriver en alternativ tilnærming hvor journalsystemet og digitale retningslinjer (DKR) tar utgangspunkt i den samme ontologien, nemlig openehr referansemodell for behandling av «lymphoma chemotherapy» 11. Reglene kan utføre kalkulasjoner (f.eks. beregning av CHA 2 DS 2 VASc score eller medisindoser) eller sørge for å overholde logiske avhengigheter mellom ulike deler av retningslinjen (f.eks. medisindose er avhengig av vekt). Kategori 3 - Prosedyreorientert medisinsk kunnskap («task network model») er ofte det som kalles for «full blown» DKR, med arbeidsflyt. Denne tilnærmingen representerer rekkefølge og tidsrelaterte aspekter ved retningslinjer, dvs. gjennomføring av en anbefaling som involverer flere steg og beslutningspunkter. Regler og maler fra kategori 2 og steg for steg oppgaveflyt («workflow») settes sammen til en prosess. Å utvikle digitale retningslinjer som modellerer oppgaveflyten i en prosess skal i utgangspunktet kunne erstatte narrative retningslinjer i stor grad. Dette kalles ofte for kunnskapsbase sentriske («knowledge base-centric») [24] hvor retningslinjen i sin helhet blir representert ved bruk av ontologier for kontrollflyt («Task Network Model» - TNM), regler og medisinske begreper. En av utfordringene som det er forsket mye på er hvordan skal retningslinjer formaliseres slik at de eksekveres i en datamaskin (DKR). Mye av forskningen har i praksis dreid seg om hvordan omsettes en retningslinje til et dataprogram. En rekke forskningsprosjekter har foreslått modeller og språk for representasjon prosedyreorienterte DKR som - GLIF, PROforma, Asbru, EON [21], osv. Disse baserer seg på ulike varianter av Task-Network-Modeling I den senere tid har dette arbeidet resultert i forslag til et nytt openehr basert regelspråk: Guide Definition Language (GDL) 12 Task-Network Model (TNM): en (hierarkisk) modell av retningslinjens kontrollflyt som et nettverk av arbeidsoppgaver (eks. flytdiagram). TNMs er typisk basert på et standard sett av generisk oppgaver som beslutninger (decisions) og aksjoner (actions). 22

25 og inkluderer i tillegg regelspråk (eks. GEL 13, Arden Syntax, HL7 GELLO). Selv om det har foregått forskning på dette ca. 15 år er status at det ikke finnes standarder innenfor denne kategorien [21] INTEGRASJON AV DIGITALE KLINISKE RETNINGSLINJER MED EPJ For alle kategoriene er det relevant med større eller mindre grad av integrasjon med EPJ. I et relativt nytt litteraturstudium foretatt av Kashfi [27] i 2011 var målet å undersøke hvor mange studier som omtalte integrasjon mellom CDS- og EPJ-systemer. På tross av erkjennelsen av hvor viktig det er med integrasjon med EPJ, så er det mest teori og lite praksis. Selv med en erkjennelse av at standardisering er viktig, så er det enda færre studier som omtaler bruk av EPJ- eller terminologistandarder som virkemiddel. Gooch og Roudsari [22] beskriver to kategorier av integrasjon på basis av 26 studier (kun 3 studier inkluderte implementasjon av system i et klinisk miljø): Studier som argumenterer for samme underliggende datamodell for både klinisk retningslinje/forløpsmal (CDS-system) og EPJ-system for eksempel HL7 Referanse Information Model (RIM) eller openehr Studier som forsøker å mappe modeller av retningslinjer til kliniske begreper i EPJ via regler (for eksempel GELLO), bruk av «virtuell» EPJ (virtual medical record VMR), standardiserte terminologier som UMLS og SNOMED CT, mellomvare for ontologimapping [28] [29], manuell systemspesifikk mapping eller via en mappingtabell. Et eksempel på første punkt med samme underliggende datamodell er beskrevet i forrige kapittel hvor maler og arketyper openehr + regler kan modellere enkle digitale retningslinjer [26]. Et eksempel på sistnevnte tilnærming er beskrevet artikkelen [10] av bl.a. Kawamoto. Her beskrives en løs koblet tjenesteorientert arkitektur (SOA 14 ) for integrasjon kalt SEBASTIAN hvor selve beslutningsstøttefunksjonene (påminnelser, alarmer og anbefalinger) er innkapslet i en sentralisert separat webtjeneste som andre systemer bl.a. EPJ-systemer kan benytte når klinikeren jobber med EPJ og har behov for kunnskapsbasert klinisk beslutningsstøtte. Dette er eksempel på kategori 2 «Maleller regelbasert medisinsk kunnskap» (jf. kapittel 3.3.2). Fordelene er at beslutningsstøttefunksjonene tilbys via systemagnostisk standardisert grensesnitt som åpner for integrasjon mot hvilket som helst annet system som har behov for tilgang til beslutningstjenester. Arbeidet med SEBASTIAN har dannet basis for standarden HL7 Decision Support Service. Det pågår også standardisering av HL7 Virtual Medical Record (vmr) [30] [31] som er beskrevet nærmere i kapittel 4.5. SEBASTIAN beskriver også behovet for en «terminology Service» som tilbyr oppslag til terminologier som SNOMED CT, ICD9, ICD10, osv. og mappinger mellom disse. Kawamoto sier videre i [32] at dagens situasjon hvor mange terminologier (mange lokale og leverandørspesifikke) er i bruk representerer en stor utfordring, i og med at forskjellene i granulariteten mellom begrepene i terminologiene ofte hindrer en en-til-en mapping av et tilsvarende begrep i en annen terminologi. SEBASTIAN beskriver en arkitektur for løs kobling mellom EPJ system og en CDS-systemer basert på at det etablerers et virtuelt EPJ grensesnitt (eks. HL7 vmr), og beskriver ikke hvordan integrasjon mellom spesifikke heterogene EPJ systemer bør gjøres. Sånn sett forutsetter det at leverandør av EPJ systemet selv håndterer semantisk interoperabilitet ved å «mappe» til egen datamodell. Unntaket er terminologitjenesten som støtter 13 Guideline Expression Language 14 Service Oriented Architecture (SOA) 23

26 mapping mellom termer fra ulike terminologier som gjør at EPJ systemet kan benytte andre kodeverk/terminologisystemer enn CDS-tjenesten. Nedenfor beskrives flere alternative tilnærminger (KDOM, IDAN, TRANSFER, MEIDA og TM-vMR) som tar for seg «mappinger» til proprietære og heterogene EPJ-systemer som hovedtema. 3.4 RELATERT ARBEID - EVICARE Forskningsprosjektet Evicare ( , Sykehuset Innlandet, NTNU IDI, DIPS ASA, Kunnskapssenteret for Helsetjenesten, Oslo Universitetssykehus) har formulert følgende hovedmål: «to develop methods and technology for providing Evidence-Based Medicine (EBM) at the point of care, integrated with an electronic health record (EHR) or other health information systems directly involved in the clinical process, resulting in higher quality of care and a more detailed, transparent documentation of care processes. Prosjektet består av flere arbeidspakker. Ikke alle er relevante her, men de som angår integrasjon av kliniske retningslinjer i EPJ systemet er relevante. Utgangspunktet er at kliniske retningslinjer finnes i narrativ tekst på helsebiblioteket.no, BestPractice, UpToDate, osv. Det man ønsker å se på er om og hvordan innholdet i journalen kan benyttes for å assistere intelligente søk etter kliniske retningslinjer som er relevante for denne pasienten med dette problemet («at the point of care»). Som en forlengelse av hovedmålet i Evicare er det også aktuelt å se på hvordan kliniker bruker informasjon i pasientens journal når han/hun leser retningslinjene. Anbefalinger inneholder typisk referanser til kliniske målinger, labanalyseresultater, problem, diagnoser som en lege må hente fra EPJ systemet før en beslutning kan tas, og forslag til tiltak knyttet til bl.a. medisineringsforslag. Context sensitive search for guideines EPR Guideline CM- CDSS Context sensitive search in EPR Figur 4 Evicare prinsippskisse Med kontekstbaserte søk menes søk både i retningslinjer og i EPJ etter relevant informasjon. Poenget er at det skal være en «semantisk match» mellom innholdet i pasientens journal og retningslinjen. Dette angripes på to måter, hvor av den første tar utgangspunkt i at retningslinjene fortsatt skal være narrativ som i dag, mens den andre tilnærmingen går ut på at retningslinjene struktureres (annoteres) manuelt av de organisasjonene/gruppene som lager retningslinjene. 24

27 I den første tilnærmingen benyttes ulike algoritmer innen naturlig språkprosessering (NLP) for informasjonsekstraksjon (IE) beriket med OWL Description Logic ontologier for semantisk informasjonssøk (IR) i retningslinjer basert på innhold i pasientens journal. I den siste tilnærmingen forutsettes det at retningslinjer følger GRADE metodikken og at det utvikles et verktøy (MAGIC research program) for å annotere anbefalingene med ulike tagger og kodeverk for å assistere søk. Håpet er at prosjektet skal utvikle metoder, teknologi, verktøy og modeller som senker terskelen for integrasjon med EPJ og bidrar til økt bruk av kliniske retningslinjer i daglig praksis enn hva som er oppnådd i tidligere prosjekter basert på avanserte flytskjemaer (GLIF, Asbru, EON, SAGE, etc.) Søketeknikker kan benyttes for å rangere anbefalinger, men er ingen «eksakt vitenskap», så det er derfor fremdeles legen som skal ta beslutningene. Anbefalingene inneholder kliniske kriterier for når en anbefalinger er aktuell. Disse kriteriene kan være harde fakta som pasientens tidligere diagnoser, alder, kjønn, blodtrykksverdi, kolesterolnivå, osv., eller pasientens personlige preferanser. Selv om «harde fakta» i utgangspunktet kan brukes til å filtrere bort irrelevante anbefalinger, kan det være andre forhold som likevel gjør at anbefalinger er relevant for pasienten (ta med eksempelet om blodpropp vs. hjerneblødning med hensyn på bruk av blodfortynnende (VTE). Det er derfor viktig å overlate vurderingen til klinikeren dvs. være beslutningsstøtte, ikke beslutningstaker. Klinikerens vurderinger av anbefalinger er avhengig av effektive oppslag i pasientens journal for å finne relevant pasientinformasjon. I Sitting s «Grand challenges in clinical decision support» [33] kalles dette for «summarize patient-level information», og er blant de høyest rangerte egenskapene til en god integrasjon med EPJ. Derfor utvikler Evicare metoder for å hente kliniske variabler (analysesvar, diagnoser, osv.) fra EPJ som er relevante for rask og riktig vurdering av retningslinjen som vises på skjermen. Denne masteroppgaven foreslår en programvarearkitektur for kontekstsensitiv søk i EPJ basert på retningslinjeinnhold basert på Lenkede data og semantisk webteknologi. Denne teknologien beskrives i kapittel 6. 25

28 4 HELSESTANDARDISERING 4.1 INNLEDNING Dette kapittelet beskriver standardiseringsarbeid og status for standardisering innenfor Helse-IKT. Som beskrevet i kapittel 2.5 består landskapet av EPJ og kliniske beslutningsstøttesystemer (CDS-systemer) i stor grad av heterogenitet systemer med ulike arkitektur, teknisk plattform, datamodeller og hvor kliniske data i databasene er knyttet til ulike nasjonale og internasjonale terminologier. Det mest utfordrende av semantisk interoperabilitet. Kapittel 3 beskrev forskning på semantisk interoperabilitet ved dataintegrasjon og mapping. I dette kapittelet beskrives standardisering som en alternativ strategi til dataintegrasjon og mapping. Full standardisering av semantikk på verdensbasis er ikke realistisk i overskuelig framtid, kanskje aldri. Språk, kultur, markedskrefter, sosiale ulikheter er faktorer som spiller inn, jf. mislykket forsøk på å innføre Esperanto som universalspråk. 4.2 GENERELT OM STANDARDISERING INNEN HELSE-IKT Å standardisere er et alternativ for å oppnå interoperabilitet mellom systemer. Målsettingen med standardene er å redusere heterogenitet mellom systemer som skal utveksle informasjon. Standardisering handler om at flere parter (en kritisk masse) bestemmer seg for å koordinere seg på en slik måte at både partene (og samfunnet for øvrig) oppnår større gjensidig gevinst enn om at partene ikke gjør det. Partene kan være kommersielle, forskningsinstitusjoner eller andre «communities» av frivillige. Det er ingen «standard» måte å standardisere på. Noen standarder blir til ved at industrien selv etablerer standarder (markedsdrevne eller defacto standarder). Det typiske er at det foregår en kamp mellom flere ulike potensielle kandidater for standarder før det til syvende står én igjen som vinner. Det finnes mange eksempler på såkalte «standardiseringskamper». Noen kjente eksempler er VHS vs. Betamax, BlueRay vs. HD DVD, OpenDocument vs OpenXML. Innenfor IKT finnes open source miljøer som gjennom å legge ut kildekode til fri bruk har potensialet til å bli standarder. I kontrast til standarder som gror «bottom-up» fra eksisterende systemer/løsninger i industrien eller open source miljøer, så kan standardisering skje forut før implementering («top down»). Slik standardisering følger en definert og åpen standardiseringsprosess som gjennomføres av et anerkjent standardiseringsorgan (dejure standarder). Ifølge The International Organization of Standardization (ISO) er definisjon på en de jure standard «et dokument utarbeidet gjennom en konsensusprosess og godkjent av et anerkjent organ som beskriver de felles regler, retningslinjer og/eller egenskaper ved produkter eller arbeidsprosesser som må følges for å oppnå optimalt resultat i en gitt kontekst.» 15. Skal en standard bli en suksess må den tas i bruk. Ulempen med de jure standarder er at det ofte ikke er noen garanti for at de blir tatt i bruk. Det finnes mange eksempler på de jure standarder som ikke (foreløpig) er blitt en suksess fordi bruken ofte er veldig begrenset (eks. OpenDocument, W3C SVG,..)

29 Standardisering er vanskelig og tar lang tid. Flere aktører, større aktører, kompliserte områder, stor eksisterende base av løsninger/systemer, hvor stor er merkantil gevinst, patentrettigheter og teknologisk endringshastighet påvirker om en standard blir en suksess og hvor lang tid det tar. Full global enighet er også svært vanskelig å få til. Et eksempel er venstrekjøring versus høyrekjøring hvor man har innsett at kostnaden med å standardisere langt overgår fordelene. Innenfor IKT kan man si at tekniske plattformer basert på Linux, Apple, Microsoft er (proprietære) standarder som lever side om side og hvor TCP/IP, HTTP, HTML5, PDF, Java RE er eksempler på standarder som sørger at plattformene snakker sammen. Standardisering er viktig innenfor IKT for at systemer skal kunne kommunisere på en korrekt og sikker måte. Det gjelder både teknologiske standarder for datakommunikasjon som spesifisert i av de 7 lagene i OSI referansemodellen 16 som skal sørge for at de fysiske tilkoblingene (IEEE , DSL, etc.), datalink (PPP), nettverkslag (IP), transportlag (TCP), sesjonslag (TLS/SSL), presentasjonslag (MIME) og applikasjonslag (HTTP, SMTP). I tillegg finnes en rekke tekniske standarder for presentasjon og kommunikasjon på internett som bl.a. HTML, CSS, XML, SOAP, XSLT, Semantisk Web, ebxml, SAML, XACML, WS-*, WSDL og OpenDocument. I tillegg til ISO så er World Wide Web Consortium (W3C) og Organization for the Advancement of Structured Information Standards (OASIS) eksempler på store globale standardiseringsorganisasjoner for tekniske standarder. Disse standardene danner fundamentet som gjør det mulig bl.a. å kommunisere mellom datamaskiner uavhengig av hardware, operativsystemer og applikasjoner som benyttes. Historisk sett fantes det konkurrerende nettverksprotokoller som IBM SNA, Novell SPX/IPX, AppelTalk, DECNet hvor kommunikasjon på tvers av disse måtte skje ved hjelp av ulike typer mellomvare («bridges», «gateways»). Disse er nå forsvunnet til fordel for TCP/IP. Standardene som er nevnt ovenfor er tekniske standarder som gjør at informasjon kan transporteres på standard strukturert format uten tap mellom ulike noder i et nettverk. De fleste standarder er helt agnostisk i forhold til innholdet («payload») i det som sendes, men standarder som ligger høyt oppe i applikasjonslaget (nivå 7) standardiserer også innholdet i det som sendes. Ifølge EU rapporten SemHEALTH roadmap rapport [34] så defineres interoperabilitet (IOp) som helse IKTsystemenes evne til å: - utveksle og handle ut fra informasjon om pasient (innbygger) og annen helserelatert informasjon og kunnskap; - utveksle informasjon mellom helsepersonell, pasienter og andre aktører og organisasjoner med ulike morsmål og kulturer; - utveksle informasjon innenfor og mellom juridiske enheter. Semantisk interoperabilitet (SIOp) adresserer i denne sammenheng hvordan koding, overføring og handling basert på meningen (semantikken) i dataene kan gjøres sømløs på tvers av helsetjenester, tilbydere, pasienter, innbyggere, myndigheter, forskning og utdanning. ehelse-enheten i EU kommisjonen har spesiell fokus på SIOp. I en roadmap rapport fra 2009 [34] sier leder av ehelse-enheten, Ilias Iakovidis, at interoperable journalsystemer er det viktigste virkemiddelet for å oppnå pasientsentrert behandling, sammenhengende pasientforløp og understøtte pasienters mobilitet. 16 Open Systems Interconnection (OSI) model (ISO/IEC ) 27

30 Standardisering krever enighet rundt meningen og termene som benyttes både for formelle ontologier og uformelle ordbøker (leksikon) som vi med en fellesbetegnelse kaller for terminlogier. Det primære målet for terminologier er å muliggjøre utveksling av meningen (semantikken) mellom maskiner og mellom maskiner og mennesker [34]. Målsettingen for EU er å standardisere informasjonsmodeller og terminologier i de neste 20 årene. De erkjenner imidlertid at dette vil gå gradvis og ta meget lang tid og mellomvareløsninger for «mapping» av begreper er derfor nødvendig som en del av strategien for å oppnå målsettingen. Standarder som standardiserer innhold (mening) er rettet mot å oppnå semantisk interoperabilitet (jf. 3.2). Det gjelder både informasjonsmodeller og terminologisystemer (ontologier). Innenfor helseinformatikk er ISO TC og Health Level 7 (HL7) 18 de største aktørene. I Norge har Helsedirektoratet avdeling Standardisering (tidligere KITH) ansvaret for standardisering. I tillegg finnes det miljøer og organisasjoner som jobber for semantisk interoperabilitet, bl.a. Integrating the HealthCare Enterprise (IHE) 19 og openehr Foundation 20. Disse er ikke standardiseringsorganisasjoner, men jobber med spesifikasjoner for interoperabilitet innenfor helseinformatikk. I tillegg finnes mange delvis overlappende terminologisystem på verdensbasis som SNOMED CT, LOINC, RxNorm, ICD9, UMLS som ikke er tatt i bruk i Norge. I Norge har vi tatt i bruk ICD10 og etablert nasjonale kodeverk som Norsk Laboratoriekodeverk (tidl. NEKLAB) og volven.no som ikke er kompatibel med de internasjonale terminologisystemene. Erfaring har vist at standardisering av mening (semantikk) av et såpass komplekst område som helse er veldig vanskelig og tidkrevende. Å bli enig om begrepsmodeller, informasjons-/datamodeller, terminologier er svært vanskelig både av lingvistiske og begrepsmessige forskjeller. I overskuelig framtid vil industrien derfor måtte forholde seg til mapping og proprietære integrasjoner. SemHEALTH anbefaler satsing på semantisk interoperabilitet for å oppnå gevinstene med kunnskapsbaserte kliniske beslutningsstøttesystemer (påminnelser, kliniske varsler og retningslinjer) og prosesstøttet EPJ for å øke effektivitet og redusere og redusere feil i pasientbehandlingen [34]. Barry Smith et. al [16] kritiserer standardiseringsprosessene ved å si at standardisering basert på ulike modelleringsparadigmer (begrepsbasert standardisering) vil skape såkalte «ontologisiloer», og forhindre semantisk interoperabilitet. Han forfekter at standardisering må baseres på «vitenskapelige prinsipper» og ikke konsensusprosesser. Å oppnå større grad av standardisering av informasjonsmodeller (referansemodeller) og terminologisystemer er derfor viktig for semantisk interoperabilitet mellom systemer (EPJ <-> EPJ, EPJ <-> CDS-systemer). Innenfor helseinformatikk, så har EU beskrevet behovet i sin roadmap «Semantic Interoperability for better health and safer healthcare» [34]. Viktigste tiltakene er å standardisere informasjonmodeller for EPJ systemer og terminologisystemer. Det finnes etter hvert en del standarder for EPJ, terminologier og terminologitjenester og representasjon av kunnskap i beslutningsstøttesystemer som skal redusere denne heterogeniteten, men mye gjenstår. Kawamoto beskriver i [32] mangelen på standarder som et hinder for effektiv spredning av eksisterende standarder og utrulling av åpne løsninger for klinisk beslutningsstøtte i EPJ systemer. Det er ikke bare mangel på standarder eller 17 e.htm?commid=

31 mangel på å ta i bruk standarder som er problemet, det er også et problem at det finnes mange konkurrerende standarder i bruk. Kawamoto har i [32] kartlagt «standardiseringslandskapet». Oversikten nedenfor er delvis basert på denne kartleggingen supplert med ytterligere standarder som er relevant i Europa og i Norge: Standarder for representasjon av pasientjournal (EPJ) a. Referanseinformasjonsmodeller: HL7v3 CDA RM, openehr RM, ISO/CEN 13606, Norsk EPJ standard RM b. Domeneinformasjonsmodeller: HL7/ASTM CCD 21, HL7 Templates, Arketyper, Norsk EPJ standard Tvangsvedtak psykiatri, osv. c. Terminologier: UMLS, SNOMED CT, LOINC, RxNorm, ICD9, ICD10, volven.no, NEKLAB, ICPC2, NCSP osv. Standarder for kliniske digitale retningslinjer a. Regelspråk: HL7 Arden Syntax, HL7 GELLO b. Informasjonsmodell: ASTM Guideline Elements Model (GEM) c. Prosedyreorientert modeller (TNM): Ingen (mange forskningsprosjekter har resultert i GLIF, Asbru, EON, PROForma uten at de er blitt standardiserte) Standarder for integrasjonsgrensesnitt a. CDS-systemer tjenester: HL7 Decision Support Service (draft), OMG Decision Support Service Standard, HL7 Context-Aware Knowledge Retrieval («Infobutton ) standard b. Terminologitjenester: HL7 Common Terminology Services standard c. Journaltjenester: IHE XDS.b, HL7 Retrieve, Locate and Update Service Nedenfor beskrives standardisering mer i detalj innenfor EPJ, terminologi og integrasjon mellom EPJ og CDSsystemer. Poenget er å vise hvor mange forskjellige standarder som finnes, og at det ikke nødvendigvis finnes en «en-til-en» transformering mellom disse. I tillegg eksisterer det mange proprietære informasjonsmodeller og kodeverk. Full standardisering er et langsiktig mål, hvis det noen gang vil oppnås. Innen standardisering er på plass vil det være behov for «bridge»-teknologi som mapper mellom ulike standard og proprietære informasjonsmodeller og terminologier. Denne masteroppgaven presenterer SEHIA som i grunnen er en «bridge»-teknologi. 4.3 STANDARDISERING AV EPJ Selv om EPJ systemer har som hovedformål å dokumentere pasientbehandling, så er det store forskjeller mellom systemene på verdensbasis. Det er forskjeller i arkitektur og teknisk plattform, funksjonalitet og representasjon av journalinformasjon (semantikk). Forskjellene skyldes ofte naturlige variasjoner i en global markedsdrevet økonomi hvor ulike initiativ oppstår uavhengig av hverandre. Siden nasjoner har sine egne lover og forskrifter, kan dette medføre spesielle krav til systemene f.eks. krav til sikkerhet, arkivering, sporbarhet, rapportering til offentlige myndigheter. Forskjellene blir først et problem den dagen man ser behov for at EPJ systemer samhandler med andre systemer både i samme institusjon, nasjon og på tvers av nasjoner. Økt spesialisering som følge av Helsereformen i Norge, og 21 Continuity of Care Document (CCD) 29

32 krav til utveksling og samarbeid om helsetjenester mellom nasjoner i EU setter store krav til å bli enig om felles utvekslingsformater. Dette handler om å bli enige om bruk av standarder som finnes, eller lage nye standarder. De tekniske standardene er ofte «lett» å bli enige om i dag i og med at disse ofte er basert på standarder som er gitt av som følge av standardiseringen av Internett (HTTP, WS, REST, XML, osv.). Litt vanskeligere er det å bli enige om hvilke tjenester som trengs og hvilken funksjonalitet de eksponerer til omverdenen (eks. «service contract» i en tjenesteorientert arkitektur). Det som er virkelig vanskelig er å standardisere innholdet (mening) hvor journalinformasjon er representert ulikt i ulike EPJ-systemer. Selv om en del av pasientjournalen består av strukturert informasjon, bl.a. kurve, medikasjon, diagnosekoder, prosedyrekoder, etc., så er mesteparten av journalen fremdeles narrativ tekst. I tillegg finnes mye i form av multimedia som skannede dokumenter, bilder, video og lyd. Meningsinnholdet i multimedia og narrativ tekst er i utgangspunktet bare tilgjengelig for menneskelig tolkning. For multimedia kan tagging og kategorisering av innhold avhjelpe dette, men tagging må gjøre av mennesker på forhånd. I narrativ tekst uttrykkes mening ved bruk termer, nyanser, usikkerhet, negasjon, viktighet osv. Noen ganger er det flere termer som betyr det samme (begrep), og andre ganger betyr samme term forskjellige ting som er gitt ut fra konteksten termen står i. Ulike språk skaper enda større utfordringer. Naturlig språkprosessering (NLP) er et stort forskningsfelt med hovedhensikt å trekke ut semantikk fra naturlig tekst som knyttes til en bakenforliggende ontologi. Den andre ytterligheten er «skjemabaserte» journaldokumenter som gir svært rigide regler for hvor informasjon registreres, og hvilke kodeverk som skal brukes. Dette kan passe bra hvor selve datagrunnlaget er strukturert, f.eks. diagnosekoder, prosedyrekoder, medikasjon, kurve og offentlig rapportering, men når behovet for å uttrykke nyanser ikke passer inn i et skjema, f.eks. når det gjelder usikkerhet, gjør at «skjemabaserte» løsninger ikke egner seg bra. En annen ting er at «skjemabaserte» journalløsninger vil kreve store endringer i arbeidsrutiner hos leger, og vil derfor skape stor motstand. Det er lett å få til «skjemabaserte» løsninger, og vanskelig å få til NLP. I mellom disse ytterpunktene finnes det ulike «hybridløsninger», som f.eks. HL7 CDA, som tillater en blanding av fritekst og strukturerte elementer. «Skjemabaserte» løsninger, «hybridløsninger» og NLP er ulike metoder for strukturert datafangst som har som formål å knytte mening (semantikk) til innholdet, m.a.o. knytte data til bakenforliggende ontologier. Journalinformasjon som er knyttet til ontologier gir helt andre muligheter for beslutnings- og prosesstøtte i systemene («computability»). Ved å standardisere ontologier for journalinnhold mellom systemer kan informasjon (data med mening) utveksles mellom systemene. Et alternativ til å standardisere er «mapping» mellom ontologier («semantic bridge») se kapittel 3.2. Å standardisere ontologier er i praksis å standardisere datamodeller og terminologier for utveksling av EPJ innhold dvs. standardiserte meldinger. Norsk EPJ-standard [35], ISO CEN/EN-13606, HL7 CDA og DICOM Structured Reporting (SR) [36] er standardene for utveksling av journalinnhold. Alle baserer seg på en felles referanseinformasjonsmodell («upper ontology») som basis for utvikling av konkrete standarder for hvert applikasjonsdomene. Norsk EPJ-standard er basert på ISO CEN/EN-13606, men med noen særnorske regler spesielt informasjonssikkerhet og redigering, retting og sletting. ISO CEN/EN er opprinnelig en europeisk standard basert på deler av openehr Foundation 22 sine spesifikasjoner. openehr er en spesifikasjon av et helt EPJ system,

33 mens ISO CEN/EN er et subsett av denne som omfatter kun utveksling av EPJ. HL7 CDA er tilsvarende standard fra HL7.org som er en standardiseringsorganisasjon som ble stiftet i USA i ISO CEN/EN (openehr) og HL7 CDA baserer seg på «two-level» eller «dual mode» modell hvor nivå 2 dvs. applikasjonsdomenet skal modelleres som hhv /openEHR arketyper og HL7 templates og installeres i systemene uten at systemenes datamodell må endres (og leverandør involveres). Det har vært gjort mye arbeid med å harmonisere standardene, men full semantisk interoperabilitet uten tap av mening kan ikke garanteres ved konvertering. Standarden ISO Detailed Clinical Models (DCM [37]) er et forsøk på harmonsering. Full standardisering av EPJ ligger likevel langt fram i tid, om det noen gang vil skje. I mellomtiden jobbes det med harmonisering av standardene som muliggjør «mapping» mellom standardene. Ingen «bridge» eller «mapping»- teknologi vil kunne håndtere semantisk inkompatible standarder. 4.4 STANDARDISERING AV TERMINOLOGIER Standardisering av EPJ referansemodeller med arketyper/templates er ikke nok for å oppnå semantisk interoperabilitet. Ulike terminologisystemer og kodeverk er i bruk for å spesifisere innhold ytterligere, f.eks. ICD10, NEKLAB, SNOMED CT, LOINC, etc. På samme måte som for EPJ referansemodeller, må bruk av terminologier standardiseres hvis «mapping» skal unngås. En terminologi er språket vi benytter som betegner de bakenforliggende begrepene. En term i Norge (eks. «bil») er forskjellig fra engelsk (eks. «car») selv om begrepet er det samme. Definisjon av de bakenforliggende begrepene kan gjøres uformelt (ordliste, leksikon eller ordbok) eller strengt formelt som i Description Language (OWL, Ontology, GRAIL, osv.) som vist i Figur 5. Figur 5: Illustrasjon ulike grader av formell definisjon av begreper. Dersom begrepene i et domene er definerte etter «sunne» ontologiske prinsipper bl. at de er egnet for resonnering (inferens) i en datamaskin - så kalles det gjerne en ontologi for domenet. 31

34 Med terminologier i denne oppgaven menes her samling eller system av termer (ord) inkludert koblinger til definisjon av de bakenforliggende begrepene hvor både termene og begrepsdefinisjonene er kontrollert (beskyttet) av en anerkjent uavhengig redaktør (for eksempel Helsedirektoratet, WHO, IHTSDO, NLM, osv.). Et begrep (med tilhørende term) er i denne oppgaven en klassifikasjon av instanser som finnes som informasjonsobjekter i et datasystem. Informasjonsobjektene kan igjen representere objekter som finnes fysisk i den «virkelige verden» (empirisk), men kan like gjerne kun finnes som digitaliserte eksemplarer av dokumenter, rekvisisjoner, henvisninger, epikriser. For eksempel vil termen «paracetamol», et virkestoff legemiddel, finnes i alle Paracet eller Pinex tablettene («individuals») som en pasient svelger. På den annen side betegner termen «elektronisk henvisning» instanser av en digitalisert form av en papirhenvisning. Poenget er at objektene i et informasjonssystem eksisterer i den «digitale» verdenen. Kodeverk menes her den unike identifikatoren - dvs. koden - som benyttes for å identifisere begrepene (eller grupper av begreper). Disse kan være identisk med termen, eller være en systemgenerert identifikator (kun ment for datamaskiner). I Norge er det Helsedirektoratet (tidligere KITH) som har ansvaret for standardiseringen av kodeverk og terminologier til bruk i Helsesektoren. Helsedirektoratet er utgiver av en rekke kodeverk som finnes på og Helsedirektoratet har også ansvaret for oversetting av termer fra internasjonale terminologier som bl.a. ICD10. I tillegg har Legemiddelverket utarbeidet en terminlogi for legemidler (FEST) basert på internasjonale ATC. Internasjonalt er det (store) organisasjoner som International Health Terminology Standards Development Organisation (IHTSDO) som har ansvaret for SNOMED CT, Regenstrief Institute som har ansvaret for LOINC, WHO har i tillegg ansvaret for ATC. Relevante organisasjoner, terminologier og oversettelser til norsk: Redaktør Terminologi Oversatt til norsk? KITH 23 Helsedirektoratet Norsk Laboratoriekodeverk (NEKLAB) NORAKO (Den norske radiologforening) 24 DRG (Diagnose Relaterte Grupper) NCMP (Norsk klassifikasjon av medisinske prosedyrer) Alle kodeverkene på volven.no N/A N/A N/A N/A WHO International Health Terminology Standards Development Organisation (IHTSDO) Regenstrief Institute ICD10 (International Classification of Diseases) ATC (The Anatomical, Therapeutic and Chemical Classification System) ICPC-2 (International Classification of Primary Care, Second edition) SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms) LOINC (Logical Observation Identifiers, Names and Nei Codes) National Library of RxNorm (normalized names for clinical drugs) Nei Ja, av KITH Ja, Folkehelseinstituttet Ja, NSAM 25 og KITH Nei 23 En del av Helsedirektoratet fra Erstattes med NCRP fra Norsk Selskap for Allmennmedisin 32

35 Medicine (NLM) UMLS (Unified Medical Language System) MeSH (Medical Subject Headings) Nei Ja, delvis av Kunnskapssenteret 26 Legemiddelverket FEST (Forskrivings- og ekspedisjonsstøtte) N/A Nordisk NCSP (Nomesko Classification of Surgical Ja, av KITH Medicinalstatistisk Komité (NOMESKO) Procedures) National Council on Radiation Protection and Measurements (NCRP) NCRP 27 Ja, av KITH Hovedproblemet med terminologiene er at de dels er overlappene, og da må koder «mappes» til tilsvarende koder i en annen terminologi. For mange nasjonale og proprietære kodeverk og terminologier finnes det ingen mappinger. F.eks. kan en diagnose i ICD10 ikke alltid mappes til en SNOMED CT kode fordi ikke finnes en tilsvarende term som beskriver det samme. Og slik er det mellom mange terminologier i bruk. Mellom internasjonale terminologier finnes det delvis mappinger, samt de mappinger som finnes er ikke eksakte. Det er også stor aktivitet i USA innen terminologimapping eks. National Center for Biomedical Ontology 28, National Cancer Institute 29 og U.S. National Library of Medicine 30. Kjernen i UMLS er en meta-tesaurus som mapper begreper fra andre kjente terminologier som for eksempel SNOMED CT, MESH, RxNorm, ICD10 og LOINC til egne UMLS-begreper. Kun begreper som finnes i andre terminologier blir egne UMLS-begreper. Mappingene gjøres med relasjoner som «identisk med», «bredere begrep», «smalere begrep», osv. The National Center for Biomedical Ontology har i tillegg database Bioportal 31 med 293 terminologier, med total over 5,6 millioner termer med mapping mellom begreper basert på W3C SKOS (se kapittel 7.4). For eksempel har ICD over mappinger. I Norge er bruk av internasjonale terminologier og kodeverk er relativt begrenset, jf. tabellen ovenfor. Skal det være mulig for Norske EPJ systemer å utveksle informasjon mellom andre EPJ og CDS systemer i utlandet, må det harmonisering og mapping også gjøres her. Vedlikehold av terminologier (kodeverk) gjøres av organisasjonene som eier terminologien (kodeverket). Distribusjon kan enten være nedlastbare XML, RDF, CSV filer osv., eller tilbys via en tjeneste. HL7 Common Terminology Services standard (CTS) er en standard som også støtter «mappinger» mellom termer (koder) i ulike terminologier (kodeverk). I tillegg støttes begrenset grad av resonnering («inference»). Full standardisering av terminologier (kodeverk) på verdensbasis er utopisk. At terminologiene (kodeverkene) harmoniseres tilstrekkelig at de kan «mappes» er viktig for å oppnå semantisk interoperabilitet. 4.5 STANDARDISERING AV INTEGRASJON MELLOM EPJ- OG CDS-SYSTEMER Som nevnt i kapittel 4.2 finnes det flere integrasjonsstandarder for ulike typer integrasjoner mellom CDS- og EPJsystemer: HL7 Decision Support Service (draft), OMG Decision Support Service Standard, HL7 Context-Aware Knowledge Retrieval («Infobutton ) standard, I kapittel ble HL7 Context-Aware Knowledge Retrieval ( infobutton ) hvor poenget var å etablere linker som kan aktiveres fra ulike steder i helseinformasjonsystemet (f.eks. EPJ, LAB, Røntgen) som er koblet til Erstatter NORAKO-koder fra UMLS Metathesaurus per januar

36 kunnskapsressurser på nett. Dette ligner på ideen til Evicare i Norge hvor kontekstsensitive søk blant retningslinjene er helt sentral, men hvor konteksten også består av de vanlige journaldokumentene i fritekst form. HL7 Virtual Medical Record (vmr) er trimmet utgave av HL7 RIM. En virtuell EPJ modell basert på HL7 RIM Act dvs. en entydig representasjon av EPJ forordninger, observasjoner, problemer, prosedyrer som er relevante for CDS-systemer. HL7 vmr skal gjøre terskelen lavest mulig for integrasjon mellom EPJ og kliniske beslutningsstøttesystemer. I denne oppgaven benyttes HL7 vmr som et «virtuelt view» mot journalen (jf. modell for dataintegrasjon i kapittel 3.2). Å mappe HL7 vmr til elementer i EPJ ved hjelp av semantisk webteknologi er hovedtema i denne oppgaven. Ifølge HL7 vmr Domain Analysis Model (DAM) [30] så jobber HL7 arbeidsgruppe for kliniske beslutningsstøtte med å utvikle en standard Virtual Medical Record (vmr) en virtuell informasjonsmodell for EPJ som kan benyttes om «payload» ved kommunikasjon med CDS-tjenester. Den er kommet i stand på basis av en større undersøkelse av 20 eksisterende CDS-systemers behov for journalelementer [31]. Informasjonsmodellen innholder opplysninger (eks. kjønn, alder, medisinkort, problemliste, labanalyser, kritisk informasjon, osv.) som kan benyttes som input til CDS. Output kan inneholde varslinger eller anbefalinger (forordninger av medisin, lab, prosedyrer osv. dvs. «order set»). HL7vMR kan både brukes til spesifisere kliniske opplysninger om pasienten selv, men også pårørende og slektninger. Figur 6 viser typisk interaksjon mellom CDS og EPJ vha. HL7-OMG DSS og HL7 vmr. HL7vMR CDS Medikasjon Labanalyser Problem osv. + tidsintervall EPJ EvaluationResponse evaluate(input) HL7vMR Varslinger og forordninger ("order sets") Figur 6: Sekvensdiagram som viser en typisk interaksjon mellom CDS og EPJ Det er tre typer innhold som kan spesifiseres i HL7 vmr: cdsinputspecification: en spesifikasjon av krav til input gitt et brukstilfelle for eksempel mammografitesting krever alder, kjønn, historikk brystkreft, historikk fjerning av bryst og historikk mammografiundersøkelser cdsinput: Reelle inputverdier til CDS-systemet for et gitt pasientkasus på basis av cdsinputspecification. cdsoutput: Respons fra CDS-systemet. For eksempel anbefalt forskriving som bør gjøres. UML diagrammer av HL7 vmr cdsinputspecification, cdsinput og cdsoutput finnes i appendiks Det er mulig å spesifisere kliniske uttrykk (ClinicalStatement) i to akser: 34

37 Akse 1 tid: Historikk hva har blitt gjort? Hvilke observasjoner er blitt gjort? Hvilke observasjoner har ikke blitt gjort? 32 Plan hva planlegges av tiltak? For eksempel iverksatte forskrivinger, labtester, osv. Anbefalinger - forslag til hva som bør gjøres? Forskrivinger, ny labtester, osv. Akse 2 type: Ugunstig helsehendelse («AdverseEvent»): For eksempel død, utslett, pustevansker, osv. Problem (diagnose): For eksempel ICD10, ICD9 eller SNOMED CT Observasjon: For eksempel serum kalium nivå, hemoglobin A1C nivå, røyking (ja/nei) Prosedyre: For eksempel appendektomi, koronar bypassoperasjon Legemiddelforskrivninger Episoder (kontakter) Målsetting: stabilisere blodtrykk, oppnå normal hemoglobin A1c-nivå Utstyr: For eksempel rullestol Noen kombinasjoner gir ikke mening, for eksempel plan (akse 1) + problem (akse 2). Ulike brukstilfelle (use case) krever ulik datainput tidligere diagnoser, labtester, legemiddelhistorikk, hvilke prosedyrer er utført tidligere osv. Det kan også være behov for journalinformasjon knyttet til en slektning for å kunne komme med en anbefaling. I noen EPJ-systemer vil de fleste data kunne hentes fra EPJ-systemets database, men i andre tilfeller vil de finnes i ulike systemer. På sikt er det også mulig at informasjon må ekstraheres fra fritekst ved hjelp av NLP 33 -teknikker. HL7 vmr refererer eksterne terminologier (datatypen CD), og løser derfor ikke problemet med ulike terminologier (kodeverk). Ulike terminologier i EPJ vs CDS-systemet må være harmoniseres og mappes til hverandre. Terminologitjenesten HL7 Common Terminology Service (CTS) med støtte for mapping og resonnering er nødvendig. HL7 vmr er bare et grensesnitt som skal skjule underliggende heterogenitet i EPJ-systemet. Hvordan mappinger mellom HL7 vmr, og det enkelt EPJ-system er derfor ikke beskrevet i standarden. 32 For eksempel «Ingen kjente allergier», «ingen kjente problemer», osv. 33 Natural Language Processing 35

38 5 METODE Den grunnleggende forskningsmetoden som vil benyttes i denne oppgaven er «constructive research» innen «software engineering» [38] hvor man tar utgangspunkt i et praktisk problem og konstruerer en eller flere demonstratorer (alternativt «Proof-of-concept», POC) som presenterer løsning på problemet. Siden forskning handler om «kunnskapsproduksjon», må det praktiske problemet i tillegg relateres til relevante teoretiske problemstillinger innenfor et eller flere forskningsområder, og på en vitenskapelig måte overbevise at demonstratoren kan bidra til bedre forståelse av de teoretiske problemstillingene innenfor forskningsfeltet ( = ny kunnskap). En vitenskapelig måte betyr at prosessen (forskningsmetoden) har nok evidensgrunnlag og er etterprøvbar (kan kontrolleres). Innenfor «constructive software engineering research» er det selve konstruksjonsprosessen, og ikke selve løsningen som vektlegges. Det vil si studiet av de metoder, verktøy, teknologier, teknikker, modeller eller algoritmer som benyttes for å løse problemet. En forutsetning for dette er at problemområdet er godt forstått på forhånd. I denne oppgaven er problemområdet semantisk interoperabilitet innen programvareintegrasjon mellom CDS- og EPJ-systemer. Som beskrevet i forskningen i kapittel 2.5, så er det et velkjent faktum at mangel semantisk interoperabilitet er et av problemene som hindrer integrasjon mellom CDS-systemer og EPJ og dermed også det overordnede målet om kunnskapsbasert medisin (evidensbasert medisin). Som beskrevet ovenfor har det vært gjort mange forskningsprosjekter som viser at det er mulig å få til, men at det har vist seg vanskelig å generalisere og standardisere disse løsningene slik at det blir attraktivt å benytte disse på bred basis for alle typer integrasjoner mellom CDS-systemer og EPJ-systemer. Semantisk interoperabilitet er bare ett av problemene, blant mange andre, knyttet til målet om prosesstøttet EPJ med klinisk beslutningsstøtte (se kapittel 3.3.1). Noen av disse er tema i det pågående forskningsprosjektet Evicare (se kapittel 3.4). Resultatene fra denne masteroppgaven hviler naturlig nok delvis på hypoteser som ennå ikke er bekreftet fra Evicare. Konsekvenser av dette drøftes i kapittel Fra etableringen av ideen om Lenkede Data og Semantisk Web på begynnelsen av 2000-tallet til i dag har det pågått en god del forskning og utvikling av teknologi som har til hensikt å få systemer kan «snakke» sammen på internett, derav navnet «semantisk web». Håndtering av semantisk heterogenitet er høyst relevant for å oppnå dette, og problemet er derfor grunnleggende det samme som når man skal integrere to spesifikke systemer med hverandre. Fra et programutviklingsperspektiv, ønsker oppgaven å finne ut om lenkede data og semantisk web-teknologi egner seg til dataintegrasjon mellom EPJ-system og WGL-CMS (en type CDS-systemer). Hvor passer det best og hvor passer det ikke? Bruk av lenkede data og semantisk web har ikke vært gjort før innenfor integrasjon av EPJ-systemer og CDSsystemer (så langt forfatter kjenner til). Det er derfor interessant å evaluere anvendelse av teknologien lenkede data og semantisk web til integrasjon av heterogene helsesystemer. I denne oppgaven er det praktiske problemet formulert som en enkel kravspesifikasjon i kapittel 6 på basis av i en ide og hypotese fra EVICARE-prosjektet. Ansvaret for validering av kravspesifikasjonen opp mot hovedmålet om kunnskapsbasert medisin i praksis ligger derfor til EVICARE å finne ut av (f.eks. gjennom brukertesting, mockups, proof-of-concepts). I denne oppgaven tas dette som en forutsetning, og fokuset er på metode, teknologi, verktøy for å oppnå målet. 36

39 I kapittel 8 beskrives det en arkitektur (modell) for hvordan kravene kan implementeres i et system som oppfyller kravene som utnytter lenkede data og semantisk web teknologiene til det fulle. Arkitekturen kalles for Semantic Health Integration Architecture (SEHIA). For å finne ut om SEHIA egner seg til integrasjonsformålet, gjennomføres det et eksperiment. Eksperimentet er en proof-of-concept (SEHIA POC), som implementerer deler av arkitekturen. Utvikling av SEHIA POC er beskrevet i kapittel 9. Lenkede data og semantisk web (LD og SemWeb) er en del av Weben, og Weben er basert på Internettet. I kapittel 7 beskrives internett og webteknologi som er bakgrunn for nødvendig teknologiforståelse for å forstå SEHIA, og anvendelsen av denne teknologien innen helse IKT per i dag. Analyse gjøres i kapittel 10 «Var det mulig å gjennomføre SEHIA POC eksperimentet med LD og SemWeb? Hva var mulig og ikke mulig? Hvorfor?». At det er mulig betyr at WGL-CMS kan integreres med EPJ-systemet bare ved bruk LD og Semantisk Web teknologi uten at hele eller deler av integrasjonen må kodes i tradisjonelle imperative språk (som f.eks. C# og Java). Poenget er at dette skal gjøres deklarativt slik at nye integrasjoner mellom EPJ og WGL-CMS kan etableres bare ved av ny konfigurasjon. M.a.o. skal det ikke være behov for nye programoppdateringer når nye integrasjonsbehov oppstår. Konklusjonen vil være hvilke deler av POCen var mulig (suksess) og hvilke var ikke mulig (fiasko). Endelig konklusjon vil ikke bare baseres på analysen i kapittel 10. I kapittel 11 drøftes svarene opp mot årsaker til at noe ikke var mulig, hvordan har lignende prosjekter løst dette, hvor praktisk anvendbar var teknologien for systemutvikling og vurdering av implementerbarhet i sykehus. Spørsmål i drøftingen er: Kan POCen forbedres slik at det er mulig å gjennomføre integrasjonen som beskrevet ovenfor, dvs. at det var en designfeil i POCen som ikke skyldes begrensninger i LD og SemWeb-teknologien? Hvordan løser POCen problemet sammenlignet mot lignende arbeid beskrevet i litteraturen? Hvordan har andre løst det? Har POCen løst dette på en lettere eller tyngre måte? Hvor praktisk anvendbar er LD og Hvordan er opplevelsen av LD og SemWeb sett ut fra et programutviklingsperspektiv gitt den verktøystøtte som det var tilgang på? For komplisert? Evt. hva var komplekst? Hvor implementerbar er løsningen gitt de krav som stilles til informasjonssikkerhet, pasientsikkerhet, integrerbarhet, åpenhet, standard, terminologistøtte og ytelse ved norske sykehus? Konklusjon gjøres i kapittel 12 på bakgrunn av analyseresultatene i kapittel 10 og drøfting i kapittel 11. I kapittel 13 reflekteres det over hvor generaliserbar og valid resultatene er basert faktorer som kompetanse og kompleksitet. 37

40 6 KRAVSPESIFIKASJON 6.1 OVERORDNET BRUKSTILFELLE Ved utvikling av ny programvareløsninger er det alltid viktig å starte med å beskrive løsningen sett fra et overordnet perspektiv slik at alle forstår hva formålet med det som skal utvikles er. Dette er spesielt viktig når den løsningen som skal utvikles kun er en del av den totale løsningen, slik som tilfellet er i denne masteroppgaven. Brukstilfellet er hentet fra forskningsprosjektet EVICARE hvor formålet er å tilby beslutningsstøttefunksjoner i EPJ integrert i pasientbehandlingen (jf. kapittel 3.4). Gyldigheten av brukstilfellet er avhengig av at hypotesen i EVICARE prosjektet verifiseres. Hensikten med beslutningsstøtte integrert i EPJ er å oppnå et kunnskapsbasert helsevesen hvor klinisk personell kan få tilgang til den beste mulige kunnskapen slik at behandlingen kan tilpasses den enkelte pasient. I brukstilfellet tilbys sanntidsstøtte for søk og visning av relevante anbefalinger i retningslinjer mens klinikeren skriver journalnotater. Integrert i samme arbeidsflate skal det være mulig å søke etter relevante retningslinjer og anbefalinger på internett. Resultatet er en retningslinje eller anbefaling som vises i en integrert nettleser. Samtidig som retningslinjen/anbefalingen presenteres, skal relevante kliniske variabler fra pasientens journal vises slik at klinikeren slipper å slå opp i journalen som klinikeren ellers ville ha gjort for å ta stilling til om anbefalingen skal følges. Det skal også være støtte for enkelt å forordne ulike typer supplerende undersøkelser (f.eks. labanalyser) som foreslås i anbefalingene. Integrasjonen vil redusere antall taste- og museklikk og gjør mer attraktivt å ta i bruk elektroniske kunnskapskilder. Forutsetning: Legen sitter med journalsystemet og skriver sitt journalnotat for en pasient. Det er ikke klart hva som feiler pasient, og legen gjør seg noen tanker mens han/hun skriver ned sine observasjoner. Systemet er et moderne EPJ-system integrert med nasjonale og internasjonale retningslinjedatabaser tilgjengelig på internett. Stegene i brukstilfellet: 1. Mens legen sitter og skriver journalnotat, vil systemet trekke ut bestemt kliniske nøkkelord som systemet vil foreslå som søkekriterier. I tillegg til nøkkelordene, vil tidligere diagnoser, henvisningsårsak, osv. være kandidater som søkekriterier. 2. Samtidig som legen skriver, foretas det søk i bakgrunnen i ulike forhåndsdefinerte retningslinjedatabaser (WGL-CMS). Det vises en rangert liste over anbefalinger som synes å være relevant for søket. Denne listen endrer seg etter hvert som legen skriver videre på notatet sitt. 3. Legen tar en titt på listen de høyest rangerte anbefalingene som kommer fram og synes dette ser interessant ut. Han/hun klikker på hyperlinken til anbefalingen for å lese detaljer. 4. Når detaljene kommer fram vil det også foretas et søk etter relevante kliniske variabler som er relevante for å vurdere anbefalingen. Det kan være blodtrykk, spesifikke labanalyser, prosedyrer, tidligere diagnoser, osv. Dette gjør at legen slipper manuelle oppslag på disse opplysningene og han/hun sparer tid. 5. Dersom det mangler kliniske variabler, f.eks. spesifikke labanalyser, skal det være mulig å rekvirere disse på en enkel måte bare ved et enkelt museklikk og rekvisisjonen opprettes. Dersom anbefalingen foreslår en behandling, f.eks. medikament, så skal det være mulig ved et enkelt klikk å opprette en forskriving. 38

41 Dr starts writing a note in EHR. Searchable keywords from note, problem list, etc. are being retrieved from EHR 1 4 Dr selects a particular recommendation to investigate details. System retrieves clinical variables (patient context), lab test, blood pressure, problems, etc. EHR desktop Guideline CMS returns a list of recommendations System conducts search for relevant recommendations in G-CMS based on search keywords. EHR System Dr chooses to prescribe suggested medication in guideline Medication order is sent to EHR system Web based Guideline Content Management System (WGL-CMS) Guideline Authoring Tools Figur 7 Overordnet flyt av data mellom arbeidsflaten til klinikeren, EPJ (EHR) og retningslinjedatabasen (WGL-CMS). Denne masteren foreslår en arkitektur Semantic Health Integration Architecture (SEHIA) for å løse steg 4 hente relevant pasientinfo gitt et valgt retningslinje. Kravene til SEHIA er beskrevet nedenfor. 6.2 FUNKSJONELLE KRAV INTRO Kravene er formulert som brukerhistorier (user stories) et begrep hentet fra smidige utviklingsmetodikk (agile) 34. Det er kun brukerhistorie F1 som utvikles i POCen, men SEHIA er designet for å løse de andre brukerhistoriene F2 F BRUKERHISTORIE F1: VISE KLINISK PASIENTKONTEKST Som lege ønsker jeg at relevante kliniske variabler (labtester, tidligere diagnoser, tilstander, etc.) automatisk skal vises når jeg vurderer en anbefaling i en klinisk retningslinje som tilbys via web slik at jeg slipper å bytte mellom ulike skjermbilder i EPJ systemet og retningslinje websystem (WGL-CMS)

42 6.2.3 DE ANDRE BRUKERHISTORIENE SOM IKKE IMPLEMENTERES I POC BRUKERHISTORIE F2: NAVIGERE TIL DETALJER I EPJ-SYSTEM Som lege ønsker jeg at alle kliniske variabler har en assosiert hyperlink som jeg kan benytte for å navigere direkte til EPJ-systemet hvor kildeinformasjonen befinner seg slik at jeg slipper å bruke unødvendig tid å finne disse selv i en travel hverdag BRUKERHISTORIE F3: BESTILLE NYE UNDERSØKELSER Som lege ønsker jeg at det skal på en enkel måte være mulig å opprette forslag til ulike supplerende undersøkelser, røntgen, EKG, osv. som nevnes i retningslinjen, men som mangler eller hvor eksisterende er gammel og er viktig for å kunne ta stilling til anbefalingen slik at jeg sparer tid og unngå feil. Steg 5 i Evicare brukstilfelle ovenfor BRUKERHISTORIE F4: BESTILLE FORESLÅTTE UNDERSØKELSER Som lege ønsker jeg at det skal på en enkel måte være mulig å opprette forslag til forordninger som foreslås av anbefalingen direkte i EPJ slik at jeg kan spare tid, samt unngå feil. Steg 5 i Evicare brukstilfelle ovenfor. 6.3 IKKE-FUNKSJONELLE KRAV Ikke-funksjonelle krav er rammevilkår («constraints») og kvalitetskrav som ikke kan formuleres som en brukerhistorie (funksjon), men som gjelder på tvers av alle funksjonelle krav. Tabellen nedenfor inneholder et lite utvalg av de ikke-funksjonelle kravene som en tenkt helsevirksomhet vil være opptatt av. Mange viktige krav er imidlertid utelatt. Bl.a. krav som omhandler brukbarhet (usability), installasjon- og driftbarhet, dokumentasjon, robusthet, backup- og recovery. Av hensyn oppgavens omfang, var det likevel nødvendig å redusere kravlisten til krav som det var mulig å gjøre en viss evaluering av uten involvering av helsevirksomheter i større evalueringsprosesser. Krav ID IF1 IF2 IF3 IF4 IF5 IF6 IF7 Beskrivelse Løsningen må ha tilfredsstillende informasjonssikkerhet iht. norske lover og forskrifter. Løsningen må ivareta pasientsikkerhet, dvs. ikke være til skade for pasienten. Løsning skal være åpen, dvs. integrasjonsgrensesnitt og mønster skal være basert på standarder som er leverandøruavhengige Løsningen må kunne integreres med nye eksisterende WGL-CMS uten at det krever endringer i teknisk infrastruktur for WGL-CMS. Løsningen skal takle at ulike terminologier (SNOMED CT, NEKLAB, LOINC, osv.) er i bruk av CDS-systemer og EPJ ved integrasjon. Årsaken er at ulike terminologier er brukt i ulike land, i beslutningsstøttesystem og EPJ-systemer, og man kan ikke forutsette harmonisering i overskuelig framtid. Løsningen må kunne kjøre på typisk nettverksinfrastruktur og sikkerhetsløsninger ved en helsevirksomhet Responstiden på brukerhistorie nr. 1 må være under 5 sekunder. For resten av brukerhistoriene skal responstiden være maks 1 sekund. 40

43 7 INTERNETT OG WORLD WIDE WEB 7.1 INNLEDNING Poenget med dette kapittelet er å beskrive Lenkede Data og Semantisk Web (LD og SemWeb) og hvor det brukes innenfor helse IKT i dag. Siden disse teknologiene er basert på World Wide Web som igjen er basert på Internett, så er det greit med en kort introduksjon av fundamentet først. 7.2 GENERELT Internett har sine røtter tilbake Advanced Research Projects Agency (Arpanet) prosjektet som startet i 1968 finansiert av det Amerikanske forsvaret. På den tiden var datamaskiner svært dyre. Ideen om ressursdeling blant forskere var derfor hoveddrivkraften for utviklingen av det tidlige internett. I starten var det kun universiteter og forskningsinstitusjoner i USA som ble knyttet sammen, men i juni 1973 ble Norge som det første land utenfor USA knyttet opp med en satelittforbindelse. I 1977 ble Arpanet en del av et eksperimentelt internett fram til TCP/IP protokollen ble ferdig utviklet og tatt i bruk i som regnes som starten på internett slik vi kjenner det i dag. Da Tim Berner-Lee oppfant World Wide Web (Web 1.0) i 1989 med Hypertext Markup Language (HTML), Uniform Resource Identifier (URI) og Hypertext Transfer Protocol (HTTP) ble det virkelig eksplosjon i både vekst og erkjennelse av at Internett var framtiden. I 1995 var internett fullstendig kommersialisert etter at de siste begrensningene av transportering kommersiell trafikk ble fjernet. I 1994 ble The World Wide Web Consortium (W3C) 35 etablert som en uavhengig standardiseringsorganisasjon som har som formål å utvikle webstandarder. Per januar 2012 har de 333 medlemsorganisasjoner over hele verdenen som bidragsytere. W3C står bak standardisering av f.eks. HTML, CSS, URI, HTTP, XML, XML Skjema, SOAP og WSDL. Web 1.0 handlet om å få til en global infrastruktur for å dele statiske dokumenter (resources) mellom mennesker. Dokumenter som HTML (PDF, JPG, TIFF, osv.) innholder ingen mening (semantikk) for datamaskiner. Tolkning av innholdet er overlatt til mennesker. Med nødvendig infrastruktur på plass ble det på slutten av 1990-tallet mer fokus på utvikling av protokoller og standarder for interaktive applikasjoner som nettbutikker, spill og sosiale nettsteder (som Facebook, Twitter, osv.). Teknologier som Flash, JavaScript, Ajax, Java, Silverlight og HTML5 utnytter maskinressurser på klientene (nettleserne) tilbyr applikasjoner med interaktivitet som man før bare hadde i desktop-applikasjoner. Etter Apple lanserte iphone i 2007 har markedet for smarttelefoner skutt fart og gjort internett tilgjengelig fra mobile enheter. Utvikling av applikasjoner på internett kalles ofte for Web 2.0 hvor «Social Web» - dvs. applikasjoner som knytter mennesker sammen er sentral. Ved oppfinnelsen av weben ble det også behov for å søke etter dokumenter. De første søkemotorene så dagens lys allerede i 1993, og siden har globale søketjenester som Google, Yahoo, Bing, osv. blitt etablert hvor Google i dag er den dominerende aktøren. Gode søkemotorer klarer å finne den informasjonen brukeren er ute etter basert på relevans. Google introduserte begrepet «PageRank» hvor websider med flest inngående lenker («links») fikk høyere rangering enn andre, noe

44 som økte relevansen og gjorde søkene bedre. Også tagging av websider, bilder, videoer, osv. har blitt brukt for å gjøres søkene bedre. Søkealgoritmer har tradisjonelt vært basert på statistiske metoder hvor relevans er beregnet uten at søkemotorene må «forstå» meningsinnholdet i dokumentene. I de siste årene har søkemotorene inkorporert elementer av semantiske søk, f.eks. geografisk lokalisering, synonymer, begrepssøk, etc. Google introduserte i 2012 sin «Knowledge Graph» som bakenforliggende kunnskapsbase basert på innhold i CIA World Factbook, Freebase og Wikipedia for å forbedre søkene ytterligere. Målet er å forstå de underliggende begrepene bak søketermene, samt relasjonene mellom begrepene, for å gjøre søkene mer «intelligente». Web 2.0 og avanserte søkemotorer er fremdeles basert på den infrastrukturen som ble introdusert med Web 1.0 hvor deling av ressurser (dokumenter og multimedia) mellom mennesker er bærebjelken. Selv om moderne web 2.0 applikasjoner presenterer dynamiske websider basert på data fra strukturerte databaser (typisk relasjonsdatabaser), så er den bakenforliggende databasen dedikert og tilgjengelig kun for applikasjonen som benytter den. Web 1.0/2.0 er derfor ikke tilrettelagt for deling av data på internett for bl.a. utveksling og integrasjon mellom datamaskiner på den måten dokumenter er tilgjengeliggjort for mennesker. Det er i prinsippet ingen forskjell fra tradisjonelle klient/tjenersystemene som dominerte 1990-tallet når det gjelder data. Behovet for en åpen infrastruktur for å dele strukturerte data på internett mellom datamaskiner var det Tim Berner-Lee i 2001 kalte for visjonen om «Semantic Web» som er en «web of interconnected data». Semantic Web er ofte kalt for Web 3.0. Det er flere aspekter med å oppnå visjonen om Semantisk Web: 1. Arkitektur for å koble sammen data i weben («Lenkede Data») 2. Knytte data til bakenforliggende vokabularer (ontologier) for å definere mening med data (= informasjon). 3. Støtte for resonnering dvs. å utlede ny informasjon basert på eksisterende data og ontologier («Inference»). 4. Strukturerte spørringer Den semantiske web en bygger på Web 1.0 teknologier som Identifiers (URI) og XML med teknologier og standarder som Resource Description Framework (RDF), RDF Schema (RDFS), Web Ontology Language (OWL), SPARQL og Rule Interchange Format (RIF). Å realisere den semantiske web en er ikke gjort over natten. I 2013, etter 12 års forskning og innovasjon, er det enda lang vei igjen. Det finnes eksempler på flere initiativ (utenfor Norge) som har tatt i bruk Semantisk Webteknologier. Som blant annet som er en åpen plattform for tilgang til alle offentlige statistikker i USA, som er lignende initiativ i Storbritannia, som er basert på strukturerte data fra og Facebooks Open Graph Protocol (OGP). Innenfor biomedisin og biologi er Open Biological and Biomedical Ontologies (OBO) den mest kjente. I resten av kapittel 6 beskrives de sentrale aspektene med den semantiske web en og anvendelse innenfor helse ikt som er relevant bakgrunn for resten av oppgaven. 42

45 7.3 LENKEDE DATA Lenkede Data (LD) er en graf 36 med noder og egenskaper. RDF er et format for å representere lenkede data (LD) på Web en iht. W3C spesifikasjoner. Å tilby data på web en i form av Web Services (WSDL/SOAP/XML) eller Web APIer (REST/JSON) er ikke noe nytt. LD har samme funksjon, men krever at alle dataobjekter må knyttes til eksplisitte globale identifikatorer (URIer) og bruker internett standardene for å konvertere URIer til adresser (URLer) på samme måte som HTML har hyperlinker (<a href>) for å kobles dokumentene sammen. Et RDF-uttrykk er en trippel (RDF Triple): <subjekt > <predikat> <objekt> <subject> er en node (ressurs) i nettverket. <predikat> er en påstand/aksiom om <objekt>. <object> kan enten være en annen node (ressurs) eller en streng ("literal"). De fleste noder har en global unik identifikator (URI) på samme måte som for adressering av websider på Internett. En sett med RDF Triples kalles for en RDF graf. De viktigste formatene for å representere RDF er XML, Turtle, N- Triples eller RDFa. RDF har en veldig enkel generell datamodell (RDF Triple Graph) som kan representere data fra alle typer datakilder (f.eks. relasjonsdatabaser og XML) på en homogen måte uavhengig av hvordan data er strukturert i sine datakilder. Den foreslåtte W3C Standarden «A Direct Mapping of Relational Data to RDF (RDB2RDF) 37 beskriver hvordan relasjonsdata kan mappes direkte over til RDF. RDFa gjør det mulig å legge inn RDF i HTML5 sider. Poenget er å beskrive innholdet i HTML-dokumentet i maskinlesbar form. Lignende tilnærminger er HTML5 Microdata og Microformats som er mindre kompleks enn RDFa. Et alternativ til RDFa er at nettstedet støtter HTTP Header Accept: application/rdf+xml forespørsler slik at en RDFutgave av et webdokument kan lastes ned i stedet for HTML som er standard for alle nettlesere. RDF muliggjør en verdensomspennende web med sammenkoblede data. For at data skal bli meningsfull, må data knyttes til bakenforliggende metadata som vokabularer, skjemaer eller ontologier. RDF kan brukes til å beskrive metadata, men inneholder ingen standard for hvordan vokabular, skjema eller ontologi skal beskrives. JSON-LD 38 er ingen W3C standard, men er et forslag om lettvekts LD format som gjør det mulig å representere RDFgrafer uten RDF-parsere for JavaScript klienter. Dette vil senke terskelen for å ta i bruk LD og Semantisk Web. 7.4 REPRESENTASJONSSPRÅK FOR VOKABULARER Vokabularer er en beskrivelse av termer, begreper og relasjoner mellom begrepene. Vokabularer gir mening til data, og for å klassifisere og karakterisere ulike begreper. Eksempler på vokabularer er terminologisystemer (SNOMED CT, LOINC, ICD10, etc.) som brukes innenfor helsevesenet for å beskrive og kategorisere klinisk

46 dokumentasjon (se kapittel 4.4), bokmåls-/nynorskordboka 39 er eksempel på vokabular for norske termer, ISO CONTSYS er UML begrepsmodell for helsevesenet, ISO/CEN som beskriver strukturering av EPJinformasjon, en datamodell for DIPS EPJ/PAS systemet. Vokabularer kan representeres på mange måter, f.eks. ordlister/ordbøker, tesaurus, taksonomier, databaseskjema (datamodeller), XML Skjema, UML, Description Logic (DL) og First-Order-Logic. Det er ikke et klart skille mellom vokabular og ontologi. Ontologi brukes gjerne for mer formelle og komplekse vokabularer (se for øvrig beskrivelse av ontologier i kapittel 3.2). På den semantiske web en finnes det flere standarder for å beskrive vokabularer (ontologier): RDF Schema (RDFS), Simple Knowledge Organization System (SKOS), Web Ontology Language (OWL) og Rules Interchange Format (RIF). Hvilken standard som benyttes er avhengig av behovet. RDF Schema (RDFS) gir muligheter ontologier som ligner på typesystemet i objekt-orienterte språk som klasser (rdfs:class) og egenskaper (rdf:property). Objektorienterte språk støtter kun subklassing (rdfs:subclassof), mens RDFS støtter i tillegg «underegenskaper» (rdfs:subpropertiesof) som ikke finnes i OO-paradigmet. RDFS er representert i RDF. RDFS kan kombineres med rikere ontologispråk som OWL og RIF. Simple Knowledge Organization System (SKOS) er en modell og anvendelse av RDF til å beskrive grunnleggende strukturer og innhold i tesaurus (synonymordlister), klassifikasjonssystemer, taksonomier, «folksonomier» og andre typer kontrollerte vokabularer. SKOS et «lettvektsspråk» for mer uformelle beskrivelser av vokabularer. Hensikten med SKOS er å gjøre det enklere å løfte vanlige kodeverk (som bl.a. de som finnes på til den semantiske weben. SKOS vokabularer kan fungere sammen med mer formelle OWL 2 vokabularer. SKOS introduserer elementer: Kodeverk/klassifikasjonssystem (skos:conceptscheme), begrep (skos:concept) tilsvarer OWL 2 class, term (skos:preflabel, skos:altlabel, skos:hiddenlabel), mappinger (skos:exactmatch, skos:closematch, skos:broader, skos:narrower, skos:related) og tekstlig beskrivelse (skos:note) Web Ontology Language (OWL2) er et ontologispråk for å beskrive ontologier som krever rikere og mer formell beskrivelse enn tilfellet er for RDFS eller SKOS. OWL2 er versjon 2.0 som bygger videre på RDFS og OWL v1.0. OWL2 utvider vokabularet bl.a. til å omfatte klasser som defineres ved at medlemmene må ha egenskaper («properties») som oppfyller bestemte kriterier (owl:restriction, owl:allvaluesfrom, owl:somevaluesfrom, owl:hasvalue), settteori (owl:intersectionof, owl:unionof, owl:complementof, owl:disjointwith), kardinalitetskriterier (owl:restriction, owl:cardinality, owl:mincardinality, owl:maxcardinality) og en rekke andre konstruksjoner (owl:inverseof, owl:transitiveproperty, owl:propertychainaxiom). OWL2 har konstruksjoner som ikke er mulig i objektorienterte språk. Rules Interchange Language (RIF) er et standard språk for å beskrive regler for den semantiske web en, og indirekte også vokabularer. Selv om OWL2 er et kraftig språk for ontologier, så har det sine begrensninger som best kan beskrives som regler (jf. ontologispektrum i kapittel 3.2)som i regelbaserte systemer. Poenget er ikke å erstatte regelspråk i tradisjonelle regelbaserte systemer (som f.eks. Prolog, Drools, SILK, SWRL, Oracle Business Rules), men å definere et standard utvekslingsformat som integrerer regelspråk med RDF/OWL på en konsistent måte. 7.5 RESONNERING Resonnering er å utlede ny kunnskap (informasjon) basert på eksisterende kunnskap (informasjon) ved logisk deduktive slutninger. På den semantiske er kunnskapen definert ved hjelp av ontologispråk som RDFS, SKOS,

47 OWL2, eller RIF. Å resonnere på den semantiske web en handler det om å etablere nye relasjoner (tripler) mellom klasser («T-Box») eller data (individuals, «A-box»). Resonnering gjøres ved hjelp av «reasoners» som genererer tripler som logisk følger av kunnskapen («entailments»). Resonnering kan enten gjøres på spørretidspunkt (on-the-fly), eller kan genereres på forhånd, og legges inn kunnskapsdatabasen for å øke ytelsen på spørringer. Avhengig av ontologispråk, så vil det være en CPU-kostnad forbundet med resonnering. Siden uttrykkskraften i OWL2 er større enn RDFS, vil resonnering på OWL2 nivå generelt ta mer tid og kreve mer minne og evt. lagringsplass enn RDFS. Det er en avveining mellom uttrykkskraft og avgjørbarhet («decidability») 40, dvs. at én kan garantere at prosessering i det hele tatt vil resultere i et svar i endelig tid. Prosedyreorienterte/imperative programmeringsspråk (eks. Java, C#, jf. «Halting Problem») og regelspråk (RIF, Drools, SWRL, Prolog, etc.) har ingen garantier for avgjørbarhet («decidability»), og det er derfor opp til «brukeren» å sørge for avgjørbarhet. Det er heller ikke mulig å garantere avgjørbarhet for en ubegrenset bruk av OWL2, såkalt «OWL2 Full». For å lette byrden og gjøre det enklere for den som modellerer, så er det definert ulike profiler (bruksbegrensninger) for OWL2 som garanterer avgjørbarhet. En av profilene er OWL2 DL som er basert på «Description Logic». En hver modell definert iht. OWL DL er avgjør bar, dvs. at det er mulig å fastslå hvorvidt klasser er like andre klasser, eller subklasser, og hvilke klasser instanser (individuals) er medlemmer av. Selv om OWL2 DL er «decidable», så kan resonnering være kompleks og ta lang tid kompleksitetsgaranti på N2ExpTime, dvs. «intractable». Ytterligere subsett av OWL2 DL er utviklet for å være optimalisert for eksekvering for ulike teknologier (algoritmer) med bedre ytelse (kompleksitetsfaktor PTime, dvs. «tractable»). OWL2 QL for å være effektiv og tilpasset implementering mot SQL og relasjonsdatabaser. OWL2 EL som er tilpasset ontologier innen biovitenskap («life science») som OBO Foundry. OWL2 RL som er optimalisert for regelbaserte systemer (Prolog, Drools, SWRL, osv.). Det betyr at alle OWL2 RL ontologier kan oversettes til regler f.eks. RIF eller en annen regelmotor. Oracle Spatial and Graph RDF Semantic Graph som er brukt i prototype i denne oppgaven støtter OWL2 RL. 7.6 SPARQL ET SPØRRESPRÅK FOR RDF-GRAFER På samme måte som SQL er et spørrespråk for relasjonsdatabaser, og XQuery spørrespråk for XML, så er SPARQL et spørrespråk for RDF-grafer. SPARQL v1.1 er en W3C standard fra november 2012, og støtter både spørringer og oppdatering («create», «update» og «delete») på samme måte som SQL. Det kan etableres ulike SPARQL tjenester som kan aksesseres via HTTP GET og POST operasjoner. SPARQL støtter distribuerte («federated») spørringer som gjør det mulig å spørre på flere SPARQL tjenester i en og samme spørring. I likhet med SQL støtter SPARQL filtrering, operatorer (+, -,* og /) og funksjoner som STRLEN(), SUBSTR(), UCASE(), LANG(), osv. 7.7 SEMANTISK WEBTEKNOLOGI INNEN HELSE- OG BIOVITENSKAP Open Biomedical Ontologi (OBO) som er et ontologirammeverk for naturvitenskap som forvaltes av OBO Foundry 41 [39] en uavhengig organisasjon som har som formål å etablere prinsipper for utvikling av ortogonale interoperable ontologier innenfor biomedisinsk forskning. Det baserer seg på noen grunnleggende ontologier «upper level» - Basic Formal Ontology (BFO) og Relational Ontology (RO) som er domeneuavhengig og som alle andre ontologier må ta utgangspunkt i. For eksempel Infection Diseas Ontology (IDO), Common Anatomy Reference 40 Decidability Theory (Computer Science) 45

48 Ontology (CARO), Chemical entities of biological interest (CHEBI) osv. OBO-ontologier representeres både i et eget OBO-format, men også OWL DL. Mange av OBO 42 terminologiene lastes ned fra Innenfor klinisk pasientbehandling vil bruken av semantisk webteknologi og OWL være avhengig av i hvor stor grad de store terminologisystemene som SNOMED CT, LOINC, osv. er i bruk i EPJ-systemer. Et rask søk på Google Scholar med «survey OWL EMR EHR» resulterte ikke i noen artikler, mens det er gjort undersøkelser på bruken av SNOMED CT i 2010 [40] som viser at SNOMED CT er i begrenset bruk, men at leverandører avventer på krav og forretningsdrivere for å lage systemer som utnytter mulighetene i SNOMED CT. Mayoklinikken (Mayo Clinic Division of Biomedical Statistics and Informatics) har etablert en infrastruktur (LexGrid)[41] for å kunne laste inn terminologier som finnes på ulike filformater inn i en felles kunnskapsbase og tilby terminologier som tjenester. Det er mulig å hente ut alle terminologiene på OWL format (LexOWL) [42]. Det er ukjent om dette er i bruk i EPJ-systemer, eller kun for forskningsformål. I Norge er det ingen bruk av semantisk webteknologi i elektronisk pasientjournalsystemer. Dette henger nok sammen med at utfordringen primært er et spørsmål om å gå over til strukturert journal (arketyper), samt ta i bruk terminologsystemer som SNOMED CT i pasientjournalen Open Biological and Biomedical Ontologies: 46

49 8 SEMANTIC HEALTH INTEGRATION ARCHITECTURE 8.1 INTRODUKSJON Semantic Health Integration Architecture (SEHIA) er en programvarearkitektur for integrasjon mellom EPJ og WGL- CMS beslutningsstøttesystem ved hjelp av lenkede data og semantisk webteknologi (LD og SemWeb) som har som overordnet mål å høyne behandlingskvaliteten ved å integrere kunnskapsbasert medisin i pasientforløpet. Dette gjøres ved å senke terskelen for bruk av digitale kliniske retningslinjer «at the point of care» slik at kliniker både oppfatter det som nyttig og effektiv å slå opp i digitale kliniske retningslinjer på web, framfor bare å stole på egne erfaringer. Det finnes mange definisjoner av en programvarearkitektur («software architecture»), men her defineres det som en beskrivelse eller modell av hvordan et system er bygget opp eller bør bygges for å overholde et sett med funksjonelle og ikke-funksjonelle krav. Alternativ kan man si at en programvarearkitektur er et sett med vesentlige designbeslutninger som karakteriserer et programvareprodukt. En programvarearkitektur er således ikke selve programvareløsningen, men en modell av programvareløsningen. Som for de fleste modeller, så er disse ofte en abstraksjon der det er gjort bevisste valg av hvilke detaljer som er inkludert, og hvilke som er utelatt. Grunntanken med SEHIA (etter ide fra Evicare) er at samtidig som retningslinjen vises i nettleser, så vil relevante kliniske variabler fra aktivert pasient i EPJ-systemet vises. SEHIA er en arkitektur som muliggjør implementasjon av de funksjonelle krav og ikke-funksjonelle krav som angitt kapittel 6. SEHIA er som navnet tilsier, en arkitektur, og ikke et system. Dette betyr at SEHIA først og fremst er en modell hvor generelle prinsipper og mekanismer er viktige og som kan implementeres på mange måter og med ulike tekniske plattformer. I denne oppgaven er det utviklet en proof-ofconcept for integrasjon med DIPS Arena EPJ som ett eksempel på at arkitekturen er mulig å implementere. Som sagt tidligere er de fleste kliniske retningslinjer («clinical guidelines») tilgjengelig via webbaserte grensesnitt (WGL-CMS). Det betyr at de er representert som HTML (retningslinjer publisert som PDF må konverteres til HTML). SEHIA støtter flere typer WGL-CMS, både de tradisjonelle statiske nettstedene med dokumenter (Web 1.0), og de med mer dynamiske websider (Web 2.0). Det er ulike integrasjonsgrensesnitt som tilbys for ulike behov. I den aller enkleste konfigurasjon, annoteres retningslinjene med RDFa-tagger. De semantiske tagene sier noe om innholdet i retningslinjene, og hvilke journalopplysninger (f.eks. lab. analyseresultater og andre kliniske observasjoner) som er relevante å lese i journalen. Retningslinjene kommer også med anbefalte tiltak (f.eks. legemidler som bør forskrives). Programvaren henter både fram relevante pasientopplysninger fra pasientjournalen som legen uansett må slå opp, samt gir muligheter til å forordne ulike tiltak som anbefalingene kommer med. Dette gjør at klinikeren både sparer tid og unngår feil. For å få dette til må retningslinjene annoteres med semantiske tagger av retningslinjeprodusentene (forfatterverktøy) før publisering. Semantiske tagger påvirker ikke eksisterende bruk av retningslinjer som oppslagsverk, men muliggjør en god integrasjon med EPJ hvor SEHIA er implementert. Figuren nedenfor illustrerer hovedprinsippet med SEHIA. 47

50 Guideline in HTML with Semantic tags (RDFa) SEHIA Webintegration Show clinical patient context: LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) HTML 1 3 RDF/JSON-LD 2 SEHIA Dataintegration EHR DB Figur 8 viser prinsippskisse for SEHIA. Det finnes alltid to representasjoner av en retningslinje (1) HTML og (2) RDF/JSON-LD. Når en retningslinje vises i nettleseren (1), så vil innholdet (2) tolkes av datamaskin og relevant pasientkontekst sendes til klient som vises i arbeidsflaten (3). SEHIA består av to hoveddeler som illustrert i figuren ovenfor: SEHIA Webintegrasjon på arbeidsflaten SEHIA Dataintegrasjon på serversiden Disse er løst koblet og kan benyttes hver for seg eller i kombinasjon. F.eks. er det mulig å benytte SEHIA webintegrasjon, og etablere en egen dataintegrasjon mot EPJ databaser som ikke er basert på SEHIA siden grensesnittene er de samme. SEHIA webintegrasjonen sørger 1) for at retningslinjer som ligger lagret på usikret Helse- eller Internett gjøres tilgjengelig for arbeidsstasjoner på et lukket sykehusnett slik at helsearbeidere som bruker EPJ-systemer også kan slå opp i retningslinjer i eksternt WGL-CMS CDS-systemer uten å kompromittere sikkerheten; og 2) at retningslinjene blir integrert mot EPJ-systemet sin brukerflate mot aktuell pasient. SEHIA webintegrasjon består av arkitekturkomponenten SEHIA Guideline Controller (GL CTL) og SEHIA RDFa destiller. SEHIA Dataintegrasjon sørger 1) for å slå opp i pasientens journal basert på innholdet i en klinisk retningslinje representert ved RDF/JSON-LD; og 2) at ulike terminologier oversettes til hverandre («mappes») slik at det er mulig å bruke ulike terminologier i CDS-systemer og EPJ system og likevel finne relevant informasjon. SEHIA dataintegrasjon består av arkitekturkomponentene SEHIA EHR Server og SEHIA RDF Store. Både web- og dataintegrasjon utnytter lenkede data og semantisk web. 8.2 SEHIA WEBINTEGRASJON INTRODUKSJON SEHIA Webintegrasjon består av mange funksjonelle komponenter som integrerer EPJ systemets arbeidsflate med webbaserte retningslinjer. Disse komponentene kan implementeres og distribueres på ulike måter avhengig av behov og EPJ-systemets tekniske arkitektur. 48

51 SEHIA legger i seg selv ingen føringer på EPJ-systemets tekniske arkitektur applikasjonsklient («fet klient») eller webbasert (tynn klient). SEHIA bygger på forutsetning om at kliniske retningslinjer tilbys via webbaserte grensesnitt som ligger lagret i retningslinjedatabaser (WGL-CMS). Både Helsebiblioteket, NEL, UpToDate og BestPractice er eksempler på WGL- CMS som er tilgjengelig via internett (se kapittel 2.3). Sykehusets nettverk må være satt opp slik at terminaler med EPJ også kan nå WGL-CMS tilgjengelig via helse- eller internett slik at kliniker kan søke etter og lese retningslinjer samtidig mens de arbeider med EPJ SEMANTISK ANNOTERING AV DIGITALE RETNINGSLINJER Webbaserte kliniske retningslinjer som distribueres som HTML-sider på vanlig måte er i utgangspunktet uleselig for en datamaskin uten avanserte teknikker for naturlig språkprosessering (natural language processing NLP) som det forskes på innenfor området kunstig intelligens (artificial intelligence AI). En mindre ambisiøs tilnærming er å legge inn skjulte tagger i websider som kan leses av datamaskinen kun på de steder der det er nødvendig for å oppnå formålet med løsningen (ala ActiveGuidelines [43]). Semantisk annotering passer best for tradisjonelle WGL-CMS med statiske websider (Web 1.0). For mer moderne WGL-CMS med dynamisk innhold (Web 2.0), så er det ikke nødvendig å annotere hvis cdsinputspecification kan sendes over til SEHIA på annen måte (se kapittel 8.2.3) SEHIA tilbyr muligheter for 1) å hente fram opplysninger fra pasientens journal (pasientinfo) som er relevant ved vurdering av de kliniske anbefalingene, og 2) for å bestille direkte fra forslag til forordninger som angis i anbefalingen. Eksempel på anbefaling: «BT-senkende behandling bør også tilbys eldre pasienter > 80 år med BT > 140 / 90 mmhg.» For å ta stilling til denne anbefalingen, må kliniker vite alder på pasient og om blodtrykket er over 140/90 mmhg. Alder er registrert i PAS eller EPJ-systemet, og blodtrykket må tas hvis det ikke allerede nylig er tatt og registrert i EPJ. Ved semantisk annotering av både alder og blodtrykk, så kan disse opplysningene automatisk hentes fra EPJ og vises samtidig ved at anbefalingen presenteres i nettleser. Dersom blodtrykk ikke er registrert i EPJ, kan systemet foreslå forordning av blodtrykksmåling som tiltak som sykepleier kan følge opp. Anbefalingen foreslår en blodtrykkssenkende behandling. Dersom det annoteres for forslag til legemidler, med eller uten fastsatt styrke og doser, så kan systemet gjøre klar et forslag til forskriving som kliniker enkelt kan bestille direkte fra anbefalingen. Relevante opplysninger som hentes fra pasientens journal som grunnlag for vurdering av en retningslinje kalles i denne oppgaven for pasientinfo. En pasientinfo består av en eller flere kliniske fakta. Eksempel på kliniske fakta er: Pasienten har blodtrykk 113/70 mmhg målt Pasienten har LDL 3,5 mmol/l målt kl Pasienten fikk diagnosen Q21.1 Persisterende foramen ovale (PFO) Pasienten ble operert med prosedyre FFC22 Perkutan lukking av ASD Pasienten har puls 51 slag/min målt Pasienten fikk forskrevet Albyl-E 75 mg x 1 den Kliniske fakta består m.a.o. både dokumentasjon av hendelser som har skjedd med pasienten, men også pågående og planlagte tiltak. 49

52 Dersom anbefalingen inneholder forslag til bestillinger av legemidler, labanalyser, prosedyrer og kliniske målinger, så kan pasientkontekst utvides med bestillingsforslag. Hvis det mangler kliniske fakta, så kan disse gjøres om til bestillingsforslag. Bestillingsforslag må endelig effektueres i EPJ-systemet, og da blir de til kliniske fakta. Pasientinfo er et utsnitt av pasientjournalen med en enhetlig representasjon uavhengig av hvilke kildesystemer pasientopplysningene er hentet fra, og hvilken struktur og format de opprinnelig er lagret på. Hvilke kliniske fakta skal være en del av pasientkonteksten varierer som sagt fra anbefaling til anbefaling. Annotering i retningslinjene er derfor en spesifikasjon av hvilke kliniske fakta som skal inngå i pasientinfoen. Annotering av retningslinjer gjøres i SEHIA ved hjelp av RDFa. Først annoteres selve retningslinjen («guideline»), og så alle anbefalingene («recommendation») og tilslutt spesifikasjon av pasientkontekst. Figuren nedenfor viser retningslinje før og etter annotering. Retningslinje (Guideline) generell tekst. bla.bla.. bla.. bla Anbefaling 1 (Recommendation) Anbefaling 2 (Recommendation) Legge på RDFa semantiske tagg er Retningslinje (Guideline) generell tekst. bla.bla.. bla.. bla Anbefaling 1 (Recommendation) Anbefaling 2 (Recommendation) Anbefaling 2 (Recommendation) Behandlingsgrenser: Det finnes ingen klare behandlingsgrenser, men alle pasienter med hjerneinfarkt A 1a eller TIA med LDL >2,0 mmol/l bør tilbys statinbehandling hvis ikke kontraindisert. Anbefaling 3 (Recommendation) Anbefaling 3 (Recommendation) Anbefaling n (Recommendation) Anbefaling n (Recommendation) generell tekst. bla.bla.. bla.. bla generell tekst. bla.bla.. bla.. bla Figur 9 Semantisk annotering av retningslinjer. Det er mulig å gjøre annoteringen manuelt, men det er lett å gjøre feil. Så det mest hensiktsmessige er at det finnes et forfatterverktøy som støtter dette direkte. På samme måte som at det finnes verktøy for utvikling av HTMLwebsider som ikke krever kjennskap til HTML, så bør forfatterverktøyet tilby støtte for annotering uten at kjennskap til RDFa er nødvendig. Annoteringen gjøres ved å knytte HTML-tagger til bakenforliggende ontologier ved bruk av RDFa «typeof» attributter. Den overordnede ontologien SEHIA har blant annet klasser for «guideline» og «recommendation». Innenfor en «recommendation», så brukes deler av HL7 Virtual Medical Record (vmr) (se kapittel 4.5) for å spesifisere hvilke kliniske fakta som er relevante og skal være med i pasientkonteksten. Blant annet klassen «ClinicalStatementInputSpecification» som brukes for å spesifisere spesifikke generelle observasjoner, labanalyser, diagnoser, prosedyrer som er relevante ved hjelp av koder fra terminologisystemer som NEKLAB, SNOMED CT, ICD10, osv. HL7 vmr konvertert til OWL ble valgt rett og slett fordi det er den eneste (kommende) standarden som finnes for tilpasset representasjon av pasientjournal for et klinisk beslutningssystem (CDS-systemer). 50

53 UML diagrammet nedenfor viser underliggende ontologi(er) som ligger bak annoteringen: sehia:guideline hasrecommendation sehia:recommendation hasclinicalstatementinputspecification haspatientinputspecification hl7vmr:clinicalstatementinputspecification requiredclinicalstatementclass hl7vmr:patientinputspecification requiredevaluatedpersonattribute hascodedattributerequirement hastimeattributerequirement hl7vmr:codedattributerequirement hastargetcode hastargetcodeattribute hl7vmr:timeattributerequirement targettimeattribute searchbacktimeperiod searchforwardtimeperiod Figur 10 SEHIA og HL7 ontologier for spesifikasjon av spørringer etter pasientkontekst basert på kriterier (se HL7 vmr kapittel 4.5) RDFa er kun en måte å bake inn RDF i HTML sider, og RDF kan ekstrahere («destilleres») vha. egnede biblioteker. For å illustrere dette kan vi ta utgangspunkt i følgende eksempel på retningslinje med lipidsenkende behandling med 3 anbefalinger: # Retningslinje lipidsenkende behandling 1 Alle pasienter med hjerneinfarkt eller TIA bør få råd og veiledning om endring i levevaner som kan påvirke lipidprofilen i gunstig retning, slik som økt mosjon, kostendringer og vektreduksjon ved overvekt (*). 2 Behandlingsgrenser: Det finnes ingen klare behandlingsgrenser, men alle pasienter med hjerneinfarkt A 1a eller TIA med LDL >2,0 mmol/l bør tilbys statinbehandling hvis ikke kontraindisert. 3 Hos eldre pasienter > 80 år er dokumentasjonen vedrørende statinbehandling relativt svak, og individuell vurdering bør foretas. Den første anbefalingen har ingen annoteringer av kliniske fakta, mens 2 og 3 har én annotering hver som uthevet med grønn og rød tekst. RDF som er ekstrahert ut fra denne HTML anbefalingen kan se slik ut i Turtle hl7vmr: ns1: ns2: <urn:/hl7vmr/evaluatedpersoninputspecification#>. 51

54 @prefix rdfa: rdfs: < < a ns1:guideline; ns1:hasrecommendation < < < rdfa:usesvocabulary ns1:. < a ns1:recommendation. < a ns1:recommendation; ns1:hasclinicalstatementinputspecification [ a hl7vmr:clinicalstatementinputspecification; hl7vmr:hascodedattributerequirement [ a hl7vmr:codedattributerequirement; hl7vmr:hastargetcode <urn:/helsedir/neklab/npu01568>; hl7vmr:hastargetcodedattribute <urn:/hl7vmr/observationbase#observationfocus> ]; hl7vmr:requiredclinicalstatementclass hl7vmr:observationresult ]. < a ns1:recommendation; ns1:haspatientinputspecification [ a hl7vmr:patientinputspecification; rdfs:label "80"; ns2:requiredevaluatedpersonattribute <urn:/hl7vmr/evaluatedperson#age> ]. Tekst med grå bakgrunn viser knytning til ontologien for hver av ressursene som er illustrert i UML diagrammet ovenfor. Grønn og rød tekst viser hva som skal være med i pasientkontekst. Grønn tekst er spesifikasjon av at observasjon av typen labanalyse LDL (NEKLAB kode NPU01568), og rød tekst er spesifikasjon av at pasientens alder. RDF er en representasjon av en graf. Eksempelet ovenfor kan derfor illustreres slik: 52

55 <urn:/local/vmr> hl7vmr:evaluatedperson VMR hl7vmr:concerningpatient rdf:type hl7vmr:ivl_ts hl7vmr:cd rdf:type <urn:/local/vmr/anonymouspatient> rdf:type NPU01568 hl7vmr:evaluatedperson#age hl7vmr:observationresult#observationeventtime hl7vmr:evaluatedperson#clinicalstatement hl7vmr:cd#code 43 <urn:/dips/db/dwundersokelse/undersokelseid= > <urn:/helsedir/neklab/npu01568> hl7vmr:evaluatedperson#birthtime hl7vmr:cd#displayname hl7vmr:ivl_ts#high T18:00:00 hl7vmr:observationbase#observationfocus P-LDL-kolest hl7vmr:observationresult#observationvalue rdf:type 2,9 hl7vmr:observationresult hl7vmr:hastargetcodedattribute hl7vmr:hastargetcode hl7vmr:requiredclinicalstatementclass cdsinputspecification hl7vmr:clinicalstatementinputspecification rdf:type <bnode_1> <bnode_2> hl7vmr:hascodedattributerequirement rdf:type sehia:hasclinicalstatementinputspecification urn:/hl7vmr/codedattributerequirement < sehia:hasrecommendation rdf:type < rdf:type sehia:recommendation sehia:guideline <bnode> = blank node Figur 11 Grafrepresentasjon av retningslinjen. Blanke noder er noder som ikke har en eksplisitt URI. Klasser (ontologi) er rammet inn. Relasjoner (properties) er vist i kursiv tekst. Det er ingen krav til hvilke terminologier (NEKLAB, LOINC, SNOMED CT, UMLS osv.) som skal benyttes. SEHIA støtter semantisk mapping mellom ulike terminologier der det er mulig. Det er gjort enkelte forenklinger ift. til den opprinnelige HL7 vmr spesifikasjonen i OWL representasjonen av HL7 vmr. En forenkling gjelder referanser til HL7 kodeverk og terminologier med datatypen CD. Disse datatypene er en måte å representere referanser til lokale og ekstern terminologier ved bruk av en kodeid + kodesystemid som strenger som kan brukes til å slå opp i kodeverkene for å finne selve kodene. CD er derfor indirekte referanser til selve registreringen som finnes i terminologien. Den semantiske web en støtter derimot direkte referanser til selve registreringen i terminologien i form av URIer (på samme måte som en peker et dataprogram). Et eksempel er attributten targetcode i entiteten CodedAttributeRequirment. targetcode er av typen CD som betyr at targetcode bl.a. har Code og CodeSystem attributter hvor streng til kode og kodesystem fylles ut, f.eks. targetcode.code = «NPU01568» og targetcode.codesystem = «NEKLAB» for å referere til labtesten «P-LDL-kolest.» i NEKLAB. På semantisk web vil targetcode være URIen eks. <urn:/helsedir/neklab/npu01568> - som referere direkte til NEKLAB-registreringen. En annen forenkling handler om at metadata (klasser) også er data for semantisk web og kan refereres til fra data («individuals»). Attributtene requiredgeneralclinicalstatementclass og requiredspecificclinicalstatementclass i entiteten ClinicalStatementInputSpecification er lokale kodeverk (CS) som angir hhv. hvilke typer kliniske fakta som 53

56 spørringen gjelder (observasjoner, problemer, forskrivinger, operasjoner, etc.), og om det er planlagte eller utførte tiltak man er ute etter. Kodeverket angir i grunnen hvilken klasse i HL7 vmr som filteret gjelder. I stedet for å ha egne kodeverk for dette, så er disse attributtene erstattet med requiredclinicalstatementclass med direkte referanser (URI) til klassene i HL7 vmr. Eksempel: I stedet for at requiredspecificclinicalstatementclass = «ObservationResult», så er requiredclinicalstatementclass = <urn:/hl7vmr/observationresult>. Direkte referanser til metadata er mulig med representasjon av data på semantisk web siden metadata også er data. En semantisk annotert klinisk retningslinje er en digital retningslinje som består både av en narrativ del og en semantisk del. Sistnevnte beskriver deler eller hele retningslinjen i maskinlesbar form. Dersom den semantiske annoteringen er så komplett at den kan gjenskape hele retningslinjen, så er det ikke nødvendig at den er knyttet til den narrative delen. Forskning på digitalisering av retningslinjer [44] har ofte vært rettet en komplett semantisk representasjon av retningslinjene (se kategori 3 i kapittel 3.3.2), noe som er langt mer ambisiøst enn i SEHIA hvor kun fragmenter av en narrativ retningslinje annoteres DESKTOP SYNKRONISERING Webbaserte retningslinjer presenteres i en nettleser. Pasientopplysninger presenteres i arbeidsflaten til EPJsystem. I SEHIA presenteres pasientinfo, dvs. pasientopplysninger som er relevant for en pasient. Pasientinfoen er både avhengig av hvilken pasient som er valgt i EPJ-systemets arbeidsflate og hvilken retningslinje som presenteres i nettleseren. Når bruker velger ny pasient i EPJ-systemet, eller ny klinisk retningslinje/anbefaling i nettleser, så må pasientkontekst oppdateres. Dette kalles for desktop synkronisering. Det er SEHIA Guideline Controller (GL CTL) som har ansvaret for desktopsynkronisering, dvs. har ansvar for at pasientinfo hentes fram når nye retningslinjer viser i nettleser, samt tilby muligheter for å «bestille» foreslåtte legemidler, labanalyser, etc. som foreslås i retningslinjen. SEHIA GL CTL er integrert med EPJ-systemklienten og med SEHIA EHR Server som returnerer pasientinfo for en gitt aktivert pasient i journalsystemet og den aktuelle retningslinje som vises i nettleser. SEHIA GL CTL inneholder består av en innebygget nettleser og et integrasjonsgrensesnitt mot EPJ-systemet. Figuren under viser samspillet mellom komponentene: 54

57 Browser with guideline SEHIA Guideline Controller LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) Notify change activated patient 5 3 b EHR system user interface RetrievePatientContext() HTTP GET 3 HTTP Response a notify navigation SEHIA EHR Server SEHIA RDF Store Figur 12 Samspillet mellom integrasjonskomponentene. 1) Først navigerer (HTTP GET) bruker til webside med semantisk annotert retningslinje (røde ruter). Responsen (2) fanges opp av SEHIA Guideline Controller (3a) som henter pasientkontekst (4) fra SEHIA EHR Server og viser denne på en tilpasset måte i brukerflaten (5). Dersom aktiv pasient i EPJ-systemets arbeidsflate endres vil dette også fanger opp av SEHIA GL CTL (3b), hvor (4) og (5) utføres deretter. Hver gang pasientopplysningene i EPJ-systems arbeidsflate endres eller ved navigasjon til ny retningslinje, vil GL CTL oppdatere pasientkontekst. Det er mange måter å implementere SEHIA GL CTL på avhengig av teknologi og arkitektur til EPJ systemet og webbaserte retningslinjesystemene (WGL-CMS). Dersom EPJ-systemets arbeidsflate er en applikasjonsklient («native» client), så kan både nettleser og GL CTL implementeres i applikasjonsklienten (samme prosess). Dersom EPJ-systemets arbeidsflate er webbasert klient, så innebærer det en mer kompleks teknisk arkitektur med kontekst server (ala HL7 CCOW 43 ) og HTTP Proxy Server. Fordelen med «native» applikasjonsklient er enklere arkitektur som er enklere å implementere. SEHIA POC er implementert i applikasjonsklient (se kapittel 9). Integrasjonsgrensesnitt for SEHIA GL CTL og EPJ-systemet med applikasjonsklienter er enten.net eller Java interface dersom SEHIA GL CTL er en integrert med hhv..net eller Java applikasjon. Kan også benytte HL7 CCOW context manager med begrenset funksjonalitet dersom SEHIA GL CTL ikke kan integreres i EPJ-systemets arbeidsflate, men må kjøres som «standalone» klient. RDFa destiller er en komponent som SEHIA GL CTL bruker til å trekke ut RDF fra RDFa annoterte HTML sider. Hvorvidt dette brukes er avhengig av om WGL-CMS kan levere RDF direkte, eller om RDF er annotert ved hjelp av RDFa tagger

58 8.3 SEHIA DATAINTEGRASJON INTRODUKSJON SEHIA dataintegrasjon består av komponentene som kjører på back end applikasjons- og databaseservere. Hjertet i løsningen er selve datalageret som inneholder de kliniske opplysningene (SEHIA RDF Store) som er samlet inn fra EPJ og andre kliniske informasjonssystemer. SEHIA EHR Server er selve motoren som genererer relevant pasientkontekst gitt en retningslinje EXTRACT-TRANSFORM AND LOAD Som tidligere nevnt er dagens helseinformasjonsystemer veldig forskjelligartet, med hensyn til brukeropplevelse, kommunikasjonsprotokoller, lagringsteknologier, operativsystemplattformer, utviklingsmiljø. Pasientopplysninger i pasientjournalen kan også ligge spredt i flere ulike helseinformasjonsystemer. Pasientopplysninger vil typisk også være representert på ulike former som relasjonstabeller, XML-dokumenter og som narrativ tekst (fritekstdokumenter). Pasientopplysningene vil også referere ulike kodeverk og terminologier som forvaltes og oppdateres jevnlig av ansvarlig organisasjon med ulike importformater. Ved integrasjon mellom CDS-systemer og EPJ vil det være behov for svært ulike pasientopplysninger fra gang til gang, og det brukes ofte ulik terminologi i CDS-systemer vs EPJ for å beskrive (delvis) det samme. Når opplysninger man er ute etter ligger distribuert i ulike systemer, vil det være en utfordring å innhente opplysninger raskt nok i situasjoner der høye krav til responstid gjelder f.eks. situasjoner der en bruker sitter foran en terminal og venter på respons fra systemet. På toppen av dette må termer «oversettes» mellom systemer som innfører ekstra kompleksitet og tar tid. I SEHIA løses dette ved å samle data i et sentralt datalager og strukturert på en slik måte at søk pasientopplysninger kan gjøres på en enhetlig og rask måte. Når opplysningene i kildesystemene (som EPJ) oppdateres, sendes oppdateringen inn i SEHIA sitt datalager kalt SEHIA RDF Store. Dette mønsteret er det samme som brukes av datavarehusløsninger 44 / Business Intelligence (BI) 45 som også kan sees på som beslutningsstøttesystemer

59 Innenfor datavarehusterminologien brukes begrepet ETL Extract, transform and load som refererer til oppgaven med å hente data ut av kildesystemet, transformere til egnet representasjon og innlasting i datavarehusdatabasen. ETL er typisk spesiallaget for hver datakilde. Resultatet er at data samles og blir representert på enhetlig måte uavhengig av hvilket kildesystem de er hentet fra. SEHIA RDF Store er på mange måter en spesiell type datavarehusløsning for klinisk beslutningsstøtte. Kildesystemene er alle systemer som inneholder pasientopplysninger klassifisert som EPJ. Query Patient Context 2 Relevant Clinical variables (Patient Context) SEHIA EHR Server EHR DB 1 SEHIA RDF Store 1 1 LAB 2 LAB 1 1 RIS Figur 13 SEHIA RDF Store samler kliniske opplysninger fra ulike kildesystemer (1) ved hjelp av extract-transform-load (ETL) mekanismer som oppdateres kontinuerlig. Forespørsel om pasientkontekst (2) kan ta gjennomføres raskt og effektiv fordi data er samlet ett sted. SEHIA RDF er en database av kliniske fakta som er utsagn om pasientdemografi, helsetilstand, målinger og labanalysesvar, legemiddelforskrivninger, kontaktopplysninger, planlagte og gjennomførte operasjoner, osv. Begrepet kliniske fakta er også benyttet ifbm. semantisk annotering av retningslinjer (jf ). I SEHIA RDF Store er kliniske fakta representert ved RDF-tripler. ETL for uttrekk av kliniske fakta data er ikke nok. Vi har data, men vi har ingen modell som beskriver mening med data metadata. Metadata fra kildesystemene er i form av databaseskjema, XML Skjema, arketyper, osv. som brukes for klassifikasjon av data og relasjoner mellom dataelementer (ontologi) må også lastes over fra kildesystem til SEHIA RDF. Hvis ikke, er det ikke mulig å klassifisere hva som er henvisning, labsvar, forskrivinger, operasjoner osv. Metadata fra kildesystemene konverteres til RDFS/OWL (owl:class, rdfs:subclass, etc.). W3C utarbeider standard for konvertering av relasjonsdatabase til RDF RDB2RDF (se kapittel 7.3). Det er også beskrevet hvordan arketyper kan mappes til OWL i [45]. Tilslutt må alle kodeverk og terminologisystemer som er i bruk lastes inn i SEHIA RDF Store. Kontrollerte terminologier som f.eks. ICD10, SNOMED CT, NEKLAB, osv. kan være representert på ulike måte fra kildesystem til kildesystem. Av plasshensyn bør man forsøke å unngå duplisering av kodeverk. Dupliserte kodeverk kan mappes etterpå vha. owl:sameas relasjoner, men er unødvendig hvis man kan unngå det. 57

60 Mye at ETL operasjonen kan derfor automatiseres fordi det er klare regler for hvordan datastrukturer fra relasjonsdatabase, XML og arketyper kan representeres i RDF, RDFS og OWL. Men som sagt er det lurt å unngå duplisering av kodeverk og terminologier. Oppsummert så må følgende data hentes fra kildesystemene, transformeres og lastes inn (ETL): Metadata (databaseskjema, XML skjema, arketyper, etc.) transformeres til OWL Terminologier og kodeverk transformeres til RDF, RDFS eller OWL. Data («particulars») transformeres til RDF ETL operasjonene vil typisk hente de deler av pasientens journal som er skjemabasert/strukturert. SEHIA RDF Store vil derfor ikke være en komplett representasjon av pasientjournalen i semantisk form. ETL fra fritekst er mulig ved hjelp av NLP teknikker, men diskuteres ikke videre i denne oppgaven. Transformering til RDF, RDFS og OWL resulterer i URIer og "literals". URIer er globalt unike identifikatorer. URIer bygges opp med navnerom (namespace) hvor ontologien framgår tydelig som prefiks helsedir.no/, osv. Neklabkode for «P-LDL kolesterol» vil ha URI Tabellen dwperson i DIPS EPJ/PAS databasen vil således ha URIen Transformering av tabeller i relasjonsdatabasen til RDF følger W3C Recommendation A Direct Mapping of Relational Data to RDF 46. URIer for kliniske fakta (data) bør bygges opp slik at det er mulig å spore disse tilbake til originale datakilder, ikke bare system, men også identifikasjon av en konkret installasjon (instans). Det vil både gjøre det enklere å unngå duplisering av data ved ETL oppdatering og lette feilsøk. Resultatet av ETL prosessen er at data nå er samlet ett sted og representert med en og samme teknologi (semantisk web). Transformering av representasjoner i ulike kildesystemer til OWL kalles for normalisering («normalisation process») beskrevet i [46]. Selv etter dette, så er data fra forskjellige datakilder knyttet til ulike ontologier (metadata). En labtest fra labsystem 1 er definert forskjellig fra en labtest i labsystem 2 selv om begge er labtester. En person registrert i EPJ-system er definert forskjellig fra en person definert i RIS-system selv om det er personer. Å bygge bro over dette gapet er temaet i neste kapittel VIRTUELT EPJ-GRENSESNITT I forrige kapittel ble alle databaseskjemaer, terminologier og data fra forskjellige datakilder transformert og lastet inn i SEHIA RDF Store, og representert med samme teknologi (RDFS og OWL). Skillet mellom databaseskjemaer og terminologier viskes ut, og går her under fellesbetegnelsen ontologier 47 (se kapittel 3.2). Man sitter igjen med et sett med ontologier med tilhørende data. På tross av at alt nå er samlet i én database (RDF Store), er det likevel isolerte øyer av data/ontologier som er definert forskjellig. Spørringer etter data for de samme begrepene (f.eks. labtest) må gjøres for hver ontologi selv om de er samlet i samme (kunnskaps-)database. Dette er akkurat som om det gjøres spørringer mot de originale datakildene, og er man ikke kommet nevneverdig lengre enn før. For å oppnå semantisk interoperabilitet, innføres det et virtuelt EPJ-grensesnitt eller ny felles ontologi - som alle spørringer gjøres mot slik at kun én spørring henter alle data for samme begrep uansett datakilde. Dette er den vanligste metoden innen data integrasjon vist i Figur 2 i kapittel 3.2. For at dette skal være mulig, må begreper i det Det er ikke enighet om definisjon av en ontologi, men i denne oppgaven er ontologi brukt slik 58

61 virtuelle EPJ grensesnittet «mappes» til begreper i de ulike ontologiene, på samme måte som wrappere eller adaptere i tradisjonell dataintegrasjon. I SEHIA ble HL7 Virtual Medical Record (vmr) (se kapittel 4.5) valgt som virtuelt grensesnitt fordi det var den eneste (kommende) standarden som er spesielt spisset mot integrasjon mellom CDS-systemer og EPJ. I konverteringen til OWL er det gjort noen forenklinger og endringer (som beskrevet i 8.2.2). Mulighetene til å oppnå semantisk interoperabilitet er den samme som for semantisk web for øvrig, dvs. gjøres med de metoder og verktøy som finnes tilgjengelig på den semantiske web en. Det er mange utfordringer med «mapping» siden mange ganger er det ikke én-til-én match. «Mapping» i SEHIA og dets begrensninger er beskrevet i kapittel 3.2. I hovedsak er det "description logic" i form av Web Object Language (OWL) DL som brukes til «mapping», men også støtte av brukerdefinerte regler (ala Rules Interchange Format (RIF)). Som nevnt tidligere er det ikke nok å «mappe» mellom databaseskjemaer. Det må også mappes mellom terminologier. I motsetning til databaseskjemaene som mappes til et virtuelt EPJ grensesnitt, så er terminologimapping noe som gjøres ved behov. Dersom systemene som skal integreres benytter samme terminologier, så er det ikke behov for mapping. Figuren nedenfor viser modellen for dataintegrasjon med semantisk web-teknologi. 59

62 MAPPING MAPPING MAPPING IT6191 Masteroppgave Semantic Health Integration Architecture (SEHIA) SEHIA Guideline Web integration Request (cdsinputspecification) Response (cdsinput) Update (cdsoutput) Hemoglobin (Hb)? Creatinin (Cr)? LDL? Blood pressure Hb = 10.3 (12/2) Cr = 52 (10/2) LDL = 3.5 (10/2) Blood pressure = 176/90 (12/2) Order suggestion: Simvastatin External terminology (SNOMED CT, LOINC) HL7 vmr Internal terminology (NEKLAB, Local terminology) DIPS DB Schema OpenEHR RM Schema EHR system Figur 14 viser prinsippet med HL7 vmr og eksterne terminologier som et abstraksjonslag i mellom lokal EPJ sin datamodell og terminologier og ekstern CDS-system (SEHIA Guideline Web integration). De gule dobbeltpilene viser mappinger som er etablert i SEHIA mapping ontologi. Spørring/svar gjøres ved bruk av cdsinputspecification/cdsinput. Eventuelle forslag til forskrivinger kan gjøres ved cdsoutput. Innholdet i SEHIA RDF Store er nå en semantisk web med ontologier («TBox») og data («individuals», «ABox») med mappinger mellom ontologiene. I motsetning til før «mappingen» ble gjort, så er det nå kun nødvendig med én spørring for å få ut data fra de opprinnelige heterogene datakildene. Ved at resonnering («inference») kjøres etter en ETL har lagt inn nye data, vil det gjøre spørringene raskere. Hvilke kliniske fakta som er relevant for å hente fram er annotert i retningslinjen som cdsinputspecification (se kapittel 8.2.2). Neste kapittel beskriver hvordan relevant klinisk pasientkontekst («cdsinput») hentes ut SEMANTISK INTEGRASJON Dataintegrasjon mellom datakilder med ulike skjemaer og kodeverk/terminologier (ontologier) gjøres ved hjelp av «mappinger». Mappinger i SEHIA defineres enten av OWL uttrykk (owl:subclassof, owl:subpropertyof) eller regler («production rules» i RIF). Deretter kjøres innholdet i SEHIA RDF Store (både ontologier og data) igjennom resonneringssystem (her: «inference engine») for å etablere mappingene mellom data («individuals») og det virtuelle EPJ-grensesnittet (her: HL7 vmr) og mellom terminologier. Etter resonnering, hvor data fra forskjellige datakilder (med forskjellige ontologier) er knyttet opp mot HL7 vmr, så kan SPARQL spørringer bruke HL7 vmr ontologi for å spørre på alle datakildene. Det er mulighetene i OWL DL + regler som setter begrensninger på hva som er mulig å få til av mappinger. 60

63 Det er hovedsakelig to typer mappinger mellom HL7 vmr og de enkelte datakildene: rdfs:subclassof rdfs:subpropertyof rdfs:subclassof mappinger: HL7 vmr klassene er et overbygg på alle underliggende datakilder. Det betyr at HL7 vmr klassene vil innholdet data («individuals») potensielt fra mer enn én datakilde. Hver av datakildene vil da kunne mappes ved hjelp av rdfs:subclassof mappinger. I Figur 15 er det gjort mappinger mellom EPJ systemets lokale skjema for laboratorieanalyser og HL7 vmr. Ressursen <urn:/dips/db/dwundersokelse/undersokelseid= > er enten rekvirert eller ferdig analysert laboratorieundersøkelse i kildesystemet. Klassen hl7vmr:observationresult er derimot kun ferdig analyserte laboratorieundersøkelser. En mappingregel i OWL som utleder at ressursen «is a» hl7vmr:observationresult for kun ferdige laboratorieundersøkelser er vist i figuren nedenfor. <urn:/dips/db/dwkodeverkverdier/kodeid=107502> dips:db/dwundersokelse#ref-undersokelsesstatus <urn:/dips/db/dwundersokelse/undersokelseid= > rdf:type dips:db/dwundersokelse # Mappingregel: Alle undersokelser som det er mottatt et provesvar paa, "Svar mottatt" (107502) [a owl:restriction; owl:onproperty <urn:/dips/db/dwundersokelse#ref-undersokelsesstatus>; owl:hasvalue <urn:/dips/db/dwkodeverkverdier/kodeid=107502> ] rdfs:subclassof hl7:observationresult. <urn:/dips/db/dwkodeverkverdier/kodeid=107502> dips:db/dwundersokelse#ref-undersokelsesstatus <urn:/dips/db/dwundersokelse/undersokelseid= > rdf:type rdf:type hl7vmr:observationresult dips:db/dwundersokelse Figur 15 viser eksempel på mappingregel basert kombinasjon av rdfs:subclassof og owl:restriction/onproperty/hasvalue. 61

64 rdfs:subpropertyof mappinger: På samme måte som for klasser, så vil HL7 vmr attributter/predikater (properties) kunne representere tilsvarende predikater (properties) i de ulike datakildene. rdfs:subpropertyof vil, på samme måte som for rdfs:subclassof, da inneholde union av alle instanser av predikater fra de ulike datakildene. Dersom rdfs:domain og rdfs:range også er oppgitt, så vil selve HL7 vmr klassene også utledes. Eksempel: NEKLAB:kode rdfs:subpropertyof <urn:/hl7vmr/cd#code>. SNOMEDCT:code_string rdfs:subpropertyof <urn:/hl7vmr/cd#code>. Når det i tillegg er definer følgende aksiom i kunnskapsbasen, <urn:/hl7vmr/cd#code> rdfs:domain <urn:/hl7vmr/cd>, så kan også klassen <CD> utledes for alle NEKLAB og SNOMED CT koder. Dette betyr at alle NEKLAB og SNOMED CT koder vil inngå i spørringer på HL7 vmr CD klassen. Det samme gjelder rdfs:range. Ikke alle begreper som finnes i HL7 vmr kan mappes direkte til tilsvarende begreper i datakildene ved hjelp av rdfs:subclassof og rdfs:subpropertyof. Begrepene finnes ikke, men kan utledes ved hjelp av resonnering. Eksempel på bruk av owl:intersectionof, owl:restriction på openehr arketyper for å komme fram til et begrep som er en subklasse av HL7 vmr ObservationResult. [owl:intersectionof (<urn:/openehr#element> [a owl:restriction; owl:onproperty SEHIA:ancestorArchetype; owl:somevaluesfrom <urn:/openehr#observation>] [a owl:restriction; owl:onproperty SEHIA:ancestorArchetype; owl:somevaluesfrom <urn:/openehr#event>])] rdfs:subclassof <urn:/hl7vmr/observationresult>. Noen ganger er det ikke mulig å formulere mappingen i sin helhet i OWL. Resonnering i OWL 2 DL er begrenset til å utlede nye relasjoner (tripler) mellom individuals (noder), men ikke mellom «individuals» og «literals» for å være «decidable». Løsningen er å definere en produksjonsregel som kopierer «literals» slik at det er mulig å mappe til HL7 vmr. Figur 16 illustrerer dette. hl7vmr:ivl_ts#low DIPSDB:dwundersokelse rdf:subpropertyof rdf:type DIPSDB:dwundersokelse#utforttid <bnode_1> DIPSDB:dwundersokelse#ref-rekvisisjonid " T12:00:00"^^xsd:dateTime X <bnode_2> rdf:type DIPSDB:dwrekvisisjon DIPSDB:dwrekvisisjon#utforttid " T12:00:00"^^xsd:dateTime Figur 16 Data "property" DIPSDB:dwundersokelse#utforttid for <bnode_1> skal ha samme verdi som DIPSDB:dwrekvisisjon#utforttid for <bnode_2>. Dette kan ikke utledes med OWL DL. Løsningen er en produksjonsregel som kopierer verdien slik at rdfs:subpropertyof kan brukes for mapping mot HL7 vmr. 62

65 Produksjonsregel i RIF-lignende notasjon for eksempelet i figuren ovenfor: IF And(rdf:type(?x DIPSDB:dwundersokelse) DIPSDB:dwundersokelse#ref-rekvisisjonid(?x?y) DIPSDB: dwrekvisisjon#utforttid(?y?z)) Then DIPSDB:dwundersokelse#utforttid(?x?z) Det å utlede nye individuals gjør resonneringen i SEHIA ikke-avgjørbar («undecidable»), dvs. at en ikke garantere at validering ikke tar uendelig tid å fullføre (i praksis henger). Terminologimappinger. Det er to typer terminologimapping som støttes i SEHIA. Det ene er 1-til-1 mapping mellom ulike termer som betegner samme bakenforliggende begrep. Den andre er spørringer vha. klassifikasjonshierarkier/taksonomier («subsumption»). I eksempel i kapittel fra vises annotering av termer som det søkes etter i retningslinjen (hl7vmr:hastargetcode) og hvor disse finnes i EPJ (hl7vmr:observationbase#observationfocus). Her ser vi at både retningslinjen og EPJ har kodet samme term «LDL-kolesterol» (<urn:/helsedir/neklab/npu01568>). Ofte er retningslinjen og data i EPJ kodet med forskjellige terminologisystemer/kodeverk, og på forskjellige abstraksjonsnivåer. Dersom retningslinjen er annotert med det overordnede begrepet «kolesterol», så inkluderer dette også «LDL-kolesterol» («subsumption»). Alle kodene i terminologiene NEKLAB, LOINC, SNOMED CT er «individuals» når de benyttes til semantisk annotering i retningslinjen og i EPJ. Men terminologiene er hver for seg ontologier med egne klassehierarkier (isa-relasjoner). Disse hierarkiene er representert som egne class-subclass hierarkier. Kliniske uttrykk som benytter kodene, vil også kvalifisere som «individuals» til de klassene kodene «tilhører». Støtte for klassifikasjonshierarkier/taksonomier ble løst ved hjelp av «Class-Individual Mirror pattern» [47] (siden «punning» er et antipattern): < a owl:restriction; owl:onproperty SEHIA:OF; owl:hasvalue < <urn:/hl7vmr/observationbase#observationfocus> rdfs:subpropertyof SEHIA:OF. For hver kode så defineres det en tilsvarende klasse som har endelsen (/Class). Det betyr at alle kliniske observasjoner (domenet til ObservationBase#ObservationFocus) vil være medlem av en klasse avhengig av property ObservationFocus. Det er nødvendig å definere restriksjonen på en "superproperty" av «ObservationBase#ObservationFocus»: «SEHIA:OF», ellers vil resonnering gjøre at nye «ObservationBase#ObservationFocus» utledes, og vi kan ikke skille på opprinnelige fakta (det som ble registrert i EPJ) og det som ble utledet. Ved å definere SEHIA:OF som en superproperty vil vi kunne skille mellom den originale "property" og alle utledede "properties". I tillegg må klassehierarkiene til terminologiene legges inn: < rdfs:subclassof < 1-til-1 mappinger mellom terminologisystemer gjøres ved hjelp av «owl:equivalentclass». Spørringer (annotering i retningslinjen) gjøres da på klassene i stedet for kodene. Samme kode (klasse), tilsvarende kode i annen terminologi (equivalentclass) eller overordnet kode i klassehierarkiet (super class). 63

66 Dersom annotering i retningslinjen gjøres med en overordnet term i klassifikasjonshierarkiet/taksonomien, så vil spørringen også inkludere spesialiserte termer og 1-til-1 mappinger. Figuren under illustrerer både klassifikasjonshierarkier og 1-til-1 mapping mellom termer Finner denne målingen i EPJ LOINC: Lipids subclassof Kode i spesifisert retningslinjen 12/08/10 målt 2,9 mmol/l måling knyttet til analyse LOINC: Cholesterol (LP ) subclassof knyttes til kodeklasse hastargetcode LP NEKLAB: LDL kolesterol (NPU01568) equivalentclass LOINC: Cholesterol. in LDL (LP ) Figur 17 Illustrasjon av spørring ved hjelp av klassifikasjonshierarkier og termmapping. Her har retningslinjen annotert med LOINC termen LP Cholesterol som er en superklasse av LP Cholesterol. in LDL. I EPJ finnes det en mapping av LDL kolesterol med NEKLAB termen NPU01568 LDL kolesterol. Ved hjelp av equivalentclass og subclassof (isa) relasjon i klassifikasjonshierarkiet LOINC, så returnerer ønsket måling. Detaljerte mappinger fra de ulike datakildene i POCen (DIPS DB og openehr) er beskrevet i kapittel ARBEIDSFLYT MELLOM KOMPONENTER INNLEDNING SEHIA skal kunne integreres med EPJ-systemer på ulike tekniske plattformer og arkitekturer. En viktig distinksjon er mellom webbaserte og «native» klientbaserte systemer. Selv om arbeidsflyt mellom SEHIA komponentene vil være tilnærmet lik for ulike tekniske arkitekturer, så vil den tekniske implementasjonen og distribusjon (hvilken «boks» komponentene kjører på) være ganske forskjellig for web- versus «native» klientbaserte systemer. Arbeidsflytbeskrivelsene nedenfor er gjort for «native» klientbasert systemarkitektur, som er den samme tekniske arkitekturen som POCen for de 4 brukerhistoriene fra kapittel 6.2. Brukerhistorie F1 blir implementert i SEHIA POC. Alle beskrivelsene nedenfor forutsetter at det er en aktivert pasient i EPJ-systemets brukergrensesnitt BRUKERHISTORIE F1: VISE KLINISK PASIENTKONTEKST «Som lege ønsker jeg at relevante kliniske variabler (labtester, tidligere diagnoser, tilstander, etc.) automatisk skal vises når jeg vurderer en anbefaling i en klinisk retningslinje som tilbys via web slik at jeg slipper å bytte mellom ulike skjermbilder i EPJ systemet og retningslinje websystem (guideline CMS).» 64

67 EHR Desktop Client App LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) SEHIA GDL CTL Navigate to readable clinical guideline by using webbrowser HTTP GET hjerneslag/sekundarforebygging/lipidsenkende-behandling Accept: text/html Sykehus intranett Web Browser (embedded) patientid + URL Helsenett Internett Brannmur EHR DB EHR application server SEHIA EHR Server SEHIA RDF Store Look up machine readable version of the same guideline HTTP GET retningslinjer/hjerneslag/sekundarforebygging/ lipidsenkende-behandling Accept: RDF/XML 4 Guideline Content Management System (G-CMS) Guideline in HTML with Semantic tags (RDFa) Extract Transfer Load (ETL) Guideline Authoring Figur 18 Arbeidsflyt mellom native klient EPJ-system og retningslinje på web (Guideline Content Management System) Forkortelser: SEHIA GL CTL = SEHIA Guideline Controller Flyten (se nummer i figuren) 1. Bruker velger å hente fram retningslinjen «lipidsenkende behandling» (sekundærforebygging hjerneslag) i nettleser:. 2. WGL-CMS webserver helsebiblioteket.no returnerer retningslinjen som forespurt i 1) som er annotert med semantiske tagger (HTML + RDFa) og som vises til bruker i innlimt ("embedded") nettleser i EPJ-systemet. 3. SEHIA GL CTL tar med URL til RDF som input + aktiv pasient ID og ber SEHIA EHR Server om å hente fram kliniske variabler. 4. SEHIA EHR Server laster ned RDF gitt URL-adressen. 5. SEHIA EHR Server bruker RDF-retningslinjen til å hente fram relevante kliniske variabler fra pasientjournalen til pasienten gitt pasient ID. Resultatet sendes tilbake til SEHIA GL CTL. 6. SEHIA GL CTL viser relevant klinisk pasientkontekst for den retningslinjen som er lastet inn i nettleseren. Nedenfor vises en variant av denne arbeidsflyten hvor RDFa destillering er lagt inn i klienten. Fordelen med denne er at det krever ingen endringer i WGL-CMS (helsebiblioteket.no, UpToDate, BestPractice, osv.). Terskelen er så lav at dette er mulig å få til med små investeringer. 65

68 EHR Desktop Client App LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) SEHIA GDL CTL Web Browser (embedded) Navigate to readable clinical guideline by using webbrowser HTTP GET hjerneslag/sekundarforebygging/lipidsenkende-behandling Accept: text/html 2 Sykehus intranett SHIA RDFa Distiller 5 4 patientid + RDF Helsenett Internett Brannmur Guideline in HTML with Semantic tags (RDFa) EHR DB EHR application server SEHIA EHR Server SEHIA RDF Store Guideline Content Management System (G-CMS) Extract Transfer Load (ETL) Guideline Authoring Figur 19 Variant av arbeidsflyt mellom native klient EPJ-system og retningslinje på web (Guideline Content Management System) hvor RDFa destillering er flyttet fra Guideline CMS (helsebiblioteket.no) til EPJ-klienten. Arbeidsflyten er litt forskjellig fra ovenfor. I stedet for at det sendes en URL til hvor en RDF-retningslinje kan lastes ned, så destilleres RDF fra websiden med retningslinjen i EPJ-klienten, og selve RDF sendes om parameter til SEHIA EHR Server (4). Begge arbeidsflytmodellene presentert ovenfor tar utgangspunkt i at WGL-CMS websidene er relativt statiske ved at innholdet endres kun ved navigasjon (HTTP GET), noe som er karakteristisk i tradisjonelle Web 1.0 nettsteder. I en mer dynamisk setting, så vil innholdet kunne endres uten ny navigasjon ved hjelp av JavaScript/Ajax (Web 2.0). SEHIA CTL bør derfor også tilby slike applikasjoner muligheter til «si i fra» når SEHIA GL CTL må oppdatere pasientkonteksten DE ANDRE BRUKERHISTORIENE SOM IKKE IMPLEMENTERES I SEHIA POC BRUKERHISTORIE F2: NAVIGERE TIL DETALJER I EPJ-SYSTEM «Som lege ønsker jeg at alle kliniske variabler har en assosiert hyperlink som jeg kan benytte for å navigere direkte til EPJ-systemet hvor kildeinformasjonen befinner seg slik at jeg slipper å bruke unødvendig tid å finne disse selv i en travel hverdag.» 66

69 SEHIA GDL CTL LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) 1 Click observation hyperlink EHR Desktop Client App + 2 Web Browser (embedded) EHR application server EHR DB Figur 20 Arbeidsflyt mellom SEHIA GL CTL og EPJ for å navigere til skjermbilde i EPJ hvor flere detaljer om observasjonen LDL registrert eller Forkortelser: SEHIA GDL CTL = SEHIA Guideline Controller Forutsetning: Brukerhistorie 1 er gjennomført, dvs. en retningslinje og hvor relevante kliniske variabler (her: labanalyse LDL målt og ) vises i arbeidsflaten i tilknytning til retningslinjen. Målingene viser som hyperlinker i brukergrensesnittet. Flyten (se nummer i figuren) 1. Brukeren velger å klikke på en av hyperlinkene (her: LDL eller ). 2. SEHIA Guideline Controller sender forespørselen til EPJ systemet med variabel som ble klikket (LDL) + identifikator som brukes av EPJ til å lokalisere objektet i EPJ-databasen (her: den konkrete labanalysen som ble gjort av LDL eller ) BRUKERHISTORIE F3: BESTILLE NYE UNDERSØKELSER «Som lege ønsker jeg at det skal på en enkel måte være mulig å opprette forslag til ulike supplerende undersøkelser, røntgen, EKG, osv. som nevnes i retningslinjen, men som mangler eller hvor eksisterende er gammel og er viktig for å kunne ta stilling til anbefalingen slik at jeg sparer tid og unngå feil.» 67

70 EHR Desktop Client App + 2 SEHIA GDL CTL LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ) Order new 1 Click «order new» hyperlink Web Browser (embedded) EHR application server EHR DB Figur 21 Arbeidsflyt mellom SEHIA Guideline Controller og EPJ-system for å benytte innhold i retningslinjen til å kunne pre-utfylle en LAB rekvisisjon i EPJ-systemet. Forutsetning: Brukerhistorie 1 er gjennomført, dvs. en retningslinje og hvor relevante kliniske variabler (her: labanalyse LDL målt og ) vises i arbeidsflaten i tilknytning til retningslinjen. Målingene vises som hyperlinker i brukergrensesnittet. Flyten (se nummer i figuren): 1. Brukeren krysser av for LDL labanalyse, og velger å klikke på hyperlinken «order new». 2. SEHIA Guideline Controller sender forespørselen til EPJ systemet med variabel som ble klikket (LDL) som «ser» at LDL er en labanalyse, og henter fram labrekvireringsbildet som fylles ut med LDL (implementasjon avhengig av EPJ-system). Dersom det er flere labanalyser som er avkrysset, så vil alle disse kunne rekvireres samtidig BRUKERHISTORIE F4: BESTILLE FORESLÅTTE UNDERSØKELSER «Som lege ønsker jeg at det skal på en enkel måte være mulig å opprette forslag til forordninger som foreslås av anbefalingen direkte i EPJ slik at jeg kan spare tid, samt unngå feil.» Tilsvarende arbeidsflyt som for brukerhistorie 3 ovenfor. For forskriving av legemidler vil det være behov for å overføre dose, styrke og form i tillegg til identifikasjon av legemiddel. Dersom dette ikke spesifiseres av 68

71 anbefalingen, kan kun identifikasjon av legemiddel overføres og klinikeren manuelt legge inn dose, styrke og form selv. 69

72 9 SEHIA POC MED DIPS EPJ 9.1 INTRODUKSJON I dette kapittelet beskrives utvikling av proof-of-concept (POC) av SEHIA som ble gjennomført som en del av denne masteroppgaven. SEHIA POC ble utviklet som en del av metoden for å evaluere SEHIA som både handler om å støtte funksjonelle og ikke-funksjonelle krav i kravspesifikasjonen i kapittel 6. I tilknytning til kravspesifikasjonen ble det derfor utarbeidet et testbatteri med 5 test cases i kapittel 9.2. En viktig del av metoden er så langt som mulig å teste ut SEHIA modellen i et så virkelig miljø som mulig. Det var derfor viktig å integrere SEHIA POC med et EPJ-system som er i daglig drift ved sykehus. Valget falt på DIPS Arena EPJ 48 levert av programvareselskapet DIPS ASA. Figuren under er oversikt over den tekniske arkitekturen med DIPS Arena og SEHIA komponentene (gule bokser) ble implementert i POCen: DIPS Arena og SEHIA POC DIPS Arena Application Client SEHIA Guideline Controller (GL CTL) Sykehus intranett Brannmur Helsenett Internett DIPS EHR DB DIPS application server SEHIA RDF Store SEHIA EHR Server Guideline Content Management System (G-CMS) Figur 22 DIPS Arena og SEHIA POC teknisk arkitektur. Gule bokser viser distribusjon av de ulike SEHIA komponentene i POCen. 48 Hvor forfatter for tiden er ansatt 70

73 SEHIA POC er en av flere mulige implementasjoner av SEHIA. POCen innholder begrenset med funksjonalitet som er tilpasset behovene i test casene. 9.2 TESTBATTERI Scenarioet som testbatteriet tar utgangspunkt i er et reelt sykdomsforløp en mann med diagnosen (lett) hjerneslag. Test casene bruker autentiske pasientdata i så langt det er mulig, men det er også konstruert testdata i noen grad for å kunne teste ut deler av løsningen som ellers ikke ville ha vært mulig. Hjerneslag har en kunnskapsbasert retningslinje i Norge: «Nasjonale retningslinjer for behandling og rehabilitering ved hjerneslag» [48] som er tilgjengelig via nettet 49. Test casene er hentet fra de sekundærforebyggende retningslinjene: blodtrykkssenkende behandling og lipidsenkende behandling: Figur 23 Retningslinje for lipidsenkende behandling fra

74 Figur 24 Retningslinje for Blodtrykksenkende behandling fra Under gjennomføringen ble diverse det gjort forenklinger, endringer, tilpasninger på de steder der OWL og regler ikke strakk til. Alternativet var å si avbryte og si at test caset ikke ble oppfylt. Å legge inn en «fiks» på de steder, og beskrive begrensningen ble vurdert som mer verdifullt ved evaluering av POCen. Alle test casene nedenfor ble derfor gjennomført sett ut fra et funksjonelt perspektiv. De neste kapitlene beskriver hvilke problemer som oppstod underveis. Generelle opplysninger: - Navn: Mr Tic Seman, f. 09/ Pasient ID i EPJ-systemet: Test case 1: Vise pasientens LDL kolesterol labanalyser Anbefaling nr. 2 Figur 23: «Behandlingsgrenser: Det finnes ingen klare behandlingsgrenser, men alle pasienter med hjerneinfarkt A 1a eller TIA med LDL >2,0 mmol/l bør tilbys statinbehandling hvis ikke kontraindisert.» 72

75 Anbefaling nr. 4 Figur 23: «Behandlingsmål: Behandlingsmål for lipidsenkende behandling etter hjerneinfarkt eller TIA bør være A 1a LDL <2,0 mmol/l hvis dette kan oppnås uten bivirkninger» Forventet resultat: «LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ),.» Test case 2: Vise pasientens alder Anbefaling nr. 3 Figur 23: «Hos eldre pasienter > 80 år er dokumentasjonen vedrørende statinbehandling relativt svak, og individuell vurdering bør foretas.» Anbefaling nr. 4 Figur 24: «BT-senkende behandling bør også tilbys eldre pasienter >80 år med BT >140/90 mmhg» Forventet resultat: «Alder: 57 år» Test case 3: Vise blodtrykksmålinger (observasjoner som arketyperegistreringer) Anbefalingen nr. 3 Figur 24: BT-senkende behandling kan også vurderes hos pasienter med BT <140/90 mmhg, og bør spesielt vurderes hos yngre og pasienter med spesielt stor vaskulær risiko. Forventet resultat: «Blodtrykk: 176/90 mm[hg] ( ),.» Test case 4: Vise pasientens LDL kolesterol labanalyse kodet med LOINC i retningslinjen og NEKLAB i EPJ DB (1-til- 1 mapping) Variant av test case 1, men hvor laboratorietesten LDL er kodet med LOINC-koden LP i anbefalingen, mens den er registrert med NEKLAB-kode NPU01568 i DB. Forventet resultat: «LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ),.» Test case 5: Vise pasientens LDL kolesterol labanalyse kodet med LOINC i retningslinjen med generell kode for kolesterol NEKLAB i EPJ DB («subsumtion») Variant av test case 4, men hvor laboratorietesten er koden med den generelle LOINC koden for kolesterol LP som innbefatter alle typer kolesterolanalyser (LDL, HDL, VLDL), mens LDL registrering er kodet med NEKLAB-kode NPU01568 i EPJ-DB. Forventet resultat: «LDL 2,9 mmol/l ( ), 2,4 mmol/l ( ),.» 9.3 DIPS ARENA EPJ-SYSTEM DIPS Arena EPJ-system er et norskutviklet journal- og pasientadministrativt system som er i daglig drift ved 3 av 4 helseregioner per i dag. Systemet ble utviklet sent på 1990-tallet og satt i drift før år Opprinnelig var systemet en klient/tjenerarkitektur med Windows (fet) klient utviklet i Delphi Win32 og relasjonsdatabase på Oracle 11gR2. I 2006 ble en gradvis omlegging over til.net og 3-lags arkitektur igangsatt og i 2013 ble den nye DIPS Arena arbeidsflaten applikasjonsklient lansert basert på Windows Metro brukergrensesnittplattformen («tiles» og «flyouts»). DIPS Arena applikasjonsklienten kommuniserer med en applikasjonsserver vha. webtjenester (WS) 50. Applikasjonsklienten har en modulær oppbygging og nye moduler kan sømløst integreres inn i arbeidsflaten. Blant annet er det integrert en Chrome-basert nettleser (Awesomium) som gjør det mulig å vise innhold fra nettsteder sammen med andre moduler i arbeidsflaten. 50 Systemet er under omskriving til ny plattform og arkitektur. Det som beskrives her er den nye arkitekturen. 73

76 Systemet består av en rekke moduler som både støtter norske lover og forskrifter for journalføring, arbeidsflytsystem, pasientadministrasjon, behandlingsplan sykepleie, medikasjon, operasjonsplanlegging, LAB rekvisisjon/svar, og nødvendige samhandlingsmoduler for utveksling av meldinger mellom fastlege, kommune og sykehus. Systemet lagrer journalinformasjon i en Oracle database i både strukturert i relasjonstabeller eller XML og ustrukturert som tekst- og binærobjekter (Oracle Large Objects LOBs). Tabellen nedenfor viser hvor et utvalg av journalopplysninger ligger: Type journalinfo Representasjon Hvor Laboratorierekvisisjon og svar Strukturert Relasjonstabeller Tekstnotater LOB Character LOB-felt Kliniske variabler (Blodtrykk, puls, Strukturert (arketyper) XML vekt, osv.) Diagnose Strukturert Relasjonstabeller Medikasjon Strukturert XML Opphold (besøk) Strukturert Relasjonstabeller Brukergrensesnittet er lagt opp til at brukerne jobber med én pasient om gangen, såkalt «aktivert pasient». Det går tydelig fram i skjermbildet hvilken pasient som er aktiv. Det er mulig å søke opp ny pasient og aktivere denne. 9.4 UTVIKLINGSPLATTFORM OG TEKNOLOGI SEHIA POC er utviklet på flere plattformer. SEHIA POC integrasjon med DIPS Arena EPJ er utviklet i språket C# i Visual Studio 2012 på Microsoft.Net 4.5 plattformen. ETL-funksjonene som trekker ut pasientopplysninger fra EPJsystemet og inn i SEHIA RDF Store er utviklet i Java i Eclipse Juno på Java SE 1.7 plattformen. Guideline CMS mockup er utviklet i Visual Studio 2010 på Python 2.7 plattformen ved hjelp av Python Django bibliotek for utvikling av webapplikasjon. Årsaken til at POCen ikke kunne utvikles på samme plattform skyldes i hovedsak at open source biblioteker for RDF/OWL prosessering finnes på Java og Python plattformen, men ikke på.net..net er derimot den plattformen som undertegnede kjenner best og som den nye DIPS EPJ klienten (Arena) er utviklet på. Det er derfor en viktig at SEHIA GL CTL integrasjon blir utviklet på samme plattform. For å få tilgang til Java biblioteker i.net så ble verktøyet IKVM.Net 51 Java Virtual Machine (JVM) for.net og Mono-plattformene benyttet. Det gjør det mulig bl.a. å skrive C# kode i.net som kaller funksjoner i Java-biblioteker (.jar). De viktigste bibliotekene for dette er RDF bibliotek Apache Jena v og RDFa destilleringsbiblioteket pyrdfa 53 (open source). DIPS Arena klienten har en integrert nettleser Awesomium 54 basert på WebKit 55 /Chromium 56 open source som gjør det mulig å integrere websider med JavaScript med EPJ-systemet på en sikkert måte

77 SEHIA RDF Store bruker den kommersielle databasen Oracle 11gR2 Enterprise Edition med Oracle Spatial og Oracle Partitioning Option som RDF triple store. Siden DIPS Arena EPJ også benytter Oracle, gjør dette ETL operasjonen enklere. Oracle har en innebygget regelmotor som støtter resonnering med RDFS, OWL 2 RL og brukerdefinerte regler (RIFlignende). Alle RDF-funksjoner kan nås via SQL og PL/SQL biblioteker (SEM_APIS). Oracle støtter SPARQL 1.0 spørringer som kan legges inn som en del av SQL spørringer som parameter til SEM_MATCH-funksjonen, eksempel: SELECT CD_URI, code, name FROM TABLE(SEM_MATCH( 'prefix hl7: <urn:/hl7vmr/> select?cd_uri?code?name where {?CD_URI a hl7:cd.?cd_uri <urn:/hl7vmr/cd#displayname>?name.?cd_uri <urn:/hl7vmr/cd#code>?code. } ', SEM_Models('DIPSSemDB'), SEM_Rulebases('OWL2RL','SEHIA_rb'), null, null)) order by 1 Spørringen ovenfor henter tripler fra en RDF Store med navn DIPSSemDB og benytter «entailments» for OWL2RL og SEHIA_RB. «Entailments» er utvidelser av triple store (her: DIPSSemDB) med tripler som er generert som følge av resonneringer som er gjort. «Entailment» er derfor en slags «cache» som gjør at spørringer kan eksekvere raskere i og med at «entailment»-triplene genereres når nye tripler legges inn i triples-store, og dermed ligger klar når spørringen eksekveres. En alternativ aksessmetode er via RDF-biblioteket Apache Jena. Oracle tilbyr en adapter som gjør at RDF repository i Oracle gjøres tilgjengelig gjennom Jena APIer. SEHIA POC benyttes Jena APIer og ikke SQL eller PL/SQL APIene for aksess. 9.5 IMPLEMENTASJON AV EXTRACT-TRANSFORM AND LOAD (ETL) Prinsippene for ETL-prosessen i SEHIA er beskrevet i kapittel Her beskrives ETL prosessen fra DIPS datamodell til SEHIA RDF Store. I POCen ble DIPS sin datamodell lagt til grunn og det ble bygget et tilsvarende ontologilag som RDF Skjema (RDFS) som gjenspeilte denne modellen (se W3C «A Direct Mapping of Relational Data to RDF» 57 ). Data («individuals») ble dels en kopiert fra relasjonstabellene og dels opprettet i TURTLE-filer med data som ikke fantes i relasjonsdatabasen. For data som ligger i XML-strukturer i DIPS databasen, så ble disse i sin helhet opprettet ved hjelp av TURTLE-filer. XML Skjemaet (XSD) ble oversatt til RDF Skjema (RDFS). Hele ETL jobben ble programmert i et Java ETL program (DIPSSemDB) som benyttet Jena biblioteket m/oracle RDF adapter. Programmet ble utviklet slik at det tømte SEHIA RDF Store hver gang sånn at det kunne kjøres hver gang det ble gjort en endring. Hver kjøring tok ca sekunder. I en virkelig implementasjon bør oppdatering gjøres inkrementelt og ved behov. Ifølge testbatteriet er det data fra domenene laboratoriemålinger og kliniske variabler (blodtrykk, puls, osv.) som ble lastet inn i RDF Store

78 I DIPS datamodell er labanalysene lagret i relasjonstabellene DWREKVISISJON, DWUNDERSOKELSE og DWUNDERSOKELSESKODER. De kliniske variablene lagres som XML iht. openehr Referansemodell XSD og arketypedefinisjoner (ADL). I tillegg finnes selve personopplysningene til tabellen DWPERSON. Figuren nedenfor viser en forenklet datamodell hvordan data henger sammen: DWPERSON Kliniske variabler (blodtrykk, puls, vekt,osv.) Lab * DWREKVISISJON * * DWUNDERSOKELSE * DWUNDERSOKELSESKODER 1 SNOMED CT NEKLAB 1 Figur 25 Forenklet datamodell som viser DIPS tabeller (gult), openehr XML Dokument (composition) og kobling til terminologier som SNOMED CT og NEKLAB. Den komplette datastrukturen til openehr XML-dokument er for komplisert til å vises i denne figuren. DWUNDERSOKELSESKODER er lokale labkodeverk hvor hver kode kan mappes til en NEKLAB-kode. Bare standard laboratoriekodeverk (NEKLAB) ble lastet inn i sin helhet, mens kun SNOMED CT termer som ble referert i fra openehr XML instanser ble lagt inn manuelt i TURTLE-filer. Det ble også lagt inn noen LOINC koder manuelt for å demonstrere terminologimapping. Transformering av openehr XML til OWL ble gjort for hånd, men på basis av beskrivelsen i artikkel [45]. Følgende URI-namespace ble brukt ifbm. oppretting av ontologier og innlasting av data («individuals») i SEHIA RDF Store: Domene DIPS openehr RM NEKLAB-terminologi SNOMED CT LOINC URI namespace urn:/dips/ urn:/openehr# urn:/helsedir/ urn:/snomed-ct(2003) Selv pasientens journal ligger i én og samme DIPS database, så er den spredt over mange tabeller og med ulik representasjon relasjons og XML. Figuren ovenfor viser bare en liten del av pasientens journal. Likevel viser den to datakilder som har helt forskjellig oppbygging selv om begge lagrer observasjoner. Selv om POC-eksemplene i denne oppgaven bare har kliniske variabler lagret som openehr arketyper, så er det ingenting i veien for at 76

79 laboratorieundersøkelser også vil bli lagret som openehr arketyper. Konsekvensen er at det ikke er nok bare å spørre i DIPS LAB-tabellene etter spesifikke utførte labanalyser. Det må også spørres i openehr arketypelageret, og da potensielt filtrert på en annen terminologi f.eks. LOINC. Å gjøre enklere er essensen med semantisk integrasjon i neste kapittel. 9.6 SEMANTISK INTEGRASJON INNLEDNING I kapittel ble modellen for semantisk integrasjon i SEHIA gjennomgått. Mappinger av datamodellen for DIPS DB og openehr XML til HL7 vmr skjer via rdfs:subclassof og rdfs:subpropertyof. Men det er ikke nok for mange av mappingene. F.eks. skiller HL7 vmr mellom observasjoner som har skjedd versus, versus bestillinger. F.eks. en labmåling LDL målt er klassifisert som en HL7 vmr ObservationResult, mens en labrekvisisjon av LDL er HL7 vmr ObservationOrder. I DIPS ligger begge deler i tabellen DWUNDERSOKELSE. Hvorvidt det er en observasjon eller en rekvisisjon er avhengig av verdien i attributten DWUNDERSOKELSE.undersokelsesstatus (jf. Figur 15). Før mapping, ble nødvendige entiteter i HL7 vmr ontologien oversatt til OWL/RDF skjema (RDFS) i en TURTLE-fil og lastet inn i SEHIA RDF Store. Ikke alle attributter er med. Kun de som er nødvendig for resonnering («inference»). I POCen mappes kun en liten del av HL7 vmr. UML under viser hvilke entiteter som mappes. Entity id : II * ClinicalStatement subclassof clinicalstatement subclassof Person ObservationBase subclassof observationfocus : CD VMR concerningpatient * EvaluatedPerson ObservationResult subclassof birthtime : datetime age : PQ observationeventtime : IVL_TS obervationvalue : string Datatypes: IVL_TS II CD PQ low : datetime high : datetime root : string code : string codesystem : string displayname : string unit: string value: decimal Figur 26 UML diagram av et subsett av entiteter og attributter fra HL7 vmr som benyttes I POCen. Noen av datatypene på attributtene er endret til enklere datatyper. Tabellen under viser hvordan klassene og attributtene ble mappet til datakildene DIPS LAB og openehr arketyper i POCen: 77

80 # HL7 klasse HL7 Attributt Kildeklasse/terminologi Kildeattributt 1.1 Entity id :II DIPS DWPERSON personid 1.2 Entity id :II openehr PARTY_SELF external_ref, id 2.1 EvaluatedPerson birthtime : datetime DIPS DWPERSON foedselsdato 2.2 EvaluatedPerson age : PQ DIPS DWPERSON kalkulert på basis av foedselsdato 2.3 EvaluatedPerson clinicalstatement : DIPS DWUNDERSOKELSE ref-personid ClinicalStatement 2.4 EvaluatedPerson clinicalstatement : openehr ELEMENT subject ClinicalStatement (OBSERVATION, EVENT) 3.1 ObservationBase ObservationFocus : CD DIPS DWUNDERSOKELSE ref-undersokelseskodeid, refneklabkode 3.2 ObservationBase ObservationFocus : CD openehr ELEMENT (OBSERVATION, EVENT) 4.1 ObservationResult ObservationEventTime : IVL_TS DIPS DWUNDERSOKELSE utforttid 4.2 ObservationResult ObservationEventTime : IVL_TS openehr ELEMENT time (OBSERVATION, EVENT) 5.1 ObservationResult ObservationValue : string DIPS DWUNDERSOKELSE tekstsvar 5.2 ObservationResult ObservationValue : string openehr ELEMENT (OBSERVATION, EVENT) value, elementvalue Etter semantisk integrasjon ved hjelp av mappinger i OWL og regler er skillet mellom datakildene DIPS LAB eller openehr XML visket ut. Alle observasjoner kan nå spørres igjennom HL7 vmr grensesnittet. F.eks. kan en spørre etter alle observasjoner slik: prefix hl7: <urn:/hl7vmr/> select?clinicalstatementuri?observationfocus?code?displayname?ts?observationvalue where {?ClinicalStatementURI a hl7:clinicalstatement.?clinicalstatementuri a hl7:observationbase.?clinicalstatementuri a hl7:observationresult.?clinicalstatementuri <urn:/hl7vmr/observationbase#observationfocus>?observationfocus.?observationfocus a hl7:cd.?observationfocus <urn:/hl7vmr/cd#displayname>?displayname.?observationfocus <urn:/hl7vmr/cd#code>?code.?clinicalstatementuri <urn:/hl7vmr/observationresult#observationeventtime>?tsuri.?tsuri a hl7:ivl_ts.?tsuri <urn:/hl7vmr/ivl_ts#low>?ts.?clinicalstatementuri <urn:/hl7vmr/observationresult#observationvalue>?observationvalue. } order by?ts De neste kapitlene benytter OWL DL og RIF notasjon for å vise hvordan mappingen ble gjort og tilhørende kommentarer. For de som ikke er interessert i detaljene rundt mappingen, er det mulig å gå rett på oppsummeringen i kapittel MAPPING #1.1: DIPS -> ENTITY.ID Fra DIPS: <dwperson> rdf:type owl:class. <dwperson#personid> rdf:type owl:datatypeproperty; rdfs:domain <dwperson>. Til HL7 vmr: <Entity> rdf:type owl:class. <Entity#id> rdf:type owl:objectproperty; rdfs:domain <Entity>; rdfs:range <II>. <Person> rdfs:subclassof <Entity>. 78

81 <II> rdfs:subclassof <ANY>. <II#root> rdf:type owl:datatypeproperty; rdfs:domain <II>. Mens DIPS <dwperson#personid> er et literal som inneholder personens ID, så finnes denne i HL7 vmr som property <II#root> til klassen <II> som refereres fra <Entity#id>. Siden owl:propertychainaxiom ikke støtter owl:datatypeproperty p.g.a. avgjørbarhet ("decidabiblity 58 "), så ble løsningen å kombinere OWL + Rules: Mappinger: <dwperson> rdfs:subclassof <Person>. <dwperson#personid> rdfs:subpropertyof <II#root>. IF And(rdf:type(?x <Entity>) rdf:type(?x <II>)) Then Entity#id(?x?x) Eksempel: _:person <dwperson#personid> 123. => _:person rdf:type <Person>. _:person <II#root> 123. _:person rdf:type <II>. _:person <Entity#id> _:person. (by rule) MAPPING #1.2: OPENEHR ->ENTITY.ID Fra openehr: <OBJECT_ID> rdf:type owl:class. <OBJECT_ID#value> rdf:type owl:datatypeproperty; rdfs:domain <OBJECT_ID>. <OBJECT_REF> rdf:type owl:class. <OBJECT_REF#id> rdf:type owl:objectproperty; rdfs:domain <OBJECT_REF>; rdfs:range <OBJECT_ID>. <PARTY_REF> rdfs:subclassof <OBJECT_REF>. <PARTY_PROXY> rdf:type owl:class. <PARTY_PROXY#external_ref> rdf:type owl:objectproperty; rdfs:domain <PARTY_PROXY>; rdfs:range <PARTY_REF>. <PARTY_SELF> rdfs:subclassof <PARTY_PROXY>. Til HL7 vmr: <Entity> rdf:type owl:class. <Entity#id> rdf:type owl:objectproperty; rdfs:domain <Entity>; rdfs:range <II>. <II> rdfs:subclassof <ANY>. <II#root> rdf:type owl:datatypeproperty; rdfs:domain <II>. Mappinger:

82 <urn:/openehr#party_proxy> rdfs:subclassof <Entity>. <OBJECT_ID#value> rdfs:subpropertyof <II#root>. _:IDRef owl:propertychainaxiom (<PARTY_PROXY#external_ref> <OBJECT_REF#id>). _:IDRef rdfs:subpropertyof <Entity#id>. Eksempel: _:person rdf:type <PARTY_SELF>; <PARTY_PROXY#external_ref> [rdf:type <PARTY_REF>; <OBJECT_REF#id> dips:patient_ _id ]. _:person_id rdf:type <OBJECT_ID>; <OBJECT_ID#value> " ". => _:person rdf:type <Entity>. _:person <Entity#id> _:person_id. _:person_id rdf:type <II>. _:person_id <II#root> MAPPING #2.1: DIPS -> EVALUATEDPERSON.BIRTHTIME Fra DIPS: <DB/dwperson#foedselsdato> rdf:type owl:datatypeproperty; rdfs:domain <DB/dwperson>. Til HL7 vmr: <EvaluatedPerson#birthTime> rdf:type owl:datatypeproperty; rdfs:domain <EvaluatedPerson>. Mappinger: <DB/dwperson#foedselsdato> rdfs:subpropertyof <EvaluatedPerson#birthTime>. Eksempel: _:person <dwperson#foedselsdato> 11/03/00. => _:person rdf:type <dwperson>. _:person <EvaluatedPerson#birthTime> 11/03/00. _:person rdf:type <EvaluatedPerson> MAPPING #2.2: DIPS -> EVALUATEDPERSON.AGE Alder kan regnes ut vha. fødselsdato. Det er ikke mulig å lage OWL eller regler som involverer kalkuleringer. Det medførte at denne kalkuleringen måtte gjøres i C# kode i SEHIA EHR Server: DateTime birthtime = DateTime.Parse(vmrModel.getProperty(anonymousPatientResource, birthproperty).getstring()); int age = DateTime.Today.Year - birthtime.year; if (birthtime.date > DateTime.Today.AddYears(-age)) age--; vmrmodel.add(vmrmodel.createstatement(anonymouspatientresource, ageproperty,anonymouspatientresource)); vmrmodel.add(vmrmodel.createliteralstatement(anonymouspatientresource,vmrmodel.createproperty(" urn:/hl7vmr/pq#value"), age)); vmrmodel.add(vmrmodel.createstatement(anonymouspatientresource,vmrmodel.createproperty("urn:/hl 7vmr/PQ#unit"), "år","no")); vmrmodel.add(vmrmodel.createstatement(anonymouspatientresource,vmrmodel.createproperty("urn:/hl 7vmr/PQ#unit"), "year(s)", "en")); MAPPING #2.3: DIPS -> EVALUATEDPERSON.CLINICALSTATEMENT 80

83 Fra DIPS: <dwperson> rdf:type owl:class. <dwrekvisisjon#ref-personid> rdf:type owl:objectproperty; rdfs:domain <dwrekvisisjon>; rdfs:range <dwperson>. <dwundersokelse> rdf:type owl:class. <dwundersokelse#ref-rekvisisjonid> rdf:type owl:objectproperty; rdfs:domain <dwundersokelse>; rdfs:range <dwrekvisisjon>. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <EvaluatedPerson> rdfs:subclassof <Person>. <EvaluatedPerson#clinicalStatement> rdf:type owl:objectproperty; rdfs:domain <EvaluatedPerson>; rdfs:range <ClinicalStatement>. Mappinger: <dwundersokelse#ref-personid> owl:propertychainaxiom (<dwundersokelse#ref-rekvisisjonid> <dwrekvisisjon#ref-personid>). <dwundersokelse#ref-personid> owl:inverseof [rdfs:subpropertyof < EvaluatedPerson#clinicalStatement>]. Eksempel: _:person rdf:type <dwperson>. _:rekvisisjon <dwrekvisisjon#ref-personid> _:person _:undersokelse <dwundersokelse#ref-rekvisisjonid> _:rekvisisjon => _:rekvisisjon rdf:type <dwrekvisisjon>. _:undersokelse rdf:type <dwundersokelse>. _:undersokelse <dwundersokelse#ref-personid> _:person. _:person <EvaluatedPerson#clinicalStatement> _:undersokelse NAVIGERING I OPENEHR HIERARKISKE STRUKTURER openehr journaldokumenter (COMPOSITIONS) er hierarkiske strukturer som egner seg til XML-serialisering. Representert som RDF/OWL vil et journaldokument være en DAG ("directed acyclic graph"). Figur 38 og Figur 39 i appendiks viser den hierarkiske strukturen i et journaldokument. En av utfordringene i en slik struktur er at den er så fleksibel, og kan ha rekursive strukturer som gi en vilkårlig dybde i XML-treet. F.eks. kan en seksjon (SECTION) inneholde, underseksjoner, under-underseksjoner, og tilslutt et klinisk uttrykk i kategorien observasjon, evaluering, forordning eller tiltak (ENTRY subtyper). Ved mapping til HL7 vmr ObservationResult så er det behov for å plukke informasjon fra ulike nivåer i denne strukturen. F.eks. vil HL7 vmr ObservationResult.ObservationEventTime hentes fra en POINT_EVENT klasse som ligger et vilkårlig antall nivåer over ELEMENT klassen hvor HL7 vmr ObservationResult.ObservationEventTime hentes fra. I XML er det relativt enkelt å navigere seg opp og ned i treet ved hjelp av XPath, mens i RDF ble løsningen å innføre «super properties» for XML parent/child elementstrukturen som binder sammen nodene i hierarkiet sammen i et journaldokument: SEHIA:ChildArchetype, SEHIA:parentArchetype, SEHIA:descendantArchetype og SEHIA:ancestorArchetype. Disse ble definert slik: # # childarchetype som super property for alle properties som binder sammen dokumenthierarkiet <content> rdfs:subpropertyof <childarchetype>. <protocol> rdfs:subpropertyof <childarchetype>. <data> rdfs:subpropertyof <childarchetype>. 81

84 <events> rdfs:subpropertyof <childarchetype>. <items> rdfs:subpropertyof <childarchetype>. <state> rdfs:subpropertyof <childarchetype>. <activities> rdfs:subpropertyof <childarchetype>. <ism_transition> rdfs:subpropertyof <childarchetype>. <description> rdfs:subpropertyof <childarchetype>. <instruction_details> rdfs:subpropertyof<childarchetype>. # # binde sammen en hvilken som helst node i hierarkiet med alle subnoder (child, child-child, osv.) <childarchetype> rdfs:subpropertyof <descendantarchetype>. <descendantarchetype> rdf:type owl:objectproperty; rdf:type owl:transitiveproperty. # # Inverse slik at subnoder kan referere noder lenger oppe i hierarkiet. <parentarchetype> owl:inverseof <childarchetype>. <ancestorarchetype> owl:inverseof <descendantarchetype> MAPPING #2.4: OPENEHR-> EVALUATEDPERSON.CLINICALSTATEMENT Fra openehr: <ELEMENT> rdfs:subclassof <ITEM>. <ENTRY> rdfs:subclassof <CONTENT_ITEM>. <ENTRY#subject> owl:objectproperty; rdfs:domain <ENTRY>; rdfs:range <PARTY_PROXY>. <CARE_ENTRY> rdfs:subclassof <ENTRY>. <OBSERVATION> rdfs:subclassof <CARE_ENTRY>. <ELEMENT> SEHIA:ancestorArchetype <OBSERVATION>. # by inference Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <EvaluatedPerson> rdfs:subclassof <Person>. <EvaluatedPerson#clinicalStatement> rdf:type owl:objectproperty; rdfs:domain <EvaluatedPerson>; rdfs:range <ClinicalStatement>. Mappinger: IF And(rdf:type(?x <ELEMENT>) ancestorarchetype(?x?y) subject(?y?z)) Then subjectclinstmt(?x?z) subjectclinstmt owl:inverseof [rdfs:subpropertyof <EvaluatedPerson#clinicalStatement>]. Eksempel: _:clistatement rdf:type <ELEMENT>. _:clistatement ancestorarchetype _:observation. _:observation ENTRY#subject _:person. => _:clistatement <subjectclinstmt> _:person. _:person <EvaluatedPerson#clinicalStatement> _:clistatement. 82

85 9.6.9 MAPPING #3.1: DIPS -> OBSERVATIONBASE.OBSERVATIONFOCUS Fra DIPS: <dwundersokelse> rdf:type owl:class. <dwundersokelse#ref-undersokelseskodeid> rdf:type owl:objectproperty; rdfs:domain <dwundersokelse>; rdfs:range <dwundersokelseskoder>. <dwundersokelseskoder> rdf:type owl:class. <dwundersokelseskoder#ref-neklabkode> rdf:type owl:objectproperty; rdfs:domain <dwundersokelseskoder>; rdfs:range <NEKLAB>. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationBase#ObservationFocus> rdf:type owl:objectproperty; rdfs:domain <ObservationBase>; rdfs:range <CD>. Mappinger: DipsObservationFocus owl:propertychainaxiom (<urn:/dips/db/dwundersokelse#refundersokelseskodeid> <urn:/dips/db/dwundersokelseskoder#ref-neklabkode>). DipsObservationFocus rdfs:subpropertyof <ObservationBase#ObservationFocus>. Eksempel: _:undersokelse rdf:type <dwundersokelse>. _:undersokelse <dwundersokelse#ref-undersokelseskodeid> _:undersokelseskode. _:undersokelseskode <dwundersokelseskoder#ref-neklabkode> _:NEKLABkode => _:undersokelse <DipsObservationFocus> _:NEKLABkode. _:undersokelse <ObservationBase#ObservationFocus> _:NEKLABkode. _:NEKLABkode rdf:type CD MAPPING #3.2: OPENEHR -> OBSERVATIONBASE.OBSERVATIONFOCUS ObservationFocus skal innholde URI til en term fra en anerkjent terminologi. For å finne systolisk og diastolisk blodtrykk finnes hhv. SNOMED CT kodene og Som URI hhv. <urn:/snomed- CT(2003)# > og <urn:/snomed-ct(2003)# >. En HL7 ObservationBase er registrerte verdier for kliniske variabler i journalen representert med openehr <ELEMENT>er, f.eks. systolisk blodtrykk, diastolisk blodtrykk, vekt, høyde osv. Hver openehr <ELEMENT> har en archetype_node_id attributt (property) som refererer til arketypedefinisjoner for elementet, f.eks. målenheter, lovlig verdiområde, terminologibinding, etc. Representert som RDF blir slike indirekte referanser supplert med direkte referanser ved hjelp av URIer (se 8.2.2) ved innlasting til SEHIA RDF Store. For å forenkle ytterligere ble en ny klasse innført SEHIA:CONCEPT for å gjøre mappingen enklere. Denne er ikke nødvendig for å få mappingen til å fungere, men gjør koden mer lesbar. Eksempel: 83

86 Systolisk blodtrykk registrert i EPJ _:OBSERVATION_ELEMENT rdf:type :ELEMENT; :archetype_node_id "at0004"; shia:concepturi <urn:/openehr-ehr-observation.blood_pressure.v1/at0004>; :name [:value "Systolic"]; :value [rdf:type :DV_QUANTITY; :magnitude "176"^^xsd:decimal; :units "mm[hg]"]. Arketype node URI Arketype terminologibinding <urn:/openehr-ehr-observation.blood_pressure.v1/at0004> rdf:type shia:concept; :code "at0004"; shia:text "Systolisk"@no; shia:text "Systolic"@en; Term oversatt til forskjellige språk shia:description "Peak systemic arterial blood pressure - measured in systolic or contraction phase of the heart cycle."@en; shia:terminology_binding <urn:/snomed-ct(2003)# >. Binding til terminologisystem Figur 27 viser en eksempelregistrering av systolisk blodtrykk i EPJ med referanse (SEHIA:conceptURI) til arketypebegrepet (SEHIA:CONCEPT) hvor både oversettelser til ulike språk og terminologibinding gjøres (her: SNOMED CT). SEHIA:CONCEPT er utledet fra openehr arketypemodellen som en forenkling av opprinnelig struktur som er mer komplisert. Fra openehr: :LOCATABLE rdf:type owl:class. :ITEM rdfs:subclassof :LOCATABLE. :ELEMENT rdfs:subclassof :ITEM. :CONTENT_ITEM rdfs:subclassof :LOCATABLE. :ENTRY rdfs:subclassof :CONTENT_ITEM. :CARE_ENTRY rdfs:subclassof :ENTRY. :OBSERVATION rdfs:subclassof :CARE_ENTRY. :EVENT rdfs:subclassof :LOCATABLE. SEHIA:CONCEPT rdf:type owl:class. SEHIA:CONCEPT#terminology_binding rdf:type owl:objectproperty; rdfs:domain SEHIA:CONCEPT. SEHIA:conceptURI rdf:type owl:objectproperty; rdfs:range SEHIA:CONCEPT. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationBase#ObservationFocus> rdf:type owl:objectproperty; rdfs:domain <ObservationBase>; rdfs:range <CD>. 84

87 Mappinger: SEHIA:Observation owl:intersectionof (<ELEMENT> [a owl:restriction; owl:onproperty ancestorarchetype; owl:somevaluesfrom <OBSERVATION>] [a owl:restriction; owl:onproperty ancestorarchetype; owl:somevaluesfrom <EVENT>]). SEHIA:Observation rdfs:subclassof <ObservationResult>. IF And(rdf:type(?a SEHIA:Observation) SEHIA:conceptURI(?a?b) SEHIA:terminology_binding(?b?c)) Then ObservationBase#ObservationFocus(?a?c) Eksempel: _:DetailedObservation rdf:type <ELEMENT>. _:DetailedObservation ancestorarchetype _:Observation. _:Observation rdf:type <OBSERVATION>. _:DetailedObservation ancestorarchetype _:Event. _:Event rdf:type <EVENT>. _:DetailedObservation SEHIA:conceptURI _:aconcept. _:aconcept SEHIA:terminology_binding _:termbinding. => _:DetailedObservation rdf:type SEHIA:Observation. _:DetailedObservation <ObservationBase#ObservationFocus> _:termbinding. _:termbinding rdf:type CD MAPPING #4.1: DIPS -> OBSERVATIONRESULT. OBSERVATIONEVENTTIME Fra DIPS <DB/dwundersokelse> rdf:type owl:class. <DB/dwundersokelse#utforttid> rdf:type owl:datatypeproperty; rdfs:domain <DB/dwundersokelse>; <DB/dwundersokelse#ref-undersokelsesstatus> rdf:type owl:objectproperty; rdfs:domain <DB/dwundersokelse>; rdfs:range <DB/dwkodeverkverdier>. <DB/dwkodeverkverdier> rdf:type owl:class. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationResult> rdfs:subclassof <ObservationBase>. <ObservationResult#observationEventTime> rdf:type owl:objectproperty; rdfs:domain <ObservationResult>; rdfs:range <IVL_TS>. <IVL_TS> rdf:type owl:class. <IVL_TS#low> rdf:type owl:datatypeproperty; # TS datatype simplified rdfs:domain <IVL_TS>. <IVL_TS#high> rdf:type owl:datatypeproperty; # TS datatype simplified rdfs:domain <IVL_TS>. Mappinger: # Alle undersokelser som det er mottatt et provesvar paa, "Svar mottatt" (107502) [a owl:restriction; owl:onproperty <dwundersokelse#ref-undersokelsesstatus>; owl:hasvalue <dwkodeverkverdier/kodeid=107502> ] rdfs:subclassof <ObservationResult>. 85

88 <dwundersokelse#utforttid> rdfs:subpropertyof <IVL_TS#low>. <dwundersokelse#utforttid> rdfs:subpropertyof <IVL_TS#high>. IF And(rdf:type(?x <dwundersokelse>) dwundersokelse#ref-rekvisisjonid(?x?y) dwrekvisisjon#utforttid(?y?z)) Then dwundersokelse#utforttid(?x?z). IF And(rdf:type(?x <ObservationResult>) rdf:type(?x <IVL_TS>)) Then ObservationResult#observationEventTime(?x?x). Eksempel: _:u rdf:type <dwundersokelse>; <dwundersokelse#ref-undersokelsesstatus> <dwkodeverkverdier/kodeid=107502>; <dwundersokelse#ref-rekvisisjonid> _:r. _:r rdf:type <DB/dwrekvisisjon>; <dwrekvisisjon#utforttid> " T18:00:00"^^xsd:dateTime. => _:u rdf:type <ObservationResult>. _:u <dwundersokelse#utforttid> " T18:00:00"^^xsd:dateTime. _:u ObservationResult#observationEventTime _:u. _:u rdf:type <IVL_TS>. _:u <IVL_TS#low> " T18:00:00"^^xsd:dateTime. _:u <IVL_TS#high> " T18:00:00"^^xsd:dateTime MAPPING #4.2: OPENEHR -> OBSERVATIONRESULT. OBSERVATIONEVENTTIME Fra openehr DV_DATE_TIME rdfs:subclassof DV_TEMPORAL. DV_DATE_TIME#value rdf:type owl:datatypeproperty; rdfs:domain DV_DATE_TIME. POINT_EVENT rdfs:subclassof EVENT. POINT_EVENT#time rdf:type owl:objectproperty; rdfs:domain POINT_EVENT; rdfs:range DV_DATE_TIME. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationResult> rdfs:subclassof <ObservationBase>. <ObservationResult#observationEventTime> rdf:type owl:objectproperty; rdfs:domain <ObservationResult>; rdfs:range <IVL_TS>. <IVL_TS> rdf:type owl:class. <IVL_TS#low> rdf:type owl:datatypeproperty; # TS datatype simplified rdfs:domain <IVL_TS>. <IVL_TS#high> rdf:type owl:datatypeproperty; # TS datatype simplified rdfs:domain <IVL_TS>. Mappinger: SEHIA:time rdf:type owl:objectproperty. <POINT_EVENT#time> rdfs:subpropertyof SEHIA:time. SEHIA:time owl:propertychainaxiom (ancestorarchetype <POINT_EVENT#time>). <DV_DATE_TIME#value> rdfs:subpropertyof <IVL_TS#low>. 86

89 <DV_DATE_TIME#value> rdfs:subpropertyof <IVL_TS#high>. IF And(rdf:type(?x <ObservationResult>) SEHIA:time(?x?y)) Then ObservationResult#observationEventTime(?x?y). Eksempel: _:DetailedObservation rdf:type SEHIA:Observation. # Fra mapping #3.2 (kap ). _:ts rdf:type DV_DATE_TIME; value " T18:00:00"^^xsd:dateTime. _:pv rdf:type <POINT_EVENT>. _:pv <POINT_EVENT#time> _:ts. _:DetailedObservation ancestorarchetype _:pv. # Se kapittel => _:ts rdf:type <IVL_TS>. _:ts <IVL#low> " T18:00:00"^^xsd:dateTime. _:ts <IVL#high> " T18:00:00"^^xsd:dateTime. _:pv SEHIA:time _:ts. _:DetailedObservation SEHIA:time _:ts. _:DetailedObservation <ObservationResult#observationEventTime> _:ts MAPPING #5.1: DIPS -> OBSERVATIONRESULT.OBSERVATIONVALUE Fra DIPS <DB/dwundersokelse> rdf:type owl:class. <DB/dwundersokelse#tekstsvar> rdf:type owl:datatypeproperty; rdfs:domain <DB/dwundersokelse>. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationResult> rdfs:subclassof <ObservationBase>. <ObservationResult#observationValue> rdf:type rdf:property; rdfs:domain <ObservationResult>. Mappinger: IF And(rdf:type(?x <ObservationResult>) dwundersokelse#tekstsvar(?x?y)) Then ObservationResult#observationValue(?x?y). Eksempel: _:u rdf:type <dwundersokelse>; <dwundersokelse#tekstsvar> «2,9». _:u rdf:type <ObservationResult>. # Fra mapping #4.1 (kapittel ). => _:u < ObservationResult#observationValue> «2,9» MAPPING #5.2: OPENEHR -> OBSERVATIONRESULT.OBSERVATIONVALUE. Fra openehr <ELEMENT> rdfs:subclassof <ITEM>. <ELEMENT#value> rdf:type owl:objectproperty; rdfs:domain <ELEMENT>; rdfs:range <DATA_VALUE>. 87

90 <DATA_VALUE> rdf:type owl:class. <DV_ORDERED> rdfs:subclassof <DATA_VALUE>. <DV_QUANTIFIED> rdfs:subclassof <DV_ORDERED>. <DV_AMOUNT> rdfs:subclassof <DV_QUANTIFIED>. <DV_QUANTITY rdfs:subclassof <DV_AMOUNT>. <DV_QUANTITY#magnitude> rdf:type owl:datatypeproperty; rdfs:domain <DV_QUANTITY>. Til HL7 vmr: <ClinicalStatement> rdf:type owl:class. <ObservationBase> rdfs:subclassof <ClinicalStatement>. <ObservationResult> rdfs:subclassof <ObservationBase>. <ObservationResult#observationValue> rdf:type rdf:property; rdfs:domain <ObservationResult>. Mappinger: SEHIA:Observation owl:intersectionof (<ELEMENT> [a owl:restriction; owl:onproperty ancestorarchetype; owl:somevaluesfrom <OBSERVATION>] [a owl:restriction; owl:onproperty ancestorarchetype; owl:somevaluesfrom <EVENT>]). SEHIA:Observation rdfs:subclassof <ObservationResult>. # Se mapping #3.2 kapittel SEHIA:elementValue rdf:type owl:datatypeproperty. <DV_QUANTITY#magnitude> rdfs:subpropertyof SEHIA:elementValue. IF And(rdf:type(?x SEHIA:Observation) ELEMENT#value(?x?y) SEHIA:elementValue(?y?z) ) Then ObservationResult#observationValue(?x?z). Eksempel: _:o rdf:type <ELEMENT> _:o rdf:type SEHIA:Observation; _:o <ELEMENT#value> _:ev1. _:ev1 rdf:type <DV_QUANTITY>. _:ev1 <DV_QUANTITY#magnitude> «72,5». => _:o <ObservationResult#observationValue> «72,5» MAPPING MELLOM TERMINOLOGIER Modellen ble beskrevet i kapittel Hovedprinsippet er at det opprettes et «klassenivå» med én klasse for hver kode som benyttes. På klassenivået etableres hierarkier vha. subclassof og termmappinger vha. equivalentclass. Test case 4 demonstrerte mapping mellom tilsvarende termer fra to forskjellige terminologier hvor anbefalingen ble kodet med LDL kolesterol LOINC kode LP , mens i EPJ-systemet var den samme analysen kodet med NEKLAB NPU Mappingen ble definert på «klassenivå» slik: <urn:/helsedir/neklab/npu01568/class> owl:equivalentclass < Spørringer med LOINC koden LP returnerer registrerte analyser med koden NPU Test case 5 demonstrerer spørringer vha. klassifikasjonshierarkier («subsumption») hvor annotering ble gjort i retningslinjen med overordnet LOINC term for kolesterol (LP ), mens i EPJ-systemet var den samme 88

91 analysen kodet med NEKLAB NPU Sammen med termmappingen ovenfor (equivalentclass), så er det behov for å definere klassehierarkiet: < rdfs:subclassof < SAMMENSATTE BEGREPER Et problem som jeg kom over var dette med sammensatte begreper. I retningslinjen for blodtrykkssenkende behandling står følgende «hos pasienter med BT < 140 / 90 mmhg». Det finnes en overordnet kode for blodtrykk i SNOMED-CT: «(On examination - blood pressure reading (finding))» som er nærliggende å benytte for annotering. I SEHIA Store lagres blodtrykk som arketypen «blood pressure» (se Figur 40 i appendiks 14.2). En blodtrykksmåling er kompleks struktur sammensatt av både systolisk og diastoliske enkeltmålinger. I openehr rammeverket brukes såkalte «templates» for å lage ulike presentasjoner med subsett av attributtene (her: systolisk og diastolisk) som er relevante for registrering og presentasjon (her: blodtrykk) i brukergrensesnitt. I OWL eller RIF er det ingen funksjoner som kan konkatenere «dataproperties» til sammensatte uttrykk. En løsning er å kreve at annoteringene i retningslinjen blir gjort med atomiske begreper, dvs. enkeltmålingene. For blodtrykk betyr det annotering av systolisk (SNOMED CT 2003: ) og diastolisk blodtrykk (SNOMED CT 2003: ) som to separate uttrykk. En ulempe er dobbelt så mye annotering (to uttrykk i stedet for ett), men også at systolisk og diastolisk blodtrykk ble presentert uavhengig av hverandre: «systolisk blodtrykk: 176 mmhg (12/08-10); diastolisk blodtrykk: 90 mmhg (12/08-10)» i stedet for den enklere sammensatte formen «blodtrykk 176/90 mmhg (12/08-10)». Løsningen i POCen er en spørring på overordnede termer i klassifikasjonshierarki («subsumption») som beskrevet i kapittel I dette tilfellet er det en «isa» (subclass) relasjon i SNOMED CT mellom systolisk/diastolisk blodtrykk og et blodtrykk generelt. Dersom man kun annoterer med blodtrykk (SNOMED CT 2003: ), så vil både systolisk og diastolisk hentes fram. Selv om dette gjør annoteringen mer fleksibelt, så vil likevel presentasjon fremdeles to adskilte målinger ULIK GRANULARITET I KILDESKJEMA OG MÅLSKJEMA Den observante leser har kanskje oppdaget at datatypene til HL7 attributtene ObservationValue : string og birthtime: datetime ikke er korrekte. Det skulle vært ObservationValue : ANY og birthtime: TS som er komplekse datatyper på linje med II, IVL_TS, CD og PQ. Når det gjelder birthtime kunne dette vært løst på samme måte som for II og IVL_TS. Så det vil ikke bidra med noen ny kunnskap. Når det gjelder ANY, så er det en annen sak. ANY er en abstrakt datatype som kan være en av de andre konkrete HL7 datatypene (PQ, TS, CD, II, osv.) runtime («late binding»). De andre datatypene er subklasser av ANY. Datatypene har forskjellige attributter. For SEHIA så er det 3 informasjonselementer som trengs for hvert klinisk uttrykk (labanalyse, blodtrykksmåling, operasjonsprosedyre, legemiddelforskriving, osv.) 1. Dato og tid (eller tidsintervall) som forteller noe når noe skjedde, skjer eller skal skje (hvis relevant) 2. Visningsnavn som er ledeteksten («LDL», «Diastolisk blodtrykk», «Vekt», «TAB00 (NCMP/SP)», «I10 (ICD10)», osv.) 3. Visningstekst som er det som presenteres i skjermbildet til brukeren («2,9 mmol/l», «76 mmhg», «72,5 kg», «Lumbalpunksjon» (NCMP/-SP), «Essensiell (primær) hypertensjon» (ICD10).) 89

92 Det er altså ikke behov for å mappe alle HL7 vmr datatypene med alle sine attributter til rette datatyper. Derfor ble datamodellen forenklet noe i SEHIA POC hvor 1) er attributten ObservationEventTime, 2) ObservationFocus og 3) ObservationValue. Men vil være andre attributter som for problemer, prosedyrer, legemiddelforskrivninger, osv. Et eksempel på et problem er mapping av «2,9 mmol/l» til visningstekst fordi kildedatabasene lagrer verdien «2,9» separat fra måleenheten «mmol/l». Det er altså veldig forskjellig fra datakilde til datakilde hvordan mapping til visningsnavn og visningstekst skal være. Ofte er det en kombinasjon av attributter som utgjør den endelige mappingen. Det er derfor ikke nok med noen enkle "subpropertyof" for å etablere et abstraksjonslag på toppen. Strengene må bygges opp av vha. av og tilbys som metoder på ANY datatypen analogt med tostring() på.net/java Object datatypene. Løsningen i SEHIA POC var å splitte visningstekst opp i «Visningsverdi» og «Måleenhet» fordi disse var mulig å mappe vha. «subproperty»- aksiomer, men dette er ikke en god løsning. 9.7 IMPLEMENTASJON AV SEHIA EHR SERVER Implementasjonen ble gjort i.net med Apache Jena RDF biblioteket konvertert til en.net assembly ved hjelp av IKVM.Net. SEHIA EHR Server tar i mot en digital retningslinjer som Lenkede Data (RDF) eller URL til hvor RDF kan lastes ned fra og pasientid som input og henter pasientinfo basert på annoteringene gjort i retningslinjen. Tilslutt returneres pasientinfo til SEHIA Guideline Controller (GL CTL). Steg for å generere output: 1) Last ned digital retningslinje som RDF fil fra angitt URL adresse (hvis ikke RDF kommer som input). 2) Parse digital retningslinje RDF-fil til en RDF graf i Jena biblioteket 3) Spør SEHIA RDF Store etter pasientopplysninger som er annotert i digital retningslinje RDF-fil 4) Generer pasientopplysninger som returneres til SEHIA GL CTL Det er 3) som er kjernen i SEHIA EHR Server. Utfordringen var å traversere alle nodene i den digitale retningslinjen og for hver node som annoterte en klinisk variabel, gjøre en spørring til SEHIA RDF Store etter pasientopplysningene. Utdrag av kode som viser traversering: Resource RecommendationResource = guidelinemodel.createresource(" Property hasclinicalstatementinputspecificationproperty = guidelinemodel.createproperty(" Property requiredclinicalstatementclassproperty = guidelinemodel.createproperty("urn:/hl7vmr/requiredclinicalstatementclass"); Property hascodedattributerequirementproperty = guidelinemodel.createproperty("urn:/hl7vmr/hascodedattributerequirement"); Property hastargetcodedattributeproperty = guidelinemodel.createproperty("urn:/hl7vmr/hastargetcodedattribute"); Property hastargetcodeproperty = guidelinemodel.createproperty("urn:/hl7vmr/hastargetcode"); Property haspatientinputspecification = guidelinemodel.createproperty(" Property requiredevaluatedpersonattribute = guidelinemodel.createproperty("urn:/hl7vmr/evaluatedpersoninputspecification#requiredevaluatedpersonattrib ute"); ResIterator recommendationiterator = guidelinemodel.listresourceswithproperty(rdf.type, RecommendationResource); while (recommendationiterator.hasnext()) // ns1:recommendation iterator #1 { Resource recommendationresource = recommendationiterator.nextresource(); StmtIterator hasclinicalstatementinputspecificationiterator = recommendationresource.listproperties(hasclinicalstatementinputspecificationproperty); 90

93 while (hasclinicalstatementinputspecificationiterator.hasnext()) // #3 { Resource ClinicalStatementInputSpecificationResource = hasclinicalstatementinputspecificationiterator.nextstatement().getresource(); Resource requiredclinicalstatementclassresource = ClinicalStatementInputSpecificationResource.getPropertyResourceValue(requiredClinicalStatementClassPropert y); // #4 StmtIterator hascodedattributerequirementiterator = ClinicalStatementInputSpecificationResource.listProperties(hasCodedAttributeRequirementProperty); while (hascodedattributerequirementiterator.hasnext()) // hascodedattributerequirement #5 { Resource CodedAttributeRequirementResource = hascodedattributerequirementiterator.nextstatement().getresource(); Resource TargetCodedAttribute = CodedAttributeRequirementResource.getPropertyResourceValue(hasTargetCodedAttributeProperty); // #7 StmtIterator hastargetcodeiterator = CodedAttributeRequirementResource.listProperties(hasTargetCodeProperty); while (hastargetcodeiterator.hasnext()) // CD - iterator - OR // #6 { Resource CD = hastargetcodeiterator.nextstatement().getresource(); buildclinicalstmtvmrmodel(vmrmodel, patientid, requiredclinicalstatementclassresource.geturi(), TargetCodedAttribute.getURI(), CD.getURI()); } // while iterator hastargetcodeiterator.close(); } // while iterator hascodedattributerequirementiterator.close(); } // while iterator hasclinicalstatementinputspecificationiterator.close(); } // while recommendationiterator recommendationiterator.close(); guidelinemodel.add(vmrmodel); // Merge models En av utfordringene var selvsagt å huske hvordan RDF-grafen var for å kunne navigere riktig. Det var nødvendig å tegne RDF-grafen på papir som hjelp for å få dette rett. Siden det ikke var verktøystøtte med autocompletion 59, så var det også lett å skrive feil URIer til ressurser. Det ble også relativt lange setninger (statements) som gjorde koden litt vanskelig å lese. Grønnmarkert kodelinje gjør selve «sammensmeltingen» av journalopplysningene som ble funnet og den digitale retningslinjen. Gulmarkert kodelinje er metoden som utfører selve spørringen i SHA RDF Store basert på pasientid, om det er en observasjon, en legemiddelforskriving, en diagnose/problem en prosedyre (se HL7 vmr klassene i Figur 37 Virtual Medical Record (vmr) - Del 2 i appendiks 14.1) og term fra terminologi (SNOMED, NEKLAB, etc.). Utdrag av koden nedenfor: switch (requiredclinicalstatementclassurifilter) { case "urn:/hl7vmr/observationresult": CliStmtConstructBlock = HL7vmr_ObservationResultConstruct; CliStmtWhereBlock = HL7vmr_ObservationResultWhere; break; default: throw new Exception("Programming error!");

94 } string CDTargetCodeFilterBlock = ""; string CDTargetCodeBlock = ""; if (TargetCodedAttributeFilter!= null) // Has target code filter { Debug.Assert(CDURIFilter!= null); } CDTargetCodeBlock = "?clinicalstmt_uri <" + TargetCodedAttributeFilter + ">?CD_URI. \n" + HL7vmr_CDConstructAndWhere; CDTargetCodeFilterBlock = "<" + CDURIFilter + "> rdf:type?cdclass. \n" + "?clinicalstmt_uri rdf:type?cdclass. \n" + "filter(lang(?cd_displayname)=\"no\").\n"; string sparql = "PREFIX rdf: < + "prefix : <urn:/dips/db/> \n" + "prefix hl7: <urn:/hl7vmr/> \n" + "prefix owl: < \n" + "construct { \n" + "<urn:/local/vmr/anonymouspatient> <urn:/hl7vmr/evaluatedperson#clinicalstatement>?clinicalstmt_uri. \n" + CliStmtConstructBlock + CDTargetCodeBlock + "}\n" + "where {\n" + HL7vmr_EvaluatedPersonWhere + "?evaluatedpersonuri <urn:/hl7vmr/evaluatedperson#clinicalstatement>?clinicalstmt_uri. \n" + CliStmtWhereBlock + CDTargetCodeBlock + CDTargetCodeFilterBlock + "filter (str(?ii_root)=\"" + patientidfilter + "\"). \n" + "} \n"; Utfordringene her er å bygge riktig SPARQL streng for å spørre SEHIA Store. Syntaksfeil er greit, det gir feilmelding. Stavefeil og feil med store/små bokstaver for URIer og attributter resulterer ikke i feilmelding som i SQL, men at resultatsettet heller blir tomt. Dette er en konsekvens av semantisk weben sin «open world assumption» (OWA) 60 [49] hvor RDF query engine i Oracle ikke validerer spørringen mot et skjema. En SQL spørring i en relasjonsdatabase praktiserer «closed world assumption» (CWA) 61 noe som medfører valideringsfeil dersom spørringen innholder termer som ikke finnes i databaseskjemaet. Etter at denne prosesseringen er ferdig er RDF-grafen, som i utgangspunktet bare inneholdt retningslinjen, nå utvidet med noder og attributter med journalopplysninger. Før opplysningene kan returneres til SEHIA GL CTL, ble opplysningene hentet ut av RDF grafen og konvertert til vanlig objekter i XML serialiseringsformat støttet av plattformen («out-of-the box»). Dette er et designvalg som ble gjort for at SEHIA GL CTL klienter skal bli så lette som mulig, og ikke kreve RDF biblioteker siden det kun var snakk om å hente ut data. Konvertering til vanlige serialiserbare objekter var noe mer arbeid enn forventet. Først ble det gjort en SPARQL SELECT spørring som genererte et datasett (tabell): sparql = "prefix : <urn:/sehia/> \n" + "prefix hl7vmr: <urn:/hl7vmr/> \n"

95 "prefix hbib: < \n" + "PREFIX rdf: < + "select distinct?idnode?hasdisplayname?hasdisplayvalue?hasdisplaytimestamp?codeuri?hasdisplayunit \n" + "where \n" + "{ \n" + "?recuri hbib:hasclinicalstatementinputspecification?cis. \n" + "?cis <urn:/hl7vmr/hascodedattributerequirement>?car. \n" + "?car <urn:/hl7vmr/hastargetcode>?codeurir. \n" + "?CodeURIR <urn:/sehia/hasresponsecd_uri>?codeuri. \n " + "?car <urn:/hl7vmr/hastargetcodedattribute>?tca. \n" + "?cis <urn:/hl7vmr/requiredclinicalstatementclass>?cliclassuri. \n" + "?idnode a?cliclassuri. \n" + "?idnode?tca?codeuri. \n" + "?idnode <urn:/hl7vmr/observationresult#observationeventtime>?event_time_uri. \n" + "?idnode <urn:/hl7vmr/observationresult#observationvalue>?hasdisplayvalue. \n" + "optional {?idnode <urn:/sehia/units>?hasdisplayunit.}. \n" + "?event_time_uri <urn:/hl7vmr/ivl_ts#low>?hasdisplaytimestamp. \n" + "?CodeURI <urn:/hl7vmr/cd#displayname>?hasdisplayname. \n" + "filter(lang(?hasdisplayname)=\"" + langfilter + "\") \n" + "}"; Deretter ble datasettet iterert for å bygge opp en liste av objekter iht. følgende klassedefinisjoner: [Serializable] public class PatientFact { public string Id { get; set; } public Uri CodeURI { get; set; } public string DisplayName { get; set; } public string DisplayValue { get; set; } public string DisplayUnit { get; set; } public DateTime? DisplayTimestamp { get; set; } } En fin egenskap med RDF-grafer er mulighetene for å støtte flere språk. Det er mulig å spesifisere språkkoden til en «data osv.). I SPARQL er det mulig å filtrere på språk ved hjelp av funksjonen lang se kodelinje markert i gult ovenfor. Denne muligheten er ikke støttet av XML direkte. Alternativt til å konvertere til vanlige objekter, er å benytte standard serialiseringsformat som RDF/XML i Jena. Skal dette gi gevinst, bør alle mottakere kunne operere på Lenkede Data/RDF direkte, ellers vil konverteringen måtte gjøres før eller senere. I POCen ble det utforsket muligheter for å implementere deler av SEHIA Guideline Controller (GL-CTL) i Javascript, men da må Lenkede Data/RDF støttes direkte av browsere/javascript-motorer eller så må RDF konverteres til vanlige JSON-objekter. Det finnes initiativer for å etablere JSON-LD 62 (JSON Lenkede Data) som beskriver hvordan RDF/Lenkede Data kan serialiseres som vanlige JSON-objekter. Dette krever tilsvarende støtte for serialisering av Jena RDF graf til JSON-LD 63. Det finnes open source prosjekter som har laget Jena JSON-LD adaptere. Dette ble ikke testet i POCen

96 9.8 IMPLEMENTASJON AV SEHIA GUIDELINE CONTROLLER (GL CTL) SEHIA GL CTL har som beskrevet i kapittel ansvaret for å synkronisere webbaserte retningslinjer (WGL-CMS) med aktiv pasient i EPJ systemet dvs. desktopsynkronisering. Det betyr å ta en retningslinje som presenteres i nettleser + en ID til aktivert pasient i EPJ arbeidsflaten, og be om relevante pasientopplysninger fra SEHIA EHR Server og presentere disse i skjermbildet. Hver gang en pasient byttes i EPJ eller ved visse hendelser i WGL-CMS nettleservindu (f.eks. navigasjon til ny retningslinje/anbefaling), vil SEHIA GL CTL foreta oppfriskning av relevante pasientopplysninger. I denne POCen er SEHIA GL CTL implementert i C# som en WPF 64 -kontroll og integrert i DIPS Arena EPJ demonstrasjonsklient (som er basert på samme teknologi som den virkelige DIPS Arena klienten). Visuelt sett består SEHIA GL CTL av et vindu som innholder et felt for relevante pasientopplysninger (kliniske variabler) og den integrerte nettleseren (her: Awesomium/Chromium/WebKit). Se figur nedenfor. EPJ-system SEHIA GL CTL komponent Relevante pasientopplysninger: Hb: 10.5 ( ) Plater: 230 ( ) Krea: 73 ( ) Blodtrykk: 176/90 mmhg Synkronisering Synkronisering Relevante kliniske variabler Integrert nettleser Figur 28 Skjermbilde som viser hvordan SEHIA GL CTL visuelt sett er integrert i EPJ-systemets arbeidsflate. SEHIA GL CTL må synkronisere innholdet basert på aktivert pasient i EPJ-systemet (her: Gul PENN), og basert på hvilken webbasert retningslinje som vises i den integrerte nettleseren. Nettleseren i SEHIA GL CTL er satt opp til å vises WGL-CMS webapplikasjonsklienten ( NGC, BestPractice, UpToDate, etc.)

97 SEHIA GL CTL kommuniserer med SEHIA EHR Server tjenesten når det er behov for å hente nye relevante pasientopplysninger fra pasientens journal. Hva som er relevante pasientopplysninger, er semantisk annotert («baket inn») i HTMLen i retningslinjene som RDFa (se kapittel 8.2.2). Siden SEHIA EHR Server kun kan operere på spørringer i form av lenkede data (RDF), må RDF ekstraheres («destilleres») fra HTML. Destilleringen kan enten gjøres av SEHIA GL CTL selv før RDF sendes til SEHIA EHR Server (se arbeidsflyt Figur 19), eller ved at sendes inn en URL til hvor SEHIA EHR Server kan laste ned en RDF utgave av retningslinjen (se arbeidsflyt Figur 18). I POCen ble sistnevnte metode valgt fordi det ikke fantes (i skrivende stund) et passende RDFa bibliotek for Java eller for.net. SEHIA GL CTL overvåker alle navigasjoner (HTTP GET) som gjøres i den integrerte nettleseren. For hver navigasjon må pasientkontekst oppdateres. SEHIA GL CTL snapper opp URLen til websiden det ble navigert til, og sender denne til SEHIA EHR Server sammen med ID til aktiv pasient i EPJ arbeidsflaten. SEHIA EHR Server bruker denne URLen og laster ned, ved hjelp av «content negotiation» (HTTP Header Accept: RDF/XML), en RDF utgave av den samme websiden som akkurat nå vises i nettleseren. 9.9 IMPLEMENTASJON AV WGL-CMS MOCKUP SEHIA krever i utgangspunktet ikke tilpasninger eller spesiell konfigurasjon av WGL-CMS systemer. Det eneste som kreves er at retningslinjen semantisk annoteres med RDFa for at integrasjon skal fungere. Det var meningen at POCen skulle lages slik, men som nevnt tidligere fantes det ingen god RDFa parser i Java (eller.net). Den eneste som ble funnet var pyrdfa på Python utviklingsplattformen. For å komme videre ble det derfor valgt å implementere RDFa parseren som en del av WGL-CMS webapplikasjon mockup slik som konfigurasjonen i Figur 18 i kapittel I en slik setting vil HTML-retningslinjer (webressurs) ha en adresse (URLer) som kan lastes ned til en nettleser på vanlig måte, men i tillegg kan samme retningslinje med den samme adressen (URLen) lastes ned i RDF-representasjon. For å støtte dette benyttes HTTP mekanismen «content negotiation» 65. F.eks. kan en nettleser hente en webside fra helsebiblioteket.no vha. HTTP GET: GET /retningslinjer/hjerneslag/sekundarforebygging/lipidsenkende-behandling HTTP/1.1 Host: Accept: text/html Tilsvarende kan SEHIA EHR Server benytte den samme URLen til å laste ned en RDF-utgave av retningslinjen GET /retningslinjer/hjerneslag/sekundarforebygging/lipidsenkende-behandling HTTP/1.1 Host: Accept: rdf/xml 65 RFC 2616 kapittel

98 10 ANALYSE OG EVALUERING 10.1 SEMANTISK ANNOTERING MED RDFA Semantisk annotering med RDFa i HTML-sider ble gjennomført i POCen nærmest problemfritt. Det eneste var manglende verktøystøtte. Siden destillering av RDF fra RDFa annoterte HTML sider krever et bibliotek som bare eksisterte på Python plattformen, gjorde at SEHIA POC benyttet det neste nivået av integrasjon hvor WGL-CMS server tilbyr alltid tilbyr RDF-versjon av HTML-basert retningslinje (jf. Figur 18 kapittel 8.4.2). WGL-CMS server mockup ble derfor implementert vha Django bibliotek i Python 2.7. Det ble imidlertid klart under gjennomføringen av POCen at forutsetningen om bruk av RDFa som en generell mekanisme for integrasjon mellom EPJ og WGL-CMS ikke var godt nok for alle typer WGL-CMS systemer. RDFa ideen hviler på forutsetning om at HTML-baserte retningslinjer er et dokument (en web resource) som en statisk webside som annoteres. Dette passer ikke for moderne websteder med dynamiske websider (Web 2.0) hvor innholdet ikke er knyttet til et spesielt dokument, men hentes opp som data (ofte i bakgrunnen) ved hjelp av Ajax/JavaScript. En webside er ikke lenger et dokument. Konsekvensen er at SEHIA modellen må utvides slik at integrasjon med WGL-CMS også må støtte Web 2.0 applikasjoner. I praksis betyr det et utvikling av et APIgrensesnitt (REST-basert). Lenkede Data bruker direkte referanser (URIer) til å koble sammen data fra ulike domener og datakilder analogt med peker i et dataprogram gjør det enklere å koble datamodeller og terminologier sammen. Eksempel fra kapittel 8.2.2: «targetcode i entiteten CodedAttributeRequirment. targetcode er av typen CD som betyr at targetcode bl.a. har Code og CodeSystem attributter hvor streng til kode og kodesystem fylles ut, f.eks. targetcode.code = «NPU01568» og targetcode.codesystem = «NEKLAB» for å referere til labtesten «P-LDL-kolest.» i NEKLAB. På semantisk web vil targetcode være URIen eks. <urn:/helsedir/neklab/npu01568> - som referere direkte til NEKLAB-registreringen.». Direkte referanser skiller data på den semantiske web en og vanlig datamodeller hvor det opereres med indirekte referanser som må slås opp i før oppslag i kodeverk kan gjøres. Å benytte direkte referanser ved annotering av retningslinjer gjør at dette forenkles. En annen utfordring var at RDFa annotering med HL7 vmr ble veldig mye tagging («verbose»). La oss ta eksempel på TURTLE representasjon av en cdsinputspecification for laboratoriemåling «LDL» fra kapittel 8.2.2: < a ns1:recommendation; ns1:hasclinicalstatementinputspecification [ a hl7vmr:clinicalstatementinputspecification; hl7vmr:hascodedattributerequirement [ a hl7vmr:codedattributerequirement; hl7vmr:hastargetcode <urn:/helsedir/neklab/npu01568>; hl7vmr:hastargetcodedattribute <urn:/hl7vmr/observationbase#observationfocus> ]; hl7vmr:requiredclinicalstatementclass hl7vmr:observationresult ]. En rad i HTML-tabellen for en retningslinje skal annoteres med RDFa som resulterer i listingen ovenfor: Før RDFa: <tr> <td> Behandlingsgrenser: Det finnes ingen klare behandlingsgrenser, men alle pasienter med hjerneinfarkt A 1a eller TIA med LDL >2,0 mmol/l bør tilbys statinbehandling hvis ikke kontraindisert. </td> <td>a</td> <td>1a</td> 96

99 </tr> Etter RDFa: <tr property="hasrecommendation" resource="recommendation2" typeof="recommendation"> <td> Behandlingsgrenser: Det finnes ingen klare behandlingsgrenser, men alle pasienter med hjerneinfarkt A 1a eller TIA med <span property="hasclinicalstatementinputspecification" typeof="hl7vmr:clinicalstatementinputspecification"> <span property="hl7vmr:requiredclinicalstatementclass" resource="hl7vmr:observationresult" ></span> <span property="hl7vmr:hascodedattributerequirement" typeof="hl7vmr:codedattributerequirement"> <span property="hl7vmr:hastargetcode" typeof="hl7vmr:cd" resource="urn:/helsedir/neklab/npu01568"> <span property="rdfs:label">ldl</span> </span> <span property="hl7vmr:hastargetcodedattribute" resource="hl7vmr:observationbase#observationfocus"></span> </span> </span> >2,0 mmol/l bør tilbys statinbehandling hvis ikke kontraindisert. </td> <td>a</td> <td>1a</td> </tr> 10.2 MAPPING Målsettingen var at all mapping ble gjort i OWL DL, og dernest som regler (rules). Det var i alt 6 HL7 vmr attributter og én relasjon som skulle mappes til DIPS LAB relasjonstabeller og openehr arketyper. Totalt ble det 12 mappinger. Av disse, så er 3 mappinger gjort i kun OWL, 8 mappinger gjort med OWL + regler og 1 mapping måtte gjøres i kode. At kun 3 av 12 mappinger var mulig å gjøre i OWL uten regler var noe skuffende resultat. Selv om regler også en del Semantisk Web teknologien, så gjør det at resonneringen blir mer uoversiktlig siden noe skjer pga. uttrykk i OWL og noe p.g.a. regler (sideeffekter). I tillegg er regler generelt «undecidable», noe som i praksis betyr at det er en fare for at resonneringen «henger seg» hvis man er uheldig. En gjennomgang viser at årsakene til at regler ble brukt kan deles i 4 grupper: 1. «Constrained» subpropertyof er ikke mulig (2) 2. «Constrained» property chains (owl:propertychainaxiom) er ikke mulig (4) 3. Property chains (owl:propertychainaxiom) fungerer ikke for relasjoner hvor objektet er DatatypeProperties (literals) p.g.a. krav om avgjørbarhet («decidability») (2) 4. «Object versus literal properties»-problemet (2) Med (1) «constrained» rdfs:subpropertyof menes muligheten til å definere en rdfs:subpropertyof relasjon over et subsett av alle forelder-relasjoner, på samme måte som for klasser hvor owl:restriction property kan benyttes til å definere en klasse ut fra bestemte property-kriterier. Eksempel regel som gjør dette: IF And(rdf:type(?x <ObservationResult>) SEHIA:time(?x?y)) Then ObservationResult#observationEventTime(?x?y). 97

100 Med (2) «constrained» property chain menes muligheten for å definere property chain over et subsett av alle mulige property chains på samme måte som for (1) ovenfor. Eksempel på regel som gjør dette mulig: IF And(rdf:type(?a SEHIA:Observation) SEHIA:conceptURI(?a?b) SEHIA:terminology_binding(?b?c)) Then ObservationBase#ObservationFocus(?a?c) Begrensningen med owl:propertychainaxiom (3) er en velkjent begrensning 66 som også skyldes krav om avgjørbarhet («decidability») i OWL 2 DL. I SEHIA POC er dette et problem som kommer i tillegg til mangel på (2) «constrained» property chain. M.a.o. hadde «constrained» property chain vært mulig, så ville det likevel strandet i 2 av mappingene p.g.a. denne begrensningen. Med (4) menes en situasjon hvor én ressurs (her: dwundersokelse) med en DatatypeProperty (her: utforttid: datetime) skal mappes til en annen ressurs (her: ObservationResult) med en ObjectProperty (her: IVL_TS) som igjen har en DataTypeProperty (her: low, high) som er den det skal mappes til. Figuren under illustrerer problemet. dwundersokelse ObservationResult observationeventtime IVL_TS utforttid: datetime low : datetime high : datetime Mapping? subclassof subclassof ObservationResult observationeventtime IVL_TS low : datetime high : datetime dwundersokelse utforttid: datetime subpropertyof observationeventtime inferred by rule Figur 29 «Object versus literal» problemet illustrert Regelen i figuren ovenfor er definert slik: IF And(rdf:type(?x <ObservationResult>) rdf:type(?x <IVL_TS>)) Then ObservationResult#observationEventTime(?x?x). Mappinger som krever regler er en ting. Flere mappinger kunne verken løses med OWL eller regler. Dette gjelder attributter som er resultat av kalkuleringer eller hvor flere attributter («data properties») fra kildedatabasene ble satt sammen til et sammensatt attributt (begrep). Fra POCen har vi:

101 Alder er property Age i entiteten EvaluatedPerson. Alder er noe som må beregnes ut fra fødselsdato, siden bare fødselsdato finnes i SEHIA RDF Store. Det er ikke mulig å lage regler hvor en verdi er resultatet av en funksjon av andre verdier (kapittel 9.6.5). Visning av blodtrykk «176/90» som er satt sammen av systolisk og diastolisk blodtrykksmåling. Å konstruere et begrepet blodtrykk som benytter en funksjon «concatenate» for å kombinere to primitive begreper til et sammensatt begrep er ikke mulig. Likevel er det mulig å annotere de overordnede begrepet «blodtrykk» i retningslinjen, og setter dermed ikke krav til at retningslinjen alltid annoteres med atomiske begreper (kapittel ). Et tilsvarende problem var datatyper med ulik «granularitet» hvor data fra kildedatabasene må settes sammen (og potensielt splittes) før de kan mappes til den virtuelle EPJ (HL7 vmr datatypene). Selv med forenklingene som ble gjort, så var det ikke mulig å kombinere måleverdi og måleenhet i én felles visningstekst (se kapittel ) OPPSUMMERING AV EVALUERING (BRA/DÅRLIG) Bra: Dårlig: - Semantisk annotering med RDFa krever ingen endringer i infrastruktur på WGL-CMS systemene og passer på tradisjonelle websteder med statiske sider (Web 1.0). - Støtter 1-til-1 og mapping mellom ulike nivåer i klassifikasjonshierarkier/taksonomier («subsumption»). - Direkte referanser forenkler koblinger mellom datamodell og terminologier. - RDFa passer dårlig for dynamiske websider (Web 2.0), og derfor behov for et API (REST-grensesnitt). - RDFa annotering av retningslinjer basert på HL7 vmr cdsinputspecification medfører mye (unødvendig) tagging («verbose»). - Mangler bibliotek for RDFa destillering på.net og Java plattformen (sjekket høst 2012) - Attributter med ulik granularitet i kildesystem og HL7 vmr kan ikke mappes i OWL/Rules. Det må være 1- til-1 match, eller så må dette håndteres på utsiden. - Kalkulasjoner støttes ikke i OWL (jf. alder) - Selv med få noen få utvalgte mappinger i SEHIA POC, så var det kun 3 av 12 mappinger som ble løst med OWL alene. 8 måtte i tillegg støttes av regler, noe som gjør resonneringen «undecidable». At OWL DL ikke støttet flere case i sin helhet, er noe skuffende 99

102 11 DRØFTING 11.1 KONSEKVENSER AV OG TILTAK FOR HÅNDTERING AV SVAKHETENE I POCEN «RDFa passer dårlig for dynamiske websider (Web 2.0), og derfor behov for et API (REST-grensesnitt)» Et av resultatene ved gjennomføring av POCen var at RDFa ikke egner seg til alle typer WGL-CMS. RDFa egner seg bra dersom WGL-CMS er et tradisjonelt nettsted med statiske websider (Web 1.0). Hver gang det navigeres til en ny webside, så destilleres siden for RDF. Med moderne WGL-CMS nettsted med dynamiske websider med JavaScript/Ajax (Web 2.0), vil innholdet kunne endres uten navigasjon til ny webside (samme URL). De mest populære WGL-CMS systemene i dag innholder for det meste statiske websider (Web 1.0), men utviklingen går i retning av mer dynamiske websider (Web 2.0). SEHIA bør derfor støtte flere «integrasjonsnivåer» med WGL-CMS: - RDFa destillering: For eksisterende WGL-CMS basert på Web 1.0 vil semantisk tagging med RDFa i HTML være det beste alternativet fordi det ikke vil kreve noen endringer i infrastrukturen, kun innholdet i HTMLsidene. Da vil SEHIA ekstrahere RDFa fra websiden og generere en RDF-graf av HL7 vmr cdsinputspecification som beskriver hvilke kliniske variabler som skal vises i SEHIA GL CTL (se for øvrig kapittel 8.2.2). - REST/JSON-LD: Dersom WGL-CMS er et nettsted med dynamiske websider med Ajax-oppdateringer (Web 2.0), kan det være behov for å sende et «refresh» kall til SEHIA GL CTL. SEHIA GL CTL spesifiserer et RESTbasert grensesnitt som WGL-CMS Javascriptkoden kan bruke til dette. REST-grensesnittet er ikke basert på standard. For avanserte klienter skal også være mulig for JavaScript å sende inn spesifikasjon på nye kliniske variabler som skal vises i SEHIA GL CTL komponenten. Imidlertid vil standard sikkerhetsinnstillinger i nettlesere hindrer Javascriptklienter å foreta REST-kall til andre servere enn den serveren hvor websiden ble lastet ned fra («same origin policy») 67. Nettleseren må derfor støtte «Cross-Origin resource sharing» (CORS) protokollen 68. CORS er støttet av Chromium/WebKit som er integrert ble brukt i SEHIA POC. Standarden vil være standarden HL7 vmr og klassen cdsinputspecification representert som JSON-LD (som tilsvarer RDF). RDF-nedlasting: Ingen integrasjon på klientsiden, men gjøres i stedet på serversiden mellom SEHIA EHR Server og WGL-CMS. For hver navigasjon i webinnholdet, så vil SEHIA GL CTL sende URL til SEHIA EHR Server «RDFa annotering av retningslinjer basert på HL7 vmr cdsinputspecification medfører mye tagging» Konsekvensen av dette kan være å se på om HL7 vmr cdsinputspecification egner seg dette, eventuelt bør man se på om det kan gjøres forenklinger i datamodellen og muligens korte ned på lengder på termer (navn). Det er også behov for å vurdere om enklere formater HTML5 Microdata 69 kan redusere «footprint». «Mangler bibliotek for RDFa destillering på.net og Java plattformen» For Java finnes det et Jena bibliotek for parsing av RDFa kalt «Java RDFa» 70 som open source på Github. Denne ble forkastet sist gang fordi den ikke fungerte. Dette bør testes på nytt. For.Net finnes det fremdeles ikke biblioteker for parsing av RDFa

103 Det bør vurderes om HTML5 Microdata, som er et enklere format og som det finnes.net støtte for, er tilstrekkelig. Konvertering til RDF er en triviell jobb. Dersom XHTML benyttes så kan visstnok GRDDL 71 benyttes for uttrekk av RDF fra RDFa annoterte HTML-sider. Å forutsette XHTML vil bety at mange eksisterende HTML-baserte retningslinjer må skrives om. Om dette i praksis er mulig å kreve, og at det vil fungere må testes ut. I så fall er kan dette være en god løsning. «Attributter med ulik granularitet i kildesystem og HL7 vmr kan ikke mappes i OWL/Rules. Det må være 1-til-1 match, eller så må dette håndteres på utsiden» Dette er et velkjent problem ved mapping mellom ontologier, og bør ikke være noen «showstopper» for SEHIA konseptet. Konsekvensen av dette er at noe av mappingen må gjøres i programvare på toppen av OWL/Rules mapping. Noen av rammeverkene utviklet av lignende prosjekter (KDOM, MEIDA, IDAN se kapittel 11.2) har denne typen funksjonalitet, og dette bør også legges inn i SEHIA. «Kalkulasjoner støttes ikke i OWL (jf. alder)» Samme konsekvens og tiltak som nevnt i forrige punkt. «Selv med få noen få utvalgte mappinger i SEHIA POC, så var det kun 3 av 12 mappinger som ble løst med OWL alene. 8 måtte i tillegg støttes av regler, noe som gjør resonneringen «undecidable». At OWL DL ikke støttet flere case i sin helhet, er noe skuffende» Det er to problemstillinger her. Den første er hvorvidt blandingen mellom OWL og regler gjør resonneringen uoversiktlig med uønskede sideeffekter. Det medfører i hvert fall mye kompleksitet, noe som ikke er bra for at teknologien skal bli tatt i bruk av industrien. Kompleksitet og konsekvenser diskuteres videre i En annen ting er spørsmålet om avgjørbarhet («decidability») er et mål. Så lenge det ikke er mulig å gjøre mappingen i OWL DL (i hvert fall så langt forfatter kan se), så kan man enten forkaste hele ideen, eller så kan man akseptere at resonneringen blir «undecidable» ved bruk av regler. Som sagt er all kode imperative språk «undecidable» av natur, og det er opp til programmereren å sørge for at det ikke får konsekvenser SAMMENLIGNING MED LIGNENDE ARBEID INNLEDNING I dette kapittelet beskriver kort lignende prosjekter beskrevet i litteraturen, og en sammenligning mellom disse og SEHIA med henblikk på mål, funksjonalitet og teknologisk løsninger ACTIVEGUIDELINES (2000) I en artikkel fra 2000 [43], beskrives en metode - ActiveGuidelines (AGL) - for integrasjon av web-baserte kliniske retningslinjer med EPJ-systemer som allerede er tilgjengelig via internett (som National Guideline Clearinghouse 72 ) eller via intranett. Bakgrunnen for arbeidet er at erfaringer med retningslinjer tilgjengelig via web ikke benyttes med mindre disse blir integrert i den naturlige arbeidsflyten til klinkere. Det betyr at 1) retningslinjer må aktiveres fra EPJ-system på passende steder i arbeidsprosessen, 2) det må være lett å velge tiltak ut fra anbefalinger i retningslinjen og 3) tiltak som velges må opprettes som forordninger i EPJ-systemet

104 ActiveGuidelines er en metode hvor det spesifiseres kriterier for relevant pasientinfo (dvs. pasientens problemer, medisinliste, allergier, lab tester, etc.) gitt en anbefaling. Kliniker får tilbud om å hente fram relevant anbefaling basert på pasientinfo. Anbefalingen vises så i en nettleser. Ulike forslag til forordninger av legemidler, labtester, osv. («order set») vises som hyperlinker i selve anbefalingen, og kan velges på samme måte som valg av artikler som legges i «handlekurv» på en nettbutikk. Etterpå klikkes «accept» som betyr at forordningene opprettes i EPJsystemet. Arkitekturskissen nedenfor som viser sekvensen av operasjoner og kommunikasjon mellom «guideline server» (WGL-CMS) tilgjengelig på intra-/internett og EPJ-system med integrert nettleser. Figure 1 ActiveGuideline arkitektur Stegene i figuren er som følger: 1. En webforespørsel (HTTP GET request) sendes med pasientkontekst til guideline server (WGL-CMS) 2. Guideline server returnerer (HTTP GET response) en HTML-guideline med skjulte AGL-tagger som angir forordninger knyttet til retningslinjen. 3. AGL-komponenten integrert i EPJ konverterer AGL-taggene til AGL-anker (hyperlinker) som kan klikkes på. 4. Når bruker klikker på et AGL-anker (hyperlink), så fanges dette opp av AGL komponenten som legger forordningen til «handlekurven» (orders accumulator),.. 102

105 6. som tilslutt aksepterer og overføres til EPJ som regulære forordninger. AGL-taggene som legges inn i HTML vises ikke av nettlesere, men brukes av AGL-komponenten til å generere anker tagger i HTML (<a href=..>) som igjen fanges opp når bruker klikker på lenke i nettleser. Eksempel på legemiddelforskriving og labforordning: Terminologi for h.h.v. legemidler og labanalyse er angitt med tagen NDC (National Drug Codes) og CPT (Current Procedural Terminology). Eksempel på anker (hyperlink) som genereres på bakgrunn av AGL-taggen for legemiddelforskriving: Det er laget en AGL add-in til Microsoft FrontPage med tilgang til legemiddelregister og prosedyrekoder som kan brukes for å legge inn AGL-taggene i eksisterende HTML baserte retningslinjer. Hvordan relevante retningslinjer og anbefalinger blir «matchet» mot pasientkontekst beskrives ikke i artikkelen. Det er derfor uklart om dette er noe som planlegges eller allerede er laget. I diskusjonsavsnittet beskrives «patient tailored recommendation» som «next step» noe som tyder på at dette planlegges. Artikkelen er relativt gammel, og det finnes ingen nyere artikler om ActiveGuidelines. En patentsøknad ble imidlertid funnet, så det kan være at konseptet nå er implementert i et kommersielt produkt i en eller annen form. Ideen bak ActiveGuidelines er det samme som ønskes oppnådd i Evicare, søke opp relevante retningslinjer basert på pasientkontekst og gi muligheter til å bestille ulike forslag til legemiddel, labanalyser, etc. («order set»). Det som skiller disse er metode og teknologi. Sammenligning med SEHIA: Ideen om å annotere HTML med skjulte semantiske tagger er den samme som SEHIA. I AGL ble forordningene lagt inn som skjulte XML-tagger i de HTML-baserte retningslinjene. Disse ble så tolket av programvaren slik at det var mulig å forordne direkte i EPJ bare ved å klikke på hyperlinker som i en nettbutikk. I SEHIA er (den ustandardiserte) XML-tagging er erstattet med standard RDFa annotering. AGL har heller ikke funksjonalitet for å hente pasientinfo fra journalen basert på innhold i retningslinjen. AGL er begrenset det som beskrives i SEHIA Webintegrasjon. SHA Dataintegrasjon dekkes ikke av AGL KDOM (2008) Knowledge-Data Ontological Mapper (KDOM) [28] er et rammeverk for å integrere digitale kliniske retningslinjer (DKR) med EPJ-systemer. Digitale kliniske retningslinjer representert i Guideline Interchange Format v3 (GLIF3) inneholder «kliniske variabler» til informasjon som ofte allerede finnes i EPJ. Disse «kliniske variablene» trengs som input-fakta ved eksekvering av regler i retningslinjen. Å unngå at klinikere må taste inn de samme variablene som allerede finnes i EPJ, vil lette arbeidet med registrering og redusere sjansen for feilregistrering. Det er også et mål 103

106 om at de «kliniske variablene» er abstrakte og ikke bundet til spesielle EPJ-systemer. Det vil gjøre det enklere å integrere retningslinjene med andre EPJ-systemer. KDOM er et forsøk på å definere en systematisk tilnærming til mapping mellom «kliniske variabler» som finnes i digitale retningslinjer og heterogene EPJ-systemer. Noen utfordringer med mapping var: Forskjellige måleenheter og tidsenheter i DKR versus EPJ-systemet. Forskjellige EPJ datamodeller og terminologisystemer i bruk på ulike institusjoner Abstrakte begreper skal mappes til konkrete data i EPJ, både medisinske begreper og tidsangivelser. F.eks. «høyt blodsukkernivå i minst 5 timer etter behandling». Sammensatte begreper som krever flere dataelementer fra EPJ. KDOM implementerer det tredje laget i GLIF3 73 «Medical Knowledge layer» som er et virtuelt EPJ grensesnitt hvor retningslinjene benytter medisinske abstrakte begreper for pasientopplysninger som gjør de digitale retningslinjene uavhengig av datamodellen til spesifikke EPJ system. For å skille begrepene i retningslinjen fra begrepene i EPJ systemet benyttes en mapping ontologi (definert som 30 Java klasser). Med mappingklassene er det er mulig å mappe mellom abstraksjoner på høyt nivå til mer konkrete begreper, f.eks. retningslinjen bruker begrepet «antibiotika», mens de enkelte legemidlene som er registrert i EPJ systemet er «Amoxycillin» og «Penicillin-V». Det er også mulig å mappe abstrakte tidsangivelser som f.eks. «siste», «gjeldende», «første» som ofte benyttes i retningslinjer. Det er også mulig å kombinere ulike abstraksjoner med logiske operatorer (and, or) og sammenligningsoperatorer (=,<,>,>=,<=,!=). Mappingene utgjør en hierarki hvor bladnodene refererer til HL7 RIM Act subklassene (observation, procedure, medication, etc.). Bladnodene forutsetter at det opprettes «connecting model» som databaseview med «utflatet» HL7 RIM Act og subklasser som mappes til konkrete databasekolonner i EPJ systemet. Figuren under er en konseptskisse for KDOM:

107 Figur 30 KDOM konseptskisse KDOM støtter ikke terminologimapping og konvertering mellom ulike måleenheter. Sammenligning med SEHIA: KDOM er et rammeverk for å integrere digitale retningslinjer (DKR) med EPJ-systemer. Dette er likt målsettingen med SEHIA dataintegrasjon og det som ble implementert i SEHIA POC. Mens SEHIA integrerer dokumentorienterte digitale retningslinjer (kategori 1 i kapittel 3.3.2) (ala AGL, HGML) for integrasjon, så integrerer KDOM kunnskapsorientert retningslinjer (kategori 3 i kapittel 3.3.2) spesifisert i GLIF3 standarden. Selv om det ved første øyekast kan se ut som KDOM og SEHIA overlapper, så er de faktisk komplementære i stor grad. KDOM definerer noe de kaller for «connecting model» som er grensesnittet mot EPJ-databasen. I KDOM er connecting model HL7-RIM Act baserte databaseviews, mens i SEHIA er dette HL7 vmr ontologi i OWL (se Figur 30 kapittel ). KDOM beskriver ikke hvordan HL7-RIM Act mappes til EPJ-databasen, noe som er selve kjernen i SEHIA. Med litt omskriving kan SEHIA HL7 vmr «connecting model» benyttes av KDOM. Selv om både SEHIA og KDOM henter pasientopplysninger fra EPJ, så er det til to veldig ulike formål og mottakere. I SEHIA er formålet å vise dette til mennesker (leger), som grunnlag for kliniske beslutninger. I KDOM er dette input først og fremst til en algoritme i en datamaskin. Dette setter større krav til integrasjonen, bl.a. konvertering mellom ulike måleenheter i EPJ systemet versus DKR, tolkning av abstrakte begreper (eks. «høyt blodtrykk»), og abstrakte tidsangivelse som «siste måling», «minst 5 timer etter siste behandling», osv. KDOM benytter HL7-RIM Act «connecting model» for å hente pasientopplysningene, såkalte «primitive fakta». I SEHIA er all «prosessering» av retningslinjen overlatt til mennesker, og som input får de «primitive fakta». Som sagt kan mappingontologien til KDOM bruke SEHIA HL7 vmr connecting model (SPARQL i stedet for SQL). Temporære abstraksjoner, logisk og aritmetiske operatorer og kombinasjoner av tidligere mappinger («prior mapping») mangler i SEHIA, men «classification hierarchy» og 1-til-1 mappingen støttes av SEHIA. 105

108 Ellers var det ikke mulig av artikkelen å se at funksjoner (som beregning av alder) var støttet, men artikkelen påstod at all mapping de gjort var deklarativt TRANSFER (1996) TransFER [50] er en formell modell designet for å støtte utveksling av pasientopplysninger på tvers av beslutningsstøttesystemer mellom institusjoner med heterogene kliniske databaser (EPJ). TransFER er det som KDOM kaller for «connecting model», og som kan brukes av kliniske beslutningsstøttesystemer (inkludert digitale kliniske retningslinjer) til å hente pasientopplysninger fra EPJ. I TransFER defineres et referanseskjema (Functional Entity-Relationship model) og sett med mappinger med mappingspråket Extended Relational Algebra (ERA) mellom referanseskjema og de ulike kliniske databasene. Spørringer formuleres i spørrespråket ReFER mot referanseskjemaet. Mappingene benyttes til å oversettes spørringene til EPJ-spesifikke SQL uttrykk. Figuren nedenfor viser et FER skjema: Figur 31 Eksempel på FER-skjema Eksempel på en ReFER spørring på basis av figuren ovenfor som henter alle glukoseverdier for en pasient ved navn «Smith» mellom kl. 05 og 08 den 28. oktober: [value-of-test(g) I (g:glucose), (pt:patient) AND Patient-Lab_Test(pt,g) AND datetime-of-lab(g) >= "1995/10/ " AND datetime-of-lab(g) <= "1995/10/ " AND last-name-of(pt) = "Smith" ] Mappingene i ERA baserer seg på deklarative mappinger basert på operatorer i algebra. Noen ganger er det ikke mulig, og da er det mulig å benytte eksterne funksjoner eller «prosedyrer» spesifisert i ERA-uttrykk. Målsettingen er flest mulig deklarative mappinger som da muliggjør optimaliserte spørringer, noe som ikke er mulig med funksjoner. Evaluering av mapping til 3 databaseskjema viste at i 7-8 % av mappingene var ikke mulig å definere deklarativt vha. ERA, ergo bruk av eksterne funksjoner var nødvendig. Sammenligning med SEHIA: I motsetning til KDOM er TransFER kun en «connecting model», og direkte sammenlignbar med SEHIA. SEHIA og TransFER benytter begge et globalt skjema som mappes til heterogene datakilder. 106

109 Artikkelen er fra 1996 som var før LD og SemWeb. Det er interessant å se at FER-Skjema (Figur 31) ligner på en SemWeb graf. Mapping-ontologien (ERA) er analogt med OWL- og regler-mappinger i SEHIA. Spørrespråket ReFER er analogt med SPARQL i SEHIA. I likhet med SEHIA POC kunne ikke alle mappinger gjøres deklarativt (ERA og OWL/Regler), noe måtte løses med prosedurale eksterne funksjoner IDAN (2005) Siden IDAN [51] ligner på KDOM i funksjon så gjøres beskrivelse veldig kort. IDAN er en arkitektur for «modular distributed temporal-abstraction mediator» som, i likhet med KDOM, muliggjør spørringer til ulike heterogene datakilder med mest mulig naturlig språk og med begreper som ligger nært opp til de begrepene som allerede brukes i retningslinjene. IDAN støtter spørringer på abstrakte medisinske begreper (som er en avledet på bakgrunn av en funksjon av primitive fakta), klassifikasjonshierarkier, temporære abstraksjoner («siste», etter», «varighet»), terminologimapping og enhetskonvertering. Primitive fakta kalles de data som brukes som er input til funksjonene som konverterer til abstrakte begreper. Disse må hentes fra EPJ-database vha. dataaksessmodulen (DAM) som er modulært oppbygget for å kunne støtte ulike EPJ-databaser vha. av konfigurasjon og/eller plug-in baserte moduler. DAM støtter konvertering av målenheter og termer mellom lokale og standard termer. Sammenligning med SEHIA: IDAN er veldig lik KDOM, i stedet for bare å forutsette at «connecting model» er HL7- RIM Act, så finnes det en modulær dataaksessmodul (DAM) som kan sammenlignes med SEHIA. DAM støtter terminologimapping og enhetskonvertering, mens SEHIA kun støtter terminologimapping. På samme måte som for KDOM, så støtter IDAN spørringer vha. klassifikasjonshierarkier, som også støttes av SEHIA. DAM kan integreres med SEHIA for å hente primitive fakta på tvers av heterogene kilder, og i stor grad komplementær til SEHIA MEIDA (2009) Medical Database Adapter (MEIDA) [52] er først og fremst en «connecting model» på samme måte som TransFER, men har i tillegg støtte for terminologimappinger. Det betyr at MEIDA ikke støtter abstraksjoner som KDOM og IDAN gjør. MEIDA bruker HL7 RIM om global virtuelt skjema. Databaseadministratoren for EPJ-systemet kan bruke et verktøy for å opprette og vedlikeholde mappingene. MEIDA har støtte for transformasjonsfunksjoner for strengmanipulering, datofunksjoner, datatypekonvertering og aritmetiske uttrykk. MEIDA inneholder også en terminologiserver og mappingverktøy for å lagre standard terminologier (LOINC, CPT, ICD9, osv.), lokale kodeverk og mappinger mellom disse. Sammenligning med SEHIA: MEIDA er en «connecting model» som kan sammenlignes direkte med SEHIA. MEIDA bruker også HL7-RIM som virtuelt EPJ skjema og mapper til ulike EPJ-skjemaer. I likhet med de andre prosjektene, så støttes skjema-, terminologimapping og konvertering av måleenheter. MEIDA støtter også tranformasjonsfunksjoner, noe som også går igjen i flere av de andre prosjektene. 107

110 TM-VMR (2012) Artikkelen [53] beskriver en arkitektur for et kliniske beslutningsstøtte. Det interessante i denne sammenhengen er bruk av teknologien Topic Maps (TM) 74 for å håndtere semantisk heterogenitet. Det foreslås en løsning hvor ulike datakilder importeres inn i et sentralt TM-repository modellert iht. HL7 vmr kalt TM-vMR. Forespørsler fra «data manager» aksesserer TM-vMR i stedet for alle datakildene. Se arkitekturskisse nedenfor: Figur 32 TM-vMR arkitekturskisse Topic Maps er en form for semantisk webteknologi som et alternativ til W3Cs RDF/OWL. Topic Maps er standardisert som ISO/IEC 13250:2003. Sammenligning med SEHIA: SEHIA RDF Store tilsvarer på mange måter TM-vMR bortsett fra at semantisk webteknologiene er forskjellig. Artikkelen [53] sier imidlertid ingenting om hvordan data fra heterogene datakilder importeres inn i TM-vMR, noe som er sentralt i SEHIA OPPSUMMERING Både KDOM, MEIDA og IDAN benytter seg av at dataaksesslag (DAM) eller «connecting model». SEHIA er mer å betrakte som en DAM eller «connecting model» og er i så måte komplementær. En ting som går igjen er konvertering av måleenheter («units»). Dette er ikke nødvendig i SEHIA så lenge poenget er å vise resultatene for et menneske. SEHIA benytter LD og SemWeb teknologi som har god støtte for terminologimappinger og spørringer på klassifikasjonshierarkier/taksonomier. Flere og flere ontologier/terminologier (LOINC, SNOMED CT, osv.) kan leveres på/konverteres til RDF/OWL-format og kan dermed lastes inn direkte i SEHIA RDF Store. Dermed er det ikke nødvendig med spesialiserte innlastingsapplikasjoner

111 Flere av de andre prosjektene har ikke klart seg bare med deklarative mappinger, men har også måtte innføre transformasjonsfunksjoner. TM-vMR benytter også semantisk webteknologi og datavarehus-konseptet for integrasjon ERFARINGER FRA ET SYSTEMUTVIKLINGSPERSPEKTIV De største utfordringene var iboende kompleksitet i grafmodellen, manglende lesbarhet i kode og testbarhet. En database som består av et stort antall sammenkoblede noder i et nettverk er kognitivt mer utfordrende enn en database med noen få tabeller og relasjoner mellom disse. Tabellene grupperer kolonner på samme måte som Objekt-orientert-paradigmet innkapsling er nyttig for å håndtere kompleksitet. I en grafdatabase som RDF Store ser man hele «skogen» uten noen form for innkapsling. RDF Store praktiserer også såkalt «open world assumption» regime, mens vanlige relasjonsdatabaser praktiserer «closed world assumption» regime. Under «open world», så er det ingen skjemavalidering som i relasjonsdatabaser. Ved feilstavelser så returnerer RDF Store ingen data, mens i relasjonsdatabaser får man en feilmelding. På samme måte som svakt typende ("weakly typed") språk, så har denne fleksibiliteten en pris ved at det blir vanskelig å finne feil. Konsekvensen av denne friheten er krav til mer krevende testing. En annen ting var lesbarhet i kode ved bruk av Apache Jena bibliotek og SPARQL spørringer. Noen kodesnutter sees i kapittel 9.7, og det er vanskelig å traversere en graf. Noen av problemet skyldes nok iboende kompleksitet i grafkonseptet (se ovenfor), men det virket ikke som Jena-biblioteket var optimalisert for dette heller. Debugging med SPARQL var en utfordring. SPARQL måtte settes sammen av mange fragmenter før det ble en komplett streng. Når resultatet ble en ny graf (SPARQL CONSTRUCT), så gjorde dette feilsøking vanskeligere. Debugging bestod i å dumpe resultater som TURTLE-filer 75. I moderne utviklingsmiljø er det mulig å «steppe» igjennom koden og inspisere verdier i variabler for simple og komplekse datatyper. Siden det manglet innebygget verktøystøtte for RDF-strukturer var det så å si umulig å inspisere grafene uten at de ble dumpet til filer. Selv da er det vanskelig å tolke innholdet fordi det manglet visuelle verktøy for å presentere grafene. Det var også vanskelig å vurdere følgende av OWL DL resonnering når det ble behov for å kombinere dette med regler. Det var i tilfellene hvor OWL DL ikke strakk til, og det var behov for å supplere med regler. Det er vanskelig å teste isolert (unit teste) siden feilene ofte oppstod helt andre steder. Inspisering av resultatet var vanskelig p.g.a manglende verktøystøtte. Det var også forholdsmessig mye jobb å sette opp ETL jobben. Uten verktøystøtte ble det mye håndkoding. I utgangspunktet skal det være en mekanisk operasjon å konvertere fra ulike representasjoner til RDF og OWL. For relasjonstabeller viste denne forutsetningen å holde bra, men for openehr RM og arketyper oppstod såpass mye kompleksitet at det det ble lagt inn noen hjelpestrukturer for å gjøre mappingen enklere. Det er viktig at disse strukturene kan genereres av en ETL applikasjon slik at håndkoding ikke er nødvendig. Oppsummering: Innkapsling ved hjelp av modularisering som mekanisme for å håndtere kompleksitet er sentralt i OO og relasjonsdatabaser, men mangler i LD og SemWeb. 75 Det må tas et forbehold om at forfatter ikke har brukt biblioteker korrekt, og ta det finnes andre og bedre måter å gjøre dette. 109

112 Manglende verktøystøtte (spesielt på.net plattformen) gjorde utvikling og feilsøk vanskelig. Kombinasjon av manglende verktøystøtte og mekanisme for innkapsling gjorde det enda vanskeligere. Vanskelig å vite følgene av resonnering ved OWL DL og regler i kombinasjon p.g.a sideeffekter. Skal LD og SemWeb bli "mainstream" innen industrien må kompleksitet håndteres. Verktøystøtte vil komme dersom LD og SemWeb blir «akseptert» av utviklingsmiljøene. Foreløpig har ikke dette skjedd LØSER SEHIA DET PRAKTISKE PROBLEMET? INTRO I dette kapittelet drøftes det hvorvidt SEHIA løser det praktiske problemet fra et brukerståsted - med basis kravspesifikasjonen i kapittel 6 (brukstilfelle fra EVICARE-prosjektet). Validiteten til kravspesifikasjonen drøftes ikke, dvs. er dette de rette kravene til å oppnå det overordnede målet om kunnskapsbasert medisin i praksis. Dette tas som en forutsetning. En grundig evaluering av SEHIA opp mot kravspesifikasjonen vil kreve omfattende prosesser med gjennomføring av Architecture Tradeoff Analysis Method (ATAM) 76 [54], ROS-analyser og/eller proof-of-concept/mock-testing i virkelige omgivelser. Dette lå utenfor denne oppgavens mandat. Det er likevel gjort foreløpig drøfting av dette siden mange av de problemstillingene som diskuteres er nødvendig forutsetning for at SEHIA skal la seg implementere i et virkelig miljø. Noen av problemstillingene er generelle for adresseres av Evicare-prosjektet, mens andre er knyttet til LD og SemWeb særskilt og utenfor Evicare. Dette vil være forslag til videre arbeid. Som sagt er viktige krav utelatt (bl.a «usability»). De kravene som er tatt med er de som berører SEHIA spesielt, og som det er mulig å si noe om uten omfattende undersøkelser INFORMASJONSSIKKERHET Krav IF1: «Løsningen må ha tilfredsstillende informasjonssikkerhet iht. norske lover og forskrifter.» Krav IF6: «Løsningen må kunne kjøre på typisk nettverksinfrastruktur og sikkerhetsløsninger ved en helsevirksomhet» I Norge er det svært strenge krav til håndtering av pasientopplysninger regulert i Helseregisterloven, Personopplysningsloven og Helsepersonelloven. I tillegg så har helsesektoren utarbeidet «Norm for informasjonssikkerhet» [55] (heretter kalt Normen) som konkretiserer og setter ytterligere krav til informasjonssikkerheten. Kort sagt er alle opplysninger som kan knyttes til en pasient er per definisjon sensitive opplysninger. Løsningen må sikre at sensitive opplysninger ikke kommer på avveie. Systemer som behandler pasientopplysninger kjører i nettverk i sikre soner bak brannvegger med DMZ hvor det i praksis er umulig å initiere tilgang fra utsiden og inn til en node i nettverket. All kommunikasjon må initieres fra innsiden og ut. Her er det imidlertid begrensninger på hvilke noder som kan gjøre dette

113 SEHIA foreslår en integrasjon mellom EPJ-systemer, som behandler sensitive personopplysninger, med et eksternt system som er tilgjengelig via Helse- eller Internett. Tar vi utgangspunkt i Figur 18 kapittel er det snakk om to typer integrasjon med tjenester på helse-/internett: 1. Integrasjon mellom EPJ-system og nettleser som kommuniserer med WGL-CMS server på internett (desktopintegrasjon). 2. Integrasjon mellom SEHIA EHR Server og WGL-CMS (serverintegrasjon) Dette er en potensiell utfordring informasjonssikkerhetsmessig. I Normen [55], kapittel «Tilkopling til internett», står det bl.a. «internett-tjenesten er logisk atskilt fra der helse- og personopplysninger behandles.». Dette vil gjelde både (1) desktop- og (2) serverintegrasjon. Hva som ligger i «logisk» er en definisjonssak. En liten undersøkelse viser at noen helseforetak praktiserer det slik at internettilgang kun er tilgjengelig via en egen terminalserverklient som kan startes fra arbeidsstasjon/terminal hvor EPJ applikasjonsklient kjører (her: DIPS Arena EPJ klient). I praksis betyr det at nettleser kjører på en helt annen maskin, og er usynlig for EPJ-systemet og dermed umulig å integrere. Andre helseforetak tillater at oppslag på internett kan skje fra samme arbeidsstasjon/terminal som EPJ-systemet, og «logisk skille» går på at applikasjoner som behandler pasientopplysninger ikke direkte kan aksessere ressurser på internett. Dette vil da gjelde både applikasjonsklienter og serverkomponenter i EPJ-systemet. Løsningen på dette er HTTP-proxy servere som kontrollerer og logger all slik tilgang. En HTTP-proxy server kan begrense tilgang til «lovlige» tjenester (f.eks. kliniske kunnskapsbaser som f.eks. helsebiblioteket.no), foreta kontroll av evt. skadelig kode og tillate kun HTTP GET (dvs. stoppe alle HTTP POST/PUT/DELETE). Men HTTP-proxy kan ikke kontrollere om pasientopplysninger sendes ut av helseforetaket (f.eks. som GET-parametere), så nødvendige sikkerhetsmekanismer må også bygges inn EPJ-applikasjonen. I SEHIA er grunnprinsippet at ingen pasientopplysninger skal utleveres fra EPJ-systemet. I desktopintegrasjonen (mellom EPJ-systemets klient og nettleser til WGL-CMS) utveksles kun kommandomeldinger som sørger for at pasientkonteksten holdes oppdatert. Ved navigering til ny webside i WGL-CMS, så fanges det opp en hendelse i SEHIA GL CTL som frisker opp pasientkonteksten deretter. SEHIA POC benytter en integrert nettleser i DIPS Arena EPJ klienten. Den integrerte nettleseren er basert på velkjent open source WebKit/Chromium med samme sikkerhet som i Google Chrome nettleseren. Nettleseren kjører i samme os-prosess som DIPS Arena EPJ, men hvor evt. applikasjonslogikk (Javascript) er avsondret fra å kommunisere med vertsapplikasjonen. I så måte er nettleseren er en slags virtuell maskin hvor vertsapplikasjon har full kontroll over når navigering foretas og når data lastes ned. I noen tilfeller endres innholdet uten at navigering gjøres, f.eks. ved dynamiske websider med Ajax. Da er det behov for at JavaScript-kode kan sende en «refresh»-kommando til EPJ applikasjonens REST-tjenester for dette (se kapittel 9.8). Disse tjenestene tar kun i mot data (JSON Lenkede Data objekter), men returnerer ingen pasientopplysninger. I SEHIA POC er disse tjenestene ytterligere begrenset til kall fra konsumenter (her: JavaScript) som kommer fra samme maskin. På serversiden så kommuniserer SEHIA EHR Server med tjenester som returnerer lenkede data (RDF eller JSON-LD). Dette er kun data, dvs. ingen applikasjonslogikk (scripts e.l.) kan lure seg inn her. Ut fra at SEHIA aldri utleverer pasientopplysninger, så skal en kunne ivareta nødvendig informasjonssikkerhet iht. personvernlover og forskrifter. 111

114 Dette forutsetter at det gis muligheter for at EPJ-systemer kan kommunisere med WGL-CMS webapplikasjoner på helse-/internett. Uansett så bør hvert foretak gjennomføre en grundige risiko- og sårbarhetsanalyse (ROS) før en løsning innføres PASIENTSIKKERHET (-VERN) Krav IF2: «Løsningen må ivareta pasientsikkerhet, dvs. ikke være til skade for pasienten.» Pasientsikkerhet vil i denne sammenheng være å sørge for at pasientkontekst som vises sammen med anbefalingen er korrekte, men også korrekt tolkning av manglende opplysninger. I motsatt fall kan legen fatte beslutninger på feil grunnlag, og dermed påføre pasient skade som følge av feilbehandling. Først og fremst er det viktig at pasientinfo som vises i tilknytning til retningslinjene tilhører den pasienten som er aktivert i journalsystemets arbeidsflate. Når bruker bytter pasient, må også de kliniske variablene oppdateres. Det er viktig at SEHIA Guideline Controller (GL CTL) komponenten får beskjed fra EPJ-systemet ved pasientbytte, og at dette er godt uttestet. En annen utfordring er tolkningen av manglende opplysninger. Dersom retningslinjen forespør pasientkontekst, f.eks. lab-analyser som ikke finnes i journalen, så betyr det ikke at de ikke finnes. Det kan bare være at analysekoden som brukes ved forespørsel ikke er mappet korrekt til lokale analysekoder i EPJ-systemet. Da ville det vært feil om det kom en melding ala «Labanalyse X kunne ikke finnes». Dette kan feilaktig tolkes som at det ikke er registrert slike opplysninger i pasientens journal, noe som ikke er tilfelle. En mulig løsning er ikke å skrive noe som helst i slike tilfeller. I stedet for å vise «INR: (ingen målinger)», så bør hele linjen inkl. ledetekst tas bort. Utfordringen er imidlertid at dersom det mangler deler av en serie labanalyser f.eks. at det ble gjort 3 labanalysemålinger den , og Dersom disse viser en trend, men hvor kun én av disse vises i pasientkonteksten er det umulig å se trenden som kanskje er viktig for å ta stilling til den videre behandlingen. Selv sjansen for at denne typen feil oppstår er liten, så er den til stede. Spesielt dersom samme type labanalyse registreres og importeres som arketypedata og som relasjonstabeller (se SEHIA POC). Dersom labanalysene er kodet med en annen terminologi for arketypedata enn de som finnes i relasjonstabellene, vil dette i teorien kunne skje. En analog til denne problemstillingen er ryggealarmer, blokkeringsfrie bremser (ABS), antiskrens på biler. Dersom sjåføren er vant med at det piper når han/hun nærmer seg en hindring, og så baserer seg på dette når han/hun setter seg inn i en annen bil uten denne innretningen kan det gå galt. Et annet eksempel er GPS navigasjon og evnen til å bruke kart og kompass. Når hjelpesystemene ikke fungerer, så må det gå tydelig fram at systemene ikke er operativ (varsling). Det er dette med varsling som ikke er funnet noen god løsning på i SEHIA. Brukergrensesnittet bør derfor utarbeides slik at det går klart fram at det kan finnes flere opplysninger enn de som vises, og at dette er ikke en erstatning for å slå opp i journalsystemet dersom man ikke finner opplysninger som er essensielle for pasientbehandlingen. Dette med håndtering av manglende opplysninger ved visning av relevante kliniske variabler ifbm. en retningslinje kan være en showstopper for SEHIA konseptet. Dette er en problemstilling det må foretas brukertester og som bør inngå i en ROS-analyse INTEGRERBARHET, ÅPENHET OG STANDARDER Krav IF3: «Løsning skal være åpen, dvs. integrasjonsgrensesnitt og modellen skal være basert på standarder som er leverandøruavhengige» 112

115 Krav IF4: «Løsningen må kunne integreres med nye eksisterende WGL-CMS uten at det krever endringer i teknisk infrastruktur for WGL-CMS.» Det er veldig mange måter å integrere EPJ-system med WGL-CMS. Den største utfordringen er å integrere SEHIA med EPJ-systemet. Denne består både av en dataintegrasjon med SEHIA EHR Server og RDF Store med ETL fra EPJdatabase. På klientsiden må SEHIA GL CTL integreres med EPJ-klienten som både kan være native applikasjonsklient eller webklient. SEHIA Webintegrasjon handler SEHIA GL CTL komponenten hvordan denne ble integrert i EPJ-systemets applikasjonsklient (her: DIPS Arena EPJ) og integrasjon med WGL-CMS webapplikasjon som var en mockup basert på innhold fra Integrasjon i EPJ-systemets applikasjonsklient er veldig avhengig av EPJ-systemets tekniske arkitektur (native applikasjonsklient eller webbasert) og runtime miljø (MS.Net, Java). SEHIA GL CTL er laget i.net med WPFgrensesnitt. Denne vil kun la seg integrere i en.net native applikasjonsklient. For EPJ-system basert på Java, må det lages en tilsvarende SEHIA GL CTL i Java. Integrasjon med webbaserte EPJ-klienter krever igjen en annen teknisk løsning med desktopsynkronisering basert på f.eks. HL7 CCOW. Integrasjon i native klienter vil bli sømløst og være bedre ut fra brukbarhets-, informasjonssikkerhets- og pasientvernhensyn (se Figur 28 i kapittel 9.8). Å integrere SEHIA med WGL-CMS er forholdvis mye enklere. Grensesnittene tillater flere mulige integrasjonsnivåer. RDFa annotering av HTML sider krever ingen endring i WGL-CMS og passer bra for enklere websteder med statiske websider (Web 1.0). Mer avanserte websteder med dynamiske websider (Web 2.0) kan benytte JavaScript og tilgjengelig REST/JSON-LD grensesnitt. Alle grensesnittene baserer seg på standarden HL7 vmr. Konklusjon: Mens det kan lages en generisk integrasjonsstøtte for alle WGL-CMS systemene, så må integrasjonen med EPJ-systemet tilpasses det enkelte system TERMINOLOGISTØTTE Krav IF5: «Løsningen skal takle at ulike terminologier (SNOMED CT, NEKLAB, LOINC, osv.) er i bruk av CDS-systemer og EPJ ved integrasjon. Årsaken er at ulike terminologier er brukt i ulike land, i beslutningsstøttesystem og EPJsystemer, og man kan ikke forutsette harmonisering i overskuelig framtid.» SEHIA støtter mapping mellom terminologier slik at en klinisk variabel (blodtrykk, labanalyse, prosedyre, legemiddel etc.) er kode med en terminologi i WGL-CMS systemet vil kunne finne samme kliniske variabel i EPJ kodet med en annen terminologi. Følgende mappinger støttes: owl:sameas og klassifikasjonshierarkier/taksonomier («subsumption»). Terminologier og mappinger må lastes inn i RDF Store som OWL/RDF-filer ved endringer eller behov for å støtte nye terminologier. Det er flere og flere terminologiorganisasjoner som tilbyr terminologiene og mappinger til en rekke andre terminologier på OWL-form. Mange terminologier finnes i andre formater, og da er det behov for konvertere. F.eks. kan mange av OBO 77 terminologiene lastes ned fra OBO format kan konverteres til OWL. Dersom det ikke finnes mappinger mellom terminologier som allerede benyttes i EPJ-systemet, og den terminologien som lastes inn må det foretas en mapping. Dette må gjøres av domeneeksperter. 77 Open Biological and Biomedical Ontologies: 113

116 Konklusjon: SEHIA har meget god støtte for nye terminologier og mappinger mellom termer. Flere og fler terminologier kommer på OWL-form, og skal kunne lastes inn direkte og tas i bruk umiddelbart. Støtte for spørringer ved hjelp av klassifikasjonshierarkier («subsumption») er veldig godt tilpasset OWL representasjon YTELSE IF7: «Responstiden på brukerhistorie nr. F1 må være under 5 sekunder. For resten av brukerhistoriene skal responstiden være maks 1 sekund.» Med de begrensede datamengder som ble brukt i SEHIA POC var det ingen problem å holde seg under 5 sekunder for krav F1. SEHIA POC egner seg derfor ikke til å konkludere på dette punktet. En måte å resonnere på er å vurdere dette opp mot en alternativ løsning. I SEHIA benytter et ETL arkitekturmønster hvor alle data som er aktuelt å søke på importeres til et sentralt lager (RDF Store). Ved hjelp av resonnering («inference») optimaliseres data for spørringer. Dette vil alltid gå raskere enn om data skal hentes fra sine respektive datakilder, som da vil medføre minst like mange spørringer. I SEHIA POC benyttes Oracle støtte for lagring av RDF-tripler, såkalt triple store, som datalager. Oracle RDF triple store er implementert på Oracles relasjonsdatabaseplattform, og baserer seg derfor på de samme mekanismer for å oppnå høy ytelse som Oracle for øvrig (partisjonering og indekser). Ifølge Oracle selv skalerer systemet opp til 100-vis av milliarder med tripler. Selv om dette i utgangspunktet høres nok ut, er det vanskelig å si hvor mange tripler som trengs for å dekke behovene for en konsolidert database for en helseregion i Norge. I Helse Vest RHF fantes det 105 millioner labanalysesvar ved utgangen av Dette utgjorde ca. 50 % av datavolumet. Hva dette vil si i antall tripler i praksis i SEHIA RDF Store gjenstår å finne ut av, men for enkelhetens skyld kan vi si at hver analyse vil minst kreve 20 tripler (12 tripler ble benyttet for hver labanalyse i SEHIA POC for et subsett av attributtene). Totalt antall tripler blir da 105 millioner * 20 tripler = 210 millioner tripler. Analogt med OLAP-kube som brukes av datavarehus for å oppnå høy ytelser ved at aggregerte opplysninger beregnes på forhånd, støtter Oracle OWL2 RL resonnering («inference») som generere nye tripler, såkalte «entailments», som gjør at spørringer går raskere enn ellers. «Entailments» kan inneholde betydelig antall tripler. Hvis vi for enkelhetens skyld sier at hver trippel i eksempelet over medfører én ny trippel. Det betyr 420 millioner tripler. Hvis vi for enkelhetens skyld sier at dette er 50 % av antall tripler i databasen, og at andre data utenom labsvar har like mange tripler, så vil totalantallet bli 840 millioner tripler. Fremdeles så er tallet under 1 milliard, så det skulle være mye å gå på. Uansett bør dette undersøkes nærmere. Konklusjon: Responstid vil være avhengig av at spørringer til selve RDF triple store går raskt nok. Under forutsetning av at antall tripler er innenfor rammene av det dagens RDF databaser kan skalere opp til, er det grunn til å tro at responstidskrav kan overholdes. Dette bør imidlertid utforskes nærmere. 114

117 12 OPPSUMMERING, KONKLUSJON OG FORSLAG TIL VIDERE ARBEID 12.1 OPPSUMMERING Sømløs integrasjon mellom EPJ- og kliniske beslutningsstøttesystemer (CDS-systemer) er identifisert som et nødvendig virkemiddel for å oppnå kunnskapsbasert medisin i praksis (prosesstøttet EPJ). Samtidig har dette vist seg svært vanskelig å få oppnå. Selv etter over 15 år med forskning og utvikling har fremdeles ikke ført gjennombrudd med nevneverdig utbredelse og standardisering av løsninger på verdensbasis for området som helhet. Mangel på semantisk heterogenitet er identifisert som en av hovedårsakene til at det er vanskelig å skalere opp og standardisere integrasjon mellom EPJ- og kliniske beslutningsstøttesystemer (CDS-systemer). Fra etableringen av ideen om Lenkede Data og Semantisk Web på begynnelsen av 2000-tallet til i dag har det pågått en god del forskning og utvikling av teknologi som har til hensikt å få systemer til å «snakke» sammen på internett, derav navnet «semantisk web». Håndtering av semantisk heterogenitet er høyst relevant for å oppnå dette, og problemet er derfor grunnleggende det samme som når man skal integrere to spesifikke systemer med hverandre. Forskningsspørsmålet var å finne ut om lenkede data og semantisk web-teknologi egner seg til dataintegrasjon mellom EPJ-system og WGL-CMS (en type CDS-systemer). Hvor passer det best og hvor passer det ikke? Metoden var å utvikle en proof-of-concept «Semantic Health Integration Architecture» (SEHIA POC) som integrerte EPJ og kliniske beslutningsstøttesystem (CDS-systemer) for å se om LD og SemWeb teknologi var mulig og hvilke problemer som oppstod. Detter ble det gjort en analyse og evaluering av resultatene fra gjennomføringen av POCen som ble oppsummert slik: Bra: Dårlig: - Semantisk annotering med RDFa krever ingen endringer i infrastruktur på WGL-CMS systemene og passer på tradisjonelle websteder med statiske sider (Web 1.0). - Støtter 1-til-1 og mapping mellom ulike nivåer i klassifikasjonshierarkier/taksonomi («subsumption»). - Direkte referanser forenkler koblinger mellom datamodell og terminologier. 1. RDFa passer dårlig for dynamiske websider (Web 2.0), og derfor behov for et API (REST-grensesnitt). 2. RDFa annotering av retningslinjer basert på HL7 vmr cdsinputspecification medfører mye (unødvendig) tagging («verbose»). 3. Mangler bibliotek for RDFa destillering på.net og Java plattformen (sjekket høst 2012) 4. Attributter med ulik granularitet i kildesystem og HL7 vmr kan ikke mappes i OWL/Rules. Det må være 1- til-1 match, eller så må dette håndteres på utsiden. 5. Kalkulasjoner støttes ikke i OWL (jf. alder) 6. Selv med få noen få utvalgte mappinger i SEHIA POC, så var det kun 3 av 12 mappinger som ble løst med OWL alene. 8 måtte i tillegg støttes av regler, noe som gjør resonneringen «undecidable». At OWL DL ikke støttet flere case i sin helhet, er noe skuffende Deretter ble konsekvenser og tiltak drøftet for å håndtere punktene i kategorien dårlig. Punkt 1) håndteres ved å utvide SEHIA konseptet til å støtte Web 2.0 applikasjoner. For punkt 2) bør det vurderes alternativer til HL7 vmr og eventuelt bytte til enklere formater som HTML5 Microdata. Punkt 3) er noe bedre dersom RDFa blir akseptert i 115

118 industrien, evt. kan man bytte til HTML5 Microdata hvis mulig. Punkt 4) og 5) bør støttes i software med støtte for OWL/Rules-resonnering. Punkt 6) er både et spørsmål om hvor mye kompleksitet kan aksepteres før «kaos» inntreffer, og om avgjørbarhet («decidability») eller ikke egentlig er et mål for suksess eller fiasko for SEHIA. Så ble det gjort en enkel sammenligning av SEHIA og lignende prosjekter som ActiveGuidelines, HGML, Semantic Clinical Guideline Documents, KDOM, IDAN, TRANSFER, MEIDA og TM-vMR. Oppsummering: Både KDOM, MEIDA og IDAN benytter seg av at dataaksesslag (DAM) eller «connecting model». SEHIA er mer å betrakte som en DAM eller «connecting model» og er i så måte komplementær. En ting som går igjen er konvertering av måleenheter («units»). Dette er ikke nødvendig i SEHIA så lenge poenget er å vise resultatene for et menneske. SEHIA benytter LD og SemWeb teknologi som har god støtte for terminologimappinger og spørringer på klassifikasjonshierarkier/taksonomi. Flere og flere ontologier/terminologier (LOINC, SNOMED CT, osv.) kan leveres på/konverteres til RDF/OWL-format og kan dermed lastes inn direkte i SEHIA RDF Store. Dermed er det ikke nødvendig med spesialiserte innlastingsapplikasjoner. Flere av de andre prosjektene har ikke klart seg bare med deklarative mappinger, men har også måtte innføre transformasjonsfunksjoner. TM-vMR benytter også semantisk webteknologi og datavarehus-konseptet for integrasjon. Før man kan konkludere på en teknologi, så må teknologien være attraktiv og akseptert av programvareutviklere. Testbarhet, lesbarhet, vedlikeholdbarhet, kompleksitet er viktige parametere. Oppsummering: Innkapsling ved hjelp av modularisering som mekanisme for å håndtere kompleksitet er sentralt i OO og relasjonsdatabaser, men mangler i LD og SemWeb. Manglende verktøystøtte (spesielt på.net plattformen) gjorde utvikling og feilsøk vanskelig. Kombinasjon av manglende verktøystøtte og mekanisme for innkapsling gjorde det enda vanskeligere. Vanskelig å vite følgende av resonnering ved OWL DL og regler i kombinasjon p.g.a sideeffekter. Skal LD og SemWeb bli «mainstream» innen industrien må kompleksitet håndteres. Verktøystøtte vil komme dersom LD og SemWeb blir «akseptert» av utviklingsmiljøene. Foreløpig har ikke dette skjedd. Den grunnleggende ideen i SEHIA er basert på at brukstilfelle fra Evicare, og derfor avhengig at dette verifiseres opp mot det overordnede målet om «mer kunnskapsbasert medisin i praksis». Med utgangspunkt i noen viktige krav som må besvares ved implementering av et slikt system på et sykehus, blir det drøftet hvilke problemstillinger og forutsetninger dukker opp og må avklares. Oppsummering: - Ut fra at SEHIA aldri utleverer pasientopplysninger, så skal en kunne ivareta nødvendig informasjonssikkerhet iht. personvernlover og forskrifter (informasjonssikkerhet) - Dette forutsettes at det gis muligheter for at EPJ-systemer kan kommunisere med WGL-CMS webapplikasjoner på helse-/internett (informasjonssikkerhet) - Håndtering av manglende opplysninger ved visning av relevante kliniske variabler ifbm. en retningslinje kan være en showstopper for Evicare og SEHIA konseptet (pasientsikkerhet) - Responstid vil være avhengig av at spørringer til selve RDF triple store går raskt nok. Under forutsetning av at antall tripler er innenfor rammene av det dagens RDF databaser kan skalere opp til, er det grunn til å tro at responstidskrav kan overholdes. Dette bør imidlertid utforskes nærmere (ytelse) 116

119 Ut fra dette bør det gjennomføres en risiko og sårbarhetsanalyse (ROS-analyse) for SEHIA (og Evicare) konseptet. Det bør også undersøkes hvorvidt SEHIA RDF Store kan skalere opp til de datamengder som er nødvendig for store konsoliderte regionale EPJ-databaser. Selv om mye av SEHIA hviler på at Evicare brukstilfelle holder vann, så er resultatene fra dataintegrasjon i stor grad gyldige for alle semantisk heterogene systemer. For webintegrasjon er det selvsagt viktig at Evicare brukstilfelle blir verifisert. Kompleksitet er et vanskelig å måle. Man må skille mellom den kompleksiteten som kommer av problemet alene og den kompleksitet som skyldes teknologi og verktøy, h.h.v. i LD og SemWeb og manglende verktøystøtte. Selv om sammenligning med andre prosjekter kan gi en viss pekepinn, så ville tilsvarende øvelse som SEHIA uten bruk av LD og SemWeb være en måte å finne ut hvor mye som skyldes LD og SemWeb/manglende verktøystøtte versus problemet med å integrere heterogene EPJ- og CDS-systemer KONKLUSJON Oppsummert kan man si at optimismen rundt LD og SemWeb var nok høyere enn hva den praktiske gjennomføringen har vist. Det er nok hovedlærdommen i forståelse av sammenhengen mellom teori og praksis når det gjelder bruk av LD og SemWeb for å oppnå semantiske interoperabilitet mellom heterogene (legacy) systemer. Forskningsspørsmålet i oppgaven var: Fra et programutviklingsperspektiv, ønsker oppgaven å finne ut om lenkede data og semantisk web-teknologi egner seg til dataintegrasjon mellom EPJ-system og WGL-CMS (en type CDS-systemer). Hvor passer det best og hvor passer det ikke? Svaret på om LD og SemWeb egner seg til dataintegrasjon er både ja og nei. Usikkerheten skyldes oppgavens begrensede omfang, og dermed også behovet for flere undersøkelser (jf. neste kapittel). Svaret er ja, fordi LD og SemWeb har stor styrker på enkelte områder, og nei fordi foreløpig har teknologien begrensninger på andre områder. Oppsummert: Ja (+): Nei (-): - Støtte for mapping av kodeverk, klassifikasjonshierarkier/taksonomier og terminologisystemer er veldig sterk i og med at internasjonale terminologiorganisasjoner er i stand til å levere terminologier på OWLform og mappinger mellom termer. - God støtte for semantisk annotering av retningslinjer (RDFa) som gjør retningslinjen maskinlesbar. - Det er ingen snarvei til målet om semantisk interoperabilitet. Andre lignende prosjekter basert på andre teknologier har lignende kompleksitet, og må etablere store rammeverk for å gjøre mapping deklarativ (konfigurasjon). - Høy iboende kompleksitet i RDF-grafmodellen var et problem. Manglende verktøystøtte gjør det verre. Men kanskje er dette en «høna eller egget» problemstilling? Bedre verktøystøtte kan gjøre håndtering av RDF-grafer enklere. - Open world assumption («svakt typet») gjør at «alt er lov». Høy grad av frihet setter store krav til testrammeverk og gjør at feilsøk blir vanskelig. - Kombinasjon av OWL DL/Rules-resonnering gjør resonneringen uoversiktlig og vanskelig å se rekkevidden av. 117

120 Når man vet at a) kodeverk, klassifikasjonshierarkier/taksonomier og terminologisystemer og mappinger mellom disse vedlikeholdes av internasjonale organisasjoner, b) at disse kan leveres på OWL form, c) at disse kan benyttes til resonnering for effektiv integrasjon av data i EPJ- og CDS-systemer og d) at lignende prosjekter nevnt i ovenfor ikke har støtte for dette eller har utviklet egne spesialmoduler for begrenset resonnering, så er konklusjonen at OWL DL resonnering kan være et sterkt bidrag til å forbedre og forenkle integrasjonen sammenlignet med konvensjonelle teknikker implementert i lignende prosjekter. Semantisk annotering med RDFa av HTML-basert elektroniske kliniske retningslinjer passer bra for statiske websider (Web 1.0), men mindre bra for dynamiske websider (Web 2.0). OWL DL er ikke tilstrekkelig alene for å integrere ulike datamodeller i CDS- og EPJ-systemer. Å supplere med RIFbasert resonnering er heller ikke nok fordi transformasjonsfunksjoner mangler. Funksjoner som f.eks. kalkulasjoner, strengmanipulering og konkatenering er nødvendig for at mappinger kan la seg gjennomføre. Det er derfor nødvendig med å implementere denne typen funksjonalitet i egne programmoduler som et lag over RDF-datalager (store). Høy kompleksitet var for øvrig et stort problem som ble erfart som skyldes både iboende kompleksitet i RDFgrafmodellen, uoversiktlig resonnering når OWL og regler ble kombinert, men også manglende verktøystøtte i POCmiljøet gjorde feilsøk vanskelig FORSLAG TIL VIDERE ARBEID Det viktigste tiltaket for å komme nærmere et entydig svar vil være å forsøke implementere en ny POC med samme funksjonalitet som SEHIA dataintegrasjon ved hjelp av konvensjonell teknologi som finnes i dag uten bruk av LD og SemWeb, og deretter sammenligne dette med arbeidet som er gjort her. Da vil det være lettere å avgjøre om problemstillingene som er kommet fram i denne oppgaven skyldes LD og SemWeb teknologien eller er uavhengig. Det bør også gjøres en volumtest for å se om RDF Store kan skaleres opp til de datamengder som regionale foretak vil besitte. Utover dette bør selvsagt EVICARE brukstilfelle verifiseres, siden spesielt SEHIA dataintegrasjon hviler på at denne hypotesen holder vann. En del av verifiseringen bør være gjennomføring av en ROS-analyse. 118

121 13 REFLEKSJON 13.1 GENERALISERBARHET Det er slik at EVICARE er et pågående prosjekt, og det gjenstår å se om brukstilfelle holder vann i forhold til målet om å oppnå kunnskapsbasert medisin i praksis. Som sagt hviler denne masteren delvis på at grunnideen blir bekreftet gjennom EVICARE-prosjektet. EVICARE brukstilfeller og testbatteri representerer på ingen måte alle problemstillingene som innen integrasjon mellom EPJ og CDS-systemer, og som andre forskningsprosjekter (jf. kapittel 11.2) har adressert som utfordring ved integrasjoner. Dette arbeidet er likevel direkte sammenlignbart med andre prosjekter. Spesielt gjelder dette «connecting model» som alle rammeverk som skal integreres med kunnskapsorienterte digitale retningslinjer på GLIF3 form har behov for. Det betyr at SEHIA dataintegrasjon gjerne kan være en grunnleggende og komplementær komponent til disse rammeverkene. Så selv om grunnideen til EVICARE ikke skulle holde vann, så vil resultatene fra dataintegrasjon være relevante i andre sammenhenger. Når det gjelder SEHIA webintegrasjon med semantisk annotering av dokumentorienterte retningslinjer, så er resultatene herfra mer knyttet til grunnideen i EVICARE. Lignende prosjekter (ActiveGuidelines, HGML) er relativt gamle (13 år), og at disse ideene ikke har blitt realisert kan være et tegn på at det ikke er en farbar vei. Men mye har skjedd siden den tid, så dette kan selvsagt være helt annerledes i dag. Når det er sagt, så har jo heller ikke noen av de andre prosjektene med kunnskapsorientert retningslinjer basert på GLIF3 vært noen suksess. Problemstillingene som er kommet opp under forsøket har også verdi utover integrasjon mellom EPJ og CDSsystemer. På tross av at det var en veldig avgrenset problemstilling, så oppstod mange problemer ved mapping mellom HL7 vmr og LAB-datakilden i relasjonstabeller og kliniske målinger i openehr XML. Dette gir en pekepinn på hvor langt man kan trekke bruken av LD og SemWeb til dataintegrasjon generelt. Resultatene rundt mapping går på grunnleggende problemstillinger som vil være tilfelle ved de fleste dataintegrasjonsbehov (f.eks. ulik «datagranularitet») ved bruk av LD og SemWeb KOMPETANSE Forfatter har snart 18 års arbeidserfaring innenfor software utvikling som systemutvikler og systemarkitekt. Da temaet for oppgaven ble bestemt i 2012, ble det jobbet flere måneder med å sette seg inn i LD og SemWeb begrepsapparat og teknologiene RDF, RDFS, OWL og regler. Det må likevel tas et forbehold om muligheten for at det finnes alternative angrepsvinkler som ville ha løst de problemene som ble identifisert rundt OWL mappingproblematikken. Forsøkene som er utført etter beste evne («best effort»). Dersom noen som leser dette skulle komme med forslag som bidrar til bedre forståelse av temaet eller løse noen av problemene belyst i oppgaven, er det svært ønskelig at disse tar kontakt med forfatteren KOMPLEKSITET Fra et programvareutviklingsperspektiv var høy kompleksitet en utfordring hele veien. Noe skyldes nok manglende mekanismer for innkapsling og modularisering av RDF-graf og resonnering med OWL DL og regel som skapte sideeffekter det var vanskelig å forutsi. Det er likevel viktig å si at dette ville nok ha vært mer håndterlig med bedre verktøy- og plattformstøtte. En annen ting er kompleksitet ved problemet i seg selv. Håndtering av semantisk heterogene systemer har vært og er et tøft problem å håndtere for forskning og industrien. For å gi et mer objektivt bilde av kompleksitet, så burde samme brukstilfelle implementeres ved hjelp av konvensjonelle teknologier og da 119

122 ville man se om høyere kompleksitet var en del av problemet eller teknologien som ble brukt for å løse problemet. Å finne ut av dette, var det ikke rom for i denne masteren. 120

123 14 APPENDIKS 14.1 HL7 VIRTUAL MEDICAL RECORD (VMR) DOMAIN MODELS Figur 33 cdsinputspecification Figur 34 cdsinput med Virtual Medical Record (vmr) 121

124 Figur 35 cdsoutput med Virtual Medical Record (vmr) Figur 36 Virtual Medical Record (vmr)- del 1 122

125 Figur 37 Virtual Medical Record (vmr) - Del 2 123

126 14.2 OPENEHR REFERENCE MODEL OG ARCHETYPE MODEL Figur 38 viser hvordan et openehr journaldokument (COMPOSITION) er bygget opp hiearkisk av seksjoner (SECTION), observasjoner (OBSERVATION), forordninger (INSTRUCTION) og tiltak (ACTION). Disse kan igjen brytes ned til mer grunnleggende elementer som igjen tilslutt ender som bladnoder i atomiske datatyper (openehr Data Types). Kilde: [56]. En slik struktur serialiseres som en openehr XML-fil, som igjen kan representeres i RDF/OWL. Bladnodene vil være «literals» i RDF, mens resten vil være URI- eller blanke noder i RDF-graf. 124