1O p en G A L E N

Binding Terminology and EHR Models:Binding Terminology and EHR Models:HL7/openEHR meet SNOMED-CT/GALEN/GO/???HL7/openEHR meet SNOMED-CT/GALEN/GO/???

Alan RectorAlan RectorInformation Management Group / Bio Health Informatics ForumInformation Management Group / Bio Health Informatics Forum

Department of Computer Science, University of ManchesterDepartment of Computer Science, University of Manchester

rector@cs.man.ac.uk rector@cs.man.ac.uk co-ode-admin@cs.man.ac.ukco-ode-admin@cs.man.ac.uk

www.co-ode.orgwww.co-ode.orgprotege.stanford.orgprotege.stanford.org

www.opengalen.orgwww.opengalen.orgwww.clinical-escience.orgwww.clinical-escience.org

2O p en G A L E N

Three models in most Health Three models in most Health Information SystemsInformation 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 hospitalised

3O p en G A L E N

interface

interface

interface

Concept Model(Ontology)

Information Model(Patient Data Model)

Inference Model(Guideline Model)

Dynamic Guideline Knowledge (2b)

Static Domain Knowledge (2a)

Patient Specific Records (1)

4O p en G A L E N

But now we have to make it trueBut now we have to make it true• Model of EHR and Messages

– HL7 V3 RIM, CDA, & Templates– CEN 13606 & Archetypes (& Templates)

• Model of Terminology– SNOMED-CT, OpenGALEN, GO, MGED, …

• Model of Use of terminology– SNOMED-CT “close to user form”,

OpenGALEN Intermediate RepresentationPEN&PAD “Perspectives”

• Built independently– Overlapping content – – Independent semantics

• No joint semantics

5O p en G A L E N

Example: The RIMExample: The RIM

6O p en G A L E N

ActsActs

7O p en G A L E N

Act & Observation in DetailAct & Observation in DetailAttributes & relations overlapping with ontology/TerminologyAttributes & relations overlapping with ontology/Terminology

subjectof care

Terminology codegoes here:

8O p en G A L E N

Example of SNOMEDExample of SNOMED

9O p en G A L E N

Act & Observation in DetailAct & Observation in DetailAttributes & relations overlapping with ontology/TerminologyAttributes & relations overlapping with ontology/Terminology

subjectof care

Terminology codegoes here: e.g.“no family history of diabetesby history”

What does it allmean together?

10O p en G A L E N

A fragment with nested ontologyA fragment with nested ontology

the ehr (hl7 rim)[moodCode=“Event” subject=“Relative” code={ } ]diabetes (subject person_in_family)

the ontology (snomed-ct) <family_hx (assoc_find Diabetes)> the combined meaning (formalism not defined)

What is legal? Required? Mandatory?What is legal? Required? Mandatory?……

11O p en G A L E N

Added Complication: Added Complication: “Close to user form” / Intermediate Representation“Close to user form” / Intermediate Representation

• Users want to see/say/tick“Nephrectomy left/right”

• But…– “Nephrectomy” = (Removal site Kidney)

• (Nephrectomy laterality Left) (Removal (laterality Left) (site Kidney))

• But a “left removal” makes no sense!

• Transform to canonical (“storage form”)– Removal site (Kidney laterality left)

• Need two-way transformations

12O p en G A L E N

And it gets worse…And it gets worse…

• Uretonephrectomy “Removal of Kidney & Ureter” – right/left

• Expands to:– (AND

(Removal site (Kidney laterality Left)) (Removal site (Ureter laterality Left)))

• And will probably get still worse…– e.g. “Ulcer of Stomach”

“Ulcer of Mucosa of Wall of Stomach”

13O p en G A L E N

Who has responsibility for the Who has responsibility for the Complexity?Complexity?

• Should applications have to understand – The nesting / binding?– The close to user form?– Can we have a standard form for applications/Decision support

to query?• The “Virtual Medical Record” or something like it

• If so– How do we express it?– How to we validate it?

• Conformance & regression tests?

– Require formalisms for• The application form• The bindings• The transformations

14O p en G A L E N

Some possible examplesSome possible examples

15O p en G A L E N

One possible transformation rule for One possible transformation rule for family historyfamily history

Shortform: “Family history must have mood code EVN”;

Paraphrase: “If the code has a context of person in family then transform it to family_history_of subject to error if mood code not EVN and subj not subkind of Relative”;

transform: [moodCode=?M subj=?*R code={disease::?D (subj_rel_ctx person_in_family::?P)} ] <family_hx of (assoc_find ?D)>;

bindings: ;

error_conditions: NOT EVN::?M -- ‘?M “illegal mood. Only EVN mood with family history”’ :: E3.5.1, NOT (Relative::?R OR ?R=nil)-- ‘“HL7 subj ” ?R “not compatible with SCT sub_rel_ctx ” ?F’ :: E3.5.2.

16O p en G A L E N

One possible rule for requestsOne possible rule for requests

ShortForm: “Requests must be indicated by intents”

Paraphrase: “If the context is a subtype of request, the mood must be Intent (and may not omitted). The statement will transform to an application form ‘request_for…’”;

transform: [moodCode=?M code={procedure::?P proc_context request::?R}] <Request_for assoc_proc ?P>;

bindings: ;

error_conditions: NOT INT::?M -- ‘?M “illegal mood Only INT mood with requests”’ :: E2.5.1.

17O p en G A L E N

And the converseAnd the converse

ShortForm: “Intents must indicate requests”

Paraphrase:“If the mood is intent, then there must be a context of subtype of request; transform to an application form ‘request_for…’”;

transform: [moodCode=INT::?M code={procedure::?P proc_context request::?*R}] <Request_for assoc_proc ?P>;

bindings: ;

error_conditions: NOT request::?R -- ‘?R “illegal context with mood” ?M “Only requests allowed with INT moods”’: E2.5.2.

18O p en G A L E N

Transformation of Transformation of “Close-to-user” representation“Close-to-user” representation

Shortform: “Move laterality from procedure to anatomical site”;

Paraphrase: “If code for a subclass of procedure_by_site is lateralized, move the lateralization to the anatomic site, provided that the procedure and site can be determined, the site can be lateralized, and the site is not already lateralized incompatibly.”;

transform: {procedure_by_site::?PbS laterality side::?L} {procedure::P site (anat::?S laterality ?L)};

bindings: ?P=procedure(?PbS), ?S=site(?PbS) ; ?LPbS=laterality(?PbS)

error_conditions: ?P=nil OR ?S=nil -- ‘“Cannot decompose” PbS’::E1.2.3,

laterizable(?S)=false -- ‘?S “ not laterizable”’:: E1.2.4, ?LPbS NOT IN (nil, ?L)-- ‘“Laterality of ” ?L “ conflicts with ” ?Y’:: E1.2.5.

19O p en G A L E N

A digression:A digression:Re-usable FragmentsRe-usable Fragments

• Medicine is a fractal structure of niches– Many too many to deal with in a single model

• So we have special submodels

– RIM RMIMS MDM Message• UMLMOF objects• Archetypes and templates

– ADL Template language

– CEN 13606/EHCRA Archetypes

• And need for arbitrary assemblages of reusable fragments– “Templates”?

• Specifications & constraints

20O p en G A L E N

Formalisms neededFormalisms needed

• How many?– Combine transformations & validation or separate?

– Combine denesting/binding & terminology transformation?

– A common representation for the terminology and structure models

• OWL? Other?

– A special language for reusable fragments & constraints?• ADL?

RMIM…MDM methodOWL + SWRL? UML+OCL?

21O p en G A L E N

Some CandidatesSome Candidates• Transformation languages

– Grammar-like– JESS rules– SWRL– other?

• Binding/constraint languages– UML+OCL– ADL– OWL+SWRL– PAL– Grammar like

• Application language + Query Language– Data model like: UML+OCL?– RDF(S) – for the instances?– Ontology like: OWL? OWL++?

• What else would be needed?

– Other?

22O p en G A L E N

RequirementsRequirements

• Expressive adequacy

• Ease of understanding by– Application Developers

– Clinical terminologists

• Easily / compulsorily annotatable

• Links to larger communities– Limit reinvention of wheels

23O p en G A L E N

The Application FormThe Application Form

• Applications should drive application form– May want to allow filtering out of detail

• e.g. Family history may be sufficient without detail of which relative

– Should be designed to be (relatively) stable wrt changes in both messages and terminology

• But requires a regression testing strategy

– May need only a partial mapping initially• Initial decision support rules likely to be simple

– Complexity will be limited by development of standard

– May need different forms for different applications• But all specified in the same way

24O p en G A L E N

Where Is OWL Appropriate?Where Is OWL Appropriate?

• Some considerations– Beware…

25O p en G A L E N

FormalismsFormalismsNot all Hierarchical Formalisms are the sameNot all Hierarchical Formalisms are the same

• Relations and objects – associated with– UML (class diagrams), ER diagrams, …

• Nested containers – containment/ has_node/items/…– XML– CDA, Archetypes, Templates

• Logical subsumption – kind of, implies– OWL, GRAIL, KRSS, …

• Thesauri – broader than/ narrower than– MeSH

• Grouping for purpose – is classified as– ICD 9/10, DRGs, CPT, OPCS 4/5, …

26O p en G A L E N

Nested ContainersNested Containers

<data_body>

<element> … </element> * <cluster> <element> … </element> * …

</cluster>

</data_body>

27O p en G A L E N

Nested Suitcase ModelNested Suitcase ModelXML and OpenEHRXML and OpenEHR

Body

element

element

cluster

element

element

28O p en G A L E N

UML styleUML style

body elementcluster

Simplified OpenEHRgeneralisation and association

Entity

29O p en G A L E N

Subsumption & Subsumption & association/containmentassociation/containment

subsumption containment

30O p en G A L E N

OWL Ontologies are not DatabasesOWL Ontologies are not Databases

• OWL– binary relational– open world

• Universals about all possible worlds

• negation = impossibility

– efficient for reasoning about classes

– questions – standard reasoning• is C satisfiable?• Is B a kind of C?

– Flexible and Fractal– Metadata separate and

awkward– Individual/class reflects world

• Database/Logic programming– n-ary relational

– closed world• Specifics about this world

• negation = failure

– efficient for reasoning about instances

– Questions – standard reasoning• Are there any Cs

• Are there any Bs that satisfy C?

– Fixed and rigid

– Metadata in schema (use varies)

– Instance/class reflects implementation

31O p en G A L E N

Indexes and RepositoriesIndexes and Repositories

• Using ontology to manage a repository of information– Classified ontologies make good indexes

– e.g. Combine:• Setting,

• Task,

• Condition,

• Use,

• Medium

32O p en G A L E N

Before classificationBefore classificationA simple treeA simple tree

33O p en G A L E N

After classificationAfter classificationA principle DAGA principle DAG

Index and inherit EHR FragmentsIndex and inherit EHR Fragments

34O p en G A L E N

Testing and MigrationTesting and Migration

• Building a life cycle – is it fit for use? – What is the migration path?

– Use/test cases & exemplars

– Identifying problems – alternative solutions - exploring consequences – deciding amongst alternatives

– Specifying solutions• Human and machine readable form

– Setting conformance tests for specifications• Building reference Implementation

– Monitoring for problems• Recording of problems and changes

35O p en G A L E N

user facing discover services – language, browsing, C0HSE/SW, Google, etc

Middleware Brokers

application service discovery

TerminologyServices

EHR/MessageServices

Use specsArchetypes,

Templates, UIServices

Lexicons/LanguageServices

Classificationservices

KnowledgeManagement

Services

DecisionSupport

Services & Applications

E-Health Care System Design & Governance

Clinicalusers

Public & Patients

Knowledge Authors

EHRModellers

Dec’n Support Developers

ApplicationDevelopers

QA, Testing & Monitoring

Services

BindingsTransformations

& Views

36O p en G A L E N

37O p en G A L E N

Meaning, Use & StructureMeaning, Use & Structure

• Models of use– When it is needed – what should be “handy”

• To say? to Ask? To Find? To use?• The “how” as well as the “What”

• Model of meaning– What can be be said – what it implies

What can be asked – what it includesWhat do the ‘chunks’ mean?

• Model of Structure– How it is to be used

• Ontology nested in EHRs– HL7 Terminfo

» HL7 + S-CT– CEN 13606 + Archetypes + Compositional terminology

• Interface specifications, regression testing, conformance testing

38O p en G A L E N

Uses – Uses –

• Many systems embody one use– Data entry

• ORCA, MedCin

– Decision support• QMR vocabulary

– Epidemiology• ICD

– Information indexing• MeSH

• A few systems make split explicit– GALEN/PEN&PAD Perspectives– Read “Entry terminology”– S-CT “Close-to-user” forms

39O p en G A L E N

Lessons from GALEN/PEN&PADLessons from GALEN/PEN&PAD

• Architecture – orthogonal– Meaning

LanguageClassificationEntryIndexing – “Reference Knowledge Resources”

• Use follows practice rather than meaning– Use requires additional information

• Some additional information can be indexed on the ontology

– Use does not interoperate in detail• Formalisms for specifying model of use can interoperate

40O p en G A L E N

Separation incorporated in the GALEN Server

A single point of access for language, classification, code conversion, and indexing - well separated internally

API

Refe

rence

Managem

ent Multilingual Dictionaries

MultilingualModule

Common Reference Model

ConceptModule

Code Store

Code ConversionModule

ClientApplication

Server

Client

Extrinsics Store

IndexingModule

41O p en G A L E N

Data entryData entry

• In a setting for a task by a user about a condition

• What is common & must be fast?What is necessary & must be safe

• Any data entry protocol is in part a guideline

42O p en G A L E N

43O p en G A L E N

ClassificationClassification

• Model of use for epidemiology and recording– Strongly built in and difficult to disentangle

– Volume II of ICD most explicit

• Index to starting points and rules– Simplification

• But leaves much to do

44O p en G A L E N

ClassificationClassificationMap rather than Model for Legacy SystemsMap rather than Model for Legacy Systems

No MatchNo Match

One MatchOne Match

More than one MatchMore than one Match

ExclusionsExclusions

Hypertension excluding in pregnancy

Hypertension during

Pregnancy

46O p en G A L E N

AuthoringAuthoring

• Intermediate representation– Split domain expert, ontology expert, and

implementor tasks

– Separate information collection from Structure

O p en G A L E N46

RUBRIC "operations on papillary muscle"CODE "35.31"MAIN surgical deed

ACTS_ON papillary muscleHAS_OTHER_FEATURE method VALUE induced arrest of heart

RUBRIC "dividing of papillary muscle"CODE "35.31.i1"MAIN dividing

ACTS_ON papillary muscleHAS_OTHER_FEATURE method VALUE induced arrest of heart

RUBRIC "reattachment of papillary muscle"CODE "35.31.i2"MAIN repairing

ACTS_ON papillary muscleBY_TECHNIQUE reattaching

ACTS_ON papillary muscleHAS_OTHER_FEATURE method VALUE induced arrest of heart

RUBRIC "repair of papillary muscle"CODE "35.31.i3"MAIN repairing

ACTS_ON papillary muscleHAS_OTHER_FEATURE method VALUE induced arrest of heart

IntermediateRepresentation

Expertise to beconserved

Model of authoring

Internal RepresentationInteroperable formModel of Meaning

Transformations& tools

48O p en G A L E N

Model of Use 1:Model of Use 1:“Close-to-user” representation“Close-to-user” representation

• Users want to say“Nephrectomy” right or left?– “Left Nephrectomy”

• Literal tranlstion would be– “Left ‘Removal of Kidney’”

• Must represent it as– “removal of ‘left kidney’”

– “removal of (kidney has_side left)”

49O p en G A L E N

““Close-to-user” representationClose-to-user” representation

Shortform: “Move laterality from procedure to anatomical site”;

Paraphrase: “If code for a subclass of procedure_by_site is lateralized, move the lateralization to the anatomic site, provided that the procedure and site can be determined, the site can be lateralized, and the site is not already lateralized incompatibly.”;

transform: {procedure_by_site::?*PbS laterality side::?L} {procedure::P site (anat::?S laterality ?L)};

bindings: ?P=procedure(?PbS), ?S=site(?PbS) ;

error_conditions: ?P=nil OR ?S=nil -- ‘“Cannot decompose” PbS’::E1.2.3, laterizable(?S)=false -- ‘?S “ not laterizable”’:: E1.2.4, ?LPbS=laterality(?PbS) NOT IN (nil,L)— ‘“Laterality of ” ?L “ conflicts with ” ?Y’:: E1.2.5.

50O p en G A L E N

Model of Use IIModel of Use II

• Ontology nested in an information model– EHR or Message (openEHR/Archetypes)

(HL7 RIM/Templates)

51O p en G A L E N

Decision Support / ApplicationsDecision Support / Applications

• What do applications query?– Who owns the complexity?

• Does every application have to know everything?

– “Conservation of complexity”• Ignoring it just pushes the problem onto somebody else

• Beware – meaning of queries vs meaning of statements– Meaning of queries dependent on use

• Does the patient has “Asthma”?– For triggering a warning about drug contraindications

– For establishing a diagnosis

– For entry into a clinical trial

52O p en G A L E N

Key Research QuestionsKey Research Questions

• Formalising models of use– UML has >6 formalisms

Ontologies currently only have one. Why?

– Formalising transformations

• Formalising views– A short statement analogous to DB view:

“A view is a reified query, persistent or transcient”

• Formalising a decision support API– Formalising semantics of nested representations