This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

New ITS Guide

From HL7Wiki
Revision as of 10:51, 9 February 2007 by Charliemccay (talk | contribs) (→‎Design Principles: changes from XML ITS R1)
Jump to navigation Jump to search

Preface

Notes to Readers

This is a work in progress draft, and far from complete

Acknowledgements

Changes from Previous Release

Prerequisites, Assumptions and Conventions

Known Issues and Planned Changes

Overview

Introduction and Scope

This document describes the rationale for the decisions taken when developing and maintaining the ITS. This information is provided to support the use of the specification, and is not intended to restrict or extend the meaning of that specification. Where there is a difference, the specification takes priority over this document.

Design Principles

  • The transform from the abstract model to the instance should be as simple as possible.
  • The instances should be pleasing to the eye of a human reader.
  • Names should be determined in the abstract model, not generated by the ITS
  • Without compromising other principle listed here the instances should be as small as possible.
  • The ITS should define the set of valid instances for a V3 artefact, and a W3C schema that describes that set. Every valid instance must be schema-valid against the defined W3C schema for that instance. It is also noted that other schemas may be used during implementations.
  • The normative Schema for each static model artefact should use well supported parts of the W3C schema language.
  • Use attributes to support the population of PSVI.
  • The ITS should support the reuse of components in implementations.
  • The depth of nesting in the instances should be a shallow as possible.
  • For each static model artefact that will be a UML model defined that expresses the structure of the XML instances, and that is compatible with UML-based case tools.
    • The CMET references and Wrapper boundaries should not be transparent in the instance.
  • Choices should be transparent in the instance - thus a class should appear in the instance in the same form whether or not it is part of a choice. This is to allow for forwards compatability when choices are introduced into models and to reduce the level of nesting
  • Issues
    • which UML case tools are supported, and what for?

Specification Walkthrough

Serialisation of HL7 Classes to XML

HL7 Class

Each HL7 class is named using the formal naming conventions defined

HL7 Choice structures

HL7 attribute

HL7 model boundary

Reshaping of RIM based Models

Abstract Serialisation Model

Informal Extensions

Backwards and Forwards Compatability

The use of schema processors

Implementation Issues

Glossary entries

The entries here are words or phrases that are used inthis document and need to be defined in the Glossary

Questions for Publishing