So using ODK2 I could create a nice app with odk-table and odk-survey. It is kind of a small EMR for outreach teams. The outreach worker find back the patient through table and then update/register data through survey.
Thanks a bunch to the ODK team for the ODK2 suite.
I am now looking at some kind of integration with DHIS2 tracker. I can see how it works with collect and aggregate, however with table I am confused:
When collecting a new data, ok, “just” have to transfer this new data to DHIS2. But what if it is an already existing data that is modified? For example in my case, a patient is changing of phone number, or address, or was HIV negative and become positive…
Also, synchronizing aggregate to DHIS2, ok. But with table I will now have a sync from aggregate to android. So would it be possible to make a change in DHIS2 that is then sync to aggregate and then Android (actually the other way around)?
Did anybody already face such integration?
Or if you have any ideas, advices or example of code, that would be much appreciated.
The way I would imagine an integration between ODK 2.0 and DHIS2 tracker would require a “bridge” service that would translate between the two. New rows or updated rows would be synced from the mobile devices to an ODK Sync Endpoint. The bridge service might periodically poll the ODK 2.0 REST API to check for changes, or the Sync Endpoint could be modified to trigger a callback. Either way, after changes are detected the bridge service would read from ODK and write to DHIS2 tracker.
This bridge service should also work in reverse. Changes to DHIS2 would be read by the bridge service and written to the ODK 2.0 Sync Endpoint. Changes to the ODK 2.0 Sync Endpoint are automatically replicated to the Android devices when they sync, so no extra effort would need to be made.
This bridge service would also need to be able to authenticate with both ODK 2.0 and DHIS2, and translate identities across the two services.
Currently, there is a prototype to allow users registered with a DHIS2 system to login to a ODK Sync Endpoint using their DHIS2 credential. The ODK Sync Endpoint also reads information from the DHIS2 server to assign users the right access to data stored on the ODK side. The next step is a prototype integration bridge for data synchronization. Once more testing has occurred it will be added to the Sync-Endpoint.
I am still a bit confused on how should look like this bridge service (python script on my Unix server or JS files; launched by DHIS2, or ODK2, or maybe a CRON; what is the scope of this service and what can be handled by ODK2 or DHIS2), but I guess an extensive reading of ODK2 and DHIS2 REST APIs will answer most of my questions.
I am new to REST APIs so I have a bit of work ahead and will take a look to this authentication prototype.
When I said bridge service I was thinking of a microservice. You could write a python microservice but it would be more heavyweight than a script. It might be possible to pull something off with CRON and python scripts, but at least what I’m imagining would get pretty complex and probably not save you much. And either way you’re going to need to use the authentication service.
The ODK 2 API will give you access to the data, but will not notify you of any changes. The authentication service will handle translating identities, but it will be the job of the bridge service to move data back and forth between DHIS 2 and ODK 2, and to translate between their data formats.
Also, just a heads up, the documentation for the latest ODK Sync Endpoint is available here. You will need to use them and not Aggregate for the authentication service.
I wrote a tool that could copy data between a DHIS2 server and a Sync Endpoint server. You can find it here.
If you’re looking to integrate identity information between the 2 servers, there is also a new authentication mechanism for Sync Endpoint that enables users to login to Sync Endpoint using DHIS2 credentials. You can find out more about this here.
If you decide to try them out, let me know if you run into any problem.
and will take a look to this authentication prototype.