Too Many to One - Implementing mHealth

For about a year and a half now, I’ve been volunteering with Global HEED—a non-profit organization focused on supporting health, education, and economic development globally. Global HEED was started in 2008 by founders Sonny Bandyopadhyay and Zain Ahmed while both pursuing their degrees at the University of Emory. Over the course of 5 years, Global HEED has made a tremendous impact in communities around the world, most notably, in a small village in Guatemala called Calhuitz. Medical students enroll to become a summer fellow wherein they will be responsible for any of the following: developing & teaching public health topics, assessing the communities needs, shadowing/assisting a doctor or nurse, etc. Some of the projects in the past involved building a pharmacy, a community health worker training center, and even first community health clinic in Calhuitz. The newest project within Global HEED is the mHealth initiative—a telemedicine project whose goal is to improve the quality of healthcare in under-served communities. Specifically, we’re collaborating with Partners for Care, an NGO based in Kenya, to implement mHealth in the slums of Nairobi by utilizing Sana Mobile.

Problem

The underlying problem is this: there are too many people in need of healthcare but there aren’t enough physicians that can support that need. As a result, not everyone gets treated; in addition, taking into account waiting and travel time, visiting a clinic or hospital can be very time consuming. In some instances, patients have to travel ~10 km by foot to pay a visit to the nearest clinic. It’s a very brutal experience as you might imagine.

Proposed Solution

To alleviate this, we implemented Sana as essentially a triaging tool to improve  the delivery and efficiency of healthcare. It works as follows: a community health worker visits a patient and enters the necessary information through the mobile device (patient information, symptoms, photos, etc.), the information is then sent to an electronic medical record system, OpenMRS, wherein a remote doctor can send a diagnosis back to the community health worker who would then perform the necessary action (more on this here). Although the entire process seems simple, there’s still a couple of BIG obstacles to go through before we can comfortably expand into other regions. To name a few, we need to verify uploading information to the EMR works 99% of the time, that patient data is consistent with what’s recorded, that the community generally accepts the technology, that the project can be evaluated in a metric and quantifiable way… thinking about all this is giving me a headache.

Conclusion

Despite all these obstacles, seeing the passion within the organization itself, that is Global HEED, gives me the confidence that these “minor” obstacles can be eventually surpassed. For instance, even though members of Global HEED are from all over the nation—Atlanta, San Francisco, and New York City to name a few—we somehow still manage to consistently collaborate and work towards the same goal thanks to the very passionate leaders within the organization. Not to mention, our use of technology for communication, which enables us to connect, should be a testament to the potential of technology for improving the lives of those around us; not just for those a few houses away, but also for those on the opposite side of the globe.

We who work in technology have nurtured an especially rare gift: the opportunity to effect change at an unprecedented scale and rate. Technology, community, and capitalism combine to make Silicon Valley the potential epicenter of vast positive change. We can tackle the world’s biggest problems and take on bold missions like fixing education, re-imagining energy distribution, connecting people, or even democratizing democracy. And with increasingly severe threats to our survival — rapid climate change, an unstable international economy, and unsustainable energy consumption — it is more important than ever that we use these gifts to change the world, foster happiness and alleviate suffering, for us and our fellow beings. by Justin Rosentein

##### If you’re a developer and would like to contribute to the project, please feel free to reach out! You can also just jump and start pushing code into the Sana source code repository, it’s open source.

Incremental Goals

Check my post on the JOCC blog about setting Incremental Goals.

Optimizing Android Layouts

I recently used the hierarchyviewer & lint tool in the Android SDK and was pretty surprised with the results I saw. Many of the views I had were heavily nested and some views did not necessarily have to be inflated off the bat (progress indicators and refresh icons to name a few). As a result, my activity took a performance hit because of a badly designed layout. Here’s a technique I used that I picked up at AnDevCon III to flatten my layouts and in general make them more performant.

ViewStub

Essentially, ViewStub is a lightweight and cheap to inflate widget that you can include in a layout. Its purpose is basically to serve as a stub or placeholder for views that don’t necessarily need to be inflated on creation. For example, let’s say your app displays notifications on a SlidingDrawer; however, when there are no notifications, that SlidingDrawer should be hidden. What you can do then is create a ViewStub that points to your SlidingDrawer layout implementation and when notifications are present, you can simply inflate the ViewStub. Here’s an example taken from Android Developers that displays the flattening of the view hierarchy using ViewStubs. Layout without ViewStub: [caption id=”attachment_341” align=”aligncenter” width=”510”] Layout Without ViewStub[/caption] Layout using ViewStub: [caption id=”attachment_342” align=”aligncenter” width=”468”] Layout With ViewStub[/caption] The code for your layout:

<ViewStub
android:id="@+id/stub_slidingdrawer"
android:layout="@layout/slidingdrawer"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
/>

The code to inflate the ViewStub:

ViewStub stub = (ViewStub) findViewById(R.id.stub_slidingdrawer); View v = stub.inflate(); 

For my specific case, it took about half the time to inflate the entire layout tree by using a ViewStub for infrequently used child layouts. Pretty sweet.