dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

No.  But the first point is to have the data model able.  From there SVS
and others are easily supportable.

On 22 December 2014 at 13:13, Carl Leitner <cleitner@xxxxxxxxxxxxxxxx>
wrote:
>
>  Hi Bob,
> Have you all discussed what standard you will be using? SVS? FHIR DSTU
> v2?  Something else?
>
> Cheers,
> -carl
> On Dec 22, 2014 5:23 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>
>  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
>
>