Hi Bob,
Thanks for this.
This will be very useful.

what do you think about openmrs generating dxf like ihris?

Ime

--- On Thu, 9/15/11, Bob Jolliffe <bobjolli...@gmail.com> wrote:

From: Bob Jolliffe <bobjolli...@gmail.com>
Subject: Re: [Dhis2-devs] dhis2 dxf data import
To: "Ime Asangansi" <asanga...@yahoo.com>
Cc: "dhis2-devs" <dhis2-devs@lists.launchpad.net>
Date: Thursday, September 15, 2011, 11:36 AM

On 15 September 2011 10:01, Ime Asangansi <asanga...@yahoo.com> wrote:

Thanks Bob, the pdf is useful.

When you mean codes, you mean the unique id for the record?


I wish life were so simple :-)  There are quite a few ways that an identifiable 
object (eg Orgunit) can be judged unique:

1.  the primary database key 
2.  the name
3.  the uuid
4.  the code


1 and 2 are not good for a number of reasons.

3 is quite ok except that (a) its a bit long and (b) we might have to map to 
data from elsewhere which doesn't use a uuid.

This latter case is quite common - if dhis was the central authority in the 
world for assigning metadata (sometimes it feels like it is designed as if it 
is :-) life might be better - but the reality is that sometimes there are other 
authorities and it is good that there are.  The case we have been dealing with 
in Kenya for example - where they have an official Master Facility List which 
is responsible for registering facilities and assigning codes.  In which case 
we use these official codes in the code field of orgunit.  



Secondly, +1 for an internal routine to assign ids

I'm in two minds about this.   For sure it might be better to have generated 
codes ou23, de456 etc rather than leave the field blank.  But codes generally 
work best when assigned, such as the MFL case above.



Thirdly, please how are you generating the dxf for ihris? 

iHRIS is doing the generating the dxf for us ie. they are generating HR 
dataelement values (number of docs, nurses etc) 


Bob


Thanks

Ime


--- On Thu, 9/15/11, Bob Jolliffe <bobjolli...@gmail.com> wrote:





This will also streamline metedata generation because one will only need to 
generate and pass metadata for only de/ou/period.

But I wonder; what's the difference between orgunitId and orgunit in your 
example.




That's a typo.  Please take a look at the pdf file I sent out earlier this week 
as that is more correct.
 


Also, some elements don't use any categories, but the model references a 
default categorycombo. How will that look in your proposed schema?



The default categorycombo is just that - default.  So in the absence of any 
categories the categorycombo is automatically set to default when saving 
datavalues. 



Would you branch Jo's code in a way we could use easily test yours as a module? 
or...



The reading of this format is already implemented in the import/export module.  
It is tightly coupled with Jo's code in the sense of making use of the same 
element/attribute name strings defined in his beans.  So you can already use it 
by just importing the xml file.  To test you should ideally set up some codes 
in your database.  We should try and do this in the demo instance so people can 
try it there.  Meanwhile I would suggest to test:



(i) pick an orgunit and assign it a code if it does not already have one (eg 
ou1)
(ii) pick a small dataset and assign it a code (eg dataset1)
(iii) assign codes to the dataelements within the dataset
(iv) assign the dataset to the orgunit



Then you should be able to import datavaluesets according to the examples given.

Alternatively you can use the existing uuids instead of the codes.

(It might be worth having a startup routine which automatically assigns codes 
based on the existing internal ids where they do not already exist.)



Regards
Bob
 


Thanks

Ime

--- On Thu, 9/1/11, Bob Jolliffe <bobjolli...@gmail.com> wrote:


The implication of adding all the above will be that whereas
 the
datavalueset above will remain valid (except perhaps shifting to
storedBy), the following would also be valid:

<dataValueSets orgUnitId="code" dataElementId="internal"
  <dataValueSet  orgUnit="23" period="201004" storedBy="Bob" >


    <dataValue dataElement="2" value="4" Sex="1" />
    <dataValue dataElement="2" value="5" Sex="2"/>
    <dataValue dataElement="4" value="43" Sex="1" Age="3" />


    <dataValue dataElement="5" value="44" Sex="1" Age="3" />
  </dataValueSet>
</dataValueSets>

I am pretty sure I can implement the above without breaking what is


currently there.  One possible but minor breaking change I would
suggest to improving parsing of very large datasets might be to
abbreviate some well known element names to dv, de and v
 for
compactness.




_______________________________________________
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

Reply via email to