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.
Regarding point 1, I was picturing a conceptual code table with two fields: authority and code. The code itself could be as you say be SNOMED code, ICD10 code, WHO GHO code, HL7 OID, etc. Or it could be a UID if we’re trying to map to UIDs in another DHIS 2 system. I was not picturing the need for a third field containing a UID for every code in the code table.
We also need to find a way to make this backwards compatible with existing systems.
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.
Jim the uid was meant as the key back to the object (dataelement, categoryoption, orgunit or whatever it might be). Not an extra uid Besides authority I think its useful to have a code type - this could allow regex validation and possibly even injection of generators (eg for uuids, patient identifiers etc).
Porting existing systems to the more flexible codes would be straightforward, In terms of backward compatibility (which we generally break with alarming regularity) one would have to have the ability to nominate a default code.
Regarding reorganising current flat lists of categoryoptions in current databases, I think a migration path is possible. An automated conversion process would create a concept (categeoryoptiongroup) called LEGACY and make all existing categoryoptions and categories be part of the LEGACY group. From there implementers could start rearranging them into more granular categories - without necessarily changing the categoryoptions and combos themselves, just their group assignments. There would be a few hiccups, like for example my ‘Unknown’ option, but not many.
Regarding point 1, I was picturing a conceptual code table with two fields: authority and code. The code itself could be as you say be SNOMED code, ICD10 code, WHO GHO code, HL7 OID, etc. Or it could be a UID if we’re trying to map to UIDs in another DHIS 2 system. I was not picturing the need for a third field containing a UID for every code in the code table.
We also need to find a way to make this backwards compatible with existing systems.
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.
Besides authority I think its useful to have a code type - this could allow regex validation and possibly even injection of generators (eg for uuids, patient identifiers etc).