hmis messages

Legacy open-hmis
1

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.

2

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. 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. I would also like to see a standardization on how we report simple metadata (for example, through SVS) between systems.
  • 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
  • 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).
  • 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.

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

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.