1

Towards a Unified Representation:Towards a Unified Representation:Representing HL7 and SNOMED in OWLRepresenting HL7 and SNOMED in OWL

Alan RectorAlan Rector11 & Tom Marley & Tom Marley22

11Information Management Group / Bio Health Informatics ForumInformation Management Group / Bio Health Informatics ForumDepartment of Computer Science, University of ManchesterDepartment of Computer Science, University of Manchester

22Salford Health Informatics Research, University of SalfordSalford Health Informatics Research, University of Salford

With the support of NHS Connecting for HealthWith the support of NHS Connecting for Health

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.org., protege.stanford.orgwww.co-ode.org., protege.stanford.orgwww.clinical-escience.orgwww.clinical-escience.org

OpenGALEN

2

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)

3

Two Related GoalsTwo Related Goals• A uniform representation with for SNOMED nested in HL7 RIM

– Sound and sufficiently expressive• Supports the constraints in the specified RMIMs (by NHS not us)

– All those formally expressed in UML/RMIM– The “Grey Boxes”

– Allows RMIMs/CMETs to be factored into reusable submodels • Support uniform policies across domains

– Closely related to Template / Archetype

– Includes a principled account of negation & flavours of NULL– Leads to suitable standard forms for querying for decision support

• Supports the development process & provides basis for tooling– Allows natural transformation to MIF/XML formats– Allows arbitrary indexing of reusable submodelss

• Lets developers find the appropriate submodels / “Recipes”

– Supports validation and conformance testing– Supports automatic documentation– Is scalable and extensible

4

HypothesesHypotheses

• By the use of a flexible and expressive formalism, it will be possible to publish constraints from multiple sources in a single artefact/document, and in a common form.

• A single publication in a common form will support– Concept development

– Message & submessage development

– Maintaining policies / Prevention of inconsistencies

– Testing & automated production of test tools

– Documentation & automated generation of documentation

– The rules can be used by message generation systems to ensure messages are correctly formed

5

ExperimentsExperiments

• Represent Request for Medication Administration & related messages from NHS “Connecting for Health” set ( MIM )– Capturing all information in the “Grey Boxes” on

the RMIMs• Literal interpretation of CfH documentation• Plus some potential additional demonstration constraints• Plus additional experiments in ‘factoring’

• All performed with generic tools (Protégé/OWL)– Aim to identify requirements for specialised tools

6

Summary of ResultsSummary of Results• Captured combined HL7 and SNOMED

– (within the framework of the CfM templates)

• Captured all of the information in the ‘grey boxes’ constraints on the RMIMs– Except for one ill defined constraint including “elsewhere”

• Factoring into consistent submodels successful technically

• Representation appears scalable– Required capturing the context model from SNOMED

• but only headings from domain model

– Appears that most message/submodel domains could be handled separately– Classification time modest

• Were able to take advantage of generic tools– Although extensive specialisation would be required to make it easy

• Hypertext report (here)

7

The Hypertext ReportThe Hypertext Report

• NotNot NHS policy– A feasibility study only

• A draft– Still evolving with discussions

• A specific experiment against Connecting for Health specifications (formally National Programme for IT NPfIT)

– Some oddities with respect to current HL7/SNOMED/Terminfo practice

– Deliberately literal as fixed point for an experiment

• To be available RSN

here

8

MethodsMethods

9

Representing HL7 in OWL:Representing HL7 in OWL:Basic IntuitionsBasic Intuitions

• Use the property hierarchy – all links in one direction in both HL7 and SNOMED have a

common super-property (demo:has_item)

• Represent required relations as existential restrictions– “Unfold” along the existential restrictions to get MIF/XML type

view

• Represent ‘clones’ as subclasses

• Use namespaces to modularise– e.g. “npfit:”, “snct:”, “demo:”, etc.

• Represent HL7 data structures for SNOMED rather than SNOMED per se

• Use ‘existential tree’ to show class hierarchy and XML-like containment hierarchy simultaneously

10

Subclass & Containment HierarchiesSubclass & Containment Hierarchies

11

Or as editable graphic Or as editable graphic

12

Or as Generated Documentation (1)Or as Generated Documentation (1)

13

Property hierarchy RequiredProperty hierarchy RequiredCommonsuper-propertyfor expansion

RIM Associations

RIM Attributes

CD Value type /SNOMED attributes

14

Other Details in reportOther Details in report

• Associations & attributes

• Domain, ranges, and value sets

• Optional/Required/Mandatory

15

Simple RulesSimple RulesDefinitions + Constraints = RuleDefinitions + Constraints = Rule

Definition/Premise: IF mood code RQO

THEN Constraint: Must have status code from these

necessary necessary

& sufficient& sufficient

necessary necessary

16

Full version of a Defined Class as a Full version of a Defined Class as a rulerule

IF a request for administration has an Act code fitting the npfit stopped pattern

THEN it must satisfy these constraints

17

Mutual constraint rulesMutual constraint rulesA medication Act must have a Medication A medication Act must have a Medication

Consumable & vice versaConsumable & vice versa

Any class indexed by medication

Any class with a participation Medication_consumable (participation)

Is is the same as & vice versa

18

Also serve for factoring into Also serve for factoring into submodelssubmodels

19

Put the factors together, classify, andPut the factors together, classify, andall the key constraints are inheritedall the key constraints are inherited

Indexing factorsWhat the developerneeds to know to search

Inherited constraints(DL syntax)

20

Run classifier to get a list of all the Run classifier to get a list of all the existing CMETsexisting CMETs

to be used as examples/templatesto be used as examples/templates

21

Unit TestsUnit TestsChecks on what should or should not workChecks on what should or should not work

• Test whether constraints work– unsatisfiable ‘probe classes’

• Ensure that constraints are not too stringent – Satisfiable ‘probe classes’

• Run report that all probe classes come out as expected

22

Strengths & WeaknessesStrengths & Weaknesses

• Strengths– A single representation for HL7 and SNOMED

• Based on widely used standard - natural links to Semantic Web

– Automatic organising, indexing & merging of submodels– “Rules” can be mutual constraints– Expressed all of the constraints in the examples– A style that captures both meaning and expansion– Clearly defined semantics

• Weaknesses– Potential complex constraints require additional rule language

• … but no cases encountered in feasibility study

– Generic tooling cumbersome - specialist tooling, debuggers required– Handing of numbers and strings poor but under revision– Relatively unfamiliar technology

• But becoming widely used

23

What’s special about OWLWhat’s special about OWL

• A standard syntax for generic Description logic technology– Widely used for schema unification & harmonisation

• Defined classes and automatic classification– Automatic organisation / indexing of submodels– Constraints/Rules of the form:

Any submodel including a fragment of this form MUST satisfy these constraints

– Strong semantics - lack of ambiguity

• More expressive constraints than XMLSchema or RDF(S), UML, etc.

24

SummarySummary

• A uniform representation is possible– A recipe for translation is available\– Almost certainly scalable

• But further confirmation needed

• Most constraints/rules including mutual constraints can be represented naturally– Complexities possible in theory did not arise in practice

• But will probably need to be dealt with eventually

• Factoring into submodels effective– Indexing and checking of submodels natural

• A major tooling effort is required to make it easy– But tied into a broader standards effort where tools are being

produced