dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi Bob,

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. ;)

Cheers,
Jim


On Mon, Dec 22, 2014 at 9:55 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> 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
>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>