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

craigappl · July 13, 2017, 6:42pm

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

mseaton · July 14, 2017, 3:46am

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

Mike

dkayiwa · July 14, 2017, 8:20am

You could also add them using this screen: https://qa-refapp.openmrs.org/openmrs/owa/metadatamapping/index.html

ssmusoke · July 14, 2017, 8:43am

We are using https://github.com/METS-Programme/openmrs-module-aijar/blob/master/api/src/main/java/org/openmrs/module/aijar/AijarActivator.java#L232-L241 for the primary identifier and still using Global Properties for the other identifiers (since that seems to still work)

craigappl · July 20, 2017, 1:15am

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.

Notes:

@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

Craig

dkayiwa · July 20, 2017, 6:22am

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?

mksd · March 4, 2020, 12:46pm

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.setUuid("e4aab2eb-5d19-496f-858b-c1269d92c549");
extraPatientIdTypesSet = metadataMappingService.saveMetadataSet(extraPatientIdTypesSet);

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

Cc @mddubey @samuel34

dkayiwa · March 4, 2020, 8:18pm

No objection from me.

mksd · March 5, 2020, 8:57am

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

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

mogoodrich · March 5, 2020, 2:48pm

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

mksd · March 5, 2020, 4:39pm

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

mogoodrich · March 5, 2020, 7:56pm

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:

github.com

openmrs/openmrs-module-metadatamapping/blob/master/api/src/main/java/org/openmrs/module/metadatamapping/util/ModuleProperties.java#L152


	public abstract String getMetadataSourceName();
	
	protected ConceptSource getConceptSourceByCode(String mappingCode) {
		ConceptSource conceptSource = getEmrApiMetadataByCode(ConceptSource.class, mappingCode);
		if (conceptSource == null) {
			throw new IllegalStateException("Configuration required: " + mappingCode);
		}
		return conceptSource;
	}
	
	protected List<PatientIdentifierType> getPatientIdentifierTypesByCode(String code) {
		MetadataSet metadataSet = getEmrApiMetadataByCode(MetadataSet.class, code);
		return metadataMappingService.getMetadataSetItems(PatientIdentifierType.class, metadataSet);
	}
	
	protected String getEmrApiMetadataUuidByCode(String mappingCode) {
		return getEmrApiMetadataUuidByCode(mappingCode, true);
	}
	
	protected String getEmrApiMetadataUuidByCode(String mappingCode, boolean required) {
		MetadataTermMapping mapping = metadataMappingService.getMetadataTermMapping(getEmrApiMetadataSource(), mappingCode);

Which is used here?

github.com

openmrs/openmrs-module-emrapi/blob/master/api/src/main/java/org/openmrs/module/emrapi/EmrApiProperties.java#L183


		if (type == null) {
			throw new IllegalStateException("Configuration required: " + EmrApiConstants.UNKNOWN_PATIENT_PERSON_ATTRIBUTE_TYPE_NAME);
		}
		return type;
	}


	public PatientIdentifierType getPrimaryIdentifierType() {
		return getEmrApiMetadataByCode(PatientIdentifierType.class, EmrApiConstants.PRIMARY_IDENTIFIER_TYPE, true);
	}


	public List<PatientIdentifierType> getExtraPatientIdentifierTypes() {
		return getPatientIdentifierTypesByCode(EmrApiConstants.GP_EXTRA_PATIENT_IDENTIFIER_TYPES);
	}


	public DiagnosisMetadata getDiagnosisMetadata() {
		return new DiagnosisMetadata(conceptService, getEmrApiConceptSource());
	}




	public List<ConceptSource> getConceptSourcesForDiagnosisSearch() {
		//The results can very well be cached to reduce calls to database.

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

mksd · March 6, 2020, 8:55am

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

EmrApiConstants.MM_EXTRA_PIT_SET_NAME
EmrApiConstants.MM_EXTRA_PIT_SET_UUID

Something like that?

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

mogoodrich · March 6, 2020, 2:06pm

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