Model Registry

This page is currently focused on the run-time use of models in a model registry.

Discussion

1. From the RIMBAA 201101 Minutes Sydney:
2. Use of a (meta-)model registry in a RIMBAA environment (Abdul-Malik Shakir)
   • AMS: the latest version of the metamodel, as used in CoH is as follows. Most of this is based on prior cross-industry work, as such there's nothing new about this.
   • 
   • AMS: a description of the model is as follows:
     • When it comes to Data Structures we have two categories: Physical Data Structures and Logical Data Structures. Examples of Physical data Structures include a 'table with columns' or a 'form'. these structures can be valued. On the other han d we have Logical Data Structures. These are abstract specification models, e.g. the RIM.
     • A Data Item may correspond to a Data Type; a Data Type itself is a Logical Data Structure. A Concept can be expressed as a Data Item or a Term, and Term is derived from a Code System (actually that part of the model contains value sets etcetera, we're focusing on the highlights).
     • The P/L Mapping specifies the mapping from the Physical Data Structure to the Logical Data Structure and/or vice versa.
   • The use case for CoH was to provide a "help capability", e.g. to get field definitions
3. Run-time use of model repositories (discussion with OpenEHR/Ocean Informatics)
   • See also (RIMBAA): persentation by AMS this week as contained in these minutes, Tuesday Q6 and the presentation by Andy Harris (point 4 in these minutes, slides 8/9 of [1]).
   • Sam/Heath: we support versions of models, and revisions of models in the model repository. A revision is backwards compatible, a version is not. When it comes to versioning the issue of Governance is very important. We have the tooling in place to verify the validity of a version/revision to prevent the creation of invalid new models. All part of structure change management. When a new version is created, the modeller decides if it is desirable to map it to another version, and if so, has the ability to create a mapping and store it in the model repository. The transformation is applied just-in-time, most clinical data is never retrieved again once it has been stored.
   • Rene: we've only seen two implementations of a model repostory in RIMBAA. Version control and having model documentation were the 2 main reasons mentioned. In your experience, what other reasons/uses are there for a model repository?
     • Sam: ontology of models, ontology of uses, packages of models (e.g. a set of models used for a particular purpose), linkages between models, SNOMED subsets, language translation of models.