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.

...

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).

Image Added