[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Health] Ebola, MERS, Zika, N.N. and GNU Health

From: Christoph H. Larsen
Subject: [Health] Ebola, MERS, Zika, N.N. and GNU Health
Date: Tue, 2 Feb 2016 12:45:25 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Dear All,

Apologies for cross-posting, but unusual circumstances demand unusual actions.

The ongoing outbreak of the Zika virus has been declared an emergency by WHO, and this certainly highlights yet another time the importance given to disease surveillance as an integral part to health information gathering, processing, reporting and related decision-making.

To date, we have a number of hospital health information systems, GNU Health, of course, included, that do their job with various strengths and weaknesses. GNU Health boasts the existing integration with Tryton as ERP system, which is simply great. Plus, is integrated with an evolving LIMS, which is of exponentially increasing importance, because surveillance is nothing without laboratory confirmation.

There is DHIS2 ( as USAID-funded and endorsed data warehouse for health data aggregation, analysis and presentation at the national level, with aim to further informed, evidence-based decision-making. DHIS2 has come a long way, but it is still pretty clunky, well, IMHO. Modifications may not always be easy to implement, depending on the running version.

Back to GNU Health: Given Tryton's scrupulously clean, lean and mean data models and structure, there is no reason, why a further push towards business intelligence (a.k.a. data aggregation, analysis and presentation, with data mining thrown in) should not be possible. This could be achieved as a Tryton or GNU Health module, or via linking to external facilities. Solr uses Java, Lucene has been ported to Python... As long as this heavy stuff runs at the central level (Ministry of Health), this does not matter *that* much, and even less, if feedback of the aggregate data and analysis can be done via lightweight communication channels back to the field. But it would, of course, be nice to keep things in the lean and mean Python family :-D.

Data capture is an issue: GNU Health is not offline-capable, as of now (correct me, oif I got that wrong!). And its suitability for mobile phone or tablet use is limited, because the interface has mainly been geared towards non-mobile technology. I know, there is an app, but I have seen better user experiences. Ideally, there is no app at all, all based on offline-capable HTML5, and running in a modern browser. (doing all this) might help doing exactly that, and could feed into GNU Health as backend, but its question types are a bit limited. We need the range of questions present in LimeSurvey (, which works actually very well in a self-contained Android stack consisting of PHP, Nginx and SQLite, with exports to a central facility via .csv or .xml, or to STATA or R. But with HTML5 e might be able to make this a bit easier. Open Data Kit tries to do this by simple .xml exports, but fails miserably on robustness, scalability data security and user-friendliness, and is poorly maintained. Plus with one toe in the proprietary world...

As for GNU Health, yes, there is a need for body system-specific modules, such as an ophthalmic or dental module. Also, diagnostics-specific modules might help, such as a facility that can display the peak expiratory flow rates in asthma patients over time.

However, I *personally* have my doubts about disease-specific modules, which includes the NTD and MDG modules. Recent history has shown that emerging diseases move way too fast to keep up. Donor-inspired vertical disease-specific interventions (HIV, malaria, TB) have not really strengthened primary health care, because they were contained in a silo, and GNU Health would do well not replicate this model.

Instead, Tryton's inventory and stock management suite offers already a model for a highly flexible alternative: The attributes model offers a unique way to capture any specifications of a stock item via a user-configurable interface. Something similar could be designed for disease-specific surveillance, starting from WHO's integrated disease surveillance catalogue to ongoing worries (EVD to newly emerging diseases, such as Zika and others to come.

This would allow the creation of a capable, flexible, yet standards-compliant surveillance and disease recording facility within hours, offline-capable, using HTML5 technologies, or a self-contained stack, and bring GNU Health to the community health workers anywhere in the world. Of course, contact tracing capabilities will be essential.

Throw in a central unique identifier database (with doing the unique identifier being a major legal as logistic hurdle!). and we can push and pull medical records across all connected health facilities with considerable ease.

I am fully aware that a lot of the above may sound a bit like a dream, but if we put the right tools together, collaborate and keep focused, it can be done.

There have been a few recent and very laudable efforts to effect surveillance in one way or the other within the group, and I think this is something which deserves applause and further support.\

Did I mention that there is a lot of money out there for surveillance? With CDC's new Global Health Security Agenda (GHSA), where are very keen targets set, yet the tools are sorely lacking. National governments are literally creaming for easy to use, ready-to-deploy solutions.

What's your take? From the field end, it's very high time, kind of three to twelve, to quote a recent assessment of the World's situation.

Thanks a lot for your critique, comments and ideas, and stay well!


Dr Christoph H. Larsen
296/33 Lương Định Của, Ngọc Hội 2, Vĩnh Ngọc
Nha Trang, Khanh Hoa, Vietnam
Mobile: +84-98-9607357 (Vietnam)
        +254-770-632403 (Kenya)
        +256-790-527900 (Uganda)
        +49-176-96456254 (Germany)
Fax:    +49-231-292734790
E-mail: address@hidden
Skype:  christoph.larsen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]