1 / 30

HL7 Version 3 – A new implementation direction

HL7 Version 3 – A new implementation direction. Grahame Grieve CfH / Jiva / HL7 Australia co-chair Infrastructure & Messaging TS Project Lead, Eclipse OHF. A New Direction. CfH experience shows that HL7 V3 is difficult to implement (but can be done)

august-glenn
Download Presentation

HL7 Version 3 – A new implementation direction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HL7 Version 3 – A new implementation direction Grahame Grieve CfH / Jiva / HL7 Australia co-chair Infrastructure & Messaging TS Project Lead, Eclipse OHF

  2. A New Direction • CfH experience shows that HL7 V3 is difficult to implement (but can be done) • All V3 projects have reported the same outcome • Health IT is difficult to implement • But this should be due to content, not engineering issues

  3. The UML ITS The UML ITS represents a vision: • A new ITS based on o-o concepts • Give implementers what they want • Publish UML Models & Schemas • Make them normative • Support Model Driven Development Make V3 easy to implement!

  4. UML ITS Overview XML ITS HL7 Stack XML ITS Wire Format Schema Generator RIM / datatypes Schemas Domain Models UML ITS Other Stuff (HDF, etc) UML ITS XUM Generation & Transformation UMLModel XML Schema XUM Wire Format

  5. UML ITS • Technical Side • Specification of the wire format using UML & XML Schema • Preparation of the reference package (data types etc) • Policy Side • What Models are used • What Transformations are applied to the models?

  6. 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)

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

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

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

  10. Example: Static Model

  11. Example: UML

  12. Example: Schema <xsd:element name="PRPA_MT110101UK11.PdsRegistrationResponse“ type="PRPA_MT110101UK11.PdsRegistrationResponse" /> <xsd:complexType name="PRPA_MT110101UK11.PdsRegistrationResponse"> <xsd:complexContent> <xsd:extension base="Clone"> <xsd:sequence> <xsd:element name="code" type="CV" minOccurs="1" maxOccurs="1" /> <xsd:element name="subject" type="PRPA_MT110101UK11.Subject“ minOccurs="1" maxOccurs="1" /> <xsd:element name="pertinentInformation" type="PRPA_MT110101UK11.PertinentInformation“ minOccurs="1" maxOccurs="1" /> <xsd:element name="inFulfillmentOf" type="PRPA_MT110101UK11.InFulfillmentOf“ minOccurs="1" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="classCode" type="ActClass" use="required" fixed="REG"/> <xsd:attribute name="moodCode" type="ActMood" use="required" fixed="EVN"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>

  13. Example: Instance

  14. Reference Package • Enumerations • Structural Vocabularies • Data Type Vocabulary Domains • Data Types • UML & XML design principles apply • O-O Implementation of Hl7 V3 data types • Cross Mapped to OpenEHR data types

  15. Reference Package

  16. Data Types

  17. Data Types

  18. Data Types

  19. Data Types • This approach to data types allows code generation • This approach to datatypes is acceptable to CEN & ISO • HL7 will bring the UML ITS datatypes forward as a candidate for the ISO datatypes • ISO affiliates will be encouraged to submit ballot comments when the UML ITS is balloted (officially or privately)

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

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

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

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

  24. Are definitions required? Yes: • Instances defined in terms of the definition • Rename, collapsing, defaults omitted, smaller • Applications need to find or know the definition No: • Instances defined in terms of the RIM • RIM names & structures, no defaults, • Applications can do generic processing

  25. Definitions are not needed • Administrative – use reshaping techniques • Clinical – leave as RIM • No clear boundary • Real price is in clinical content • ? Still to be finalised

  26. 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 • CDA has invested in a stable document format

  27. Stable Wire Format • Use Domain Models as a basis for serialisation • Apply RMIMs, Message Types as Templates • Policy development to make Domain Models more stable & reduce overlaps

  28. Where to now? • Implementation Trial commencing with CfH suppliers • XUMs are available for MIM 4.1.04 • We can experiment with messaging reshaping • Develop Domain Model for CfH Pharmacy

  29. New Directions • Templates Specification (at last) • SOA – unlocking V3 content • Re-Tool HL7 – make the tools a strength • UML ITS – reduce cost of adoption • Collaboration with CEN • Work with OMG on long term engineering solutions

  30. Charlie McCay Lloyd Mackenzie Gunther Schadow Thomas Beale Rene Spronk Galen Mulrooney Dave Carlson Laura Sato Ken Lunn Rik Smithies David Markwell Tim Benson Joe Waller Ann Wrightson Acknowledgements Many people have contributed to this work

More Related