Development

Mobile health initiatives and free software

Healthcare is a popular subject in the open source software community today—as it is in the proprietary software world—with a number of high-profile projects tackling problems like electronic health records (EHR) and hospital management. But, as Neetu Jain explained in her talk at Texas Linux Fest 2013 in Austin, thus far open source developers are not addressing the needs of the most at-risk patients in developing countries. She highlighted several successful but closed-source projects already deployed in Africa and India, which have taken off because they center around mobile phones rather than desktop systems, and she encouraged more open source developers to get involved.

Mobile healthcare (or "mHealth") can encompass a range of different subjects, from measurement, to diagnostics, to patient treatment, to large-scale global initiatives. Measurement includes sensor-based patient monitoring and personal (that is, non-automated) monitoring that is often focused on data-mining or research. Diagnostics is focused on tools for doctors and other healthcare providers, such as point-of-care decision-making or portable imaging devices. Treatment projects include everything from personal calorie counting to clinical trial management. The global initiatives include an array of large-scale efforts, from information dissemination to disease surveillance to data collection.

First-world and third-world challenges

But within the rather large scope of mHealth, there is a big disconnect between mHealth services in the developed countries and those in the developing world. For starters, developed countries focus on different healthcare topics: personal fitness, chronic disease management, and aging, for example. Initiatives in developing countries focus on basic healthcare service access, prenatal and childhood health, and infectious disease control. Both have their place, of course; she highlighted several mHealth projects that assist the elderly, such as "smart" medicine bottles that sync with a mobile phone to help the patient remember to take medication.

There are also technical differences. Most mHealth projects in developed countries are built on smartphone platforms and are tied to always-on, ubiquitous Internet access. Both are rarely found in poor and developing countries. Nevertheless, "dummy phones" with cellular network access are widespread, she said, citing a United Nations report that there are now more people with access to cell phones than people with access to toothbrushes or to clean toilets. No matter how poor people are, Jain said, they recognize the value of mobile phone communications, although in many cases entire families or even multiple families share a single device. mHealth projects have taken advantage of this situation largely by building software systems that rely on SMS text-messaging as the communication medium, which is a system exploited only rarely in developed countries whose smartphone and tablet users prefer apps using data connections and WiFi.

The other major difference that distinguishes mHealth in developed and developing countries is that the majority of mHealth initiatives in developing countries receive no corporate backing. That is a stark contrast with the investment support that surrounds the startup culture in many developed nations, and it makes mHealth projects in developing countries a good opportunity for open-source projects. Yet there are relatively few open source developers volunteering, perhaps in part because so many open source developers live in developed regions like Europe and North America.

Success stories

Jain then discussed a series of successful mHealth initiatives deployed in developing countries. HealthLine is an interactive "help line" that connects callers to a call center staffed by physicians. mDhil is healthcare information service in India that sends out broadcast messages over SMS. Sproxil is an anti-counterfeiting system deployed in Nigeria, with which patients can verify the authenticity of medication by texting a code number from the bottle. TextToChange is a program used in Uganda that tracks patient satisfaction after treatment. Changamka is a project that helps poor people in Kenya save money for healthcare expenses by making small deposits through a mobile phone. Project Masiluleke is a service that uses South Africa's free "public service" SMS system to distribute information about HIV and tuberculosis, connecting users with counselors and clinics.

There are many more examples, but Jain went on to describe the two projects with which she volunteers. The first is Raxa, an open source health information system (HIS) that has been deployed in India for two or three years. Raxa consists of several related components, such as an EHR system, patient tracking, and in-the-field doctor support tools. Raxa is based on the open source OpenMRS platform, which is used in a variety of other EHR projects as well. But Raxa is different in that it focuses on building mobile client software in HTML5, rather than desktop applications.

The second project Jain is involved with is Walimu, a nonprofit organization working with the largest hospital in Uganda. In the past the organization built and deployed a low-cost severe-illness diagnostic kit for doctors, but it is currently working on building a clinical decision support system. The software project is currently in the nascent stage, Jain said, so more help is welcome.

Jain also suggested that interested developers visit the "get involved" section of the mHealth Alliance web site, which helps people find projects and initiatives that they can contribute to.

There are a lot of challenges facing any mHealth initiative in the developing world, Jain said, but open source developers are capable of helping on a number of fronts. The funding problem means that volunteers are needed to work on development and on administering system infrastructure. There are also cultural challenges, such as the fact that an SMS-based application in India needs to support more than 400 languages. Most mHealth initiatives face other cultural issues (such as the complexity introduced by large groups of people sharing one phone) that do not have development solutions, and they face regulatory challenges, but more volunteers can help ease the burden.

The Q&A session after the talk was lively; one member of the audience asked a question that revealed yet another complexity in mHealth development. Asked why so many of the initiatives discussed were deployed in just a single region, Jain responded that the two biggest developing-nation regions are sub-Saharan Africa and the Indian subcontinent, but that the same project rarely succeeds in both places. The two are similar in one respect—the constraints on resources—but in practice the linguistic, cultural, and regulatory differences between them mean that a solution usually needs to be re-implemented to work in both regions.

mHealth projects in the developing world, like most humanitarian software projects, are relatively easy to "sell" as a Good Thing. But that fact, naturally, does not make the technical hurdles (nor the regulatory or administrative ones) go away. Fortunately, interested developers have already seen the value of utilizing SMS messaging to work around the connectivity problem in developing countries; hopefully the community will continue to find practical solutions to such unique problems.

Comments (none posted)

Brief items

Quotes of the week

— Tom Hacohen (hat tip to Olav Vitters)

— Michael Stahl, on a not-insignificant commit to LibreOffice. (hat tip to Cesar Eduardo Barros)

Comments (none posted)

GCC 4.8.1 released

The GCC 4.8.1 release is out. It is primarily a bug-fix release, but it is not limited to that: "Support for C++11 ref-qualifiers has been added to GCC 4.8.1, making G++ the first C++ compiler to implement all the major language features of the C++11 standard."

Full Story (comments: 39)

PulseAudio 4.0 released

Version 4.0 of the PulseAudio audio server is out. Changes include better low-latency request handling, improved JACK integration, a new role-based audio "ducking" module, various performance improvements, and more; see the release notes for details.

Full Story (comments: 28)

PyTables 3.0 released

Version 3.0 of the PyTables package for wrangling large datasets has been released. This version is the first to support Python 3, and as the announcement notes, almost all of the core numeric/scientific packages for Python already support Python 3 and thus are immediately usable. Other changes include support for in-memory image files, basic HDF5 drivers, and the extended precision floating point data types Float96, Float128, Complex192 and Complex256.

Full Story (comments: none)

Buildroot 2013.05 available

Version 2013.05 of the Buildroot tool for creating embedded Linux systems has been released. The release notes indicate there are 84 new packages, as well as support for multiple OpenGL providers. The default compiler has changed to GCC 4.7, a new external Microblaze toolchain has been added, and there are both new CPU architectures supported and a few old architectures dropped.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the past week

• Caml Weekly News (June 4)
• What's cooking in git.git (May 29)
• What's cooking in git.git (June 2)
• What's cooking in git.git (June 4)
• Haskell Weekly News (May 30)
• OpenStack Community Weekly Newsletter (May 31)
• Perl Weekly (June 3)
• PostgreSQL Weekly News (June 2)

Comments (1 posted)

Processing goes 2.0 with an OpenGL core (The H)

The H looks at the Processing 2.0 release. "The new version of the language, which has been in development since mid-2011, brings OpenGL rendering to the core of the platform, replacing the older software-based P2D and P3D renderers with new OpenGL-accelerated P2D and P3D renderers. A new OpenGL library, based on work done on the Android version of Processing, has also been incorporated and OpenGL is now part of the core of Processing." For some background on Processing, see this LWN article from last October.

Comments (none posted)

O'Callahan: Blink, PNaCl, And Standards

At his personal blog, Mozilla's Robert O'Callahan offers some criticism of Google's Portable Native Client (PNaCl) project, which it was recently announced would be enabled in Google's "Blink" rendering engine. At issue is that PNaCl support seems to go against Google's pledge that Blink would stick to supporting open standards. "PNaCl and Pepper are not open standards, and there are not even any proposals on the table to standardize them in any forum. They have documentation, but for the details one must defer to the large bundle of Chrome code that implements them. Other vendors wishing to support PNaCl or Pepper would have to adopt or reverse-engineer this code."

Comments (none posted)

Lohn: A Call for Source Code CSS

At his blog, K Lars Lohn argues for a stylesheet-like approach to source code formatting, which can be restyled to adhere to any of several coding styles, rather than the rigid-format approach of today. Lohn's discussion stems from Python style (the PEP8 style guide in particular), but he seems to have broader applicability in mind. "I want to be able to load that method into my editor and see it styled in the manner that works for me. If someone else wants to see it in the PEP 8 style, that ought to be an option on the editor. Our source code should express functionality and functionality alone. Like the relationship between HTML and CSS, source code style should be left to some presentation layer."

Comments (4 posted)

Page editor: Nathan Willis
Next page: Announcements>>