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.friedman@mindspring.com.
Saludos, Roger
···
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.
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.
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.friedman@mindspring.com.
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.
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.
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.
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.
I think there will be something more of a cyclic relationship between 2 and 3 than a simple ordering if we are to be pragmatic.
Cheers
Bob
···
On 2 July 2014 10:26, Ryan Crichton ryan@jembi.org 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.
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.friedman@mindspring.com.
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.