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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
