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 2007-05-30

openEHR, 13 mars SNOMED CT, 17 april ”Arketyper live”, 30 maj www.imt.liu.se/mi/ehr

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

Grunder & teori

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…

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

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!

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

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

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, …

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

Systemutveckling vid tvålagersmodellering

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)

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

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 13606 (standardisering påbörjad) HL7 CDA?

openEHRs referensmodell (RM)

Övergripande struktur

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.

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

Folder

Section (mellanrubrik)

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.

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å: http://www.openehr.org/FAQs/t_entry_types_FAQ.htm 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” 8.2.2 i EHR IM.

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.

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

History & Event RM Data structures, chapter 6

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

Tid i journalen

Evaluation data, protocol

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

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.

Vad är en arketyp? – Tekniskt sett?

Vad är en arketyp? – Tekniskt sett?

Arketypanvändning? – Tekniskt exempel.

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

Arketypbibliotek openEHR Archetype finder Arketyp-wiki openEHR:s bibliotek http://svn.openehr.org/knowledge/archetypes/dev/index.html Archetype finder Ser ut att innehålla samma arketyper som openEHR:s bibliotek Prototyp av ett sökverktyg http://www.archetypes.com.au/archetypefinder/archetypefinder Arketyp-wiki Öppet för vem som helst att hjälpa till att utveckla arketyper NHS står bakom http://www.ehr.chime.ucl.ac.uk/display/nhsmodels/Home

Arketypeditorer LiU Archetype Editor Ocean Archetype Editor Institutionen för medicinsk teknik, Linköpings universitet, Sverige http://www.imt.liu.se/mi/ehr/ Ocean Archetype Editor Ocean Informatics, Australien http://oceaninformatics.biz/CMS/index.php?option=com_content&ta sk=view&id=4&Itemid=25

Arketypbiblioteksverktyg ADL Workbench Ocean Informatics, Australien http://www.oceaninformatics.biz/ http://my.openehr.org/wsvn/oe_distrib/windows/tools/ADL_Workben ch.msi?op=file&rev=0&sc=0

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

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

Bindning till terminologier

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

Processer och aktiviteter Daniel Karlsson och Erik Sundvall

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?

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.

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…

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. http://www.openehr.org/publications/workflow/t_browne_thesis_abstract.htm Läsning av åtminstone kap 10 (7 sidor) inger respekt för områdets komplexitet.

Forskningsexempel…

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.

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

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) http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/proposals/instruction.pdf 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.

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

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.

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.

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.

…

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

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

Standardvårdplan

Framtid, tillämpningar, diskussion Hans åhlfeldt

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 4431 3654 90273 GALEN Ontologies & Description logics Clinical research Decision Support & Knowledge Presentation Data Entry Electronic Health Records Best Practice

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 d.kalra@chime.ucl.ac.uk

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

NHS Key Conclusions: Producing and maintaining a common reference record architecture NHS stakeholders have indicated interest in using 13606 / 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”

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

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

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

Utredningen

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”

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

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)

Reservbilder följer…

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

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

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

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

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

Arketyphantering

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

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: http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/architecture/rm/integration_im.pdf

Spårbarhet, feeder audit (common_im.pdf)

Spårbarhet, feeder audit

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)

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… http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/proposals/instruction.pdf 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: http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/ proposals/instruction.pdf

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” 8.2.2 i EHR IM.

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

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

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.

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.

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

Utdelade diagram följer

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.