Dear everyone,
Happy 2015, and hope everyone had a great holiday. We have been in ongoing discussions at the MOHSW about moving forward with the DHIS2-HFR integration that has been in our plan. We have had several meetings during the last 6 months related to this integration, and attached is the Visio/JPG which describes this integration model.
The MOHSW has decided that the HFR will be the master record for all facility data, and other systems will be able (once integrated) to read from this system. During several discussions, it has been agreed to move forward with a standards based integration
approach, which will make it easier for all other HIS to integrate with the HFR. Currently, the HFR underlying data system – RM and DHIS2 support the Care Services Discovery Standard (CSD) V1.0 (see the following link for details
- ftp://ftp.ihe.net/DocumentPublication/CurrentPublished/ITInfrastructure/IHE_ITI_Suppl_CSD.pdf). We had completed a preliminary mapping of key DHIS2 facility fields to the HFR fields (see second attachment). There will be some minor modifications
needed to CSD V1.0 to fully support the mapping across fields, but we can get help from the OHIE community to assist with this, particularly those who have been working with CSD and the interoperability testing of some of the OHIE components using this standard.
Interoperability testing for CSD V1.1 is ongoing currently with RM.
Related to the content harmonization, we have two staff who are using a tool provided by OHIE to do the facility comparison, region by region (and council within region). We have completed several regions so far, and this is taking longer than planned as there are more differences than expected (although quite a few are more minor such as ownership differences), and have taken one example region of Arusha (and all councils) and created the summary excel file that highlights differences, with cover note that can be shared with the DMO to review and reconcile the differences in these facilities. Once we have this reconciliation back (and we can do this incrementally across regions) the needed updates can be made through the curation tool. See the attached example Arusha comparison which shows the differences found between the HFR and the DHIS for facilities.
I also wanted to introduce Nseya Kipilyango, who started working with our team, mainly working with the ICT Unit, more specifically in eHealth, working with Marcos and his team. Marcos and his team will follow up here with the broader HFR group (and we may need to update the googlegroup distribution list) to start the needed discussions in country related to this integration. RTI will continue to work with InSTEDD and the OHIE team to ensure that their work is supporting the proposed integration here.
I rely on Marcos, Esther, Nseya and the team to follow up here, and also correct anything here that I may have misstated,
Regards
Niamh
--
You received this message because you are subscribed to the Google Groups "hfr-tz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hfr-tz+un...@googlegroups.com.
To post to this group, send email to hfr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<DHIS2-HFR.jpg><DHIS2-HFR.vsd><Field Mapping HFR-DHIS2-CSD.docx><26 Nov Arusha_sites Comparison.xlsx>
Hi Nico,
Right now, for DHIS2 changes, the user calls UDSM and then UDSM checks DHIS2 and then makes the update. They are making a few of these a week (or that is what I have been informed). I would imagine that this rate has dropped off significantly. The UI refresh here means that once UDSM have added the facility into DHIS2, and notified the user, the user will now see this facility listed in DHIS2, marked as active in DHIS2 and then also the forms that match the services the facility offers will be visible for this facility (e.g. IPD, OPD …).
In this case, the district level person who notified UDSM about the facility addition is supposed to go to the HFR, and then request the change, which is then approved by the MOHSW. Right now, the conflict resolution we are looking at is all manual, as we do this HFR-DHIS2 comparison.
There has been no final decision on where the master geographic administration (GA) is stored. Right now DHIS2 has their own hierarchy (Region-Council) and facilities fall under Council. Any GA changes are made by UDSM manually in DHIS2 (the most recent district splits they moved the facilities over). We also loaded the revised GA into HFR from the official list received through PMORALG/MOHSW and the associated facilities moved along with this change.
The GoT have not made a final determination on how the GA will be managed officially, and changes tracked. This is something that needs to be addressed, and is on the long list of things to do related to EA. In the DHIS2-HFR integration we have not talked about how we manage GA updates in this process, and these can be managed manually in the short term until the GoT decides how to manage this electronically or who is the authoritative source for managing this GA.
Sri may be able to weigh in here as to whether the NeHSC has discussed this issue at all to date?
Thanks, Niamh
Hi everyone,
Here is a follow up message from Paul that for some reason did not make it through the hfr-tz google group list.
Thanks, Niamh
From: Paul Biondich <pbio...@regenstrief.org>
Date: Tue, Feb 3, 2015 at 2:41 PM
Subject: Re: [ HFR TZ ] Planning for HFR-DHIS2 integration to circulate
To: hfr...@googlegroups.com
Cc: "nkipi...@nb.rti.org" <nkipi...@nb.rti.org>, "mz...@moh.go.tz" <mz...@moh.go.tz>, "Esther
Msechu (ems...@moh.go.tz)" <ems...@moh.go.tz>, "Perera, Sriyanjit (Sri) (CDC/CGH/DGHA) (CTR) (ii...@cdc.gov)" <ii...@cdc.gov>,
"Kalungwa, Zaharani (CDC/CGH/DGHA) (iy...@cdc.gov)" <iy...@cdc.gov>, "Mkwati, Denis Alan (CDC/CGH/DGHA) (wl...@cdc.gov)" <wl...@cdc.gov>,
"Wengaa, Desderi" <dwe...@rti.org>, "Shaun J. Grannis" <sgra...@regenstrief.org>, Carl Leitner <clei...@capacityplus.org>
Hi Niamh, thanks for taking the time to write this up.
I wanted to write a couple of quick comments to frame some of what will soon come from this work.
1) "Central authority": The MOHSW has committed to a central authority, which is the HFR, and the work they are doing to harmonize DHIS2 with HFR will ultimately create a more up to date central authority which can then be used by other systems. The Arusha sample comparison you sent over is a great example of what happens when there are multiple authorities/sources for facilities . In this case, either the HMIS system or the FR contain what seems to be more current/relevant information for a given facility. In my experience, the key to resolving this is to do what the MOHSW is doing: committing to a central authority. There will be ways programmatically to ensure that changes to the HMIS system show up for stewards of the facility registry, and vice versa. However, the key is that we all help the MOHSW make sure the FR represents truth.
2) What is a health facility in TZ? As you know Niamh, I helped the MOHSW define a facility data specification, which defined, among other things, what the inclusion and exclusion criteria for health facilities were. In talking with some of my friends in the OpenHIE community, it seems that operational realities might nudge the MOHSW in taking another look at this. The specific example I learned about yesterday was a project organized around the health worker registry, which helped the MOHSW learn that ambulance mechanics are too few and diffuse to appropriately manage the ambulances within the country. The health worker registry folks defined these mechanics as health workers, and there was supposedly a need to track the places where these workers were employed from. Does that imply that the definition of a health facility needs to change?
Regardless of the specific example, there's going to be a natural need to continually refine and modify the facility registry data specification over time, as examples like this come to light. We need to make sure that the MOHSW is in control of this process, and naturally we can do whatever we can to help that happen efficiently.
3) Use of standards: in the case of the communication between registries like the facility registry, OpenHIE is putting a lot of energy into "plucking" and refining pre-existing standards for communication needs like you've described. However, those standards sometimes fall short of perfect fits for the functions we need of them. That said, the CSD specification is very much a work in progress, and needs a few rounds of revision and simplification to get it to the place where it can support the things TZ needs of it. We'll make sure to do what we can to take that real world experience and push changes in the standards.
Here to help, as always,
-Paul
From: hfr...@googlegroups.com [mailto:hfr...@googlegroups.com]
On Behalf Of Darcy, Niamh
Sent: Monday, February 02, 2015 6:02 PM
To: hfr...@googlegroups.com
Cc: nkipi...@nb.rti.org; mz...@moh.go.tz; Esther Msechu (ems...@moh.go.tz); Perera, Sriyanjit (Sri) (CDC/CGH/DGHA) (CTR) (ii...@cdc.gov); Kalungwa, Zaharani (CDC/CGH/DGHA) (iy...@cdc.gov); Mkwati, Denis Alan (CDC/CGH/DGHA) (wl...@cdc.gov); Wengaa, Desderi
--
Thanks Elaine,
Excellent point, and one that I know we used to have on our HFR to do list in 2013, to start to form a working group in this area. We lost this from our action item list as we got to focus more specifically on the HFR and the urgency to get this up and working.
So, maybe something that under HSSP IV could be added somewhere? I have not heard this discussed under HSSP IV but it seems like it would be really useful to have this in HSSP IV.
Niamh