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.