Governance proposals

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

• 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	SNOMED CT LOINC, where content is not also available in SNOMED CT	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	Transformation between Web Ontology Language and Archetype Definition Language Transformation between HL7 Clinical Document Architectureand an openEHR Specification	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	CIMI Clinical Information Model	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.