CIMI formalism requirements

Owned by Thomas Beale
Last updated: 09-Apr-2012

Requirements Assessment Spreadsheet

This page contains the CIMI requirements (original here). The spreadsheet, to enable CIMI team assessments to be recorded, is Requirements/CIMI_Clinical_Modelling_Language (Options and Considerations) v0 5a.xlsx.

Requirements List

Structural Requirements

  • REQ-ST-01Data Elements Support the explicit representation of data elements in the clinical model, including their characteristics and appropriate groupings.
  • REQ-ST-02Structural Relationships Represent structural relationships between different information components at different levels of detail.
  • REQ-ST-03Reusable Models Represent re-usable sub-models, and allow these to be composed into multiple, more complex model structures.
  • REQ-ST-04Use Case Independent & Specific Models Represent use-case independent clinical concepts (e.g. problem/diagnosis, blood pressure), as well as use-case specific compositions of these models (e.g. discharge summary, prescription, domain analysis models).
  • REQ-ST-05Rules for Composability Allow rules to be defined on valid ways in which models can be composed together.
  • REQ-ST-06Model Specialisation Allow models to be defined as specializations of one or more other models.
  • REQ-ST-07Multi-Linkage Allow multiple valid linkages between two data elements, either using a graph-based model or data links.
  • REQ-ST-09Binds to Common Information Model Enable the clinical models to be bound to a common information/reference model, which supports generic information requirements (e.g. record keeping requirements, common structure, common datatypes, common EHR model, common message model).
  • REQ-ST-10Model Example Data Allow each model structure to be illustrated using example data to demonstrate its function in clinical practice.
  • REQ-ST-11Model Data Interpretation Allow the interpretation of values (e.g. cut off points, ranges, min, max values) to be made explicit in clinical models.
  • REQ-ST-12Clinical Behaviours /Workflow Allow the clinical behaviour of clinical models to be represented, if these are required to ensure quality data recording/storage.
  • REQ-ST-13Model Content Allow the clinical purpose, evidence and context to be represented, if these are required to ensure appropriate use of the models

Constraint Requirements#

  • REQ-CO-01Comprehensiveness Define constraints against all levels of the model structure, including constraints on common information model attributes, clinical model data groups, clinical model data elements and data type subcomponents.
  • REQ-CO-02Cardinality and Occurrence Define the cardinality constraints of each data group, data element or data instance occurrence (e.g. 0..1, 0..*, 1..1, 1..*).
  • REQ-CO-03Uniqueness Define combinations of data elements that should be unique within a given data structure.
  • REQ-CO-04Ordering of Elements Define the logical order of a set of data elements within a given structure.
  • REQ-CO-05Data Types Define the datatype of each data element (e.g. DateTime, ConceptDescriptor), using an agreed set of healthcare-specific datatypes.
  • REQ-CO-06Format Define the valid format or pattern of each data element value, where relevant (e.g. "YYYYMMDDHHMMSS").
  • REQ-CO-07Intra-Element Constraints Define additional constraints on an individual data element, such as value constraints (e.g. "> 120").
  • REQ-CO-08Inter-Element Constraints Define additional constraints that may exist between different data groups and data elements (e.g. "Start_Date <= End_Date").
  • REQ-CO-09Element Choice Define choices of elements (ie. alternatives), where applicable .

Terminology and Semantic Requirements

  • REQ-TS-01aExtensional Value Binding Define a valid value domain, by referencing a list of individual concepts from a given terminology (with appropriate identification of the terminology referenced).
  • REQ-TS-01bIntensional Value Binding Define a valid value domain, by stating an intensional definition of the set of valid values from a given terminology (with appropriate identification of the termionlogy referenced).
  • REQ-TS-01cReference Set Value Binding Define a valid value domain, by binding the coded data element to a predefined terminology reference set.
  • REQ-TS-02Specialise Value Binding Constrain a given data element's value domain, that has been adopted from a different clinical model, to ensure that it is subsumed by the original.
  • REQ-TS-03Semantic Binding Define the meaning of a particular data element in the model, by binding it to a concept. Please note that the language should not preclude elements being created that do not (at the time of creation) have an appropriate concept to bind to.
  • REQ-TS-04Semantic Link Binding Define the meaning of a link between two data elements in the model, by binding it to a concept.
  • REQ-TS-05Design Pattern Define the semantics of a group of data elements (design pattern), in which a 'focal concept' data element can be qualified or modified by other data elements in the group (e.g. diagnosis, procedure, medication).
  • REQ-TS-06Inter-Element Terminology Constraints Define terminology-based constraints between two data groups, data elements or data attributes.
  • REQ-TS-07Multi-Lingual Support Allow coded data elements to be bound to terminology value domains from different languages. Allow the model itself to have data elements named using multiple languages.
  • REQ-TS-08Multi-Purpose Support Allow coded data elements to be bound to different terminology value domains, for different purposes (e.g. international reference terminology, national reference terminology, local interface terminology). The language should also allow bindings to different terminologies (e.g. ICD-10, SNOMED CT, LOINC, ICNP, ICF).

Additional Requirements

IP Requirements

  • REQ-AD-01Governance, Cost and Licensing Have no Intellectual Property, legal conditions or costs associated with it that would restrict or impede the member community's ability to create, use and share the language's logical artefacts, and to build tools to support the creation, storage, rendering or transformation of these artefacts. The language should be governed by an organisation that is sustainable going forward, and has appropriate mechanisms in place by which the language can be extended and maintained to fully support the requirements of the member community.
  • REQ-AD-02Clinician Verification Be able to be verified by non-technical clinicians and other data users, or transformed into one or more formats that can be effectively verified by non-technical clinicians and data users (e.g. tree-based hierarchy, user interface design, clinical report etc).

Tooling Requirements

  • REQ-AD-03Computable Allow the models (and their example data) to be represented in a computable way.
  • REQ-AD-04Automated Generation of Artefacts Be able to be used to automatically generate multiple different artefact types, with minimal (or no) change to the meaning - including computable exchange format specifications, clinical models defined in other formalisms, human-readable documentation, and user interfaces.
  • REQ-AD-05Model Mapping Allow mappings to be defined to/from other model formalisms, with no loss of meaning (where possible).

Operational Requirements#

  • REQ-AD-14Data creation Support creation of new data via the content models.
  • REQ-AD-15Data validation Support runtime validation of received data via the content models.
  • REQ-AD-06Queryable Allow instance queries to be constructed over the clinical models, which are written in terms of clinically-relevant data element names.

Formalism Requirements

  • REQ-AD-07Versioning Support the inclusion of version information in clinical models.
  • REQ-AD-08Metadata Capture appropriate metadata about each clinical model. This may include the author, use, misuse, clinical context, clinical purpose, clinical evidence, origin/source, scope, date created, date updated. There should also be a mechanism by which each clinical model includes information about which organisations, professional bodies or government bodies have endorsed the model, when this endorsement occurred, and under which criteria. Please note that some of these requirements may be met by a model repository, rather than the modelling language itself.
  • REQ-AD-09Extensible Able to be extended with additional capabilities to support the requirements of the member community.
  • REQ-AD-10Ease of Use Provide a representation that is easy to use without sophisticated software.
  • REQ-ST-08Model Serialisable into Hierarchy Be automatically serialisable into a decidable hierarchical representation.
  • REQ-AD-16RM-independence Be independent of any 'reference model' or 'data types', enabling the same tooling to be used regardless of reference model (to aid in inter-model transposability).
  • REQ-AD-17Encapsulation & Identification Support discrete, identified models, rather than simply being part of a single (huge) node network (e.g. SNOMED CT)

Maturity Requirements

  • REQ-AD-11Education, Documentation and Expertise Have a strong library of education material, appropriate documentation and industry expertise.
  • REQ-AD-12Tooling Be supported by an established set of existing tools, and/or allow the fast development of new tools, which can provide a distributing authoring environment, effective viewing mechanisms, a storage repository and model-to-model transformation tools. The preference is for open source, or free-to-use tooling - however tooling should, at a minimum, be affordable. Existing capabilities to import/export to/from existing tools and languages would be an advantage.

Interoperability Requirements

  • REQ-AD-13Standards Be considered to work toward the clinical modeling language's conformance to ISO 13972, once this work has arrived to sufficient maturity.