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