UML ITS Tutorial

1. UML ITS Tutorial Grahame Grieve CfH / Jiva / HL7 Australia co-chair Infrastructure & Messaging Project Lead, Eclipse OHF

2. Agenda • Introductions / Background • UML ITS Fundamentals • A Model • Unresolved Issues • Where to now?

3. Why the UML ITS • UML based representation of HL7 Models • A work in progress. • RIM is “pure” UML • Datatypes are not • Models (RMIMs etc) are not • “pure” UML means: • Standard o-o concepts • No stereotypes

4. CfH Implementation • Message Simplification task force outcomes • Low Instance to other data ratio • Complex Structures • Unstable Wire Format • Unable to code generate productively

5. V3 Background • 3 level modeling • RIM • Static Models • Templates

6. RIM

7. RIM: Interoperability • The semantic requirements embedded in the RIM force models to be rigorous • Modelers must carefully analyse their concepts and define them against the RIM classes and terminologies • This provides a solid base for shared understanding

8. RIM Structural Codes • A pattern over the top of the Class based RIM • Each class carries key coded attributes that independently carry semantic meaning • Can ignore type information (or not know it) and rebuild implicit meaning from the representation of the instances

9. Static Models • A set of constraints on the RIM • Presented as a Class Diagram • Not proper UML • Clones • Choices • CMET mixins

10. Templates • Express custom requirements on Models • Differences between Static Models & Templates: • Templates are represented differently in the instance • Templates are intended for implementation • Templates may be incomplete

11. Incompleteness

12. Types & Templates • Template: A set of constraints on a type • Type: A set of constraints on a type • An artefact “conforms” to a template • An artefact “is” of a type • Type is a concept with exclusivity

13. Types & Templates RIM • So HL7 instances conform to many models at once • One can be the type • it’s derivation chain are super-types • Others are templates DIM RMIM Template MT Template Template

14. V3 Processing Approaches • V3 presents a rich plethora of options for processing instances • Structural code based • RIM Type based • Static Model based • Template based • Many implementations combine these

15. V3 Processing Approaches • Generic Processing • Process every instance without knowledge of the static model upon which it is based • Uses structural codes to infer meaning • Specific Processing • Processes instances based on the static model • Generally hand coded for the model

16. XML ITS issues • Surprise attributes • Representation transforms • Datatypes complexity • Mixins • Clever data formats • No final representation

17. UML ITS • Goal: Give implementers what they expect • What’s that?

18. UML ITS Industry norms: • Standard Object (o-o) Representation • WYSIWYG – formally correct model of the wire representation • Support for Model Driven Development

19. UML & XML • UML is the preferred notation for modeling • XML is the preferred format for interchange • Need a tight relationship between UML and XML UMLModel XSDSchema XML Wire Fomat

20. XUM • XUM – XML UML Model • A XUM is a model that describes, as both a UML class diagram and an XML schema, an implementable form of a V3 instance based upon an Static Model. The XUM describes a particular wire format, and is also useful in terms of commercial tools use and ease of implementer understanding. The UML and XML forms of the XUM should be as isomorphic as possible.

21. XUM • A definitions of classes with attributes and associations • Associated implementation constraints and enumerations • Artefacts and Constraints describe a static model as completely as possible • Presented as a UML Model and an XML Schema (W3C)

22. UML Diagram Rules • Classes with Attributes • Parameterized classes with one class parameter. All parameterized classes are collections • Constraints using OCL in notations attached to the class. • Generalization associations • Named composition associations (represented as by value in XML) • Named associations (represented as by reference in XML) • The stereotype <<enumeration>> for enumerations • The stereotype <<io>> for marking entry points. • The inbuilt types from the OCL 2 kernel, or any types found in other XUMs which must be explicity accessed as UML packages

23. XSD Schema Rules • Complex Types • Element and attribute definitions • Global elements for entry points • Simple Types for enumerations • Sequences & Choices • Schematron rules for constraints • The inbuilt types from the schema standard, or any types found in other XUMs which must be explicity imported as schemas • Comments in AppInfo annotations

24. XUMs are normative • Current XML ITS schemas are not normative – they are wrong • Accept that the wire format needs to be formally & correctly documented • Make the wire format driven by the XUM model

25. Examples • PdsAllocateNhsNumberRequest (PRPA_MT100101UK12) • CareEventReport (REPC_MT150007UK05)

26. XUM Reference Package • Enumerations • Data types • ANY • BL • ED • CD • EN • SET • IVL

27. XUM Summary • XUM – representation of what goes on the wire • Suitable for • Documentation • Automatic processing • Model Driven Development • Allow implementers to get started quickly

28. Unresolved Issues • What transformations are performed when preparing the XUM? • How well do we solve the problems? • Low Instance to other data ratio • Complex Structures • Unstable Wire Format • Unable to code generate productively

29. Are definitions required? • The most significant question of all is:“Do you need the definitions to read the instance?”

30. Definitions Required If definitions are required: • Instances define themselves in terms of reference to the definition • Names need not be RIM or Static model names • Definition must map the names to RIM concepts • Instances can omit anything found in the definition • Instances are smaller • You must read or “know” the definition to author or understand the instance

31. Definitions Not Required • If definitions are not required • The instance must carry everything that defines it (by reference to the RIM) • Instances will be larger (fixed values) • Names must be RIM Centric • Applications can understand the instance without consulting the definitions

32. Definitions Required? • XML ITS is in the middle • Implicitly to allow reading with definitions • But omits fixed and default values, so definitions are required – unless you have PSVI • JavaSIG – uses the definition to construct a RIM graph, then ignores it • Eclipse – will allow either • Most implementers already have an architecture based around XML tools, which don’t provide services like this

33. Definitions Required • NHS project focused on moving as much as possible into the definitions • “Interoperability is just a definition away”

34. * Analysis Model HL7 Model Manual Mapping Schemas (XML ITS) Automated Transform Msg Automated Transforms Automated Transform Conformance Profile Implementable UML Model Msg UML ITS R2: Concepts

35. Example

36. Example

37. Example

38. Example

39. Example

40. Problems • Real Analysis Models turned out to be unsuitable • Often have significant transforms between Analysis and Communication • Do not address implementation issues • NHS Implementers do generic processing, and can not easily consult the definitions • Clinical Content was less malleable

41. Choice More Level of Abstraction Less Domain Domain / Realm RMIM RMIM/Realm Project Generate Implementable Model Generate Implementable Model Generate Implementable Model Generate Implementable Model Generate Implementable Model Abstract More Interoperable Specific Less Interoperable Level of Abstraction

42. RMIM Reshaper • Robert Worden has developed an RMIM reshaper • It has been illuminated by the UML ITS analysis • We expect that it will become more aligned with the UML ITS work • May be part of the basis for exploring the pros and cons of reshaping

43. Choice • Administrative – use reshaping techniques • Clinical – leave as RIM • No clear boundary • Real price is in clinical content • ? Still undecided how to progress

44. Unstable Wire Format • Existing format is unstable because: • Constraints are represented in the instance • Constraints change between models and versions because the concepts are described differently • The concepts themselves change much less, and more slowly

45. Wire formats & SOA Control the operation of your SOA with BPEL

46. Wire formats & SOA Control the operation of your SOA with BPEL What’s this? Standardisation of data models & formats enables the SOA Flocks of servers share the same document format

47. Wire formats & SOA • HL7 has domain harmonised models • They are locked up within the V3 messaging context • Wider project with HL7: unlock the concepts for services • HL7 Services Project (SOA) • UML ITS • MnM revisiting the dynamic model

48. Wire Format Stability RIM • HL7 instances conform to many models at once • One can be the type – “the basis for serialisation” • Higher up = more stable & more abstract • Higher up = more work up front • We lean towards DIM level DIM RMIM Template MT Template Template

49. Choices? • The current HL7 V3 serialisation approach is a middle of the road approach • There appears to be grounds for either more abstract or more specific formats • More specific formats should be as specific as possible

50. CEN 13606