1. BioHealth Informatics Group 1 OWL, HL7, SNOMED, and UML Making Models Managable Alan Rector, University of Manchester Tom Marley, University of Salford rector@cs.man.ac.uk T.Marley@salford.ac.uk

2. BioHealth Informatics Group 2 HL7 & SNOMED: Issues for sustainable implementation ►HL7 ►Variable structure leading to difficult maintenance ►How to the same thing the same way or know the reason why ►Finding standard ways of saying things - ‘recipes’ for developers ►(See also Tom Marley’s recent note) ►Modularisation and Re-use of Modules ►The semantics of ‘cloned classes’ ►Expressing constraints ►Including “The grey text boxes” ►SNOMED ►Context ►Negation

3. BioHealth Informatics Group 3 HL7 + SNOMED Issues ►Interaction of HL7 & SNOMED ►Binding, mutual constraints, Negation & NULL values ►Complexity and documentation ►Co-evolution ►How to know the effects of changes ►How to manage regression/conformance testing ►A DL based terminology nested in an UML type model but developed independently\ ►An almost unique problem to Healthcare

4. BioHealth Informatics Group 4 The experiment: A Feasibility study ►Could the pharmacy examples be represented in OWL: ►So as to capture all the contents of the RMIMs etc themselves? ►So as to represent the bindings to SNOMED? ►So as to capture the constraints in ‘grey boxes’ on the RMIM diagrams? ►So as to support factoring into modules & indexing? ►So as to allow regression/conformance testing? ►To be done using existing tools ►Specialised user environment required for any production work

5. BioHealth Informatics Group 5 The main conclusion: There is a problem, Current tooling will not solve it ►The issue is variability between models rather than constraints ►Constraints we can manage, but… ►Patterns are only approximately followed ►Only as systematic as human beings using copy & paste ►There are no generic models or formal mechanisms for specialisation ►Information is not always in the same place ►e.g.: “Dosage instructions” vs “Timing Instructions”, ►If there is a clear difference? it is not documented, let alone formally specified ►Maintenance will therefore be difficult or impossible ►Cannot predict effects of changes ►Costs will be difficult to control … and this was only for one domain developed by a small team

6. BioHealth Informatics Group 6 The main conclusion: There is a problem, Current tooling will not solve it ►Investment in new technology is necessary to manage the problems ►OWL could address these problems and meet other requirements ►(with significant new tooling) ►The main benefit of using OWL would be to improve & formalise of modelling to ►Lower maintenance costs ►Let models scale ►Reduce risk of catastrophic failure ►Improve conformance of implementations ►Ultimately, to make development faster and cheaper

7. BioHealth Informatics Group 7 Specific results: More successful than anticipated ►We know it can be done ►Succeeded in initial version on content, binding, and constraints ►Separate study on factoring ►Primary difficulty is understanding HL7 rather than representation in OWL ►Revised binding and alternative representation of SNOMED developed subsequently ►Covers additional requirements for binding presented subsequently: ►Specified code set ►All descendants of a given code ►Any boolean combination of above

8. BioHealth Informatics Group 8 Cut to HTML Report Here

9. BioHealth Informatics Group 9 ►What is OWL? ►What is Protégé ►What does OWL do? ►What part of the problem might they address? ►What parts of the problem could it not address? ►What would a programme using OWL look like?

10. BioHealth Informatics Group 10 What is OWL? ►A general representation language and standard ►A standard way to use Description Logic Technology ►Language Features ►A superset of UML class models as used in HL7 ►True negation, and, or, cardinality, local and global range/domain ►Rigorous semantics ►Use ►Compositional and modular ►Definitions to link modules ►Well defined normalisation procedure ►Namespace mechanism ►Features ►A uniform rule mechanism for both classes and instance ►Standards backing and tools

11. BioHealth Informatics Group 11 What is Protégé ►A plug and play environment for intelligent information systems ►Probably the most widely used OWL development environment ►Several interfaces developed for different groups of users ►Several backends for different applications

12. BioHealth Informatics Group 12 What does OWL do? ►Imposes & checks consistency, locally and globally ►Do subclasses conform to superclass requirements? ►Does each class conform to overall constraints? ►Difficult even with the ETP set of tens of messages ►How to achieve for thousands of messages? ►Classifies ►Manages muiltiple hierarchies ►Indexes & composes subtemplates ►A natural effect of classification ►Manages combinatorial explosions ►By dealing with each axis separately

13. BioHealth Informatics Group 13 Example: Decomposing Pharmacy Acts (MIM v4.0.01) RecommendAdminister Single dose Aborted RequestSupplyCourse(Completed) Plan(Active) Perform Apparently 1 family; 4 axes 8 selected from 48 possible. Why? Which are legal? Which make no difference? e.g. Can one plan supply? Abort a request for administration?

14. BioHealth Informatics Group 14 Enter in Tool, Classify structure Is this what was intended?

15. BioHealth Informatics Group 15 OWL based systems: Conceptual Lego recommended request event aborted completed Procedure Observation Medication Role Person Participation Administer Supply

16. BioHealth Informatics Group 16 OWL based systems: Conceptual Lego “Request for Medication Administration aborted” “Performance of medcation administration”

17. BioHealth Informatics Group 17 Logical Constructs build complex concepts from modularised primitives “Mood” Act Substance Status Disease Request for| administration of Steroid Completed request for Administration of Steroid Completed request for administration Of steroid for Asthma “Request for Administration”

18. BioHealth Informatics Group 18 Normalising (untangling) OWL Models Act Status Mood Act Status mood

19. BioHealth Informatics Group 19 Today’s demonstration ►Introduction to UML and HL7 in OWL ►Composition and factoring ►Constraints

20. BioHealth Informatics Group 20 Basic conventions (1) ►All submodels and clones are sublcasses ►All associations and attributes are expressed as OWL properties ►All relevant properties are subproperties of “demo:has_item” ►“Unfolding” along demo:has_item gives the submodel skeleton

21. BioHealth Informatics Group 21 Everything in OWL is expressed by subclassing: Part of the Act Class Hierarchy

22. BioHealth Informatics Group 22 All associations & attributes are expressed as subproperties of demo:has_item: Part of the properties hierarchy

23. BioHealth Informatics Group 23 “Unfolding along demo:has_item gives the skeleton of the message Unfolding: The Message skeleton Not to be confused with The class hierarchy

24. BioHealth Informatics Group 24 Basic Conventions (2) ►Modules are marked by namespaces: e.g. “npfit:”, “hl7:”, etc. ►The SNOMED structure is modelled as in HL7 messages ►SNOMED qualifier structures are represented in the same way as any other class

25. BioHealth Informatics Group 25 Basic Conventions (3) ►Everything in OWL is expressed by subclassing ►If a subclass has a definition, then it behaves as a rule, e.g. IF anything satisfies the definition THEN it must satisfy the necessary conditions ►Definitions are expressed as “necessary and sufficient” conditions

26. BioHealth Informatics Group 26 Can have multiple definitions - Equivalent to if and only if ►Useful for managing HL7/SNOMED mutual constraints ► IF anything satisfies any of the definitions THEN it must satisfy all of the definitions AND it must satisfy the necessary conditions ►Anything that ► has an Act_Code with a SNOMED context of Active (including descendents) ►must have an Act_status_code of Active (including any descendents) ►AND vice versa. ►Anything satisfying either of the above ► must have a pertinent information request.

27. BioHealth Informatics Group 27 Example in Tool “Definitions”: necessary & sufficient “Description:” Necessary conditions

28. BioHealth Informatics Group 28 Everything in OWL is checked by the ‘Classifier’ (aka ‘Reasoner’) ►The classifier serves three functions: ►To check consistency ►that the strict classification hierarchy and constraints are maintained ►That all unit tests come out as expected ►To create a multiple hierarchy and combine subtemplates ►Classes moved under each definition that they fit ►To index classes

29. BioHealth Informatics Group 29 (sub)Templates are just OWL classes that can be combined by the classifier ►Call them “factors” ►Medication_factor ►Completed_factor ►Administration_factor ►Request_factor ►Together they form a Completed_request_for_Medication

30. BioHealth Informatics Group 30 The example templates in the tool

31. BioHealth Informatics Group 31 Classification: Graphics view (simpler case) before after (defined classes in orange)

32. BioHealth Informatics Group 32 The example: Before classification: Four parents, simple structure

33. BioHealth Informatics Group 33 After classification: Polyhierarchy of parents

34. BioHealth Informatics Group 34 Put them together to form required sublcass If inheritance doesn’t work when checked by the classifier, then something is broken

35. BioHealth Informatics Group 35 Adding unit testing to classification ►Create “probe” classes to test constraints ►Classes that violate constraints to test that they constrain ►Classes that are just outside constraints to check that they are not caught accidentally. ►Mark each class with expectations ►Run tests after classification for conformance/regression testing List of Unit Tests - green checks indicate passed - red indicates inconsistent - green + red indicates deliberately inconsistent

36. BioHealth Informatics Group 36 Other Benefits: OwlDoc

37. BioHealth Informatics Group 37 The SNOMED Binding Problem ►Which codes to use where? ►Code set specification ►Sets of specified codes ►Expressions specifying large sets codes ►Boolean combinations of above ►Mutual constraints between HL7 & SNOMED ►HL7 mood, status, etc. codes ►SNOMED context model ►Code, Value, and Target attributes ►(Controversies between USA and UK)

38. BioHealth Informatics Group 38 Observation class Kernel clinical notion Terminology/Ontology Context model

39. BioHealth Informatics Group 39 Example ontology nested in the EHR the ehr (hl7 rim) [moodCode=“Event” subject=“Relative” code={ } ] diabetes (subject person_in_family) the ontology (snomed-ct)  the combined meaning What is legal? Required? Mandatory?…

40. BioHealth Informatics Group 40 One of David Markwell’s rules from Terminfo: mood=EVN  subject_relationship= Person OR New

41. BioHealth Informatics Group 41 One of David Markwell’s rules in OWL Fully expanded version If you really want to you can say it all in one long expression; Alternatively you can name every step; or anywhere in between

42. BioHealth Informatics Group 42 Limitations of OWL: “ it doesn’t make the coffee” ►Object-attribute-value triples only No variables, No n-ary relations ►Did not limit this study Close match to UML limitations (as used in HL7) ►Strictly first order ►How HL7 represents SNOMED rather than being “SNOMED in OWL” ►Open World - advantage and disadvantage ►Requires explicit closure axioms when translating from databases ►A new technology, and a new application of that technology ►Needs tools and training ►Numeric ranges and strings new and not tested in this validation ►A strictly temporary problem, now almost resolved.

43. BioHealth Informatics Group 43 What might a process using OWL for subtempates be like in production? ►For message design and validation ►In a ‘steady state’ ►For message re-design and validation ►As a migration path ►For instance validation ►At run time

44. BioHealth Informatics Group 44 For message design and validation ►A two phase process ►Subtemplate design ►Create subtemplates / re-usable models and index them ►Test by combining to create exemplar messages ►Validate, classify and commit results ►Document, publish and add to repository ►Message design ►Identify subtemplates via index ►Combine and check consistency with classifier ►Refine / specialise as needed ►Report and negotiate any changes to templates ►Validate, classify & commit results ►Document, publish and add to repository

45. BioHealth Informatics Group 45 Template & Message design two phases / cycles Message development Quick turn around Modest expertise required Highly specialised but restricted tools Problems fed to subtemplate / pattern developers Re-usable subtemplates and pattern development Slower turn around More expertise required More general less restricted tools Respond to new requirements & problems

46. BioHealth Informatics Group 46 What might a process involving OWL be like in transition: ►For message re-design and validation ►Import of families of representations from MIF to OWL ►Rearrangement and editing in OWL using special tools and scripts ►Addition of editorial information ►Refactoring and indexing as appropriate ►Classification for validation and organisation ►Commitment of classification results ►Export to MIF (or XMI …)

47. BioHealth Informatics Group 47 Validating instances ►Method 1: guaranteed complete ►Transform to include ‘closure’ axioms ►Assert that missing data is really missing ►Classify and register errors ►Takes SNOMED structures into account automatically ►Highly desirable for SNOMED binding constraints ►Method 2: ►Generate structural rules from OWL ►Test instances with structural rules ►Adequate for numeric ranges and string patterns ►Difficult for complex SNOMED-HL7 mutual constraints

48. BioHealth Informatics Group 48 How big does it have to be? Would it scale? ►SNOMED ►Context is critical part of SNOMED ►~1000 codes ►Header codes for key areas of clinical use ►<1000 codes ►Link to external server for remainder ►HL7 ►Only generic models needed as base ►Load specific families or submodels, e.g. ETP, as needed.

49. BioHealth Informatics Group 49 Next Steps: Address the critical problem Focus on Modularity, Reducing variability, & Re-use ►Unified representation of one family of messages ►Generic models and templates ►Modularity ►Indexing ►Integration with S-CT Context Model ►Produce initial tailored software ►Plugin for Protégé ►HL7ized or UMLized UI - first steps ►Extended unfolding views ►Export/inport from MIF ►Involve a few more modellers ►Demonstrate that the method will be usable when complete

50. BioHealth Informatics Group 50

51. BioHealth Informatics Group 51 Supplement on Negation

52. BioHealth Informatics Group 52 Need to rationalise negation: ►How to say: ►“Skull fracture without intracranial haemorrhage” “Skull fracture without subdural intracranial haemorrhage” ►“No skull fracture” ►… ►OWL supports full negation ►Can this help? ►Wrap everything in “Clinical_situation” (label it as you will) ►This also avoids the problem of splitting of information between Finding and Context_Dependent_finding

53. BioHealth Informatics Group 53 “Skull Fracture without Haemorrhage” becomes ►Clinical_situation & includes SOME (Finding & has_morphology SOME Fracture & has_site SOME Skull ) & NOT includes SOME (Finding & has_morphology SOME Haemorrhage & has_site SOME Skull) ►And the rest comes for free

54. BioHealth Informatics Group 54 Demo From Protege-OWl Given a series of definitions of the form: And underlying definitions such as Skull_fracture_without_intracranial_haemorrhage_situation = Intracranial_haemorrhage_finding =

55. BioHealth Informatics Group 55 Then a flat list of such stated definitions for:

56. BioHealth Informatics Group 56 Will be rearranged by the OWL classifier to give the correct classification automatically

57. BioHealth Informatics Group 57

58. BioHealth Informatics Group 58 Supplement on alternative iota interface ►Development of alternative interfaces is relatively straightforward in Protégé. ►The next slide shows part of an interface for the IOTA project developing an anaesthesia terminology ►Anaesthesia Patient Safety Association

59. BioHealth Informatics Group 59