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

Governance proposals

From HL7Wiki
Jump to navigation Jump to search

Caveat

This page is a work in progress - it does not represent CIMI policy or consensus

The CIMI principles

The CIMI Principles, agreed in the meeting in London in December 2011 provide the overarching context for the governance of CIMI. These are:

  1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.
  2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modelling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.
  3. CIMI is committed to transparency in its work product and process.

Implications of the CIMI principles

Freely available to all

CIMI specifications

CIMI specifications will be available

  • without hindrance to access or use
  • without financial or other payment

This imposes the following requirements for CIMI specifications:

  • any CIMI specification should be shared with intellectual property rights
    • the details of the licence should be included in the CIMI specifications
  • These right will enable contributors and consumers to
    • copy, publish, distribute and transmit the intellectual property;
    • adapt the intelelctual property;
    • exploit the intellectual property commercially

Template:DecisionRequired

  • The intellectual property rights should be a worldwide, perpetual, non-exclusive licence
  • It is reasonable, but not necessary, to request the source of the intellectual property is attributed, including prescribing an attribution statement
  • The licence should indicate the jurisdiction it is governed in, which will normally be the principle jurisdiction of the the intellectual property owner
  • The licence should include the extent of any warranty
  • The intellectual property rights should be royalty free

These requirements can be seen as the quality criteria for the licence for CIMI specifications.

Underpinning / foundation intellectual properties

For this principle to be discharged, any underpinning or foundation intellectual property (such as reference models, reference terminologies or infrastructure) must be licenced in a manner which enables CIMI specifications to be shared with a licence which meets these quality criteria. It does not necessarily require the licence for the underpinning or foundation intellectual property to conform to these quality criteria.

Available in a number of formats

Each Clinical Information Model should be capable of transformation into multiple structural and serialisation formats. Template:DecisionRequired For a fully specified Clinical Information Model it should fully express the semantics of the model so that other iso-semantic models can be identified / created. The quality criteria for a fully semantic model are not yet defined.

Transparency

CIMI specifications will be available to view and review throughout their development and assurance. This will include specifications which have not been adopted and models which are not declared fit for any particular purpose.

Types of Clinical Information Modelling Initiative Specification

The following examples of types of Clinical Information Modelling Initiative Specification may exist:

Illustrative types of CIMI specification
Type of specification Examples CIMI governance requirements Comments
Clinical Information Model
  • a heart rate model,
  • a venothromboembolysm risk assessment model,
  • an APGAR score model
CIMI will need to specify the quality criteria for a model.

Conformance to these quality criteria may be asserted by the model contributor / developer or by CIMI

The person or organisation asserting conformance to the quality criteria should be stated in the model metadata Template:DecisionRequired Template:DecisionRequired

These models will be safety critical.

These models are the principle reason for CIMI.

For any particular use case there may be multiple models contributed. These may be Isosemantic Models, incomplete or incompatible with each other.

CIMI Reference Model CIMI will require governance in the initial stages of development but in due course governance should pass to a recognised Standards Development Organisation. Once passed to an SDO CIMI governance should be through that SDO. CIMI is expected to have one reference model
Reference Terminology None Governance of the reference terminologies will be controlled by the owner of that Reference Terminology
CIMI terminology extension A CIMI SNOMED CT extension A governance conformant with the quality criteria set by the owner of that reference terminology
Terminology Bindings A Terminology Binding using a Reference Set can only be assured against specific releases of a Reference Terminology. A terminology binding should therefore include advice on the issues involved in transferring the terminology binding to a different realm or extension.
Model transformations Governed by the sub-set of members with an interest in that transformation The model transformations must specify whether the transformation is lossy or enables a round trip (i.e. formalism 1 => formalism 2 => formalism 1) without loss of meaning or functionality
Governance infrastructure
  • quality criteria for a CIMI specification,
  • process definition for clinical Information model assurance
  • register metadata requirements
  • repository interface specifications
  • editorial policy
  • style guides

A suggested lifecycle of a CIMI clinical information model

A CIMI Clinical Information Model is expected to follow a development cycle however the initial phases of development may well occur outside CIMI. The expected steps are described in the table below.

CIMI Specification lifecycle
Stage Governance within CIMI Key products see note below Responsible Accountable Contributors Other involved
Initiation Optional
  • Business challenge / problem statement
  • Clinical requirement description
Any CIMI member The responsible CIMI member

Selected by by the responsible member

The contributors may refine the business challenge / problem statement and requirements

Selected by the responsible member
Seek contributions Optional

Set of responses / contributions in response to the business challenge and clinical requirements. Each contribution will include

  • Licence terms
  • Statement of intended use

Each contribution may include

  • Evidence of fitness for intended use, for example a pilot implementation report
CIMI Members The initiating CIMI member Any global contributor Open for global involvement
Consolidate and build Optional
  • Draft CIMI Clinical Information Model based on consolidation of contributions
  • Evidence of fitness for intended use
  • Implementation guidance
  • Guidance for application in different realms and context
To be allocated by developer To be allocated by developer Any CIMI contributor Open for global involvement
Testing and assurance

Optional for member use

Required for CIMI approval

  • Test report
Developer

Selected by initiating member for member use

Allocated by CIMI membership for CIMI approval

Any CIMI contributor Open for global involvement
Publication

Optional for member use

Required for CIMI approval

Repository manager Member, or CIMI if CIMI approved Clinical Information Model None Open for global consumption if CIMI approved Clinical Information Model

Note: The key products are additive, that is for completion of a development stage the quality key products of all previous stages must be assured.