OpenEHR. Arkitektur for et strukturert EPJ? Sigurd From Utviklingsdirektør. DIPS ASA Jernbaneveien 85 Bodø

Transkript

1 OpenEHR Arkitektur for et strukturert EPJ? Sigurd From Utviklingsdirektør DIPS ASA Jernbaneveien 85 Bodø Telefon: Epost: Telefon:

2 DIPS Arena - neste generasjon EPJ/PAS

3 DIPS Arena - Sentrale egenskaper Håndtere strukturert informasjon Gi prosessstyring Delt elektronisk Dokumentasjon Enkel Prosessstøtte DIPS EPJ/PAS DIPS Arena

4 DIPS Arena Håndtere strukturert informasjon Håndtere strukturert informasjon Registrere vha kodeverk Registrere fritekst Registrere variable

5 DIPS Arena Gi prosesstyring Gi prosessstyring En klinisk prosess består av aktiviteter og evt. arbeidsflyt som har til hensikt å forandre en helsetilstand hos en pasient Aktiviteter må kunne planlegges frem i tid Benytte forløpsmaler for å forenkle planlegging Aktiviteter må kunne monitorers og følges opp Blod i urin (Hematuri) Urografi Cystoscopi (polikl.) Lab, utr. hematuri Frist : 2 (6) uker Henvisning Pasienten har merket blod i urinen

6 DIPS Arena Implikasjon for arkitektur Håndtere strukturert informasjon Både håndtering av strukturert informasjon og prosesstyring krever et dynamisk system som kan tilpasses: Nye informasjonsstrukturer Nye prosessdefinisjoner Gi prosessstyring Dette krever at det tenkes nytt i implementering av IT-systemet To-nivå modelldrevet arkitektur er et svar på denne utfordringen

7 2-nivå modelldrevet arkitektur Sluttbrukere Variabler, arketyper og terminologi Skjemamaler Prosessmaler og behandlingsplaner Autorisasjonsmaler og mandater instansierer og benytter Domeneeksperter modellerer Datainnhold Skjermbilder Arbeidsprosesser Tilgangskontroll Modelldrevet OpenEHR Two-level Modelling skaper Stabil og enkel kjerne Tjenester og grensesnitt Referansemodeller Standarder Databaseskjema Utviklingsdrevet Utviklingsteamet

8 Kan openehr benyttes til å lage et slikt dynamisk EPJ?

9 openehr openehr er en internasjonal not-for-profit organisasjon som arbeider for å gjøre pasientsentriske, shared cared EPJ til en realitet å øke foreståelse av helsedomene innen IKT Dette gjøres ved å lage åpne spesifikasjoner og open source programvare (bl.a. verktøy) å delta i standardiseringsarbeid i ISO og CEN å delta i kliniske implementasjonsprosjekt Tre sentrale spesifikasjoner: Reference Model (RM) Basis informasjonsmodell for EHR Archetype Model (AM) Modell for arketypes og templates Service Model (SM) Modell for tjenester for openehr EHR Kompatibel med CEN EHRCOM

10 Two-Level Modelling Separation of Information and Knowledge Knowledge Models Business Logic Information Models Source: Rong Chen, Guest lecture at UiT, IFI, June Two level modelling and futureproof information system

11 Information Reference Model Knowledge Archetype Model Semantics of constraint Instances Instances Runtime constraint Information Archetypes Source: Rong Chen, Guest lecture at UiT, IFI, June Two level modelling and futureproof information system

12 OpenEHR arketype for blodtrykk

13 Arketype, maler og brukergrensesnitt Arketype Mal (Template) Brukergrensesnitt

14 openehr: Klinisk problemløsnings prosess

15 openehr: Distribusjon av arktetyper CKM

16 Erfaring med implementering

17 Utgangspunkt: Arketyper og template i et «CKM»

18 Importere arketyper og template (OPT) i DIPS Arena

19 Forhåndsvisning

20 Deretter kan brukeren benytte dem i journalnotat OBSERVATION

21 Eller i tidslinjevisning i Panorama ACTION INSTRUCTION ACTIVITY

22 Erfaringer til nå Vi har lært mye av openehr bla. fleksibiliteten ved to-nivå modellering. Vi har vist at vi er i stand til å importere arketyper og OPTer Vi er i stand til å generere automatisk brukergrensenitt basert på OPTer for registering av data Vi støtter i dag OBSERVATION og EVALUATION arketyper Vi støtter INSTRUCTION og ACTION med noen begrensinger Vi er i stand til å håndtere arketyper/opter i journalnotat og i Panorama for visning i tidslinje Vi er i stand til å lagre de strukturerte dataene i EPJdatabasen

23 Utfordringer Vi mangler en felles måte å utvikle og vedlikeholde arketyper og maler (templates) på i Norge. Det bør opprettes en felles norsk CKM = Clinical Knowledge Manager. Mange arketyper forutsetter kobling til terminologier som SNOMED CT. Skal vi benytte internasjonale arketyper må forholdet til SNOMED CT avklares. openehr dekker bare delvis arbeidsflyt (workflow) i dag. Dette er et område under utvikling. Vi må derfor regne med å supplere med andre standarder / teknologier for å dekke dette området fullt ut. Valg av teknologi for effektiv lagring og gjenfinning

24 Konklusjon Jeg mener openehr og arketyper kan benyttes som arkitektur for et dynamisk EPJ som håndterer både strukturert informasjon og prosesstyring Håndtere strukturert informasjon Gi prosessstyring Potensielle gevinster Lettere å søke og sammenstille informasjonen Lettere å utveksles informasjon Informasjon kan utnyttes til kvalitetssikring Informasjon kan benyttes til klinisk forskning Potensielle gevinster Forenkle planleggingen og sikre at viktige aktiviteter er med Sikre at planlagte aktiviteter blir fulgt opp og ikke glemt Muliggjøre evaluering i ettertid.

25 Muligheter fremover Mel ding Register AT AT Offentlige aktører CKM AT AT AT AT Helseforetak 1 Melding Mel ding Helseforetak 2

26 Takk for oppmerksomheten