dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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.

Regards
Bob

2009/8/7 Dr. Juma Lungo <juma.lungo@xxxxxxxxxxxx>

>
> -------- Original Message --------
> Subject: Re: OpenMRS integration
> From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> Date: Fri, August 07, 2009 8:57 am
> To: "Dr. Juma Lungo" <juma.lungo@xxxxxxxxxxxx>
> Cc: Jorn Braa <jornbraa@xxxxxxxxx>, anthony_muyepa@xxxxxxxxxxx,
> muyepaa@xxxxxxxxx, dhis2-devs@xxxxxxxxxxxxxxxxxxx,
> johnlewis.hisp@xxxxxxxxx, larshelge@xxxxxxxxx, sundeep.sahay@xxxxxxxxx,
> yusuphk@xxxxxxxxx, Yusuph Kassim <yusuph28@xxxxxxxxxxx>
>
> Hi Jumar
>
> Thanks for this.
>
> 2009/8/7 Dr. Juma Lungo <juma.lungo@xxxxxxxxxxxx>
>
>> 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 :-)   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.
> -------
>
> Regards
> Bob
>
> 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 <bobjolliffe@xxxxxxxxx>
>> Date: Fri, August 07, 2009 12:35 am
>> To: Yusuph Kassim <yusuph28@xxxxxxxxxxx>
>> Cc: Jorn Braa <jornbraa@xxxxxxxxx>, anthony_muyepa@xxxxxxxxxxx,
>> muyepaa@xxxxxxxxx, dhis2-devs@xxxxxxxxxxxxxxxxxxx,
>> juma.lungo@xxxxxxxxxxxx, johnlewis.hisp@xxxxxxxxx, larshelge@xxxxxxxxx,
>> sundeep.sahay@xxxxxxxxx, yusuphk@xxxxxxxxx
>>
>> 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.
>>
>> Regards
>> Bob
>>
>> 2009/8/6 Yusuph Kassim <yusuph28@xxxxxxxxxxx>
>>
>>>
>>>
>>> Hi,
>>> 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)
>>>
>>> cheers
>>>
>>>
>>>
>>>
>>> > Date: Thu, 6 Aug 2009 10:06:39 +0200
>>> > Subject: Re: OpenMRS integration
>>> > From: jornbraa@xxxxxxxxx
>>> > To: anthony_muyepa@xxxxxxxxxxx; muyepaa@xxxxxxxxx;
>>> bobjolliffe@xxxxxxxxx; dhis2-devs@xxxxxxxxxxxxxxxxxxx;
>>> juma.lungo@xxxxxxxxxxxx; johnlewis.hisp@xxxxxxxxx; larshelge@xxxxxxxxx;
>>> sundeep.sahay@xxxxxxxxx; yusuphk@xxxxxxxxx; yusuph28@xxxxxxxxxxx
>>>
>>> >
>>> > 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 <bobjolliffe@xxxxxxxxx> wrote:
>>> > > Thanks Lars. I will take responsibility for putting together and
>>> > > implementing a plan of action for this. This will have to include
>>> > > absorbing
>>> > > 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
>>> > > from
>>> > > Murod. Alongside there have been developments in the availability of
>>> xml
>>> > > interchange standards which can impact positively or negatively on
>>> the
>>> > > work.
>>> > >
>>> > >
>>> > > 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
>>> > > Bob
>>> > >
>>> > > 2009/8/5 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>> > >
>>> > >> 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.
>>> > >>
>>> > >>
>>> > >>
>>> > >> cheers
>>> > >>
>>> > >> Lars
>>> > >>
>>> > >> _______________________________________________
>>> > >> Mailing list:
>>> > >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>> <https://launchpad.net/%7Edhis2-devs>
>>> > >> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> > >> Unsubscribe :
>>> > >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>> <https://launchpad.net/%7Edhis2-devs>
>>> > >> More help : https://help.launchpad.net/ListHelp
>>> > >>
>>> > >
>>>
>>> ------------------------------
>>> Share your memories online with anyone you want anyone you want.<http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1>
>>>
>>
>>
>