← Back to team overview

dhis2-devs team mailing list archive

On dhis2 as a terminology server ...

 

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:

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

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

3.  (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:
1.  there should always be a categoryoptiongroupset called CONCEPT.  This
can be hard wired in the "firmware".
2.  categoryoptions must be a member of exactly one group within CONCEPT
3.  categoryoption names must be unique within categoryoption groups.
4.  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.

Comments?

Bob