Please add your ideas/wishes for use cases for the Metadata Mapping Module. Here we want to focus on brainstorming and not care about any strict definitions of what a "use case" is. You may also include "non use cases" that document what you think this module is not meant to do. We might use these preliminary use cases to test our design or facilitate discussion. Ultimately, we may choose suitable use cases and include them in some form in the documentation of the module.

Note that development of the module is already under way. As such, the purpose of this page is not to start development from scratch but to refine our understanding of what we are doing and flesh out ideas for future development.

Lifecycle of metadata mappings in an OpenMRS installation

From https://talk.openmrs.org/t/metadata-mapping-module-development-progress/3315/33

Question: How will the metadata mappings be defined in practice when looking at it from the perspective of a OpenMRS installation?

@raff: I see 2 possibilities:

1. Some modules may install its own metadata, which is typically done in module's activator on startup. In such a case a module will install metadata only if a mapping does not exist in the system yet. Following installation of metadata in module's activator, both terms and mappings can be created by a module using API calls to MetadataMappingService. If metadata cannot be installed due to any reason e.g. duplicate names validation error, then the module may decide to create just terms and let an administrator set mappings to metadata, which exist in the system.

2. Some modules will only come with terms (added on startup from module's activator), expecting an administrator to set mappings to metadata, which exist in the system.

Use Case Diagram - Module Overview

Reverse-engineered from the in-progress code base, design page, and the epic that spawned this module:

Purpose: present a high-level overview "what" the module should do, not "how" it is done. Show how this module interacts with other entities (humans, services, etc).

Actors: The key human actors derive from a common metadata end-user but take on three distinct roles: metadata creator, maintainer, and consumer. These may be the same person in a single OpenMRS implementation. The key non-human actors are the Metadata Mapping Service and Concept Service.

Use Cases: each use case (oval) is a task that the actor(s) are required to complete, linked to other use cases as needed. An important abstraction, supported by the current back-end implementation (but not yet in the UI) is that the human actors are not required to differentiate between classifying a metadata term as a concept or non-concept in order to create mappings.

Out-of-scope, but related: 1. Metadata sets (no agreement yet). 2. Metadata Sharing Module (noted at top).

Open