New ITS Investigation NHS CfH Research Report Grahame Grieve, Laura Sato, Charlie McCay

Agenda Status Findings Issues What is the use of XML Element Names Datatype proposals Methodology proposals UML ITS proposals Examples

Status This presentation has been prepared for HL7UK to summarise development in the NHS CFH New ITS investigation. We will seek during the consultation day to produce a variation on this presentation that can be taken to HL7.org with the support of HL7UK

Findings Domain Analysis Models Implementation Experience Removal of Fixed Values Interesting background –H7v3 as storage format –CEN / HL7 harmonisation

Domain Analysis Models Business names useful Do not capture “non-functional” requirements (eg those that impact SLAs) Mapping exercise useful, but not the best way to shape models for implementation.

Implementation Concerns V3 judged on implementation experience, examples and schemas Few do detailed background work that javaSIG has done Most start their implementations using the schemas, but end up finding them much less useful than expected

Key Implementation Problems Node count and deep nesting, with each XML element requiring processing by developer and application Schema do not support tools or code reuse Requirements to instance mapping not clear Datatype property constraints hard Model Reuse (20 similar medication models) Mapping to different host systems

Fixed and Default Values Provide support for generic processing Cost is “ugliness” and “low data density” Implementers not keen to access separate definitions for every message type Need to explore name stability strategies Impact on related sets of messages, and versioning of messages over time HL7v3 as storage format…

HL7v3 XML as storage format HL7 does recognise this as a requirement for CDA documents (persistence) Is a requirement for store-and-forward systems, and there is a continuum between these and registries Registry interfaces that address non- functional requirements must address this issue

CEN / HL7 harmonisation Reference Model – Datatypes… Reference Model – Structural… Constraint Mechanisms… Wire Format (to be continued)

CEN / HL7 harmonisation Reference model –Proposed UML ITS datatypes a potential common datatype solution – Issues between Clinical Statement and to be explored Constraint Mechanisms –HL7 refinement process/CMETs/Templates/Vocab and archetypes achieve equivalent constraints –Interchangeable representations (some minor differences in expressivity, mainly tool related)

Outstanding Requirements Issue What’s the use of element names? –Maybe to infer some fixed/default values –What xPaths do folk want to write? –What criteria should be used for name stability between models and versions? More issues after the introduction of the ITS proposals

Abstract R2 Datatypes issues Propose R2a and R2b releases The following Null Flavors to be removed and consequent problems resolved –Other, TRC, SQ –PINF, NINF II.usecode to be added CD.group to be added

Methodology changes *Ensure that there are business names for every class in a RMIM Syntax to be proposed for datatype component constraint Enable explicit constraints for infrastructureRoot attributes *Add the ability to indicate that a class can/must/must-not be included by reference in the instance (eg ActRef)

New ITS Proposals For every RBM create a UML model and XML Schema – these will be called the XUM (XML UML Model) in this presentation The XUM will be normative The UML and XML Schema expressions of the XUM with be equivalent The XUM will be expressed as a mix of rules (ocl/schematron) and structure There will be a reference package of datatypes and enumerated types There will be a secondary UML representation using the XML for UML profile from to make the XML-UML mapping explicithttp://

New ITS (cont) The XUM will not include fixed and default values in the wire format (a more general model should be used as a basis for serialisation if this irritates) The XUM will collapse nested classes to some extent Because there is a XUM for every RBM, there can be serialisation at any level of specificity (see issues) If template assertions are included then they cannot be validated by XML schema (as for the XML ITS)

Issues Governance for which model in a hierarchy to use to serialise What are the guidelines for inheriting names from a parent model? What happens at model boundaries? Should we use business names in instances?

Examples

Next Steps