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 13606 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 http://www.xmlmodeling.com to make the XML-UML mapping explicit

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