From: Ann Hendrix-Jenkins
Sent: Wednesday, May 05, 2010 1:27 PM
To:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Subject: mHealth ideas for your comments
Dear mHealth group,
Adam Slote has drafted two simple, helpful documents designed to guide health program planners in integrating mhealth into their plans. He would appreciate your comments and suggestions. One is a brainstorming tool, and one is checklist of questions that can help program designers. See attached!
Thanks Adam for your initiative here. Whatever we can do to facilitate better health programming through mHealth!
Attached to original email:
From: David Aylward, Executive Director, mHealth Alliance, UN Foundation
Nice work, Adam!
Let me suggest an additional thought. All of this seems to be geared to single interventions. Almost by definition, those are not scalable. Costs that otherwise could be shared across a multiplicity of uses have to all be supported by the one intervention. And the synergistic value of information sharing across applications is lost. I hope we can turn away from encouraging the proliferation of single purpose solutions.
So I would ask at a minimum: “Does it fit in a continuum of care? Can it share systems with other interventions? What would be the best collection of applications including this one? Can it share information with them?”
As we develop global enterprise architecture, we will be able to be more explicit, asking whether a solution fits in the open architecture and communicates using defined standards.
From: James BonTempo, Learning Technology Advisor, Jhpiego
I think this is a great set of tools – thanks, Adam!
I only have possible addition. How about also looking at how critical steps that might not have major constraints could be improved or strengthened through the application of mobile technology? The critical bottlenecks & challenges are the obvious places to start, but improvements can potentially be realized across all steps in the process. Does that make sense?
From a recent blog post of mine, “The problem may be that we don’t even realize that there is a problem” @ http://linearityofexpectation.blogspot.com/2010/04/problem-may-be-that-we-dont-even.html, and for additional clarity:
“In the end, my point is that the problems to which ICT can be a solution do not have to be those obvious things which are clearly barriers to getting work done. The problems may simply be the way we've always gone about doing things. And if we don't even allow ourselves to think about how we might improve upon our work, if we're not willing to challenge our established beliefs and ‘slay the sacred cow,’ we may be missing out on major opportunities. The problem may be that we don't even realize that there is a problem.”
|
From: Slote, Adam (GH/SPBO/SPB) Definitely agree that we need to look for synergy and scalability. Once we repeat the brainstorming process with a few different health interventions, we will start to notice that certain types of mobile solutions are showing up again and again. For instance, making a phone call to a CHW is useful not only for a child with pneumonia, but also a child with malaria, a newborn with sepsis, a mother in labor, etc. As far as I can see, none of the mobile solutions I brainstormed are limited to pneumonia, or are single purpose. I didn’t even start to get at the technology piece, which I think is where you’re going. For instance, SMS reminders could come in all flavors: FrontlineSMS, RapidSMS, CommCare, Voxiva, TextToChange, Babycenter, etc., etc., etc. That’s where it’s important to stop and take a look around at what is already being implemented in a country (one of the bullets in my checklist). But until we identify the bottlenecks for each of our health interventions, how will we be able to prioritize? How will we know where to start or where to make the biggest investments? That’s my biggest complaint about the mHealth state of the art at the moment: it’s completely ad hoc, non-strategic and not directed towards scaling up our critical HEALTH interventions. Mobile phones are only a tool for implementing our health interventions. They won’t save lives by themselves. They will only save lives if they increase the availability, quality and utilization of evidence-based HEALTH interventions. (Apologies for the capitals, but I’m passionate about this). But I know I’m preaching to the choir. I just feel that we need a systematic methodology for quickly selecting the most promising mHealth uses. From: James BonTempo If in moving from paper to phone you realize significant time & cost savings is that "meaningful," Does the integration of technology have to improve the quality of services directly or are the other ways to benefit? From: Lubinski, David, Sr. Advisor Health Mgmnt Info. Systems at PATH Agree this is really useful guidance, I also agree with my colleague David. |
From: James BonTempo
Are there opportunities for others to get involved in this “enterprise architecture” work?
From: Lubinski, David
Indeed – there is a growing enterprise architecture community emerging, mostly around a specific projects. There is an active effort to create a virtual community for the sharing and convening of people interested in this work. This will go a long way to bring visibility to the many efforts and ways we can collaborate as a community.
From: James BonTempo
I think there may be two things being conflated here: the use of a tool & the use of technology.
If folks aren’t using a paper-based birth plan form (or any other type of form) to make decisions, that’s one type of problem – i.e. they’re not using data for decision-making. And moving that tool to a mobile device or any other ICT may not change that behavior (though it’s possible the novelty of the technology might inspire use, at least initially).
As for the use of technology, in another recent blog post of mine, “Defining the limits of ICT, designing appropriate decisions” @ http://linearityofexpectation.blogspot.com/2010/04/defining-limits-of-ict-designing.html, I wrote about how critical it is to understand the specific capabilities of the technology. If the affordances of the technology are not aligned with the challenges they’re meant to solve – i.e. if the programmatic issues are not ones of information &/or communication but rather, say, ones of individual behavior and motivation – then the technology is not going to solve anything.
Does that make sense?
From: David Aylward
Indeed, and the “virtual community” to which David is referring is one of the functions of the Public Square initiative the Health Metrics Network of WHO, our Alliance, Rockefeller and others are developing.
From: David V. Isaak, Mobile Technology Consultant, SixBlue Data
I agree fully with "systematic methodology" as the approach since there are a multitude of players (e.g. solution providers, MOH's, etc.). It is vital that the approach is combined with field level viability for all stakeholders with a focus on the beneficiaries and CHW's.
Pilots are excellent proof-of-concept instances to demonstrate scalability.
From: David Aylward
I agree with Adam’s concern about ad hockery. I also think focusing on mHealth is the wrong place to start.
I suggest we start the way business does: with comprehensive requirements planning, for an integrated, interoperable system. This calls for an iterative process whereby health subject matter experts conceive of a world where all the information one might want at any given point in a care continuum is available in the form and factor desired. Usually this requires help from ICT experts, because practitioners often have trouble making that leap. PATH is just completing exactly this requirements process for supply chain, using a global template, refined by direct, detailed ground consultations with practitioners in 3 African and 1 Asian countries.
If we design an modern digital information system to meet those requirements, we can then conduct value chain analysis (health and economics). We can also develop a path to that desired state, as it is unlikely that a complete system will be built immediately. Here is where priorities can be made.
The advantage of doing it this way is that you will be less likely to create a bunch of silos; instead you will be adding building blocks, hopefully starting with the foundation of the shared, hosted platform David Lubinski mentioned. If you plug solution apps into a platform (electronic service bus) interoperability is much easier, and each customer-facing application doesn’t have to do its own security, auditing, access control, etc.
Then put it in the field, learn from the mistakes, and start the next cycle of spiral development again.