Need help displaying extra patient identifiers in patient header in refApp 2.6

Hi Everyone,

EMRAPI changed from looking at global properties to metadata mappings. We upgraded to the ref app v 2.6 and can’t figure out how to add the extra patient identifiers to the patient header. The database states that there’s a metadata set responsible for the patient identifiers. How do I create that metadata set and where should I place it?

Thanks, Craig

FYI @mogoodrich, @ssmusoke, @gutkowski

@craigappl, I’m no expert, but I believe you will want to inspect / alter the following tables;

  • metadatamapping_metadata_set (Should contain an emrapi module source)
  • metadatamapping_metadata_set_member (Should contain a term for the emrapi source with code = “emr.extraPatientIdentifierTypes”)
  • metadatamapping_metadata_source (Should contain a set that the above term member points to)
  • metadatamapping_metadata_term_member (Should contain look-ups for the various patient identifier types to include)

Hope this points you in the right direction.

To populate this, you can likely take the direct SQL approach, or you can set these up using the API in the metadatamapping module.


You could also add them using this screen:

We are using for the primary identifier and still using Global Properties for the other identifiers (since that seems to still work)

Thanks everyone!

@jmaxy figured it out today. Setting the global property alone didn’t work in EMRAPI 1.21.0. We had to adjust the database by adding a metadatamapping set member for each identifier.


  • @raff, @dkayiwa The metadatamapping OWA didn’t propertly display the emr.extraPatientIdentifiers metadata set. We could search by it in the bottom of the UI, but we couldn’t edit it. It looks like we can only edit unmapped identifiers that are in the top part of the OWA UI.
  • When OpenMRS starts, the metadatamapping_metadata_term_mapping table has an entry for emr.extraPatientIdentifierTypes with code = emr.extraPatientIdentifierTypes, metadataClass = org.openmrs.module.metadatamapping.MetadataSet metadataUUID =feb674fc-36c3-4c87-8d9e-6479b4849923 This means that the extra patient identifier types are mapped to a metadata set with that UUID. The metadatamapping_metadata_set table has one entry with that UUID.
  • We realized that we needed to create a metadatamapping_metadata_set_member for each patient identifier. So, we added two rows and it worked. Here are the liquibase changesets


Thanks @craigappl for the detailed feedback. Is having to do the liquibase changeset specific to your implementation, or would it be required by all the others?

Ok so this MetadataSet ID’d 1 is actually created here.

@dkayiwa I think that’s problematic since it is not possible to refer to it in any non-internal way, there is no UUID to refer to.

Anyone has any objection to change this to something like:

MetadataSet extraPatientIdTypesSet = new MetadataSet();
extraPatientIdTypesSet = metadataMappingService.saveMetadataSet(extraPatientIdTypesSet);

That’s so that we can use MetadataMappingService#getMetadataSetByUuid(String) in Iniz.

Cc @mddubey @samuel34


No objection from me.


Ok I did that as a follow-up commit on the old MAP-19.

@mogoodrich, let us know if anything wrong from your end.

1 Like

Thanks @mksd! Generally looks good, I added one comment to the commit.

Thanks @mogoodrich, I’ll address your comment tomorrow.

Actually, @mksd, what is the use case here? Is there any reason you can’t first fetch the set by code? There’s a utility method here in this case:

Which is used here?

That being said, it’s not a huge deal to add a hard-coded uuid if it’s helpful… we just can’t assume that it’s set to this value across all implementations…

Take care, Mark

1 Like

It looks like implementations assume that this specific metadata set’s internal ID is 1, and that seems unreliable (see here and here for iSanté Plus).

Our story is that we need to manage metadata sets with Iniz, and hence we need to specify a fixed external key to that specific set created by EMR API.

Any preference for the naming of the constants? GP keys seem to be prefixed with GP_, should we do MM_.


Something like that?

P.S. I undid my commit for the time being, I’ll come back with a PR depending on this conversation.

Works for me @mksd! And, yeah, referring by key is a bad idea! If you do need to reference it directly, makes sense to a set uuid.

Take care, Mark