Metadata Mapping Module development progress

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

@mogoodrich, thanks for bringing this back to our attention. We were waiting with merging changes around mappings to EMR API for RA 2.5 to be released. The changes had been finally merged and reverted in

@dkayiwa, what is the story behind reverting it?

@raff i had earlier on reverted to first release a stable version of the module without these changes. So the commit you are pointing to is reverting the earlier revert. It therefore means we have the changes as intended. :slight_smile:

Thanks @dkayiwa! I just read revert… but it’s a revert of a revert :slight_smile:

@mogoodrich, I haven’t had a chance to look into integrating mappings into metadata deploy. Your best option for now is to use MetadataMappingService directly as for example here:


The 2 commits show how to quickly migrate from GPs to mappings. There’s also a utility class, which assists with the above:

(not sure why it wasn’t used for those 2 commits)

Thanks @raff! I will take a look…

Take care, Mark