OpenMRS integration

Hi Jumar

Thanks again for the clarification. I just wanted to be clear because in your earlier post you referred to the need to alleviate some of the “manual collation and aggregation activities (manual generation of health facility based statistical report)”. We agree that DHIS does not do this at the facility level. The register based software must have the functionality to produce these reports. What DHIS provides - in an integrated scenario - is a destination application which can consume this data if it is produced in an agreeable format, in this case DXF. And then do a lot of relief of manual collation and aggregation at that level.



2009/8/7 Dr. Juma Lungo

-------- Original Message --------

Subject: Re: OpenMRS integration

From: Bob Jolliffe

Date: Fri, August 07, 2009 8:57 am

To: “Dr. Juma Lungo”

Cc: Jorn Braa,,,,,,,, Yusuph Kassim

Hi Jumar

Thanks for this.

2009/8/7 Dr. Juma Lungo

Hi Bob

i will take your last question, why integration is necessary?

In our case, all healthcare organisations are obliged to report their services to higher authority. While Register based Software (care2x and afyapro - in our case) serve a lot at the facility level, they do not relieve health workers with manual collation and aggregation activities (manual generation of health facility based statistical report). This integration serves this purpose.

OK. This makes sense. How would it work in practice? I am thinking of the scenario of DHIS and Care2X at the same level, perhaps even on the same machine or LAN. I suppose you start with the required statistical paper report form and work back to see how much of this information you already have in Care2X register-like records. What bothers me is that then you still have to do the aggregation in Care2X (typically maybe counting with SELECT COUNT from your registers) before you export to DHIS. So presumably you can generate the monthly report without the use of DHIS. Some of the value-add of integration I’m guessing might be (i) the ability to combine with other data not present in Care2X (ii) ability to analyze the aggregate data over time (iii) data warehousing and reporting audit trail …

Bob, DHIS and Care2x cannot sit in one computer in most of the cases. And even if it happens, they will have completely two different users. DHIS is aimed to work at District Medical Office (DMO), Regional Medical office (RMO) and at the national level (MoH). Care2x cannot find its way to the DMO, RMO and MoH. Register Systems work only at Health Facility level. Thus, there will be always a process of generating report from health facility (100km away from DMO) to the DMO office. Then from DMO to RMO and then from RMO and MoH. In climbing the ladder, here is where register based system find their limitation hence DHIS.

In terms of proven fruitful and functional integration, we are not there yet. This is because, these register based software are implemented in places (regions) with limited DHIS use. However, we are heading to proving the usefulness/uselessness of this approach. we want to put the DHIS in the areas where there is substantial use of care2x and afyapro software.

I am sure it will be usefulness that you uncover :slight_smile: Are you talking of putting DHIS at the district level where it might accept facility aggregate data from a number of care2x, afyapro and manual and other systems? Rather than running the two on the same level?

YES. Imaging a district with 100 health facilities located at least 100 kms from DMO. This implies that if you put DHIS at DMO, then, data clacker at this level will enter 100 reports to the DHIS monthly. now if some of these 100 HF have installed Care2x, then care2x enabled HF will be bring electronic copy of their monthly reports and get imported straight to the DHIS. It will server time and improve accuracy of data.


BTW. I see on website that AfyaPro also claims to do government monthly reporting. Presumably it replicates the paper reporting form. Ideally we also want the software to make this available as a dxf (or maybe sdmx) file which might be consumed by a DHIS instance upstream? In other words (in an ideal world) government should mandate an electronic format (just as currently they mandate a paper form) which Care2X, AfyaPro and others should be able to produce and which dhis2 can consume.

Juma Lungo

-------- Original Message --------
Subject: Re: OpenMRS integration

From: Bob Jolliffe

Date: Fri, August 07, 2009 12:35 am
To: Yusuph Kassim
Cc: Jorn Braa,,,,,,,,

Hi Yusuph

Thanks for this update. This is interesting to me as I think it is my first sighting of another implementation of dxf format in the wild! That’s important to know if we start tweaking with the format.

I haven’t looked at care2x for a long time. Last I looked it was based on PHP (v4). There was still some angst about adopting the right framework for move to PHP5. I guess that is all resolved now. Or maybe they decided to stary put with php4. Is your php implementation of dxf available anywhere? I’d like to take a look.

On the question of organisation hierarchy, I’ve had this discussion with a few people and maybe your experience will confirm. It is only DHIS which really needs to have a knowledge of the tree. For a hospital or facility running care2x or openmrs it presumably doesn’t matter. What matters is that it has an identifier which is recognizable by DHIS. Am I right in thinking this?

I’m interested in your translation of icd10 codes to dataelements. Am I right in thinking that for each named ic10 code you have (potentially) a dhis dataelement with the same name? Or you have a mapping between named icd10 codes and named dhis data elements? I’m wondering if there might be something general we can extract from this, like a standardized ICD10 dataelement mapping for other contexts. Possibly not. But what actual data have you imported? I know that care2x has a lot of tables ranging from canteen to patient record. I guess if you are focussed on ICD10 it is derived from patient record. So you have aggregated monthly, weekly or what have you within care2x and then exported to DXF?

Most importantly, why have you done this? I am looking for proven use cases where dhis is linked to another system and there is a clear and tangible beneficial outcome.

Sorry for all the questions.



2009/8/6 Yusuph Kassim


Just to high light the work done in integrating the DHIS and care2x which also is the same way used in integrating with the other afya pro system is to produce an xml file with dfx format for that particular system, the idea is that DHIS mainly finds the dataelement, the organization unit, the period and the values (which references the later) as the main fields, the good thing about it, if you have the names of the organization unit and the name of dataelements and the date format exactly as in DHIS then the import is easy, so what we actully did, is to map the names of the ICD10 in care2x and the names of data element in DHIS and everything was automatic.

hope this highlights what we did.

NB. the organizationunitrelationship (the parent and the child mainly depends if you are importing data for the first time, but if you have all the names of facility in your system, the hierachy will sort itself out)


Date: Thu, 6 Aug 2009 10:06:39 +0200
Subject: Re: OpenMRS integration


Bob and all,
think broader than openmrs. In tanzania we have also care2x and
another hospital sw, which will also come to malawi, where baobab,
which uses openmrs data structure, is a priority.

Bob, include tz and mw in your mandate for dhis integration. We want
generic approach to mapping and etl w dhis as destination. Note that
baobab should be thight as openmrs as they are large national project

w whom we working. Openmrs is also in mw, so same approach for both.

Discuss w yusuph how they do care2x in tz.

Jorn, on mobile

On 8/5/09, Bob Jolliffe wrote:

Thanks Lars. I will take responsibility for putting together and
implementing a plan of action for this. This will have to include
the learning from the various integration efforts which have happened -

there is the work Abyot has done, there is work Phumzile and others have
done on the OpenMRS side, there is an existing (untouched for two years)
DHIS “connector” module for openmrs and there is the most recent effort

Murod. Alongside there have been developments in the availability of xml
interchange standards which can impact positively or negatively on the

Also there are opportunities to interoperate with other software (such as
iHRIS HR package and no doubt others in the future) so it is important to
not treat each as a new design program, but rather expose and document a

standard process for getting data in and out of DHIS2.

The first step will be to identify the right forum for communication with
the relevant people from across projects. I’m interested in people’s

thoughts on this.

Regards for now

2009/8/5 Lars Helge Øverland

Hi all,

after some discussions with Jørn we have decided that Bob will be
responsible for the OpenMRS - DHIS 2 integration process. This means

that he will come up with a design and plan of action, and suggest who
will be developing on the various components.

I admit that this could have been communicated better and earlier. I

will from now on take more responsibility on coordination of tasks and
communication of what we agree on.

More info from Bob later.



Mailing list:<>

Post to :
Unsubscribe :<>

More help :

Share your memories online with anyone you want anyone you want.