Your database has another concept named Status. And as a result, the concept service’s getConceptByName method finds more than one concept with this exact name, leading to this problem. As a workaround, rename this concept from Status to something else. Then use that new name as the setting for queue.statusConceptSetName
1 Like
@dkayiwa thank you for that observation, we have been able to use the workaround you suggested, and here is the output
{
"uuid": "169f0fd1-addc-42fc-9da6-e9f3b054efe7",
"visit": {
"uuid": "24629d16-3919-4578-989b-cfc03fb975ab",
"display": "Facility Visit @ Demo HC III - 06/10/2022 00:00",
"patient": {
"uuid": "363450fc-9371-4248-8bc9-3f9eeb688667",
"display": "Peter Pan",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/patient/363450fc-9371-4248-8bc9-3f9eeb688667"
}
]
},
"visitType": {
"uuid": "7b0f5697-27e3-40c4-8bae-f4049abfb4ed",
"display": "Facility Visit",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/visittype/7b0f5697-27e3-40c4-8bae-f4049abfb4ed"
}
]
},
"indication": null,
"location": {
"uuid": "629d78e9-93e5-43b0-ad8a-48313fd99117",
"display": "Demo Hospital",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/location/629d78e9-93e5-43b0-ad8a-48313fd99117"
}
]
},
"startDatetime": "2022-10-06T00:00:00.000+0300",
"stopDatetime": "2022-10-06T15:42:52.000+0300",
"encounters": [],
"attributes": [],
"voided": false,
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/visit/24629d16-3919-4578-989b-cfc03fb975ab"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/visit/24629d16-3919-4578-989b-cfc03fb975ab?v=full"
}
],
"resourceVersion": "1.9"
},
"queueEntry": {
"uuid": "ab028aef-7756-4a26-a5c7-c9b305084da0",
"display": "EMESU PETER",
"priorityComment": "Needs urgent attention",
"sortWeight": 0.0,
"startedAt": "2022-09-29T13:02:54.000+0300",
"endedAt": null,
"queue": {
"uuid": "3630c5b0-b1c5-400b-982f-316ea7365360",
"display": "Triage queue",
"name": "Triage queue",
"description": "This triage queue",
"location": {
"uuid": "629d78e9-93e5-43b0-ad8a-48313fd99117",
"display": "Demo Hospital",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/location/629d78e9-93e5-43b0-ad8a-48313fd99117"
}
]
},
"service": {
"uuid": "cec6c3c1-5397-47a9-85b7-94d8c37aa903",
"display": "Triage",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/cec6c3c1-5397-47a9-85b7-94d8c37aa903"
}
]
},
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/queue/3630c5b0-b1c5-400b-982f-316ea7365360"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/queue/3630c5b0-b1c5-400b-982f-316ea7365360?v=full"
}
],
"resourceVersion": "2.3"
},
"status": {
"uuid": "46390e71-e93d-4113-b33c-575ba00a1919",
"display": "Waiting",
"name": {
"display": "Waiting",
"uuid": "11b8bb06-d7f4-491a-a26e-2787fff0daef",
"name": "Waiting",
"locale": "en",
"localePreferred": true,
"conceptNameType": "FULLY_SPECIFIED",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/46390e71-e93d-4113-b33c-575ba00a1919/name/11b8bb06-d7f4-491a-a26e-2787fff0daef"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/46390e71-e93d-4113-b33c-575ba00a1919/name/11b8bb06-d7f4-491a-a26e-2787fff0daef?v=full"
}
],
"resourceVersion": "1.9"
},
"datatype": {
"uuid": "8d4a4c94-c2cc-11de-8d13-0010c6dffd0f",
"display": "N/A",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/conceptdatatype/8d4a4c94-c2cc-11de-8d13-0010c6dffd0f"
}
]
},
"conceptClass": {
"uuid": "8d492774-c2cc-11de-8d13-0010c6dffd0f",
"display": "Misc",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/conceptclass/8d492774-c2cc-11de-8d13-0010c6dffd0f"
}
]
},
"set": false,
"version": "1.0",
"retired": false,
"names": [
{
"uuid": "11b8bb06-d7f4-491a-a26e-2787fff0daef",
"display": "Waiting",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/46390e71-e93d-4113-b33c-575ba00a1919/name/11b8bb06-d7f4-491a-a26e-2787fff0daef"
}
]
}
],
"descriptions": [],
"mappings": [],
"answers": [],
"setMembers": [],
"attributes": [],
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/46390e71-e93d-4113-b33c-575ba00a1919"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/46390e71-e93d-4113-b33c-575ba00a1919?v=full"
}
],
"resourceVersion": "2.0"
},
"patient": {
"uuid": "363450fc-9371-4248-8bc9-3f9eeb688667",
"display": "Demo Client",
"identifiers": [
{
"uuid": "f1fc19ca-cbf8-4677-8120-68b3fa14decf",
"display": "OpenMRS ID = ",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/patient/363450fc-9371-4248-8bc9-3f9eeb688667/identifier/f1fc19ca-cbf8-4677-8120-68b3fa14decf"
}
]
},
{
"uuid": "c1109648-ece5-435c-bc1d-72f5721882b5",
"display": "HCT No. = 16318-2019-AA",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/patient/363450fc-9371-4248-8bc9-3f9eeb688667/identifier/c1109648-ece5-435c-bc1d-72f5721882b5"
}
]
}
],
"person": {
"uuid": "363450fc-9371-4248-8bc9-3f9eeb688667",
"display": "Demo Client",
"gender": "M",
"age": 49,
"birthdate": "1973-01-01T00:00:00.000+0300",
"birthdateEstimated": true,
"dead": false,
"deathDate": null,
"causeOfDeath": null,
"preferredName": {
"uuid": "e57e4789-9e5a-4303-a8d2-21a20deb8b07",
"display": "Demo Client",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/person/363450fc-9371-4248-8bc9-3f9eeb688667/name/e57e4789-9e5a-4303-a8d2-21a20deb8b07"
}
]
},
"preferredAddress": {
"uuid": "8f708dbb-2743-44d1-9344-dc4bb9bee183",
"display": null,
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/person/363450fc-9371-4248-8bc9-3f9eeb688667/address/8f708dbb-2743-44d1-9344-dc4bb9bee183"
}
]
},
"attributes": [
{
"uuid": "27e635aa-1eee-46eb-8b93-1f033635404d",
"display": "Telephone Number = ",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/person/363450fc-9371-4248-8bc9-3f9eeb688667/attribute/27e635aa-1eee-46eb-8b93-1f033635404d"
}
]
}
],
"voided": false,
"birthtime": null,
"deathdateEstimated": false,
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/person/363450fc-9371-4248-8bc9-3f9eeb688667"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/person/363450fc-9371-4248-8bc9-3f9eeb688667?v=full"
}
],
"resourceVersion": "1.11"
},
"voided": false,
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/patient/363450fc-9371-4248-8bc9-3f9eeb688667"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/patient/363450fc-9371-4248-8bc9-3f9eeb688667?v=full"
}
],
"resourceVersion": "1.8"
},
"priority": {
"uuid": "160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
"display": "Emergency department",
"name": {
"display": "Emergency department",
"uuid": "108746BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
"name": "Emergency department",
"locale": "en",
"localePreferred": true,
"conceptNameType": "FULLY_SPECIFIED",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/name/108746BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/name/108746BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB?v=full"
}
],
"resourceVersion": "1.9"
},
"datatype": {
"uuid": "8d4a4c94-c2cc-11de-8d13-0010c6dffd0f",
"display": "N/A",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/conceptdatatype/8d4a4c94-c2cc-11de-8d13-0010c6dffd0f"
}
]
},
"conceptClass": {
"uuid": "8d492774-c2cc-11de-8d13-0010c6dffd0f",
"display": "Misc",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/conceptclass/8d492774-c2cc-11de-8d13-0010c6dffd0f"
}
]
},
"set": false,
"version": "1.0",
"retired": false,
"names": [
{
"uuid": "108744BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
"display": "Casualty department",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/name/108744BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}
]
},
{
"uuid": "108745BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
"display": "Accident and emergency department",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/name/108745BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}
]
},
{
"uuid": "108746BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
"display": "Emergency department",
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/name/108746BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}
]
}
],
"descriptions": [],
"mappings": [],
"answers": [],
"setMembers": [],
"attributes": [],
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/concept/160473AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA?v=full"
}
],
"resourceVersion": "2.0"
},
"locationWaitingFor": null,
"providerWaitingFor": null,
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/queue/3630c5b0-b1c5-400b-982f-316ea7365360/entry/ab028aef-7756-4a26-a5c7-c9b305084da0"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/queue/3630c5b0-b1c5-400b-982f-316ea7365360/entry/ab028aef-7756-4a26-a5c7-c9b305084da0?v=full"
}
],
"resourceVersion": "2.3"
},
"links": [
{
"rel": "self",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/visit-queue-entry/169f0fd1-addc-42fc-9da6-e9f3b054efe7"
},
{
"rel": "full",
"uri": "http://154.72.205.54:8081/openmrs/ws/rest/v1/visit-queue-entry/169f0fd1-addc-42fc-9da6-e9f3b054efe7?v=full"
}
],
"resourceVersion": "2.3"
}
@corneliouzbett given that a concept name is not unique, is there any reason why you used a concept name for the queue.statusConceptSetName setting? Instead of a uuid or anything else that is guaranteed to be unique?
@dkayiwa this was our suggestion, preferably UUIDs or concept ids since they are unique otherwise the names may be challenging.
The idea was to have a human-readable setting, using concept names with restrictions to fully-specified names and locale-preferred names to make it return a unique result.
I don’t mind reverting to the most recommended UUID setting.
@corneliouzbett I am of the view that we revert to using UUIDS, they are certainly easier to deal with although not human readable.
Ideally, any process referring to a Concept would allow UUID and SAME-AS mapping to be used interchangeably.
The best feature of UUIDs is the ability to generate a unique identifier at any moment on a whim without worrying about creating duplicates (the space of available identifiers + random generation ensures no duplicates). All other identifier systems require an authority to control identifier assignment to avoid duplicates. There are two particular use cases where UUIDs fail us:
-
Identifiers humans need to work with. UUIDs are long and untenable for humans to manage. We can copy & paste, but are far less likely than a computer to distinguish
361af83a-3894-4a34-889a-ede4d5cd82a0and361af83a-3894-4a34-889a-ede45dcd82a0. It’s much easier for a human to use a mapping likeorg.openmrs.module.queue:STATUS. -
Interoperability. UUIDs are meant to refer to a single unique thing in the universe. This means when a concept is referred to by UUID, that concept must be specifically created in every implementation. For example, if a module or feature uses a “Status” concept referenced as
361af83a-3894-4a34-889a-ede4d5cd82a0, then an implementation must create a new Status concept with the matching UUID, even if the implementation already has an existing Status concept. If, instead, a module references a concept through a SAME-AS mapping likeorg.openmrs.module.queue:STATUS, then any implementation with an existing concept for Status only needs to add the mapping to their concept for it to work.
tl;dr if you want a feature to work in more than one implementation, refer to concepts by mappings instead of UUIDs.
1 Like
That would not apply in this particular case because the uuid is not hard coded, but rather passed as a global property/setting. So an implementation would simply set the value of this global property to the uuid of their corresponding status concept. 
The above being said, the concept mapping would meet the needs of @corneliouzbett to have a human readable identifier. So @corneliouzbett, i would go for both the uuid and mapping. The beauty of this is that the same backend API automatically differentiates between a uuid and mapping and returns the corresponding concept.
1 Like
@burke @corneliouzbett @dkayiwa on any day for this context i would trade readability for uniqueness. The context of users in this case are systems administrators and people who can actually get a uuid of a concept and careless about readability.
Also every implementation will be able to determine its concepts that help configure the queue module. For new implementations an initialization package can be put in place that configures such out if the box together with the base concept dictionary for openmrs that includes these concepts required for queue module.
I couldn’t agree more!
The iniz module already has a domain for global property. I’d agree that implementors should/could leverage this to configure the queue module.