ITS SIG telcon 20070219 notes

Present

• Charlie McCay (chair and notes)
• Paul Knapp
• Rob Leif
• JD

We reviewed the draft ballot notice. The "New" had been dropped from the name of the New ITS documents, which made the name inappropriate. Also "datatypes" should be two words (following the HL7v3 Glossary) CM to email Don Lloyd asking for these changes to the draft notification.

There was discussion about the voc.xsd - with a suggestion from RL that the enumerations should be packaged in the same schema files as the types that use them, rather than in a single huge schema file. This is not something that can be done in the ITS or schema generation process unless the packaging is done in the abstract models. CM took and action to raise this as a suggestion to MnM , noting that the MIF structure allows for the appropriate packaging of artefacts, and so this may be something that MnM already have in hand.

We reviewed the design principles in the New ITS rationale document, and these were agreed to by those on the call.

There was discussion about the extensive use of abbreviations in the datatypes (such as TS and Id, and also the use of case to distinguish between types and classes. Both of these conventions were criticised as being arcane, and should be reviewed in the work on the new ITS and ISO datatypes. It was noted that the ISO datatypes preparation and ballot were a good opportunity to propose changes to the naming, in the light of implementation experience, and industry practice that has evolved since the names in abstract datatypes and XML ITS were finalised five years ago. It was noted that software is starting to be treated as a type of medical device and subject to the same patient safety checks. This means that clarity in the schemas and instances is important and the rationale for the particular compromise between brevity and explicitness should be documented, ideally with reference to established practice.

JD listed three approaches to classifying definitions - there is namespaces, the versioning of schemas, and the use of registry services to establish which versions are to be supported in releases. This is part of a wider topic of configuration management, and the ITS should address how it supports this.

A good example about why schema versioning is needed is CDA Normative Edition 2005(NE2005) and Normative Edition 2006 (NE2006). Two different versions of voc.xsd and datatyps xsd are used by same POCD_MT000040.xsd. By given a single CDA instance, without version information, it's hard to tell what version of voc.xsd and datatypes xsd the instance refers to, and usually requires a work around solution which could be resolved by simply supporting version informaiton inside shema. (Edited by JD Li)

This will be explored further since the call ran out of time...