CimiOriginalRequirements

From CIMI
Jump to: navigation, search

This page contains the CIMI requirements, copied from the IHTSDO Collabnet page. The spreadsheet, to enable assessments to be recorded, is Requirements/CIMI_Clinical_Modelling_Language (Options and Considerations) v0 5a.xlsx(info).

Requirements List# Structural Requirements#

   REQ-ST-01 Data Elements - Support the explicit representation of data elements in the clinical model, including their characteristics and appropriate groupings.
   REQ-ST-02 Structural Relationships - Represent structural relationships between different information components at different levels of detail.
   REQ-ST-03 Reusable Models - Represent re-usable sub-models, and allow these to be composed into multiple, more complex model structures.
   REQ-ST-04 Use 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-05 Rules for Composability - Allow rules to be defined on valid ways in which models can be composed together.
   REQ-ST-06 Model Specialisation - Allow models to be defined as specializations of one or more other models.
   REQ-ST-07 Multi-Linkage - Allow multiple valid linkages between two data elements, either using a graph-based model or data links.
   REQ-ST-09 Binds 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-10 Model Example Data - Allow each model structure to be illustrated using example data to demonstrate its function in clinical practice.
   REQ-ST-11 Model 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-12 Clinical Behaviours /Workflow - Allow the clinical behaviour of clinical models to be represented, if these are required to ensure quality data recording/storage.
   REQ-ST-13 Model 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-01 Comprehensiveness - 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-02 Cardinality 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-03 Uniqueness - Define combinations of data elements that should be unique within a given data structure.
   REQ-CO-04 Ordering of Elements - Define the logical order of a set of data elements within a given structure.
   REQ-CO-05 Data Types - Define the datatype of each data element (e.g. DateTime, ConceptDescriptor), using an agreed set of healthcare-specific datatypes.
   REQ-CO-06 Format - Define the valid format or pattern of each data element value, where relevant (e.g. “YYYYMMDDHHMMSS”).
   REQ-CO-07 Intra-Element Constraints - Define additional constraints on an individual data element, such as value constraints (e.g. “> 120”).
   REQ-CO-08 Inter-Element Constraints - Define additional constraints that may exist between different data groups and data elements (e.g. “Start_Date <= End_Date”).
   REQ-CO-09 Element Choice - Define choices of elements (ie. alternatives), where applicable . 

Terminology and Semantic Requirements#

   REQ-TS-01a Extensional 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-01b Intensional 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-01c Reference Set Value Binding - Define a valid value domain, by binding the coded data element to a predefined terminology reference set.
   REQ-TS-02 Specialise 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-03 Semantic 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-04 Semantic Link Binding - Define the meaning of a link between two data elements in the model, by binding it to a concept.
   REQ-TS-05 Design 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-06 Inter-Element Terminology Constraints - Define terminology-based constraints between two data groups, data elements or data attributes.
   REQ-TS-07 Multi-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-08 Multi-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-01 Governance, 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-02 Clinician 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-03 Computable - Allow the models (and their example data) to be represented in a computable way.
   REQ-AD-04 Automated 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-05 Model Mapping Allow mappings to be defined to/from other model formalisms, with no loss of meaning (where possible). 

Operational Requirements#

   REQ-AD-14 Data creation - Support creation of new data via the content models.
   REQ-AD-15 Data validation - Support runtime validation of received data via the content models.
   REQ-AD-06 Queryable - 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-07 Versioning - Support the inclusion of version information in clinical models.
   REQ-AD-08 Metadata - 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-09 Extensible - Able to be extended with additional capabilities to support the requirements of the member community.
   REQ-AD-10 Ease of Use - Provide a representation that is easy to use without sophisticated software.
   REQ-ST-08 Model Serialisable - into Hierarchy Be automatically serialisable into a decidable hierarchical representation.
   REQ-AD-16 RM-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-17 Encapsulation & Identification - Support discrete, identified models, rather than simply being part of a single (huge) node network (e.g. SNOMED CT) 

Maturity Requirements#

   REQ-AD-11 Education, Documentation and Expertise - Have a strong library of education material, appropriate documentation and industry expertise.
   REQ-AD-12 Tooling - 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-13 Standards - Be considered to work toward the clinical modeling language's conformance to ISO 13972, once this work has arrived to sufficient maturity.