1. 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 rector@cs.man.ac.uk co-ode-admin@cs.man.ac.uk www.co-ode.org., protege.stanford.org www.clinical-escience.org

2. 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. 3 Goal 1: 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 –Plus the “Grey Boxes” Supports specification of value sets –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

4. 4 Goal 2: 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

5. 5 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

6. 6 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’ Supplementary experiments on value selection following SNOMED CMWG/Terminfo meeting London All performed with generic tools (Protégé/OWL) –Aim to identify requirements for specialised tools

7. 7 Summary of Results Captured combined HL7 and SNOMED Constraints (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” –Captured all value selection criteria Factoring into consistent submodels successful technically Representation appears scalable –Required capturing the context model from SNOMED but only headings from domain model –Input/output to MIF appears straightforward (but validation out of scope) Were able to take advantage of generic tools –Although extensive specialisation would be required to make it easy

8. 8 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

9. 9 Methods

10. 10 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

11. 11 Subclass & Containment Hierarchies Class hierarchy Expansion of selected class along associations & attributes

12. 12 Or as editable graphic

13. 13 Or as Generated Documentation (1)

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

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

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

17. 17 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

18. 18 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

19. 19 Also serve for factoring into submodels

20. 20 Put the factors together, classify, and all the key constraints are inherited Indexing factors What the developer needs to know to search Inherited constraints (with source)

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

22. 22 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

23. 23 Strengths & Weaknesses Strengths –A single representation for HL7 and SNOMED A style that captures both meaning and structure –Clearly defined semantics –ndexing & merging of submodels Including constraints based on usage/context Expressed all of the constraints in the examples: All value set requirements met in extension –“Rules” can be mutual constraints –Based on widely used standard - rapid expansion in available tools Weaknesses –Generic tooling cumbersome - specialist tooling, debuggers required Handing of numbers and strings poor in current implementation –but under revision –Relatively unfamiliar technology But becoming widely used with many tool builders in many communities –Potential complex constraints require additional rule language … but no cases encountered in feasibility study

24. 24 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 Strong notions of namespace and inclusion –Modularisation should be possible More expressive constraints than XMLSchema or RDF(S), UML, etc. –& Further extensions coming de facto & de jure

25. 25 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

26. 26

27. 27 OWL & Alternatives OWL –Defined classes & automatic creation / checking of class hierarchy –Range of restrictions Cardinality, only, some –Single representation & single strong semantics Extension require care –Indexing factoring comes ‘for free’ Alternatives –Asserted hierarchy only All hierarchies and combinations must be created manually –Limited restrictions –Multiple representations & weak semantics Easily extensible but consistency hard to maintain –Indexing & factoring not addressed