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