Just a brief note to capture some points of discussion between Jim Grace and myself last week lest they are forgotten forever.
Three relatively minor enhancements to our model which would allow dhis2 to operate as a reasonable terminology service:
Extend the hard wired single “code” attribute to allow multiple codes or aliases. ie. identifiable items should be linked to a code table with at a minimum fields objectuid, code, authority. This would allow multiple codes to be stored against an item. For example these are the sorts of code one tends to come across: SNOMED code, ICD10 code, WHO GHO code, the HL7 oid, the-code-used-in-system-X, the uuid from system Y etc.
Enforce/enable the use of the new categoryoptiongroup/set mechanism so that category options can be grouped by concept, eg age groups, gender categories, disease categories etc. rather than the current heterogenous bag of unique labels.
(Related and dependent on 2). Remove the absolute uniqueness requirement on categoryoption names. Category option names should be unique within a group but there is no real informational requirement which is served by making them unique across the set of all categoryoptions. ‘Unknown’ in the context of age group is different to ‘Unknown’ in the context of sex and can and will have different codes, particularly if imported from or mapped to elsewhere. They should both be able to exist in the same table without conflict.
The above implies two constraints which meet actual information requirements:
there should always be a categoryoptiongroupset called CONCEPT. This can be hard wired in the “firmware”.
categoryoptions must be a member of exactly one group within CONCEPT
categoryoption names must be unique within categoryoption groups.
categories must draw their categoryoptions from within a single categoryoptiongroup
The above can lead to a simpler UI for managing categoryoptions and more seamless interoperability with external coding systems. It also allows dhis2 to be used as a relatively generic terminology service.