Metadata Mapping Module development progress

I agree. A UML class diagram would support communication much better as a relational diagram is in my opinion more useful when discussing about db implementation details.

There might be a lesson to be learned here. When this project landed on my desk I made the naive assumption that the (undocumented) functional requirements have already been so well thought of that we only needed to focus on the implementation details. Now that we have hit a couple uncertainties/disagreements it would be very helpful if someone had documented the original requirements based on which the initial implementation design had evolved.

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.

Are there are any other outstanding design issues, which I am missing?

Thanks, this helps a lot. Actually I went so far as to create a wiki page for gathering this kind of use cases or workflows:

Feel free to write you ideas and comments there. I know this comes a bit late in the process but I thought we would still benefit from any kind of written descriptions of what this module is about and what is out of scope. So why not give it a try? Am I making any sense to any of you out there? :slightly_smiling:

Excluding sets, I can’t think of anything urgent except for @darius’s post which leaves some things hanging in the air as no one has commented on them:

1 Like

@wyclif, @burke, would you like to comment on the above?

I recall we talked about this on some design call and as Darius says these mappings seem to differ from concept mappings which gets confusing at one point because it becomes had to distinguish them from tagging and we never seemed to come to an agreement when it comes to the sets

I started another thread for access control related design. @raff, care to comment?

Good idea. I just added a use case diagram there to try to provide some perspective on what the module’s requirements look like.

Hopefully at some point we can generalize that page into something like a “design playground” for the module, a place to exchange design/purpose/scope ideas informally and prior to any official design documentation. To Wyclif’s point, I agree that the relationships between the existing metadata-associated initiatives are confusing - having a place to “think out loud” about them could help!

Great stuff!

Ok, let’s try to pull a release together.

The only remaining confusion seems to be whether a MetadataTermMapping’s reference to a OpenmrsMetadata should be optional or not. I say we make it optional, publish an alpha release and see how it goes. If everyone is happy we do a proper release, otherwise we try something else.

We have 3 tickets in design/progress for version 1.1.0:

One of those tickets is still unassigned (nudge nudge).

After a series of various delays we finally have published Metadata Mapping Module 1.1.0-alpha1. It is available at and And why the alpha tag? Well, it’s just because I personally expect we might need to tweak the api a bit based on feedback.

So please give it a try. And remember: any feedback is good feedback.


@kosmik, thank you for leading the project and congrats on the release! I think we are ready to implement REST for the mapping functionality.

Since we bundle the webservices-rest module with a platform I think you can make the metadatamapping module require the webservices-rest module and implement REST resources in the metadatamapping module. I think we’ll want to expose MetadataSourceResource and MetadataTermMappingResource. Could you please create an issue for the work? Please see

Thanks @raff!

I have managed to forget the REST api. I guess it would make sense to include the this in 1.1.0. The point of making an alpha release was to test and stabilize the module api before making a stable release and REST is basically just another “protocol” to access the same api.

In OpenMRS, is the REST api usually a 1-to-1 mapping to the Java service api or would the requirements of, say, client side view implementations need special attention?

OpenMRS REST resources are usually 1-to-1 mapping to the domain objects. Next we implement searches for resources using SearchHandlers to enable finding resources in a similar way our java services let them to be retrieved. Search handlers are optional, though very helpful.

OpenMRS REST API is general purpose and no particular client side view is being taken into consideration.

I have some time this week to look at implementing the REST api. I plan to implement it myself or to have an idea on how to delegate the work.

1 Like

Tried to reply as a linked topic but don’t see any links anywhere so here is a manual link for your convenience:

Dear Team,

It’s been a while. I have taken advantage of the quiet period in the community’s interest towards Metadata Mapping Module and have taken a break myself.

So where are we? Earlier, we released the alpha version 1.1.0-alpha1 for people to try. It does not have a REST api which is still under way in MAP-8. I have not released the REST api yet as I’m still waiting for feedback.

So what next? Currently I feel I won’t be able to do any development work on the module before August. When I get back to work on the REST api, I can probably figure out all the technical details and write documentation and stuff but I would need feedback regarding the functional side of things. How does one use the module’s api? Another option would be that someone else takes over the responsibility of developing the module. Maybe someone with more time available or someone with more experience with OpenMRS.

Any thoughts?

1 Like

Thanks @kosmik for staying positive even though it takes us that long to look at your work. I’m sorry about that.

I’ll review your pull request the first thing tomorrow and do some testing. Once we are done with that we’ll need to do a number of things to facilitate adoption.

  1. Work on a simple UI to manage reference metadata mappings (supporting CRUD operations). Typically we would implement it using AngularJS + REST backend. Ideally using UI components from

  2. Add support for metadata mapping to Basically one should be able to add mappings together with other metadata on module’s startup.

  3. Consider adding support for mappings to HTML Form Entry module so that you can start referencing metadata using mappings instead of their names or UUIDs in form’s html.

Is there any area which you would like to focus on first?

Thanks @raff! I will continue working on the pull request at the beginning of August. At this point I can’t say much about the TODO items you listed except that we need more people to work on these, I guess.

Thanks @kosmik!

I’m happy to announce that we’ll be having a sprint to put those features into the Metadata Mapping module :slight_smile: Please see Metadata mapping sprint

@raff just wondering if any work has been put into #2 above (Adding support for metadata mapping to Metadata Deploy Module).

We are looking to upgrade to the latest EMR API, and I’m starting to evaluate what changes would be required so that are current PIH EMR could support metadata mappings.

Thanks, Mark