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 <cleit...@capacityplus.org> 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 <bobjolli...@gmail.com> 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-users Post to : dhis2-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
