hmis messages

Hi Bob, I guess about now you are beginning to regret cancelling the call, instead you have to reply to all this e-mail.

I think there’s a real need for “survey” and “event” data in DHIS2; I believe I first expressed it several years ago vis-a-vis Ghana. It certainly affects the ability of DHIS2 to store facility data. While I think Carl undervalues the importance of periodicity to DHIS2 for interpolation, and the importance of interpolation for indicators with population in the denominator when population is determined infrequently, I think you are conceding that users of DHIS2 have requested the ability to enter this kind of data and perhaps even that those requests are consistent with the Swiss Army knife view of DHIS2. So, like the category combo option bypass we discussed in the last call, perhaps this is something that you need to take to the HISP roadmap with strong support.

With respect to Ryan’s points about messaging, I think your response is “we have DXF and REST, what more do you want?” And I think the point is (1) we are looking to implement messaging standards to the extent they exist; and (2) we are looking to implement a logical messaging model that is independent of any product’s physical data model so that a Tracnet- or PROMIS- or Pentaho-based product can implement the interface and plug-and-play in OpenHIE. I expect that based on your experience with SDMX-HD your response is “gag me with a spoon.” And I think the time that took would be prohibitive for OpenHIE. But surely we could take at least concepts about dimensional data, metadata about provenance, codesets, etc. from SDMX and put that into a logical messaging model which could be addressed by a REST interface or defined messages to the SHR or TS; each of the objects should be close enough to existing DHIS2 structures that the effort could build on the code for existing REST interface. Maybe the interface Phillipe Boucher is using for the WHO Global Health Observatory would work.

And I still would like to link (perhaps via the TS) to an indicator registry with the ultimate goal of machine-interpretable definitions.

Saludos, Roger

···

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:

  1. 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?
  2. 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.
  3. 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:

  1. 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.
  1. 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.
  1. 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
.

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.

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.

Hi Roger. Absolutely regretting starting these discussions in one sense, but the flood of feedback indicates they they are necessary to have. I am going missing for the next 10 days or so, so looking forward to other folk also contributing.

Sorry Ryan my response was overly brief but I am pushed for time right now. Roger my response was not quite “we have DXF and REST, what more do you want?” though I can see how it might be interpreted that way. It was more that there needs to be a more nuanced interaction between what is there and what could or should be there.

There are some limitations of the GHO work which I think are shared with SDMX - without going into detail it comes down to the fact that it is more suited for the publication of indicators than for the input of routine data. ie it is much better suited for input than output.

As I say I have to concentrate on something else for the next few days and am on leave the following week. Will pick up the baton when I get back :slight_smile:

···

On 10 July 2014 12:41, r.friedman@mindspring.com wrote:

Hi Bob, I guess about now you are beginning to regret cancelling the call, instead you have to reply to all this e-mail.

I think there’s a real need for “survey” and “event” data in DHIS2; I believe I first expressed it several years ago vis-a-vis Ghana. It certainly affects the ability of DHIS2 to store facility data. While I think Carl undervalues the importance of periodicity to DHIS2 for interpolation, and the importance of interpolation for indicators with population in the denominator when population is determined infrequently, I think you are conceding that users of DHIS2 have requested the ability to enter this kind of data and perhaps even that those requests are consistent with the Swiss Army knife view of DHIS2. So, like the category combo option bypass we discussed in the last call, perhaps this is something that you need to take to the HISP roadmap with strong support.

With respect to Ryan’s points about messaging, I think your response is “we have DXF and REST, what more do you want?” And I think the point is (1) we are looking to implement messaging standards to the extent they exist; and (2) we are looking to implement a logical messaging model that is independent of any product’s physical data model so that a Tracnet- or PROMIS- or Pentaho-based product can implement the interface and plug-and-play in OpenHIE. I expect that based on your experience with SDMX-HD your response is “gag me with a spoon.” And I think the time that took would be prohibitive for OpenHIE. But surely we could take at least concepts about dimensional data, metadata about provenance, codesets, etc. from SDMX and put that into a logical messaging model which could be addressed by a REST interface or defined messages to the SHR or TS; each of the objects should be close enough to existing DHIS2 structures that the effort could build on the code for existing REST interface. Maybe the interface Phillipe Boucher is using for the WHO Global Health Observatory would work.

And I still would like to link (perhaps via the TS) to an indicator registry with the ultimate goal of machine-interpretable definitions.

Saludos, Roger

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

From: Bob Jolliffe

Sent: Jul 10, 2014 5:32 AM

To: Carl Leitner

Cc: Roger Friedman , “greg.rowles@gmail.com” , Pierre Dane , “open-hmis@googlegroups.com” , Scott Teesdale

Subject: Re: hmis messages

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:

  1. 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?
  2. 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.
  3. 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:

  1. 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.
  1. 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.
  1. 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
.

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.

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.