HL7 Project Scope Statement for Core Properties

From HL7Wiki
Jump to navigation Jump to search

(also available as a Word document on Gforge)

Project Name and ID:

Develop Normative Standard with Preliminary Title of: “Core Principles and Properties of HL7 Version 3 Models”

A project ID will be assigned by the PMO

Sponsoring Group(s)

Modeling & Methodology, supported by Vocabulary and Infrastructure & Messaging Technical Committees

Project Scope:

This project seeks to develop an infrastructure standard that will supplement the RIM, Data Types and Vocabulary documents. When completed, the document will be maintained as part of the HDF, as a “sibling” to the “Refinement, Constraint and Localization” standard.

Version 3 is predicated on HL7’s ability to develop specifications (CDA, Messages, SOA) that are derived from three common specifications – the RIM, Data Types and Vocabulary.

When HL7 formally undertook Version 3 in 1997, the principles for developing specifications in implementing them were embodied in the Message Development Framework (MDF). Although the principles underlying the information model (the Reference Information Model) were understood and documented, there was, as yet, no understanding of the data types model to be implemented and consideration of vocabulary constraints in both data types and the RIM was still in its nascency.

As HL7 refined and balloted its foundation models -- the RIM, Data Types, and Vocabulary -- the committees began to recognize elements that appeared to reside primarily in one of those models, but which in truth affected equally one or both of the others. Moreover, each of these topics had a direct impact on implementers. Early adopters were frequently puzzled as to where to seek clarification on particular issues. Examples include:

  • As individual realms developed implementation specifications, they found it necessary to constrain data types (data type flavors) but lacked a solid way of documenting the implications of such flavors on conformant implementations.
  • The principles by which constraints on the vocabulary (codes) to be used for a particular model attribute, or particular data type property, had been articulated within vocabulary, but not well coordinated with those developing tools and guides for implementation of CDA and message specifications.
  • The notion of an "update mode" to communicate changes in information from one system to another had been incorporated in the original MDF, but the full implications of update mode for implementers was only recently articulated, and resulted in changes to the prior "rules".
  • Various implementation projects have adopted the notions of templates, profiles, and data type flavors to simplify and constrain their specifications, but the "proper" way to incorporate these concepts in creating pr parsing message or document instances has, at times, been inconsistent.

As each of the examples above surfaced, implementers and HL7-standard developers sought guidance from one or all of the Modeling and Methodology Technical Committee, the Vocabulary Technical Committee, and the Infrastructure and Messaging Technical Committee. When these questions arose, the three committees sought to coordinate their responses and provide consistent guidance. In some cases the results of that guidance was captured as a change in one of the core models. But these "rulings" have not been captured in a single place where they can be both viewed, reviewed, and approved.

The goal of this project is to create such an overarching specification. The title "Core Principles and Properties of HL7 Version 3 Models" is intended to reflect the fact that the principles (rules) and properties being documented are not, strictly speaking, applicable to any one of the three models, but rather reflect the principles and properties needed to use these three models effectively whether in developing specifications or in implementing the specifications so developed.

The document will be taken through a complete Normative ballot cycle. Because most of the content has been previously discussed and documented, we believe that an initial Committee Ballot can be undertaken in the May 2008 cycle, and that a goal of completing normative balloting by the end of 2008 is not unreasonable.

Project Dependencies:

I&M Data Types Specifications, RIM and Vocabulary Binding Principles

Project Objectives:

Create a Normative Standard from existing work documented in:

  • Message Development Framework (1999)
  • Reference Information Model
  • Abstract Data Types (I & II)
  • Documented M&M Hot Topics that resolved ballot issues
  • Documented agreements between M&M and Vocabulary over last 30 months

The actual standard will be a textual document with reference to contents of RIM, data types, vocabulary, but without new formal models.

Document outline includes:

  • V3 Models – Overview, Principles and Interrelationships
    • RIM – Vocabulary - Data Types)
  • Use of Constraints in V3 Static Models
  • Overarching Concepts – Definitions, Principles of Use, and Implications for Implementers
    • Cardinality, Optionality
    • Null Flavors
    • Conformance Testing Considerations
    • Vocabulary Bindings and Constraints
    • Conformance to Vocabulary Constraints
    • Use and Conformance to “types”
      • templates, profiles and flavours
    • Coordination and Communication of Information Updates
    • Documenting Accountability and Validity

Project Deadlines

Initial Committee level ballot for 2008May and Membership ballot to follow.

Seek completion within 15 months.

Project Intent, Categorization and Collaboration (for HITSP)

The mission of ANSI Healthcare Informatics Standards Board (HISB) is to provide an environment that facilitates, coordinates and harmonizes national and international healthcare informatics standards.

The following represents some minimal information needed to assist in that effort.

Project Intent

(Checked both Create New Standard and Supplement to a current standard because even though this is a “new” document it really supplements the existing RIM, Data Types, and Refinement, Constraint and Localization documents.)