hmis messages

Roger_Friedman · July 5, 2014, 7:27pm

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

···

After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com > > > wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Carl_Leitner1 · July 8, 2014, 5:25pm

See the inline comments below.
Cheers,
-carl

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

 “I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

···

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

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

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com > > > > wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

bobj · July 10, 2014, 9:32am

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

···

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Carl_Leitner1 · July 10, 2014, 1:41pm

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)
measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

···

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

bobj · July 10, 2014, 2:19pm

Hi Carl

I understand the mathematics of interpolation algorithms (at least I used to much better …). And I also understand the importance of modelling survey data, which I think (somebody correct me) we don’t currently do. And if you had a time series of survey data measurement points you could interpolate between them. I believe we do currently do some pretty primitive (linear) interpolation for things like population data which are reported year by year but are often required in calculation of monthly indicators. The same could be done with staffing figures which are reported say quarterly and are then used in monthly indicators.

But I don’t really understand why that is such a big issue in your case - I think there are other cases where it would be. In your case there would be a data flow agreement (see note below) whereby the HWR would report data every quarter (or month or whatever has been setup for the dataset). In this case the only inconvenience you suggest is that you have to compute the period (eg 2014Q1 from the date 2014-03-30). That doesn’t seem too cumbersome and I recollect that you have handled this in the past fairly well with xslt.

Though it seems a reasonable suggestion that there could be the ability within dhis2 to compute this period on the basis of 1. the reporting date and 2. the period type of the dataset in the absence of a period attribute in the datavalue. You can certainly create a blueprint for this. Though this would be different to the question of interpolation.

Bob

note: sdmx had quite a good vocabulary for modelling data flow agreements. Its a part which the WHO folk had ruled out of scope for sdmx-hd but I always felt was very useful. But I think the IL is the proper place for modelling these.

···

On 10 July 2014 14:41, Carl Leitner litlfred@gmail.com wrote:

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)

measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

On Jul 10, 2014, at 5:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Carl_Leitner1 · July 10, 2014, 2:41pm

Hi,

Certainly in my case, it is not overly cumbersome. That being said, it is yet one more thing that someone needs to configure and get right before we can light up the systems. As Health IT HR resources are pretty thin, if there is a chance of eliminating a configuration step, that is providing no new information, I would be in favor of it.

Although my case is only one example, I do think it highlights a gap in the current state of DXF that others would likely come across.

Could you possibly point to some more about the SDMX vocab. for data flow agreements. That sounds interesting.

I’ll leave off submitting any blueprints. We now have two reasonable options, and I am not really that concerned how DHIS2 deals with measurement data, only that I think it should. In either case, I think each option would require a change to DXF. I think there is also more feedback that will likely come in on this (e.g. at the HELINA conference).

Cheers,
-carl

···

On 10 July 2014 14:41, Carl Leitner litlfred@gmail.com wrote:

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)

measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

On Jul 10, 2014, at 5:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

sgrannis · July 10, 2014, 2:47pm

Good conversation.

Re: SDMX vs DMX –

For what it’s worth, we evaluated SDMX for two previous projects (unrelated to OpenHIE), and chose to create our own aggregate data format in one case, and in the second case we opted for DMX.

A common concern regarding SDMX for both assessments: SDMX generates (what we believed to be) unnecessarily large, duplicative transactions.

Best,

Shaun

···

Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Thu, Jul 10, 2014 at 10:41 AM, Carl Leitner litlfred@gmail.com wrote:

Hi,
Certainly in my case, it is not overly cumbersome. That being said, it is yet one more thing that someone needs to configure and get right before we can light up the systems. As Health IT HR resources are pretty thin, if there is a chance of eliminating a configuration step, that is providing no new information, I would be in favor of it.

Although my case is only one example, I do think it highlights a gap in the current state of DXF that others would likely come across.

Could you possibly point to some more about the SDMX vocab. for data flow agreements. That sounds interesting.

I’ll leave off submitting any blueprints. We now have two reasonable options, and I am not really that concerned how DHIS2 deals with measurement data, only that I think it should. In either case, I think each option would require a change to DXF. I think there is also more feedback that will likely come in on this (e.g. at the HELINA conference).

Cheers,
-carl

On Jul 10, 2014, at 10:19 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

I understand the mathematics of interpolation algorithms (at least I used to much better …). And I also understand the importance of modelling survey data, which I think (somebody correct me) we don’t currently do. And if you had a time series of survey data measurement points you could interpolate between them. I believe we do currently do some pretty primitive (linear) interpolation for things like population data which are reported year by year but are often required in calculation of monthly indicators. The same could be done with staffing figures which are reported say quarterly and are then used in monthly indicators.

But I don’t really understand why that is such a big issue in your case - I think there are other cases where it would be. In your case there would be a data flow agreement (see note below) whereby the HWR would report data every quarter (or month or whatever has been setup for the dataset). In this case the only inconvenience you suggest is that you have to compute the period (eg 2014Q1 from the date 2014-03-30). That doesn’t seem too cumbersome and I recollect that you have handled this in the past fairly well with xslt.

Though it seems a reasonable suggestion that there could be the ability within dhis2 to compute this period on the basis of 1. the reporting date and 2. the period type of the dataset in the absence of a period attribute in the datavalue. You can certainly create a blueprint for this. Though this would be different to the question of interpolation.

Bob

note: sdmx had quite a good vocabulary for modelling data flow agreements. Its a part which the WHO folk had ruled out of scope for sdmx-hd but I always felt was very useful. But I think the IL is the proper place for modelling these.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 10 July 2014 14:41, Carl Leitner litlfred@gmail.com wrote:

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)

measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

On Jul 10, 2014, at 5:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

bobj · July 10, 2014, 2:58pm

you’d have to rummage around the internet and read the sdmx source docs. But the Data Flow as a concept is defined here http://stats.oecd.org/glossary/detail.asp?ID=7098.

As you well know, you could drag me through a hedge backwards before I’d suggest we adopt sdmx per se. But nevertheless, things like the data flow are interesting to look at when looking for guidance and inspiration on these things. As I recall (and its been a while) it allows you to specify the sources and sinks for particular transactions as well as things like particular key families and periodicity. IHE may support a similar profile, I don’t know. I suspect its really an IL question ie. supporting a grammar to describe orchestration.

···

On 10 July 2014 15:41, Carl Leitner litlfred@gmail.com wrote:

Hi,
Certainly in my case, it is not overly cumbersome. That being said, it is yet one more thing that someone needs to configure and get right before we can light up the systems. As Health IT HR resources are pretty thin, if there is a chance of eliminating a configuration step, that is providing no new information, I would be in favor of it.

Although my case is only one example, I do think it highlights a gap in the current state of DXF that others would likely come across.

Could you possibly point to some more about the SDMX vocab. for data flow agreements. That sounds interesting.

I’ll leave off submitting any blueprints. We now have two reasonable options, and I am not really that concerned how DHIS2 deals with measurement data, only that I think it should. In either case, I think each option would require a change to DXF. I think there is also more feedback that will likely come in on this (e.g. at the HELINA conference).

Cheers,
-carl

On Jul 10, 2014, at 10:19 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

I understand the mathematics of interpolation algorithms (at least I used to much better …). And I also understand the importance of modelling survey data, which I think (somebody correct me) we don’t currently do. And if you had a time series of survey data measurement points you could interpolate between them. I believe we do currently do some pretty primitive (linear) interpolation for things like population data which are reported year by year but are often required in calculation of monthly indicators. The same could be done with staffing figures which are reported say quarterly and are then used in monthly indicators.

But I don’t really understand why that is such a big issue in your case - I think there are other cases where it would be. In your case there would be a data flow agreement (see note below) whereby the HWR would report data every quarter (or month or whatever has been setup for the dataset). In this case the only inconvenience you suggest is that you have to compute the period (eg 2014Q1 from the date 2014-03-30). That doesn’t seem too cumbersome and I recollect that you have handled this in the past fairly well with xslt.

Though it seems a reasonable suggestion that there could be the ability within dhis2 to compute this period on the basis of 1. the reporting date and 2. the period type of the dataset in the absence of a period attribute in the datavalue. You can certainly create a blueprint for this. Though this would be different to the question of interpolation.

Bob

note: sdmx had quite a good vocabulary for modelling data flow agreements. Its a part which the WHO folk had ruled out of scope for sdmx-hd but I always felt was very useful. But I think the IL is the proper place for modelling these.

On 10 July 2014 14:41, Carl Leitner litlfred@gmail.com wrote:

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)

measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

On Jul 10, 2014, at 5:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Carl_Leitner1 · August 11, 2014, 10:17am

Hey,

Just to follow-up a bit, one of the things I sorta hand on my mind was that it would be cool to look at disease incidence and environmental conditions reported from a monitoring station. For example, here is an example of water quality monitoring.

[http://www.waterqualitydata.us/portal_userguide.jsp](http://www.waterqualitydata.us/portal_userguide.jsp)

What is of note is that there is a start date/time and end date/time for measurements.

Cheers,
-carl

···

On 10 July 2014 14:41, Carl Leitner litlfred@gmail.com wrote:

Hi all,

Circling back to Bob’s original question #3, on to the types of messages that an HMIS should support — There are already identified use cases that we are being requested to implement in multiple counties (#HWs by cadre and facility). Doing so currently is a bit cumbersome because of the impedance mis-match in the time-component in the type of data being reported:

counts: which are something done over a period of time (the current data model, as I understand it in DHIS2)

measurements: which are done at a specific point in time (this includes event/survey data)
Both of these can be done on a routine basis.

I am sure that I am missing something here, but putting on my old math and data modeling hat, it seems completely evident that one can use measurement data to interoperate data for periodic reporting. Data interoperation lets us “know (approximately) what it was over the period of interest.” Once we are able to interpolate the periodic data sets from the event/survey data, then you can use that data for aggregation as you move up from the org units.

I understood Bob’s original question in the context of “we have DHIS2 and DXF” as starting point, what needs to change. The preceding paragraph is intended only as a not-unreasonable alternative for how DHIS2 could reasonably support an expanded message set (encompassing survey/event based data as well as periodic data), and not saying that that it should do it that way.

My main concern is to ensure that requirements for the messages submitted to the HMIS to be driven by the requested use cases, rather than current software functionality.

Cheers,

-carl

On Jul 10, 2014, at 5:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Carl

The aggregate data model of dhis2 is fundamentally geared towards periodic routine reporting. So for example if we are looking at maternal mortality and trying to relate that to number of midwives, then we will be looking at that over a period (a month, a quarter, a year or what have you). So it less interesting for the HMIS to know the staffing complement at an instant in time than it is to know (approximately) what it was over the period of interest.

So we store the dataelement with a period identifier. iHRIS is concerned with the complement as it is in the present. Agree the period could be computed on either side, or somewhere in between. But it is certainly easier to support a uniform message which contains the period.

There is certainly a case for dealing with survey data (as distinct to routine data) and event based data. I think there has been many discussions around the former in HISP over the years. Perhaps others will contribute to a description the current state of thinking. Event based data is supported, though I don’t think that is suitable model for messages from the HWR.

Currently, at least within dhis2, it is not supported that the same dataelement is reported at different frequencies.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On 8 July 2014 18:25, Carl Leitner litlfred@gmail.com wrote:

See the inline comments below.
Cheers,
-carl

On Jul 5, 2014, at 3:27 PM, r.friedman@mindspring.com wrote:

Carl, thanks for the report from the field. I have interlineated some comments below. BTW, for those not on the HMIS list, there will NOT be an HMIS call this coming week. Saludos, Roger

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

From: Carl Leitner

Sent: Jul 3, 2014 8:44 AM

To: “greg.rowles@gmail.com”

Cc: Pierre Dane , “open-hmis@googlegroups.com” , “r.friedman@mindspring.com” , Bob Jolliffe , Scott
Teesdale

Subject: Re: hmis messages

Hi All,
After a couple of rounds of iHRIS + DHIS2 integration, and Health Worker Registry (HWR) + DHIS2 integration, here is what I think some of the key areas that could be improved.

Sharing of metadata between systems. In the Liberia iHRIS+DHIS2 we were able to exploit the Sharing Value Set (SVS) standard quite well. In particular, thanks to Bob, we could use a SVS document to create the DXF metadata with a data elements for each
of the elements in the SVS file as well as a data set to wrap these things up.

1>> I think we need to have a way to synchronize the TS with DHIS2’s internal representation of categories and category options. If a value set is in only one of the two, it can be added to the other. If it’s in both, things are a little more dicey. For one thing, you can’t tell from the value the code set to which it belongs, because it can belong to more than one. I would hope the TS would support synonyms and a function like translate(original_source, original_code, target_source) : target_code.

The area of ambiguity here was to determine which reporting period should be used for the data set. I personally would like to see the separation of the “reporting period for
the dataset” from the “dataset” itself.

2>> I’m afraid the time dimension is fundamental for data warehousing.

Sorry for being unclear here. I didn’t intend to suggest that data shouldn’t be reported with a time element (See also my comments after your #7). Although the time dimension is fundamental for reporting, I get the impression that the reporting period is primarily to make the DHIS2 visualization tool easier to implement. As an alternative, if we were to allow a timestamp instead of period for dataset submission, then there are lots of standard techniques that can be used to fit and then extrapolate a value for a a given period on a set of timestamped data.

Another reason to have a clear seperation here is that It seems like the same data set should be able to be able to reported at different frequencies depending on the org unit.

I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.

3>> This is on the HMIS agenda.

Following on this issue of separation of the dataset from the reporting period…. DHIS2 seems to be built around the idea of “counts over a time period.” This is not particularly well suited to the likes of, iHRIS and the HWR, which present data more
as a measurement at a set time. I would like to see the ability for a system like iHRIS or the HWR (or perhaps even the SHR) to be able to report the values for a dataset at a set time rather than a period. I think it is a bit awkward to have the “measurement
device” (e.g. iHRIS) to know the particulars about the reporting periods that DHIS2 is configured for. In other words, as the data reported in iHRIS is time-based and not dependent on a reporting period, then there should be an expectation that iHRIS/HWR/SHR/etc.
report the period. They should just report a time stamp

4>> I think it has already been pointed out to DHIS2 that there is a need for aperiodic data, whose value as of a particular date is the last value before that date. This will also open up the use of non-numeric data types. The question of how this aggregates up is open.

Disaggregation of the values of data elements is a problem. For example if we have a data element for the # of health workers in cadre X (the data element) to be reported for a facility (the orgunit) we can do that just fine. But if we start wanting to
disaggregate (as we are often asked to do) by gender, or by gender and age bracket, then this quickly becomes unmanageable. Perhaps again, exploiting SVS to define the disaggregators (rather than trying to look them up in DHIS2 and interpret them in the
source system).

5>> We discussed this at the last HMIS call. We agreed that it was important to be able to pass data using disaggregation dimension values rather than category combo option codes.

The way hierarchies are exposed in the metadata export (as s with and elements) is quite cumbersome to work with. One often needs to know the facilities in DHSI2, which are at “level 4” for example. It is quite
computationally expensive (and unnatural) to calculate where in the level hierarchy an orgunit is in order to extract it. It seems that the was chosen out of convenience based on the underlying data structure of a relational database,
rather exploiting the hierarchical data structure inherent in XML. This is related to issue already brought up about supporting multiple hierarchies.

6>> I agree that the org unit XML is a little weird, but it shouldn’t be too expensive, you just have to do it once and cache it, we are talking about a lot less than 20,000 facilities. Also, I think you are asking for the wrong thing when you ask for “level;” the depth in the hierarchy can reflect administrative and organizational issues rather than parity of facilities. Facility attributes such as owner, type, service level, program participation, etc. are all just as important (you can even have level as a facility attribute if you want). It has already been pointed out that selection or aggregation by org unit group or org unit attribute value is not available in DHIS2.

Consider, as a concrete example, this DHIS2 metadata export from Zimbabwe. Here at level=1 we have the MoHCC, at level=2 are the provinces, at level=3 we have the districts and at level=4 and 5 we have facilities. There is nothing in the metadata export to indicate what the level of an org unit is except by processing the orgUnitRelationship. Also, there is nothing else besides the level to determine the org unit type. In particular the groups, facility types or other attributes are not set consistently in DHIS2 implementations.

In case you are interested, here is a xquery script to minimally represent the DHIS2 orgunit hierarchy in CSD:

https://github.com/his-interop/openinfoman-zim/blob/master/resources/DHIS_Meta_Data_To_CSD.xq

which uses the following xquery module:

https://github.com/openhie/openinfoman-dhis/blob/master/repo/dxf_1_0.xqm

It is the dxf:orgunit_get_level() call that is particularly expensive.

I have also done similar things with XSLT as a transform tool and with HPD as an intended output format, and the same issue remains.

The above were about the metadata in the DHIS2 DXF file as well the structure of the data being reported to DHIS2.

In terms of the API (Bob’s original question) noting that currently one can only push data to DHIS2, on my wish list is:

a way to register a “measurement device” with DHIS2 for a dataset. Then DHIS2 can then pull in the data based on the reporting period that DHIS2 is configured for

7>> One thing we hope to talk about more is workflows and whether the movement of data from a data source (data entry routine or aggregate calculation from an EMR or other transactional system) to the HMIS DW should be a push or a pull or either. But I don’t think you are going to be able to get around a start-date/end-date or as-of-date/period-type parameter.

Again, I think it is perfectly fine to report a time-component to a measurement, but I think it should be able to be up to the HMIS (rather than the reporting system itself) as to which reporting period something gets slotted into. In other words, it makes sense from iHRIS / HWR to say:

“I have 25 nurses in facility X on Jan 23, 2014”

It would then be the responsibility of DHIS2 to slot this into “Q12014” or “012014” as appropriate based on the DHIS2 configuration.

I think that a timestamp should be sufficient for submitting.

My 2cents.

Cheers,

-carl

On Jul 2, 2014, at 6:57 PM, greg.rowles@gmail.com wrote:

Dear Community

There are a variety of sub-communities represented in this group and I would like to share some thoughts. Perhaps it is my “over-obsessive need to categorise things” kicking in but from what I can tell we’re working with EMR, RHIS (Routine Health IS) and
mobile/mHealth that lie somewhere in between. I guess operational systems also have a place in our landscape (HR systems, etc, please feel free to correct me).

Based on my country’s implementation of HMIS we have our RHIS collecting aggregated data (through paper and electronic registers) aligned to our ‘work in progress’ data-dictionary that not only houses (master) indicator + data element definitions (in their
current iterations/versions) but is also used to manage our MFL, Master-Schools-List (a new initiative), WBOT (Ward Based Outreach Teams list), EHR (Environmental Health Services list), etc. In my mind each of these ‘orgunit lists’ service different populations
under the banner of ‘health’ and as such they each have unique (orgunit) attributes which could be moulded as special data sets, e.g. a [WBOT team member] has unique data elements such as name, staff code, shoe size, etc, while the [Facility] orgunit (which
is currently under pressure to be renamed to Service-Point) may require the usual address, contact number, gis coords, etc.

It is my opinion that orgunit-hierarchy structures (civic or spatial) and orgunit-classification systems (DHIS type/ownership/rural-urban) belong more to the data warehousing domain than to EHR. I say this based on the dimension modelling I’ve seen required
for health management reporting (i don’t know what dimensions are required from EHR data warehouse environments).

I agree with the need to ensure historic trails for changes to these two groups of data (especially as it may affect historic plans+resource allocations - financials in SA are partially determined by OUtype classification). What is especially important
to consider for any HMIS is population data and maybe this is something that OpenHIE should consider. Population data sets for regional/civic/spatial levels.

The (abbreviated) HMIS cycle involves:

planning indicators (for health system + program performance measurement)

planning data elements to be collected

rolling out, training + data collection (aligned to HIE components)

analysis + management reporting + intervention (resource re/allocation)

starting over / reassessing indicators

Best,

Greg

Sent from my HTC

----- Reply message -----

From: “Pierre Dane” pierre@jembi.org

To: open-hmis@googlegroups.com

Cc: r.friedman@mindspring.com, bobjolliffe@gmail.com, steesdale@instedd.org

Subject: hmis messages

Date: Wed, Jul 2, 2014 20:05

Hello Ryan, Bob, Roger et al,

I have just recently attended the DHIS2 academy in Rwanda, and will be attending another advanced academy in Oslo in August. Some very good point brought up in this thread. GHIS2 is indeed being widely used (in East Africa and beyond!) and many implementations
are making use of the web api. This has matured significantly even over the last few months and the Oslo team has made the entire DHIS2 core api based. Jembi has been using both the dataset api and the tracker api in a number of projects. I agree that the
tracker component is not of much interest to this community.

I have heard no talk from HISP Oslo about opening up standards based interfaces to the api - I would imagine that the REST api will be the only communication mechanism with DHIS2 for the near to middle term future. So to Ryan’s second point - I don’t think
it’s worth looking at (non-restful) standards based interfaces in SPECIFIC relation to DHIS2, which is not to say the investigation is not a valuable one. I’m not sure if there are any health standards that apply to this kind of aggregated data - does anyone
else out there have an idea? If there aren’t any maybe we should formalize the json payloads of the DHIS2 dataset api and use those as document standards.

As I’m new to this community I’m not exactly sure what the focus of the HMIS is (besides acting as a warehouse) - is it to provide data to other systems, or to provide a front end for consumption of reports and graphs, or both. DHIS2 can do both of these
but it’s main focus is on the latter - allowing rapid development of meaningful reports. I have not delved too deeply into the former, but I know that any data presented on the front end of DHIS2 can be accessed via the api, and can be returned in a variety
of formats (json, xml, csv, excel). When this comes to datasets containing tens of thousands of ‘raw aggregated data’ rows or more (rather than further aggregated pivoted data) I don’t think any kind of http interface is ideal in any case.

In terms of the facility registry - Roger’s points are all valid.There is one strict hierarchy, no historical data, and as far as I know no way to get facility data into datasets (but I’ll ask about this in August). But there is something called the FRED
API which is supposed to be a all about administering facility registries. This must be tightly coupled to the organisational unit hierarchy in DHIS2. I have not used it at all though. My feeling is that the FRED API might be used for updating DHIS from a
more specialized facility registry, if more specialized functionality is required. We are using DHIS2 as a FR for our MomConnect project at the moment - but it is a very simple use case, and tightly ciupled to the org unit hierarchy.

Thanks

On Wednesday, July 2, 2014 11:26:53 AM UTC+2, Ryan Crichton wrote:

Hi Bob,

While DHIS2 was not designed to operate in an HIE, we don’t need a full redesign to allow it to participate in an HIE. I’m sure adaptors could be implemented to connect DHIS to an HIE. There are really 3 things that I think we need to be thinking about
for HMIS community in my opinion:

Designing the workflows (and use cases) whereby data to sent / queried from an HMIS. What is needed in an HIE environment? How will other systems interact with a HMIS?

Specify the standards-based interfaces and user facing functionality that a general HMIS system would need to implement to enable the defined workflows. This is like looking at a HMIS as a black box and seeing what interfaces / functionality it exposes to the HIE.

Designing how the reference application (DHIS2) can map to / implement the identified interfaces and functionality.
We should start at number 1 and move to number 2 and 3 once we have an idea of what needs to be achieved. I think this will help to scope out exactly what DHIS will need to do to support a deployment within the OpenHIE architecture. I doubt will will need
to use the full functionality that DHIS provides but DHIS will likely be able to adapt the parts that are required of it within OpenHIE to communicate with other systems. I don’t think we would want to change the current functionality of DHIS where it would
impede its standalone deployment.

Cheers,

Ryan

On Tue, Jul 1, 2014 at 2:53 PM, r.fri...@mindspring.com
wrote:
Bob –
Thank you very much for this.  I don't think anyone would denigrate DHIS2 or the role it plays in global health.  I had always envisioned the HIE interface to DHIS2 to be an add-on in the same way that the REST API is an add-on.  On the other hand, I don't
think you would contend that DHIS2 is able to do everything a health facility, program or department needs in the way of data management and presentation. I think you would agree that the overall capacity of a health information architecture is improved by
deploying a HIE and that this requires a somewhat deconstructed look at DHIS2.
Looking at DHIS2 as a FR, I think it is missing some capabilities.  For example, I don't think there is any way of getting facility attributes into datasets, and i don't think they are available over the REST interface.  It allows only one hierarchy, typically
current civil divisions, thereby excluding organizational hierarchies, former civil divisions (for which historical data may exist but not at any more granular level), or catchment areas. It does not handle intermittently-updated data, such as facility contact
or water source, where the value of a variable at time x is the value at the last update before x. This is not to say that it is the duty of DHIS2 to handle all of these, just that it is the duty to DHIS2 to allow other software to access data in a manner
that supports other uses.
I think that we can all agree that the path from a descriptive indicator definition to a DHIS2 indicator to a DHIS2 data element to the TS variables involved in a SHR aggregation query is a perilous one, especially if the indicator is disaggregated.  It
would be nice to address this problem. At a minimum, it would be good to have DHIS2 indicators and data elements in the TS.
At the moment, I think the only message we have been asked to define is one by which the HMIS will receive indicator values from PoS system.  I think there is a fundamental question of whether, when acting as an HIE element, the HMIS should receive indicator
values from PoS or only from the the SHR, and whether it should be a push (data source telling HMIS what data it has) or a pull (HMIS telling data source what data elements it wants calculated). I don’t think there is anything that would prevent us from using
the REST API for now, although we might want to add other modalilties, such as FHIR-style REST API or Atom bundles. Do we want the IL to handle authentication and validation, for example by making sure that the data references only the facility associated
with the PoS? I think direct PoS/HMIS communications are ruled out by the architecture.
Talk to you soon.  Please make sure you send hangout info to
r.fri...@mindspring.com.

Saludos, Roger

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

From: Bob Jolliffe

To:
open...@googlegroups.com

Subject: hmis messages

In advance of our discussion this afternoon (morning for some) I want to offer some long overdue thoughts on definition of messages involving the hmis component of our openhie project.

These thoughts are necessarily rooted in our concrete living experience with the dhis2 software which is actively deployed in a growing number of countries as the national HMIS. This fact should provide a positive impetus on which to build and develop
integration solutions but is nevertheless complicated by a number of factors:

It was conceived as a self-contained system without outside dependencies on other computer systems and with an ability to adapt to different technological landscapes. So it has been deployed on standalone machines in health district offices with data
capture being done from paper reports being brought on foot, bike and motorized vehicles from health facilities through to deployment in national and international data centres with health workers interacting over the internet using a range of devices. As
we try to conceptualize its integration with other openhie components we need to be mindful of the this broad range of configurations. Whereas there is I believe a willingness to adapt in order to better fit in with the emerging openhie architectural vision
that will also be tempered by the need also to continue to serve its core constituency in the HMIS departments of ministries of health.

In order to fulfill its core functionality as an HMIS, and one which can and does function in the absence of other registry type systems, dhis2 has from the start encompassed the notion of an accurate register of health facilities within the health
system as well as a structural metadata repository of minimum datasets, dataelements and health indicators. It seems likely that it will retain and even enhance such functionality in the foreseeable future. So whereas it is a goal to be able to integrate
with external sources of such data where they exist, if this was an architectural dependency then dhis2 would be deployable in 1 or 2 countries rather than more than 30.

Despite its history as a district based system for capturing, processing and analyzing aggregate data from paper registers in health facilities it has grown in scope over time to meet other needs, most notably individual event based data. I think
there is some consensus that it is only the aggregate data aspect of dhis2 which is of immediate interest to this community.

All of the above can be sources of tension between sometimes competing architectural visions. It is important of course to be able to conceptualize and demarcate what is the hmis functionality required in openhie in more abstract, idealized terms, but
equally to understand that short of abandoning the dhis2 project and building perhaps dhis3 from the ground up, the current objective reality suggests that we will gain most advantage by also working with what is there. Of course these approaches are not mutually
exclusive - I think we can address the immediate challenges and opportunities whilst at the same time have an eye on the future.

Anyway, after such a long winded prologue let me get to the point. My suggestion as a starting point for looking at messages is to invite people to study and critique the api as it exists in dhis2 today and is (fairly well) documented at

https://www.dhis2.org/doc/snapshot/en/user/html/ch31.html. The most immediately relevant section for this group relates to the posting of aggregate datavalues which is described in https://www.dhis2.org/doc/snapshot/en/user/html/ch31s09.html.

The datavalueset is the most immediately useful message type for posting aggregate data into dhis2. It is loosely inspired by ideas from the SDMX-HD cross-sectional dataset. If people think it is useful I can run through a brief presentation of the salient
features on this or a subsequent call.

Other messages are defined to retrieve the supporting structural metadata codes for dataelements, disaggregation, facilities etc. Again I suggest a starting point is to look at what is there and critique it. The representation of disaggregation is I
believe a particular difficulty in dhis2 currently, but the current scheme of is quite deeply embedded in the data model. Again I think it would benefit from a thorough external critique. But for the immediate term it works the way it works and has proved
useful in a variety of existing contexts. I have ideas on how it could be improved (again informed to some extent by experience with sdmx) but input from potential users in the openhie community would be invaluable.

Regards

Bob

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

open-hmis+...@googlegroups.com.

For more options, visit
https://groups.google.com/d/optout.

–
Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH
AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail:
ry...@jembi.org

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Open HMIS” group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.