dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Murod

In workshop so only time for quick response.

2009/9/14 Murodullo Latifov <murodlatifov@xxxxxxxxx>

>  Hi Bob,
>
> Good point to make unique id for data element, org unit and so. This way in
> DHIS we could have uid for say same data element across different existing
> installations, just by updating uuid. But this could solve internal issue of
> DHIS, not interoperability with other systems like openmrs. At least
> maintaining uuids will be overhead. uuid is meant to create unique id in non
> controlled (non centralized) environment, and later merge data together
> without id conflict.
>

I agree uuids are not ideal.  Would be better to use URI based on CODE but
for the moment we have uuid so can use it,  For SDMX purposes we must
provide a urn for shared elements.  So simplest (if not prettiest) solution
is to compose urn by including uuid.


>  Interoperability, especially when data at different levels should be
> linked, has to be based on atomic unit of data. In our case, this would be
> ICD10. OpenMRS uses ICD10 (should use) to uniquely identify each disease, so
> every concept in openmrs should have corresponding uuid (this would be one
> to one mapping 1 concept - 1 ICD10 code). In contrast DHIS as data warehouse
> will have one to many relation to ICD10 codes. This is where generalization
> occurs. Say we have TB data element to generally show TB status, it would
> include all TB related diseases ICD10 A15-A19 or subset of TB types: A15,
> A16, A17, A18 and A19, but not detailed one like shown in
> http://apps.who.int/classifications/apps/icd/icd10online/. This list
> should be used by openmrs and alike systems.
> Now when both systems confirm to ICD10 codes, it would be simple to map
> data at different levels because openmrs uses ICD10 at atomic level, and
> DHIS make generalization as it needs to form data element. Also we give
> freedom to implementers what to choose, what ICD10 codes form particular
> data element of particular country.
> So idea of uuid will not serve best for interoperability, it will be
> overhead and also lengthy. I think the only way is to map dhis data to icd10
> and openmrs to icd10 and icd10 to icd10, giving freedom to dhis implementers
> what icd10 codes will form particular data element.
>
  DataSet, Category and Categorycombo are DHIS internal structure, they
> cannot be part of any standard. Tying this all into one as to solve
> interoperability issue, will not bring to success.
>

Dataset is a common concept between dhis, sdmx dsd and openmrs reporting
module.

I agree that Category and CategoryCombo are DHIS idioms but they do
translate to Dimensons, Dimensionsets and Codelists within SDMX.  These are
shared with openmrs so require urn.  Currently I am generating these SDMX
messages by xslt from dxf but uuids is required.


>
> As part of my PhD I am learning standards and standard making in healthcare
> and so far I didn't see two countries using the same form for data
> collection. there is explanation for this: each country has prioritized
> certain aspect of healthcare, like in Tajikistan it is TB and in African
> countries it may be HIV and child mortality. From this countries may haver
> different set of data elements, even at dhis level they want more detailed
> info on particular cases, say from example above Tajikistan uses all TB
> ICD10 in DHIS with little generalization and more details. It also can go
> down to level as http://apps.who.int/classifications/apps/icd/icd10online/.
>
> I tried to express my ideas on interoperability, hope it helps in some way.
> In general DHIS meta should be something like this:
>
> <de name='TB' id='whatever implementer did'>
> <neededICD10>
> <icd10 idFrom='A-15' idTo='A-19'/>
> <icd10 id='J-321'/>
> <icd10 id='P-001'>
> </neededICD10>
> </de>
> <de name ...
>
> This would be enough for openmrs like system to figure out what data needed
> looking at icd10 library of its own.
>

For the moment these ICD10 codes are not required.  OpenMRS composes its
aggregate dataelements in its reporting module manually.  It is not an AI
operation.  We are not required to tell them how to do the mapping.  BUT ...
using sdmx it is possible to attach arbitrary additional metadata to
dataelement definitions so I can foresee this is where in the future,
information like the icd10 codes and possibly other information which might
assist the mapping, would be attached and would be useful to assist in the
mapping process.

Regards
Bob
.



>
> murod
>  ------------------------------
> *From:* Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> *To:* dhis2-devs <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
> *Sent:* Sunday, September 13, 2009 3:46:21 PM
> *Subject:* [Dhis2-devs] interoperability and uuids
>
> Greetings
>
> Looking at data exchange with openmrs using sdmx_hd (or anything else for
> that matter).  Every metadata that is exchanged will require a uuid.
> Currently looking at what is required to share metadata regarding a
> metadata, means that the following are required to have uuids:
>
> DataElement - already have
> OrgUnit- already have
> DataSet
> Category
> CategoryCombo
>
> The DataSet is not strictly required, but probably useful.  The category
> (Dimension) and CategoryCombo (DimensionSet) are.  Any objections,
> suggestions or other comment?
>
> Regards
> Bob
>
>
>
>