Fetch primary identifier-type and all other identifier-types in a single endpoint

Hi everyone! Currently, to fetch all the patient-identifier-types, we need to call: /ws/rest/v1/patientidentifiertype and, to fetch the primary identifier, we call the endpoint: /ws/rest/v1/metadatamapping/termmapping?v=full&code=emr.primaryIdentifierType. Is there any way to merge these 2 endpoints into a single endpoint, wherein I get the list of identifier-types and also get to know, which identifier-type is the primary identifier?

Thanks! CC: @zacbutko @ibacher

In theory, yes. In practice, though, this sounds messy. Are the two network calls causing significant performance problems? Can we (somehow) just group them together?

Currently this is a small out of the way feature which is causing no problems. However this grouping is more appropriate as a backend task.

In general I think it’s a better practice to have each UI element only depend on one endpoint when possible. This should lead to a cleaner API, more concise data object, and maybe even some backend optimizations if the queries can be combined.

In general, I agree, but this can only be the case where we’re building something genuinely new. I think it’s also important that we maintain backwards compatibility with existing systems, which is a bit of a limit here.

The problem is that the “primary” identifier designation isn’t something that openmrs-core knows about at all. It’s defined through a metadata table in the metadatasharing module. The metadatasharing module, however, is generic. It doesn’t have a “getPrimaryIdentifier” endpoint–it’s just returning basically a key-value pair. Hence the difficulty in getting this in a single endpoint, i.e., there’s a lot of work to do to move things around and stick this as a single query. So, if there’s a real gain to be had here, let’s do it, but if it’s just a “nice-to-have” I’m not sure it’s worth the time it will take to develop a new endpoint.

1 Like

I think this might be my main misunderstanding.

And also adding to the maintenance burden.