dhis2-users team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.



On 22 December 2014 at 15:20, Jim Grace <jimgrace@xxxxxxxxx> wrote:
>
> 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
>>
>>
>