Post on 04-Jan-2016
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