1 Towards a Unified Representation: Representing HL7 and SNOMED in OWL Alan Rector 1 & Tom Marley 2 1 Information Management Group / Bio Health Informatics Forum Department of Computer Science, University of Manchester 2 Salford Health Informatics Research, University of Salford With the support of NHS Connecting for Health protege.stanford.org

2 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 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 Hypotheses 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 Experiments 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 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)(here)

7 The 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 Methods

9 Representing HL7 in OWL: Basic 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 Hierarchies

11 Or as editable graphic

12 Or as Generated Documentation (1)

13 Property hierarchy Required Common super-property for expansion RIM Association s RIM Attributes CD Value type / SNOMED attributes

14 Other Details in report Associations & attributes Domain, ranges, and value sets Optional/Required/Mandatory

15 Simple Rules Definitions + Constraints = Rule Definition/Premise: IF mood code RQO THEN Constraint: Must have status code from these necessary & sufficient necessary

16 Full version of a Defined Class as a rule IF a request for administration has an Act code fitting the npfit stopped pattern THEN it must satisfy these constraints

17 Mutual constraint rules A medication Act must have a Medication Consumable & 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 submodels

19 Put the factors together, classify, and all the key constraints are inherited Indexing factors What the developer needs to know to search Inherited constraints (DL syntax)

20 Run classifier to get a list of all the existing CMETs to be used as examples/templates

21 Unit Tests Checks 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 & 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 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 Summary 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