Terminology in openEHR Jussara Rötzsch Adapted from Thomas Beale
Drivers for Integrated EHRs and Semantic Interoperability• Manage increasingly complex clinical (multi professional) care• Support collaboration between multiple locations of care delivery• Deliver evidence based health care• Need for intelligent decision support in medicine• Better exploit biomedical research• Improve safety and cost effectiveness of health care• Enrich population health management and preve ntion• Empower and involve citizens
Coding in the context of integrated EHRs• Codes in the context of electronic health records are identifiers of concepts and used primarily for assisting computer processing of those concepts. They are the key to semantic interoperability • The coding of data in itself, offers very little though. Systems need to be able to make use of the codes. Todays clinical systems aren´t prepared to use codes ina way they can supply the benefits that coded data offers. This is very expensive.• So, there is a proliferation of many small, ad hoc codesets subverting interoperability achievement. • Variations… overlapping and conflicting meaning, and management and versioning issues attendant with the codesets ‐ all are barriers to EHR systems that acquire their data from many sources.• For searching of EHRs and for decision support, a single comprehensive terminology and terminology architecture is highly desirable ‐ something offering the potential power of an improved SNOMED CT. Clinical systems based on such a complex terminology require the use of codes.• The use of closed, proprietary coded terminologies and the notion of semantic interoperability are mutually incompatible. Ubiquitous semantic interoperability requires ubiquitous access to the codes and the terminology by all participating systems. Adapted from Erik Browne; http://www.openehr.org/wiki/display/healthmod/Codes%2C+EHRs+and+Sema ntic+Interoperability
Three models in the design of interoperable EHRs (most systems)• Information / Structure• Terminology / ontology / reference facts – inference about what is always true • “All pneumonia is an infection of the lungs” • “Pneumonia causes shortness of breath”• Decision support / inference / rules – inference about what is true in an individual case • John’s pneumonia is caused by pneumococcus • If pneumonia is causing shortness of breath in an elderly patient, then the patient should be hospitalized4
Patient Specific Records (1) Information Model (Patient Data Model) int e er fac r f ac e e int interface Inference Model Concept Model (Guideline Model) (Ontology) Dynamic Guideline Static Domain Knowledge (2b) Knowledge (2a)5
But how to make it true• Model of EHR and Messages – HL7 V3 RIM, CDA, & Templates – CEN 13606 & Archetypes (& Templates) – OpenEHR• Model of Terminology – SNOMED‐CT, OpenGALEN, GO, MGED, …• Model of Use of terminology – SNOMED‐CT “close to user form”, OpenGALEN Intermediate Representation Nesting‐binding‐ openEHR approach• Built independently – Overlapping content – – Independent semantics • No joint semantics6
The openEHR methodSource: Koray Atalag Fonte :Koray Atalag
TechnicalThe openEHR method INSTRUCTIONAL Technical concern DESIGN How to describe what to build LEGO BRICKS MANUAL What is possible to How to build what we put in a model want LEGO MODEL User driven What is actually built
TechnicalThe openEHR method ADL Technical concern How to describe what to record in EHRs INFORMATION ARCHETYPES MODEL What we want to What is possible to record in EHRs record in EHRs DATA User driven What is actually recorded in EHRs
Archetypes and terminology Each archetype has its own internal terminology – may be mapped to >= 1 external terminologies The Archetype terminology provides “names” – in name/value pairs – on internal value sets External terminology may be ‘bound’ to provide values for coded text nodes
What is ‘terminology binding’?• A formally expressible connection between information model representation and terminology representation of clinical statements recorded in the EHR
To do the binding • We need to know how to control the use of terminology within structured data so that it achieves what we want: • Provides basis for querying • Economically feasible• First, we need to know how to structure data so it: • Doesn’t violate ontological truths; • Is mappable to ontological concepts; • Supports data entry, storage, querying, reuse
Which ‘structured’ data?• Two kinds: • Legacy proprietary: structures are all different • Shared, standardized: agreed structures and information model, within a community of users (can be more than one such community).• The second kind we can standardize on.• Shared clinical data generally include structure and many data types.
Data are structured• Clinical statements are naturally structured, e.g. • lab results: list / tree structure; normal ranges; • Microbiology is usually a large tree structure • vital signs: timing and multiple data points; • BP: (2 data points + patient state) x time‐series • physical examination: structured by anatomy • E.g. Endoscopy of colon • assessments: structured according to e.g. temporal model of disease course; • orders: timing info, structured medication info; • actions: timing, medication structured info
Data have many types• Clinical statement data includes instances of: • Text • Coded terms • Quantity, including units, proportions, counts, etc. • URIs • Booleans • Date, time, date/time, duration • Parseable text, e.g. Units, medication timing • Other more complex types
Other sources of structure• Data capture: at the user interface, the elements of a clinical statement are naturally distinct, e.g. procedure, site, protocol, time...• Document structures: reports, referrals etc. are also structured, including audit info, sections.• For querying: data items that are queried for separately are usually separated, e.g. procedure type and body site.
What should be coded?• Answers which are: • textually expressible • whose value range is • Best modelled by as ontological description (i.e. discrete categorization), • likely to be independently queried later on. • E.g. types of disease; blood types; but not general patient story (not expressible as just concepts)• I.e. a subset of textual data, which are a subset of all data
What could be coded?• Questions which: • Need to be queried on using an agreed reference coding standard.• Example: ‘serum sodium’ (in context of blood film result of patient) does not need any coding to be 100% reliably queryable in openEHR environment. However, for the data to be re‐usable by ANYONE later on, SNOMED or LOINC ‐coding makes sense.
Understanding the binding problem• One thing complicates the task...SITUATION• Examples: • list of body positions is not the same as list of body positions pertinent to measuring BP; • valid Rh blood types differs depending on whether for blood collection or transfusion; • almost all scales, e.g. Apgar, GCS, Borg, Barthel etc. define their own value sets for common phenomena, which differ from context less value sets of the same / similar phenomena in naming and number of divisions.
Where is binding relevant in openEHR?• openEHR Archetypes ‐ essentially, maximum data sets, i.e. all data points for a given domain ‘recording’ concept (not its ontological ‘description’). • Examples: • Vitals signs: BP, Heart‐rate etc. • Labs – very structured, well understood • Physical exam – e.g. Pain, symptom....numerous! • Scales, e.g. GCS, Apgar, Barthel – ordinal data • Terminology need: globally invariant mappings; broad value sets e.g. ‘infectious agent’
Where is binding needed?• openEHR Templates ‐ essentially, use‐case specific content specifications; consist of data points from archetypes • Examples: • Discharge summary • Lab report • Encounter note • Terminology need: define local / region‐specific or specialty‐specific value sets and constraints, e.g. ‘lung infection’
Kinds of binding ‐ today• Compositional expressions already used• Direct binding to concept points• Archetype local value sets direct binding – value set specific to archetype• Ref set binding for data points that correspond to reusable value sets• Templates can have direct binding to SCT terms, with static value set defined in archetype or ref set reference