Detta är en mall för att göra PowerPoint presentationer.

En presentation över ämnet: "Detta är en mall för att göra PowerPoint presentationer."— Presentationens avskrift:

1 Arketyper Live™ - pusselbitar till ändamålsenlig vård- och omsorgsdokumentation
Detta är en mall för att göra PowerPoint presentationer. Du skriver in din rubrik på första sidan. För att skapa nya sidor, tryck Ctrl+M. Skriv sedan in din text. Om du vill ha fast datum, eller ändra författarnamn, gå in under Visa, Sidhuvud och Sidfot. Vill du använda hörnet med loggan över en utfallande bild, gå in på Bildbakgrund och kopiera. Klistra sedan in på den sida du vill ha den. Institutionen för medicinsk teknik Medicinsk informatik Linköpings universitet

2 openEHR, 13 mars SNOMED CT, 17 april ”Arketyper live”, 30 maj

3 Innehåll Scenario 2: VGR samordnad vårdplanering (30 min, MF)
Framtid & Tillämpningar (20 min, HÅ, DK) Igår, idag, imorgon? -- Inmatad data blir stabil och väldefinierad Övergång från ”gamla” till ”nya” system Erfarenheter från NHS Arketyper + SNOMED CT Nationell samordning Diskussion & Frågor (60 min, HÅ moderator) Välkommen (HÅ) Grunder & teori (20 min, ES) Vad är en arketyp? Referensmodell (13606, openEHR) Verktyg & arketypsamlingar (15 min, MN) Arketypeditorer, "Archetype workbench” Var hittar man "färdiga" arketyper? Scenario 1: Årlig diabeteskontroll Vårddokumentation (30 min, MN) Detaljstruktur: Element, Cluster Designmönster 1: Evaluation, Observation Sammanhang: Section, Composition Terminologibindningar (15 min, DK) Processer och aktiviteter (30 min, ES, DK) Processmodellering Designmönster 2: Instruction + Action

4 Grunder & teori

5 Vad är arketyper? Vad är de inte?
Inget ”helt nytt”, bygger på traditionell objektorientering omfattande mångårig analys av krav för patientjournalsystem principer om separation av roller & ansvar mellan domänexperter och teknikexperter (jfr Excel och kalkylark) System av system (Den som gapar över (för) mycket…) För många forskare inte så spännande som mål för forskning, men intressant bidrag som medel för att kunna tillämpa och genomföra annan forskning kring t.ex. Beslutsstöd, data mining, kunskapsutvinning terminologi/ontologi och deras bindning till informationsmodeller användargränsnitt, översikter, navigering …och intressant för den som vill skapa logiskt sammanhängade system för vård- och omsorgsdokumentation som spänner över gränser mellan organisationer, leverantörer, nationer…

6 Vad är en arketyp? – Tankar bakom
Semantisk interoperabilitet Tvålagersmodellering ”Gränskontrakt” mellan informationsstruktur och terminologi/ontologi Journalinformationsdelning över spåkbarriärer

7 Semantisk interoperabilitet
Semantisk interoperabilitet? Meddelanden eller systemarkitektur i fokus för normering? export/import export/import export/import Störningar uppstår vid översättning/transformering mellan ”verklighet” och tanke (observation) tanke och dokument/it-system (o)likheter mellan bedömare? Relevanta, uppdaterade konsensus-modeller? mellan (ev.) olika modeller i it-systemen Undvik översättning/mappning om möjlilgt!

8 Semantisk interoperabilitet
Semantisk interoperabilitet? Meddelanden eller systemarkitektur i fokus för normering? Normering export/import export/import export/import Normering av meddelandeformat (och ev tillhörande term- och kodlistor tillåtna i meddelandet) Ofta en naturlig start för befintliga system och små, väldefinierade informationsmängder.. Introducerar störningar i form av semantiska omtolkningar för icke-triviala informationsmängder. En patientsäkerketsfråga. Kräver ändringar i export/import-funktioner hos för varje ny meddelande/tjänstetyp. En kostnads- och underhållsfråga Exempel på normeringsbeskrivningar: XML-scheman, Arketyper, HL7 CDA Templates

9 Omtolkningsproblem Olika semantisk struktur
System A Meddelande (normerat?) System B Fem fält Tre fält Fyra fält Exempel från Östergötland: sju olika sätt att dokumentera läkemedelsöverkänslighet Många interoperabilitetsproblem kan ej lösas med en algoritm (t.ex. en formel eller datorprogram). En övertro på automatiserade översättningsprocesser eller integrationsplattformar kan innebära patientsäkerhetsrisker

10 Semantisk interoperabilitet
Semantisk interoperabilitet? Meddelanden eller systemarkitektur i fokus för normering? Normering Normering export/import export/import export/import Normering av referensmodell och dess användande i ”källsystemen” En högre grad av normering? Undviker behov av semantiska omtolkningar. Export/import-funktioner blir triviala (algoritmiskt lösbara) och behöver inte göras om vid utökning till nya informationsmängder. Exempel på normeringsbeskrivningar: Arketyper, …

11 Vad är en arketyp? – Tankar bakom
Semantisk interoperabilitet Tvålagersmodellering separation av roller & ansvar mellan domänexperter och teknikexperter Kan kraftigt underlätta hanteringen av nya/ändrade normerade informationsstrukturer för systemleverantörer och systemägare ”Gränskontrakt” mellan informationsstruktur och terminologi/ontologi Journalinformationsdelning över spåkbarriärer

12 Systemutveckling vid tvålagersmodellering

13 Systemutveckling vid tvålagersmodellering
Kontinuerligt arbete Trädgårdsmästare? SKL, SoS, professionen? Upphandling utveckling, implementation (sällan). Eller ”köpa produkt”. Stabil! Systemutveckling vid tvålagersmodellering ”Eget liv”, Snomed CT, ICD… Upphandling drift (återkommande)

14 Vad är en arketyp? – Tankar bakom
Semantisk interoperabilitet Tvålagersmodellering ”Gränskontrakt” mellan informationsstruktur och terminologi/ontologi Exempel senare av Daniel Journalinformationsdelning över spåkbarriärer Ev. exempel i arketypeditor i mån av tid och intresse

15 Vad är en arketyp? – Mer konkret?
“Mallar” för “fristående” (kliniskt meningsfulla) bitar av journalen. Mindre arketyper kan kombineras och användas som byggstenar i större arketyper. Bestämmer hur en underliggande generell referensmodell får användas i ett visst sammanhang. Exempel: dokumentation av en viss klinisk undersökning. För att begripa detta måste vi veta vilken underliggande struktur, ”referensmodell” (RM) som skall ”arketypas” och vad den innehåller. openEHR RM (används för exempel i detta seminarium) CEN / ISO (standardisering påbörjad) HL7 CDA?

16 openEHRs referensmodell
(RM)

17 Övergripande struktur

18

19 Composition The Composition is the primary ‘data container’ in the openEHR EHR and is the root point of clinical content. Instances of the Composition class can be considered as self-standing data aggregations, or documents in a document-oriented system. The key information in a COMPOSITION is found in its content, context, and composer attributes.

20 Vid ITEM_STRUCTURE kan godtycklig trädstruktur byggas i arketyper
Composition event v.s. persistent Section och Entry The Composition is the primary ‘data container’ in the openEHR EHR and is the root point of clinical content. Instances of the Composition class can be considered as self-standing data aggregations, or documents in a document-oriented system. The key information in a COMPOSITION is found in its content, context, and composer attributes. Vid ITEM_STRUCTURE kan godtycklig trädstruktur byggas i arketyper

21

22

23

24 Folder

25

26 Section (mellanrubrik)

27

28 Description of the method (i.e. how) the information
För IT-folk OBS arv: subject (pat själv, släkting m.m.) Säkerhetsåtgärd vid inferens m.m. Om det avviker från composer i omslutande composition: provider (of information) + other_participations (e.g. nurse who administered drug) workflow_id (för koppling till ev workflow-engine) CARE_ENTRY protocol (how) Description of the method (i.e. how) the information in this entry was arrived at. For OBSERVATIONs, this is a description of the method or instrument used. For EVALUATIONs, how the evaluation was arrived at. For INSTRUCTIONs, how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a Larger care process. Guideline_id (why) An ENTRY is the root of a logical item of “hard” clinical information created in the “clinical statement” context, within a clinical session. There can be numerous such contexts in a clinical session. Observations and other Entry types only ever document information captured/created in the event documented by the enclosing Composition. An ENTRY is also the minimal unit of information any query should return, since a whole ENTRY (including subparts) records spatial structure, timing information, and contextual information, as well as the subject and generator of the information.

29 Meta-model for entry types
Denna metamodell är inget openEHR-påfund utan bygger på andras tidigare foskning (ref. se openEHR- dokumentationen) Mycket läsvärd FAQ om detta publicerades nyligen på: Börjar på en mellan-nivå Gjorda av mindre byggblock (de ni såg i editorns panel) Kan sättas ihop i större strukturer/dokument Denna nivå: små/begränsade, kliniskt meningsfulla begrepp (nära löven, långt ut i träden) ”Entry” egentligen tillräckligt på denna nivå i teorin, resten skulle kunna ”arketypas” (så gör 13606). Extra klasser/typer erbjuder dock färdig struktur enl. beprövad erfarenhet underlättar och harmoniserar/styr modellerandet. Strax titta närmare. Admin_entry: Koordinera vårdproc. (vissa bokningar(när,var) etc). Även användbart för ekonomi/redovisn (ofta används andra system). Kännetecken: Går att ta bort utan att ”compromise clinical integrity” i EHR IM.

30 Description of the method (i.e. how) the information
För IT-folk OBS arv: subject (pat själv, släkting m.m.) Säkerhetsåtgärd vid inferens m.m. Om det avviker från composer i omslutande composition: provider (of information) + other_participations (e.g. nurse who administered drug) workflow_id (för koppling till ev workflow-engine) CARE_ENTRY protocol (how) Description of the method (i.e. how) the information in this entry was arrived at. For OBSERVATIONs, this is a description of the method or instrument used. For EVALUATIONs, how the evaluation was arrived at. For INSTRUCTIONs, how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a Larger care process. Guideline_id (why) An ENTRY is the root of a logical item of “hard” clinical information created in the “clinical statement” context, within a clinical session. There can be numerous such contexts in a clinical session. Observations and other Entry types only ever document information captured/created in the event documented by the enclosing Composition. An ENTRY is also the minimal unit of information any query should return, since a whole ENTRY (including subparts) records spatial structure, timing information, and contextual information, as well as the subject and generator of the information.

31 Observation Extra stöd för tidpunkter och tidsserier. Minst en tidpunkt: (OBSERVATION.data.origin i klassen HISTORY) data, state, protocol

32 History & Event RM Data structures, chapter 6

33 Ex uppvakningsavdelning (sovande – vaken) blodtryck, saturation, puls

34 Tid i journalen

35 Evaluation data, protocol

36 Instruction & Action Planer och deras genomförande Tillståndsgraf
Mer i senare pass…

37 Vad är en arketyp? – Tekniskt sett?
Tekniskt: Arketyper anger namn (+sökvägar) samt kombinations- och valideringsregler för noder i en trädstruktur uppbyggd av objekt från referensmodellen (RM*). *) RM är en normal objektorienterad modell.

38 Vad är en arketyp? – Tekniskt sett?

39 Vad är en arketyp? – Tekniskt sett?

40 Arketypanvändning? – Tekniskt exempel.

41 Arketypsamlingar, arketypverktyg och Vårddokumentation
Mikael Nyström [Exempel kördes ”live” därav få presentationsbilder]

42 Arketypbibliotek openEHR Archetype finder Arketyp-wiki
openEHR:s bibliotek Archetype finder Ser ut att innehålla samma arketyper som openEHR:s bibliotek Prototyp av ett sökverktyg Arketyp-wiki Öppet för vem som helst att hjälpa till att utveckla arketyper NHS står bakom

43 Arketypeditorer LiU Archetype Editor Ocean Archetype Editor
Institutionen för medicinsk teknik, Linköpings universitet, Sverige Ocean Archetype Editor Ocean Informatics, Australien sk=view&id=4&Itemid=25

44 Arketypbiblioteksverktyg
ADL Workbench Ocean Informatics, Australien ch.msi?op=file&rev=0&sc=0

45 Arketypexempel Element och Cluster Observation Evaluation Section
openEHR-EHR-CLUSTER.symptom.v1.adl Observation openEHR-EHR-OBSERVATION.laboratory-lipids.v1.adl Evaluation openEHR-EHR-EVALUATION.problem-diagnosis.v1.adl Section openEHR-EHR-SECTION.SOAP.v1.adl Composition openEHR-EHR-COMPOSITION.problem_list.v1draft.adl

46 [Exempel kördes ”live” därav få presentationsbilder]
Teminologibindning Daniel Karlsson [Exempel kördes ”live” därav få presentationsbilder]

47

48 Bindning till terminologier

49 Exempel ”live” Inbyggd lokal terminologi
Det mesta kan bindas till externerna terminologier Mellanrubriker Både ”höger- och vänsterled” En arketyp som helhet … ”at-koder”, terms ”ac-koder”, constraints Code v.s. Path binding UMLS-koppling

50 Processer och aktiviteter
Daniel Karlsson och Erik Sundvall

51 Slutsatser; beslutstöd uppföljning m.m.
Vad datoriseras helt respektive delvis? (repris) Var finns processer och flöden? export/import Vård- dokumentation Slutsatser; beslutstöd uppföljning m.m. Medicinsk kunskap Generell medicinsk kunskap Domänkunskap, riktlinjer, generella processbeskrivningar, terminologisystem m.m. Vård- och omsorgsdokumentation Slutsatser (epidemiologi, uppföljning, beslutsstöd m.m.) processer och metoder för att utvinna ny kunskap ur patientdokumentation eller att relatera patientinformation till existerande kunskap Vid datorisering: Bra att hålla isär modeller (hanterbarhetsfråga) Gränsdragningar & konflikter blir förtydligade Vilken del av processerna skall gör avtryck i själva journalhandlingarna? Bör hanteras av openEHR? Arkivbeständighet? Vad skall IT-stöd för processer klara av?

52 openEHR & ”workflow” “Regarding automation of Instructions, the goal is to enable openEHR to support workflow automation without re- inventing it. The EHR is treated as a memory device available to a workflow engine, but does not try to replicate its functionality, nor oblige any automatic workflow processing to be done at all” Journalen som långtidsminne och faktabank för flödeshantering (både manuell och datorstödd) Eftersom RM är en vanlig objektmodell kan den vid senare tillfälle byggas ut till att omfatta fler delar om så önskas, t.ex. mer omfattande processtöd. Detta utan att redan existerande journaldata berörs.

53 Processer och flöden kommer i många varianter…
Olika omfattning och komplexitet Olika mängd interaktion med omgivande processer Olika syften Kan beskrivas på väldigt olika sätt …olika sätt att att impemetera i it-system kan vara lämpade för olika typer. Vi börjar vid forskningsfronten i den ”tyngsta” änden…

54 Forskningsexempel… Inte trivialt med formell beskrivning av interagerande samverkande processer. Datorer petiga med detaljer om de skall hålla många processer ”i luften” och dessutom prioritera mellan dem. Läsning av åtminstone kap 10 (7 sidor) inger respekt för områdets komplexitet.

55 Forskningsexempel…

56 Forskningsexempel… Traditionella ”workflow systems” inte självklart lämpade för patienters individuella vårdplaner Ytterligare försvårande faktorer: individanpasssningar, många aktörer, icke-determinism, komplexitet, ofullständiga specifikationer.

57 Forskningsexempel… Intressant även för patientöversikter Målstyrd processmodellering/hantering intressant för interagerande processer (icke-trivialt…)

58 openEHR & ”workflow” - Gapa över mindre…
Frestande att omfatta för mycket I samma modell. Forskning fortfarande i sin linda (men inte ung). Lås inte modell, fånga det som behöver doklumenteras I journalen och ge möjlighet att koppla in valfri “workflow engine”. Tillåt även ickeformaliserade processbeskrivningar I fritext. Obligatoriskt, ger bl.a. säkerhet och arkivbeständighet. Möjligt att aktörer från vissa organisationer saknar tillgång till eller använder annan ”workflow engine” än där journalanteckningen gjordes. Text kan med fördel automatgenereras för att undvika dubbeljobb när formaliserade processbeskrivningar används. openEHR har ”besinnat” sig på denna front… Bakgrund, inaktuellt dokument, “Instruction proposal”, (20-25 sidor) Nuvarande utformning finns i specifikationen ”EHR Information Model” (8-10 sidor) Artilkar & avhandling från S. Baretto visar mer komplex struktur än nuvanarde instruction+action.

59 = Möjligheter att ”koppla in” Eller referera till externa
”workflow engines” etc. ”lagra avtryck” För IT-folk OBS arv: subject (pat själv, släkting m.m.) Säkerhetsåtgärd vid inferens m.m. Om det avviker från composer i omslutande composition: provider (of information) + other_participations (e.g. nurse who administered drug) workflow_id (för koppling till ev workflow-engine) CARE_ENTRY protocol (how) Description of the method (i.e. how) the information in this entry was arrived at. For OBSERVATIONs, this is a description of the method or instrument used. For EVALUATIONs, how the evaluation was arrived at. For INSTRUCTIONs, how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a Larger care process. Guideline_id (why) An ENTRY is the root of a logical item of “hard” clinical information created in the “clinical statement” context, within a clinical session. There can be numerous such contexts in a clinical session. Observations and other Entry types only ever document information captured/created in the event documented by the enclosing Composition. An ENTRY is also the minimal unit of information any query should return, since a whole ENTRY (including subparts) records spatial structure, timing information, and contextual information, as well as the subject and generator of the information.

60 Description of the method (i.e. how) the information
För IT-folk OBS arv: subject (pat själv, släkting m.m.) Säkerhetsåtgärd vid inferens m.m. Om det avviker från composer i omslutande composition: provider (of information) + other_participations (e.g. nurse who administered drug) workflow_id (för koppling till ev workflow-engine) CARE_ENTRY protocol (how) Description of the method (i.e. how) the information in this entry was arrived at. For OBSERVATIONs, this is a description of the method or instrument used. For EVALUATIONs, how the evaluation was arrived at. For INSTRUCTIONs, how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a Larger care process. Guideline_id (why) An ENTRY is the root of a logical item of “hard” clinical information created in the “clinical statement” context, within a clinical session. There can be numerous such contexts in a clinical session. Observations and other Entry types only ever document information captured/created in the event documented by the enclosing Composition. An ENTRY is also the minimal unit of information any query should return, since a whole ENTRY (including subparts) records spatial structure, timing information, and contextual information, as well as the subject and generator of the information.

61 INITIAL: initial state, prior to planning activity (default starting state for computable
representation of state machine). PLANNED: the action has been described, but has not as yet taken place. POSTPONED: the action has not taken place and will not without specific conditions being met. Specifically, events and conditions that would normally ‘activate’ the instruction will be ignored, until a restore event occurs. SCHEDULED: the action will take place at some designated future time, and has been booked in a scheduling system. CANCELLED: the action was defined, but was cancelled before anything happened; it has not and will not take place. ACTIVE: the action is taking place according to its definition. The entire course of medication or therapy corresponds to this state. SUSPENDED: the action was begun, but has been stopped temporarily, and will not be restarted until explicitly resumed. ABORTED: the action began but was permanently terminated before normal completion. COMPLETED: the action began and was completed normally. EXPIRED: the time during which the action could have been relevant has expired; the action may have completed, been cancelled, or never occurred.

62 POSTPONED: the action has not taken place and will not without specific conditions being met. Specifically, events and conditions that would normally ‘activate’ the instruction will be ignored, until a restore event occurs. SCHEDULED: the action will take place at some designated future time, and has been booked in a scheduling system. CANCELLED: the action was defined, but was cancelled before anything happened; it has not and will not take place. ACTIVE: the action is taking place according to its definition. The entire course of medication or therapy corresponds to this state. SUSPENDED: the action was begun, but has been stopped temporarily, and will not be restarted until explicitly resumed. ABORTED: the action began but was permanently terminated before normal completion. COMPLETED: the action began and was completed normally. EXPIRED: the time during which the action could have been relevant has expired; the action may have completed, been cancelled, or never occurred.

63 …

64 Titta på exempel (i mån av tid)
Web Editor

65 Processer och arketyper
Generaliserade vårdprocesser (Kind-of-patient workflow) kan beskrivas i dokumentationsmallar, ex. standardvårdplaner En standardvårdplan innehåller Evidensbaserat vårdprogram Standardiserad dokumentationsmall Typiska standardvårdplaner kan innehålla observationer och instruktioner

66 Standardvårdplan

67 Framtid, tillämpningar, diskussion
Hans åhlfeldt

68 Where I come from (Alan Rector)
Clinical research & Decision Support Clinical Terminology Data Entry Clinical Record Best Practice Healthcare Mr Ivor Bigun Any country Anytown Dun Roamin GALEN Ontologies & Description logics Clinical research Decision Support & Knowledge Presentation Data Entry Electronic Health Records Best Practice

69 NHS CFH 13606 Investigations
Dipak Kalra, on behalf of Laura Sato CEN TC/251 Joint Working Group Meeting Vienna, Austria - February 2007 Dr Dipak Kalra Centre for Health Informatics and Multiprofessional Education (CHIME) University College London

70 NHS Key Conclusions: Expressing clinical information
reading, discussing and designing archetypes relatively straightforward techniques for flexible and multiple indexing of archetypes constraint formalism (ADL) support all identified requirements openEHR tools may be adapted to conform to 13606 no detailed rules or guidance for designing archetypes distinction between design patterns Observation - Evaluation – Instruction – Action (as specialisation of ENTRY) need for tools and demonstrators

71 NHS Key Conclusions: Producing and maintaining a common reference record architecture
NHS stakeholders have indicated interest in using / openEHR 13606 / openEHR are generally more easily understood by clinicians than HL7 v3 13606 / openEHR have a potential to provide a common record architecture archetypes are designed for re-use and support indexing for retrieval no large scale implementations or evaluations yet available limited support for developing a hierarchy of linked archetypes semantic coherence between archetypes must be supported by guidelines from a “clinical semantic framework”

72 RM + AM vs. SNOMED CT The SCT association Finding informer would be captured by the RM (as part of its medico-legal context) The SCT association Interprets, and its inverse Has Interpretation, are not described clearly enough in the SNOMED CT User Guide … Use of the two sub-classes of Clinical Finding: Finding and Disorder? Some aspects of the SCT context model define high-level linkages from a Clinical Finding to other Clinical Findings or to other high-level concepts. In an EHR these links would normally be between entries (through a LINK association), rather than be captured within a single entry. Basic entry structure: the openEHR EVALUATION is supported by the tools

73 Clinical finding Qualifier value Disorder Finding Pathological process
Substance – Organism – Physical fource – Physical object – Procedure - Product Qualifier value Gradual – Sudden onset Severities Episodicities Courses Periods of life Severity 0..1 Course 0..1 Occurrance 0..1 Onset 0..1 Gradual - Sudden Finding method 0..N Finding site 0..N Associated with 0..N Clinical finding Episodicity 0..1 Procedure – Clinical finding - Event Subject of record – Provider of history – Performer of method – Subject of record Finding informer 0..1 After 0..N Due to 0..N Laboratory procedure – Evaluation procedure – Observable entity Interprets 0..1 Disorder Finding Pathological process Pathological process 0..N Causative agent 0..N Substatance – Organism – Physical fource – Object – Pharma prod. Has definitional manifistation 0..N Substance – Organism – Physical fource – Physical object – Pharma product

74 RM + AM + SNOMED CT ~ mapping of SCT relations to 13606/openEHR-structures
Severity, Occurrence, Onset, Course, Episodicity (0:1) represented as an ELEMENT Finding site (0:n) represented as CLUSTER (0:n) Associated morphology (0:n) represented as an ELEMENT with unbound upper limit … … Has definitional manifestation ~ Is manifested by Associated with ~ Is related to the same health issue Due to ~ Is caused by After ~ Is sequel Interprets ~ Is cause, Revised interpretation, Evidence for Has interpretation ~ Is caused by, Is justified by

75 Utredningen

76

77 Förslag på pilotprojekt
”Arketypande” erfarenheter från modellering av vårddkokumentation mha arketyper erfarenheter från termbindning (SNOMED CT, ICF m fl terminologisystem) utveckling av ”referensarketyper” avgjutningsarketyper mot befintliga system Jfr. NHS Investigations on CEN 13606 CEN 13606/openEHR-baserade systemkomponenter vidareutveckling av systemkomponenter (bl a utvecklade inom SemanticMining) Strukturerad DataInmatning (SDI) baserat på openEHR, ”från arketyp till SDI” Pilot för processorienterat informationssystem baserat på CONTsys del 2 + openEHR/arketyper alt. HL7 CDA TIS V-TIMs kravbild re-representerad med openEHRs referensmodell Översättning – mappning – demo SNOMED CT Patientöversikt ”från vårddokumentation till kvalitetsregister”

78 Diskussion EHRCom/openEHR, CONTsys, HL7 v3… vs. lokala modeller Öppna specifikationer vs. slutna system Aktörer: verksamhetsföreträdare + konsulter + systemleverantörer + akademi + myndigheter + politik … Samordning mellan nationella projekt: NI – TIS – NTKR (SNOMED CT) – RIV … Modellering  Standardiserad referensmodell  Demonstrator/pilot  System/applikation Demonstratorers roll som katalysator för systemutveckling v1.0 Iterativ systemutvecklingsprocess

79 Forskningens roll Evidensbaserad medicin
Evidensbaserad medicinsk informatik Vad är gjort tidigare? Erfarenheter? Metod- och systemutveckling State-of-the-art + frontlinjeforskning Emerging evidence … jfr. Cochrane-studier Standarders tillämplighet? EN13606/openEHR versus HL7 CDA? Hur bygger vi en sammanhållen informationsstruktur och IT-arkitektur? Vi har ett antal pusselbitar, men vad är målbilden? Ändamålsenlig vård- och omsorgsdokumentation! Samverkan enligt Trippel-Helix universitet + näringsliv + hälso- och sjukvård (offentlig verksamhet)

80 Reservbilder följer…

81

82 MI@LiU Hans Åhlfeldt, prof Hans Gill, forskningsingenjör
Daniel Karlsson, tekn dr Håkan Petersson, tekn dr Nosrat Shahsavar, doc Leili Lind, fil dr Amir Reza Razavi, doktorand Mikael Nyström, doktorand Erik Sundvall, doktorand … … Exjobbare Studenter

83 www.semanticmining.org Principles in ontology engineering
examples: FMA, GO, SNOMED CT Terminology systems in laboratory medicine communication between bioinformatics, laboratory medicine and the EHR Multi-lingual medical dictionaries English, German, French, Portuguese, Spanish, Swedish Data/text mining in bioinformatics IR applied in biomedicine (at EBI) What can ontologies do for health statistics? study on semantic distance, use of SNOMED CT for aggregation SNOMED CT strategies for evaluation and translation The semantic-based EHR reference models based on open standards

84 Enkla men viktiga principer
Informations- och kunskapmodellering Allt skall inte dokumenteras eller modelleras i vårddokumentationssystem. Gränsdragningar till terminologisystem Semantisk interoperabilitet Undvik semantiskt riskabla omtolkningar. Normera så nära ”källan” som möjligt. Hållbart ekosystem Dimensioner av skalbarhet, system av delsystem, iterativ utveckling

85 2 1 3 Generell medicinsk kunskap Vård- och omsorgsdokumentation
”Journal” 1 2 3 Generell medicinsk kunskap Domänkunskap, riktlinjer, generella processbeskrivningar, terminologisystem m.m. Vård- och omsorgsdokumentation Slutsatser (epidemiologi, uppföljning, beslutsstöd m.m.) processer och metoder för att utvinna ny kunskap ur patientdokumentation eller att relatera patientinformation till existerande kunskap

86 Vad datoriseras helt respektive delvis?
export/import Bra att hålla isär modeller även vid datorisering Gränskonflikter blir förtydligade

87 Arketyphantering

88 openEHR-hybris? I och för sig intressant och mer substans än i vissa konkurrerande världsbilder…

89 Integration Syntactic + semantic conversion
Risk när de blandas ihop och görs innan de når målsystemet (Jfr fara i beskrivet fast XML-format, inkl semantik, för import) Semantisk omvandling fortfarande farlig (!) men mycket original-lik data finns i alla fall lätt tillgängligt vid tveksamheter. Från:

90 Spårbarhet, feeder audit (common_im.pdf)

91 Spårbarhet, feeder audit

92 För- och nackdelar för… …systemleverantörer, vårdgivare, vårdtagare?
export/import export/import export/import Hur påverkas marknad och roller nationellt? Internationellt? Kan man ”ta sina journaler” och byta systemleverantör? Om informationsmodeller är givna, är de resterande delarna å intressanta att utveckla och konkurrera kring? (T.ex. användargränssnitt, drift, lagring, prestanda, tjänster)

93 Slutsatser; beslutstöd uppföljning m.m.
Individual Patient workflow Procedures such as many types of surgery and complex, personalised medications such as anti-coagulation and chemotherapy will usually be specific to the patient, even if the overall model is more or less the same for all patients of that category. Additionally , many simple medications are also specific to the patient at least in dose if not duration, particularly those use for chronic problems such as decongestants, insulin, thyroxin etc. Vad datoriseras helt respektive delvis? (repris) Var finns processer och flöden? export/import Vård- dokumentation Slutsatser; beslutstöd uppföljning m.m. Medicinsk kunskap 2.3.1 Case Specificity Individual Patient workflow Procedures such as many types of surgery and complex, personalised medications such as anti-coagulation and chemotherapy will usually be specific to the patient, even if the overall model is more or less the same for all patients of that category. Additionally , many simple medications are also specific to the patient at least in dose if not duration, particularly those use for chronic problems such as decongestants, insulin, thyroxin etc. Kind-of-patient workflow Many workflows, such as simple surgery and many anti-biotic drug administrations, follow exactly the same process definition for all patients of a particular category. For example, any otherwise healthy adult for whom the diagnosis is “giardiasis” might be given metronidazole 500mg. Any-patient workflow Some workflows are completely independent of the patient, such as the one that a GP follows in her surgery: • accept patient; • ascertain patient concern; • perform examination; • determine assessment; • create prescription; • send patient out; Bakgrund… Vid datorisering: Bra att hålla isär modeller (hanterbarhetsfråga) Gränsdragningar & konflikter blir förtydligade Vilken del av processerna skall gör avtryck i själva journalhandlingarna? Bör hanteras av openEHR? Arkivbeständighet? Vad skall IT-stöd för processer klara av? Any-patient workflow Ex inskrivning  utskrivning Kind-of-patient workflow Many workflows, such as simple surgery and many anti-biotic drug administrations, follow exactly the same process definition for all patients of a particular category. For example, any otherwise healthy adult for whom the diagnosis is “giardiasis” might be given metronidazole 500mg. Källa: proposals/instruction.pdf

94 Meta-model for entry types
Börjar på en mellan-nivå Gjorda av mindre byggblock (de ni såg i editorns panel) Kan sättas ihop i större strukturer/dokument Denna nivå: små/begränsade, kliniskt meningsfulla begrepp (nära löven, långt ut i träden) ”Entry” egentligen tillräckligt på denna nivå i teorin, resten skulle kunna ”arketypas” (så gör 13606). Extra klasser/typer erbjuder dock färdig struktur enl. beprövad erfarenhet underlättar och harmoniserar/styr modellerandet. Strax titta närmare. Admin_entry: Koordinera vårdproc. (vissa bokningar(när,var) etc). Även användbart för ekonomi/redovisn (ofta används andra system). Kännetecken: Går att ta bort utan att ”compromise clinical integrity” i EHR IM.

95 Terminologi [Bilder av Mikael Nyström från första openEHR-seminariet]
openEHR-seminarium IMT:s seminarieserie våren 2007

96 Terminologi inom referensmodellen
En speciell typ av terminologier finns ”inbyggd” i referensmodellen Terminologierna understöder informationen i referensmodellen Terminologitypen ska inte blandas ihop med kliniska terminologier som ICD-10, ICF och SNOMED CT Exempel på vad den här typen av terminologier kan innehålla: Språk Länder Teckenuppsättningar Mediatyper Kompressionsalgoritmer Kontrollsiffrealgoritmer Signeringstyp Matematiska funktioner Tillståndsmaskins tillstånd Mätbara storheter Typ av deltagande Typ av relation till patienten

97 Terminologi inom arketyper
En arketyp innehåller en egen terminologi i sin ”ontologidel” Terminologin lagras som en platt lista med kod (”at-kod”), term och beskrivning Termen och beskrivningen kan finnas översatta till flera språk Fördelar med att arketyper innehåller egen terminologi är: Arketyper är användbara utan koppling till terminologiservrar Översättningar behöver inte ta hänsyn till termernas sammanhang Möjlighet att använda egna termer Arketyper kan delas oavsett externa terminologisystem Terminologins koder används till att: Identifiera en datanod i en arketyp Vara värdemängder i lövnoder at = archetype term I en blodtrycksarketyp kan en kod användas för att identifiera systoliskt och diastoliskt blodtryck. De kan även vara värdemängder för var blodtrycket togs, t ex höger arm, vänster arm, höger ben och vänster ben.

98 Terminologibindningar från arketyper
En arketyps interna terminologis koder kan bindas till en eller flera termer i externa terminologisystem Terminologibindningar gör arketypens termer bättre specificerade Bindningarna kan göras generellt till en kod eller till en kod i en viss nod i arketypen Arketyper stöder (ännu) inte bindningar till postkoordinerade termer i externa terminologisystem Ett exempel på bindning till en kod är att binda arketypens alla systoliska blodtryck till den externa termen ”systoliskt blodtryck”. Ett exempel på bindning till en kod i en viss nod är att binda det systoliska blodtrycket mätt 5 minuter efter avslutad cykling till den externa termen ”systoliskt blodtryck 5 minuter efter fysiks aktivitet” i en arketyp som innehåller flera blodtrycksmätningar.

99 Terminologibindningar från arketyper till värdemängder
Värdemängder i arketyper kan slås upp från externa terminologier En speciell typ av kod (”ac-kod”) skapas i arketypen och binds till en fråga som slår upp en (eventuellt strukturerad) värdemängd i externa terminologisystem Frågan är tänkt att exekveras i en terminologiserver Det finns (ännu) inte någon standard för frågespråket ac = archetype constraint

100 Utdelade diagram följer

101

102 Description of the method (i.e. how) the information
För IT-folk OBS arv: subject (pat själv, släkting m.m.) Säkerhetsåtgärd vid inferens m.m. Om det avviker från composer i omslutande composition: provider (of information) + other_participations (e.g. nurse who administered drug) workflow_id (för koppling till ev workflow-engine) CARE_ENTRY protocol (how) Description of the method (i.e. how) the information in this entry was arrived at. For OBSERVATIONs, this is a description of the method or instrument used. For EVALUATIONs, how the evaluation was arrived at. For INSTRUCTIONs, how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a Larger care process. Guideline_id (why) An ENTRY is the root of a logical item of “hard” clinical information created in the “clinical statement” context, within a clinical session. There can be numerous such contexts in a clinical session. Observations and other Entry types only ever document information captured/created in the event documented by the enclosing Composition. An ENTRY is also the minimal unit of information any query should return, since a whole ENTRY (including subparts) records spatial structure, timing information, and contextual information, as well as the subject and generator of the information.