Hi all
Following our call this afternoon I’ve attached a sample here of what the dxf2 xml message should look like for the ANC aggregate dataelements in the Rwanda HMIS system. I’ve included the text of an earlier mail to provide a little background. As you can see there is a little housekeeping to be done with the codes but nothing serious which should hold us up.
@Suranga, this is basically what we need to produce from your queries. Its a bit verbose with all the comments but those are obviously not necessary on the real messages. James knows that we can already produce this using the openmrs dhisreport module (https://github.com/hispindia/dhisreport), but it would take a little bit more work to make it more suited to a shared health record vs single facility database. Not a lot but a little. I have a recollection in the beginning (earlier version of openmrs) that there was no location identifier in openmrs that we could use. At the time I think I did some hack to append the code to the end of the name. The guys in Hisp India may have gone on to improve that - I’m not sure. Its been a while 
I know they have improved a few things. If you do decide to do some work on the module then I should get you all introduced with the current maintainers in HISP India (copying Arunima fro HISP India for now). If you look at the report template example here (https://github.com/hispindia/dhisreport/blob/master/README.md) you can see that it is all setup to just add in your existing sql queries as annotations.
I think its good that you look at it and James will be well able to guide you through. Do feel free to prod me with technical questions as well. Personally I am not sure 110% sure if this user interface driven approach is what we need at all. I am tempted to think that a simple python (or node.js) script which can be triggered monthly from cron would also solve our little problem quite simply. Still I don’t want to discourage hands willing to improve the module either. Its not beyond the bounds of reason we end up doing both … Can I give you guys a couple of days to go through and we firm up a strategy towards the end of next week?
I’ve been thinking of how (or more where) to setup a test dhis2 instance to practice posting to. I have a linode I can use, but its up and down as I use it for different things. I wonder does this make sense as something to setup in the openhie sandbox? I guess I should chat to Ryan Yates about this. Once we have success in the sandbox we can work with the hmis team to setup the dataset on the production system.
Bob
dvsetCodeANC.xml (2.49 KB)
dvsetCodeANC_SHR.xml (2.56 KB)
···
---------- Forwarded message ----------
From: Bob Jolliffe bobjolliffe@gmail.com
Date: 9 July 2014 09:19
Subject: Re: OpenMRS - DHIS-2 integration - baby steps first
To: “Wilson, Randy” rwilson@msh.org
Cc: “Dawn C. Seymour” dawn@openmrs.org, Uwayezu Gilbert martuwagil@gmail.com, Dusabe Eric duserik@gmail.com, Carl Fourie carl@jembi.org, Muhire Andrew muhireandrew@yahoo.com, Richard Gakuba richard.gakuba@gmail.com
Hi Randy
Its perfectly fine to leave the dataset as it is. Then as I say, to just remove the unreported datavalue rows from the template. I’ve attached revised ones which are just ANC, Perhaps the Jembi team who have produced the SHR queries can look at that further and see if it matches what they have and trim further.
Practically what it means for the data entry staff is that if they start the data entry after the data has been fed from the SHR they will encounter a form which is half filled in. That could be OK. They will fill in the remaining elements and signal completeness when they are done. Of course if the ANC data has many zeros it might be difficult to know whether they have been filled or not. Or if they have conflicting data from the paper record they would need to know what action they should take - overwrite or not? Do we have much sense yet from running the queries ‘off-line’ of how the data quality will be and how it will compare with data taking the ‘traditional’ route? Perhaps it would be worthwhile to do a dry-run against the SHR for the past few months and take a look at the numbers against what is in dhis2.
Given the enormous difficulties in keeping all the POC systems up and running and reporting data all the time we might well find that, besides the numbers being different, it might also likely be patchy with some reports missing from some of the facilities some of the time. The question is how much discretion we put in the hands of the data entry clerk to handle the situation.
Maybe it will be best to make another ANC dataset in the short term. It would be easy to create the dataelements with codes with _SHR appended to them (eg ANC8142_SHR). Another reason to prefer codes over uids. Then we can generate monthly reconciliation reports between the 2 which would be excellent feedback for the facilities anyway. If and when you are ready to take the full plunge it would be trivial for the producer to drop those _SHR appendages at any stage in the future.
Regards
Bob
PS. Note that the code for “ANC pregnancy under 15 years” is inconsistent with the others. It should have a ‘ANC’ prepended to it. You should really fix that inside hmis and repair the template accordingly.
