Thanks for responding with your insights and suggestions. And all the other threads of discussion which have started within this thread. I don’t have much time to respond right now to yours and others but I will get to it …
But just a quick thought on the question of HMIS scope and reference to other similar applications. Its really been quite a topic of discussion within the HISP community over the past few months. We live with an interesting contradiction that there are other systems which do some of what dhis2 does - things like pentaho for data analysis come to mind for example. But what has made dhis2 successful is that it bundles all of this functionality together in a way that other systems haven’t done. Jim I think has described this as the boom-box approach (presumably as distinct to componentized hi-fi). And it seems that boom-boxes turn out to be really useful. There is an architect within me which finds the boom-box unstaisfying - contradicting much of what I know and value about open systems, heterogenous architecture etc. And certainly we see it creak in some contexts, for example scaling in the larger Indian states. But in the current era it seems to meet a great deal of real need in the real world.
Personally I would also like to see greater disintegration of dhis2 functional components, but I see this as a process which will happen over (potentially a long) time. I think engagement in the openhie process and exposure to critique will contribute to that.
In the short-time there are concrete problem we can solve regarding exchange of routine aggregate data, particularly from the SHR to the HMIS but also from the HWR, which seems to be reasonably well understood. I’m really pleased to see momentum is gathering again on this in Rwanda.
···
On 8 July 2014 19:00, Paul Biondich pbiondic@regenstrief.org wrote:
Great note, Bob… thanks for taking the time to write notes.
I want to add some comments below, but it’s specifically to you as a thought leader of the DHIS2 community:
–
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 Tue, Jul 1, 2014 at 7:32 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
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.
Part of the challenge I see is that DHIS2 is a lot of things to a lot of people.
In some environments, it serves as a tool at the point of care to collect aggregate-level data around service delivery.
In some environments, it serves as a tool at the MOH to aggregate, and report visually results around these aggregate statistics (I think of this as HMIS).
In some environments, it serves as a tool to collect simple, patient level data for clinical settings.
In some environments, it serves as a source of authoritative information around facility metadata.
Some environments have multiple uses as above.
But people in the world refer to all of that as DHIS2. That makes it very difficult for all to understand the nuances of configuration alluded to above.
Have you all ever given any thought to distinguishing these different kinds of functional components, and label them appropriately? For example, DHIS2-Collect, DHIS2-HMIS, etc etc?
- 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.
That makes complete sense. There’s no way, in it’s role as a rock-solid HMIS, that it could work without an accurate facility list. Where it gets tricky of course is in the additional descriptive information around facilities that has utility outside of the purview of HMIS.
- 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.
OpenHIE as a meta-community is concerned with all health information flows, whether they are aggregate in nature, or individual in nature. There are many point of care systems that are working to integrate with OpenHIE. Why couldn’t the component of DHIS2 responsible for collecting patient-level information be a player in a HIE? I would hope it would! But that’s perhaps a conversation for a different mailing list. 
As it relates to HMIS (again, I think you all need to explicitly define the boundaries of what HMIS means), I think you all additionally have an important role to describe how POC systems who might want to send aggregate-level data should do so in standard ways. As such, thinking about POC systems in this role within this community seems fundamental, but that’s just my $0.02.
All of the above can be sources of tension between sometimes competing architectural visions.
Is it “competition” or is it simply natural evolution? I could be wrong, but I’d be surprised to hear that the HISP team knew upfront what DHIS2 would become back when it started, or that it had a strategic vision upfront for DHIS2 to do all of the things that it currently does.
I think OpenHIE is simply trying to rationalize information system behaviors/needs into components, and think about the ways in which those components communicate with each other. If in the process of doing so, a country decides to build all of that with a single technology stack, then that is their choice. I would only add that I think we all have a responsibility as external supporters to help countries understand the pros and cons of any given approach to implementing an architecture, so OpenHIE will take that on as well, in a broad-based community approach.
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.
Makes total sense.
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.
It’s a very important starting point, without question. To not use it as a foundational part of the dialogue would be really weird.
My question to you is: are there any other reference points that should be considered? For example, what about something like PROMIS? What about more traditional data warehouses?
Some of that of course depends on what “HMIS” means to you all.
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.
I like how you’re approaching this, Bob. My only (slight) concern is that if you only have one example to conceptualize against, you run the risk of tunnel/narrow vision. I know you well enough though Bob, to know that you work hard to prevent that sort of thing in yourself. I just wonder if looking at one or two other contemporaries (if they exist) might add to the necessary debate.
-Paul
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.