Last Mile Initiative: Difference between revisions
Line 126: | Line 126: | ||
== Sustainability Plan == | == Sustainability Plan == | ||
<center>'''Last Mile Initiative Community Health Data Collection Sustainability Plan'''</center> | |||
'''Introduction''' The Last Mile Initiative Community Health Data Collection project was designed to allow community volunteers in Rwanda to go door-to-door and gather important health information from the citizens via mobile phone. The original scope of the project was to develop the application and perform a pilot test of it in two districts in Rwanda. Due to unforeseen political and funding issues that pilot was not performed and the development process was altered to accommodate the lack of hardware available to test with. | |||
'''1. Development''' One success of the work done on LMI has been that the public health professionals working in conjunction with the Twubakane project benefited from the process of us reviewing the data collection forms and the health indicators the forms are based on. Unfortunately for our development this caused a great deal of dynamic flow to the indicators and forms which in turn, required us to redo the database and forms. | |||
'''1.1 OpenMRS''' It was decided during the development process that the freely available OpenMRS[#FOOTNOTE-1 1] (Open Medical Records System) was a perfect fit for this project. OpenMRS provide a stable, flexible platform to work with when collecting health data. The open-source system has been under development for many years and has a very robust community which continually improves it. The community is very engaged and helpful, providing a good source for support not only in development, but in usage of the system as well. | |||
'''1.2 Indicators''' When the project started the Twubakane project had close to 30 health indicators in which the data collection forms were based on. By the close of our work that has been narrowed to 15 indicators. While this is good streamlinging for their purposes it does point out the complications inherent to such a system.Health indicators are always dynamic as diseases take hold in certain regions or populations and international focus shifts. It is important to understand and design for some shift in the indicators over longer periods of time. However, rapid changes would be detrimental to the data collection process as well as the availability of developer time in changing the database schema and front-end forms. The rate of change that happened during our work was unexpected. | |||
'''1.3 Example: Adding an Indicator''' If, for example a new indicator was added the database would have to be altered to include the new indicator. This would involve adding the new indicator to the schema however, since we are using OpenMRS the change would be fairly trivial. In fact, a non-programmer could add the new indicator via the administrative tools provided with OpenMRS.Adding the new indicator to the database is only half of what is needed, the forms which allow the community volunteer to enter the data are static and would need to be done by hand. While this can be something a non-developer can learn how to do it would help to have someone who is fairly comfortable doing so. However, translating that form to Kinyrwandan (or another language if taken to another country) would, of course, require some expertise. | |||
'''1.4 Scalability''' Due to the selection of OpenMRS, which utilizes the MySQL database, all running on linux, scalablity is not a big concern for this system. The system should be able to handle, conservatively estimating, over 6000 transactions per hour. It is doubtful that even if the system were to be rolled out to the whole country that those numbers would even be realized.Having said that, as with most countries in the region which Rwanda is in, having the server in a location which provides stable and strong bandwidth is a concern which is related to scalability and is one which would benefit from revisiting from time to time were the system in use. Please refer to the Pilot section of this document for more on server support issues. | |||
'''Rapid development''' | |||
'''Licensure''' | |||
'''Community''' | |||
'''Launchpad''' | |||
'''Wiki''' | |||
'''2. Hardware''' This particular project has a strong reliance on numerous, inexpensive hardware. For a country like Rwanda was important to look for hardware which is readily available in-country but still was capable of displaying readable information and accept data input in a manner which was effecient for the volunteers. While there was much discussion about hardware during this project, no single model was ever identified.This is quite important for this project for development. At this time our development focused on least-common denominator hardware and thus is a web-based front-end. However, as explored below, the platform selection can allow for far more interesting interaction. What must be clear for any future implementation is whether ''available'' hardware is more important than the development concerns. At this time Rwanda is very limited in the models of phones available. As we were working closely with Qualcomm we tended to focus on the phones available through Rwandatel (the CDMA driven network), however if MTN (the GSM carrier) were looked at the models available would be vastly superior. | |||
'''2.1 Costs''' Mobile phone costs in Rwanda tend to run similar to their exact counterparts in Europe, keeping in mind that they are utilizing much older models than Europe currently has available. Pricing for phones ranges from as low as $40(US) to $500(US) with the $500 model being a smart-phone with a full keyboard (though this model is normally not readily availble).Considering just the original pilot plan for working with two different health clinics in Rwanda we would have been working with between 20 and 60 vounteers if it had been fully rolled out. While that would have covered quite a few villages (3 to 6 volunteers per village) it still would have been very small in comparison to the number of clinics and villages throughout the country. The costs for phones to accomplish that would be quite high. | |||
'''2.2 Available Platforms''' The most prominant phone brand in all of Rwanda is Nokia. Nokias, for the most part, run on the Symbian operating system. This system is the leading installed embedded operating system for phones worldwide (46% of all phones use Symbian). Symbian's application layer is an implementation of Java ME (J2ME). The distinct problem however is that the older model, smaller phones often do not have a similar application layer which, in our case, meant that we would not have been assured of having Java available had we chosen it.Having said that, for sustainability's sake as well as to combat poor coverage in certain areas, we would recommend further development to focus on Java and phone which utilize it in the application layer.Of particular note is the OpenROSA[#FOOTNOTE-2 2] project. OpenROSA is an open-source effort to reduce duplication of effort in the area of mobile data collection. More specifically it is a data collection application toolkit for J2ME with its first implementation having a strong focus on OpenMRS usage. Intrahealth has contributed to discussions on the development of OpenROSA with the Last Mile Initiative as the prime example of the needs we had for the toolkit. | |||
'''2.3 Lifecycle''' One consideration when thinking of hardware is the lifecyle of a mobile phone. Small, somewhat fragile devices such as phones are bound to encounter some problems and are typically easier to replace than repair. This can have a fairly large impact on the sustainability of the project.Replacement costs for lost or broken phones must be worked into the costs of rolling out to any area. One rule of thumb might be to suggest that for every three operational phones there should be funds available to purchase one replacement. The choice of three to one being based on the fact that for each small village there would be up to three volunteers working at one particular time. | |||
'''3. Mobile Network''' During the development cycle of this project most of our focus was on Rwandatel due to our relationship with Qualcomm who are the makers of the CDMA network technology which Rwandatel uses. Most of the information below is based on this focus and could be quite different if MTN, or even both networks were considered for rollout. | |||
'''3.1 Carriers''' The two main carriers in Rwanda are Rwandatel and MTN. While we focused mostly on Rwandatel, it is important for sustainability to keep an eye on both especially when considering the growth of the networks in the more rural areas of the country. '''Rwandatel''' - Rwandatel's history is one which is divided almost equally between being state-owned and private. It is clear that the government does not want to own the business as it has sold it off quickly after resuing it from certain failure. Currently a majority stake of the company is owned by a Lybian investment firm but there are constant rumors of its sale to many different companies, most European. Rwandatel is also the country's wired phone and internet provider in the country which brings with it some great benefit. In terms of this project this was most useful in that Rwandatel had offered to host any servers for the project. Since they are the main internet provider in the country this is about as good as can be asked for in terms of bandwidth and stability. '''MTN''' - It is safe to say that MTN is the more stable of the two companies. It is a South African based company which provides mobile coverage in many countries throughout Africa. In fact, in most countries in which it has a presence, it tends to be the leading provider. | |||
'''3.2 Coverage''' Coverage in Rwanda is quite good for both mobile networks. However, the areas in which the higher-end technologies that provide higher bandwidth are generally only located in Kigali and the areas just outside Kigali. There are exceptions to this though which, for Rwandatel, can be seen on the Rwandatel Mobile Coverage Map (2007) on the LMI wiki[#FOOTNOTE-3 3]. Despite the smaller areas outside of Kigali, the higher bandwidth technologies are not readily available despite the mobile coverage as a whole being quite good.We do not have a similar map for MTN and the situation may be quite different for them. Furthermore, both networks continue to grow and are upgraded frequently. This situation may be completely different in a few years. | |||
'''3.3 Partnerships''' The approach we took with this project relied heavily on the mobile network companies. In our case, we approached Rwandatel and had conversations about their role in the project. The two most important parts for the growth of this project were airtime and hosting. Airtime, which is detailed below, while cheaper than many countries, could be expensive were the client to stay as it is and work mostly with browsing technologies. However, a partnership with the mobile company in which they donate or discount the airtime used in the project would save a great deal of money. One particular question raised by Rwandatel was whether or not the volunteers would be using these phones for their personal usage when not working on the project. They were not in favor of this idea although we had looked at it as one incentive for the volunteers to actually do the work. Estimating the time it would take for the workers to do the work and getting just that amount of airtime was one idea explored to answer this question. Rwandatel was also ready to offer us hosting services which were referred to previously. Again, in a country where hosting can be very unstable, we determined that Rwandatel would provide the most stable offering. | |||
'''3.4 Costs''' For mobile network access the costs certainly do depend on any parntnerships which could be formed with the two main companies working in Rwanda. However, to get an idea of what kind of costs would be associated with normal usage, both companies work at roughly the same price breakdown: | |||
{| class="prettytable" | |||
| Time Period | |||
| Pre-pay | |||
| Pay-as-you-go | |||
|- | |||
| Peak | |||
| $.16/minute | |||
| $.18/minute | |||
|- | |||
| Off-peak | |||
| $.12/minute | |||
| $.16/minute | |||
|} | |||
If we were to spread this out across multiple phones throughout the country it would get expensive and could possibly go beyond what the mobile carriers are willing to donate. However, the numbers which we were estimating for an initial pilot did not seem to pose a problem for Rwandatel in terms of donating the airtime, especially when coupled with the important nature of the work for the welfare of the country. | |||
'''4. Pilot''' | |||
'''4.1 Ministry of Health''' | |||
'''4.2 Volunteers''' | |||
'''4.3 Training''' | |||
'''4.4 Support Structure''' | |||
'''4.5 Costs''' | |||
'''Conclusions''' | |||
# http://openmrs.org/wiki/OpenMRS | |||
# http://www.openrosa.org/ | |||
# http://wiki.ihris.org/wiki/upload/RURA_coverage_Regional_boundaries.xls | |||
Revision as of 14:43, 4 December 2008
Welcome to IntraHealth Informatics Last Mile Initiative Wiki.
This page will have updates on all of the ongoing work being done for the SRA/IntraHealth Last Mile Initiative Community Health Data Collection System.
What is the Last Mile Initiative
The overall objective of the USAID Last Mile Initiative (LMI) is to expand rural poor communities’ access to telecommunications using sustainable and scalable approaches in order to improve livelihoods and access to development opportunities.
Within the context of LMI, the project objective is to design, develop, install and pilot usage of a telecommunications-enabled Community Health Services Information System for the health sector in Rwanda. Using the paper-based system already developed by the Twubakane Program as the base, IntraHealth will design an Open Source application for data collection and reporting via cell phones and other mobile devices. The data system will improve the capabilities, impact, and timeliness of the current paper-based system by allowing easier data entry of health service indicators and also improving the ability to measure performance of these indicators against district, national, and global targets.
The automated system itself is designed to rely on a centralized voice-response unit. Community health workers will make phone calls to the central processor and will be prompted to provide service data on a set of pre-determined indicators. The data collected via the voice response system will then be written to the database. Managers will be able to call into the system to retrieve performance data indicating how well their communities are meeting targets or performing as compared to the district, regional, and/or national averages. The automated system also will support the broadcasting of updates from district, regional, or national authorities that will keep health workers abreast of recent policy changes and disease outbreaks.
The software package used to support the automated system will accommodate a variety of data entry devices ensuring maximum accessibility from remote areas and will include instructional and supporting documentation, multilingual capabilities, a web interface and a set of standardized reports with options for customizing to local conditions.
Major implementation steps include:
1) Manage project and report milestones;
2) Identify, hire and train local developer and local development support team; 3) Develop functional requirements;
4) Design and develop software application;
5) Develop user and technical documentation;
6) Pilot system and make adjustments; and
7) Develop scalability and sustainability plan.
System implementation will rely on local development resources and partnerships. Local development efforts will include a full time Open Source developer, senior Open Source development consulting, ICT support for hardware implementation, local trainers, and local monitoring and evaluation support from the existing Twubakane staff. US-based IntraHealth staff will provide project management leadership and senior systems and development support. Rwanda-based technical assistance from the Twubakane Project will be critical to development of functional requirements and support from TRACplus and the Rwanda Ministry of Health HMIS unit will ensure maximum system integration.
The implementation plan included below contemplates a one year timeline for system delivery including: local team building, stakeholder development, and creation of system specifications and use cases will span 4 months; pilot software and related material development will span 3 months; software introduction, training, support, and monitoring of two pilot districts will take 3 months; and implementing final improvements will take 2 months. Given the short timeline for delivery, local development staff will be supported by US-based senior advisors as needed. Quarterly travel is planned by project management leadership to ensure all timelines are met and that stakeholders remain actively engaged.
Implementation also will be supported via a partnership with Qualcomm who will provide financial support to cover all hardware and software costs as well as training and documentation.
Partners
- IntraHealth International
- SRA
- Qualcomm
Contact Information
- David Mason – Health Informatics Advisor - dmason@intrahealth.org – 919. 313.3555
- Vanessa Spann – Informatics Team Lead – vspann@intrahealth.org
- Mark A. Hershberger – Informatics Team Member – mhershberger@intrahealth.org – 717.271.3396
- Laure Almairac and Jana Scislowicz – Program Support – lalmairac@intrahealth.org - 919.313.229
Activity Plan, Reports, and Updates
Original Documentation
Implementation
We will store data and forms in OpenMRS. OpenMRS provides analysis tools and can be integrated with Rwanda's TRACnet using Kettle. In-depth, custom reports can be generated using BIRT and the OpenMRS ODA plugin for BIRT.
Asterisk, programmed via Adhearsion will provide a voice prompt system. Custom code will translate the forms into voice and present them to the end user. This code will also post responses back into the OpenMRS back-end.
Likewise, a lightweight Ruby-on-Rails (RoR) system will translate the forms into WAP or HTML for presentation on EVDO-capable phones. RoR is preferred here since Adhearsion and RoR can easily share code.
If time permits, we will include form presentation on OpenROSA-capable handhelds. This would enable health care workers to collect data even in places where there is no cell-phone access, or to collect data without using airtime.
(Diagrams of this proposed implementation: PDF format and Inkscape SVG source
Translation for Forms and Menus
Kinyarwanda translation interface
If network connectivity is good enough, you can edit translations or view suggested translations (from other Launchpad-hosted projects) online. If you would rather use a desktop application, download and install Poedit as well as the .pot translations template.
If you edit the translations offline, you'll need to upload the .po file produced to Launchpad or mail it to me.
For context, you can walk through the current screens online.
Forms
Use Cases
Indicators
1. Number of infants less that 12 months of age completely vaccinated in the preceding month
2. Number of children aged 12 to 23 months who received one dose of vitamin A during the last month
3. Number of children aged 12 to 23 months who have received a Mebendazole-based de-parasite treatment during the last month
4. Number of feverish children aged 6-59 months who received one dose of anti-malarial medication at the community level in the last month
5. Number of children aged 2-59 months suspected to have pneumonia and treated at the community level during the last month
6. Number of children aged 0 to 59 months suffering from diarrhea and treated with oral rehydration salts and zinc at the community level in the last month
7. Number of home deliveries during the last month
8. Number of home deliveries where mother and neonate were referred to health center during the last month
9. Number of women accompanied for delivery at a health center during the last month
10. Total number of deceased children under the age of 5 in the last month
11. Number of couples sent to the health center for family planning during the last month
12. Number of cycles of oral contraceptives distributed in the course of the last month
13. Number of condoms distributed in the last month
14. Number of couples sent to health center for PMTCT services in the last month
15. Total number of deaths in the last month
Equipment Plan
Pilot Plan
Sustainability Plan
Introduction The Last Mile Initiative Community Health Data Collection project was designed to allow community volunteers in Rwanda to go door-to-door and gather important health information from the citizens via mobile phone. The original scope of the project was to develop the application and perform a pilot test of it in two districts in Rwanda. Due to unforeseen political and funding issues that pilot was not performed and the development process was altered to accommodate the lack of hardware available to test with.
1. Development One success of the work done on LMI has been that the public health professionals working in conjunction with the Twubakane project benefited from the process of us reviewing the data collection forms and the health indicators the forms are based on. Unfortunately for our development this caused a great deal of dynamic flow to the indicators and forms which in turn, required us to redo the database and forms.
1.1 OpenMRS It was decided during the development process that the freely available OpenMRS[#FOOTNOTE-1 1] (Open Medical Records System) was a perfect fit for this project. OpenMRS provide a stable, flexible platform to work with when collecting health data. The open-source system has been under development for many years and has a very robust community which continually improves it. The community is very engaged and helpful, providing a good source for support not only in development, but in usage of the system as well.
1.2 Indicators When the project started the Twubakane project had close to 30 health indicators in which the data collection forms were based on. By the close of our work that has been narrowed to 15 indicators. While this is good streamlinging for their purposes it does point out the complications inherent to such a system.Health indicators are always dynamic as diseases take hold in certain regions or populations and international focus shifts. It is important to understand and design for some shift in the indicators over longer periods of time. However, rapid changes would be detrimental to the data collection process as well as the availability of developer time in changing the database schema and front-end forms. The rate of change that happened during our work was unexpected.
1.3 Example: Adding an Indicator If, for example a new indicator was added the database would have to be altered to include the new indicator. This would involve adding the new indicator to the schema however, since we are using OpenMRS the change would be fairly trivial. In fact, a non-programmer could add the new indicator via the administrative tools provided with OpenMRS.Adding the new indicator to the database is only half of what is needed, the forms which allow the community volunteer to enter the data are static and would need to be done by hand. While this can be something a non-developer can learn how to do it would help to have someone who is fairly comfortable doing so. However, translating that form to Kinyrwandan (or another language if taken to another country) would, of course, require some expertise.
1.4 Scalability Due to the selection of OpenMRS, which utilizes the MySQL database, all running on linux, scalablity is not a big concern for this system. The system should be able to handle, conservatively estimating, over 6000 transactions per hour. It is doubtful that even if the system were to be rolled out to the whole country that those numbers would even be realized.Having said that, as with most countries in the region which Rwanda is in, having the server in a location which provides stable and strong bandwidth is a concern which is related to scalability and is one which would benefit from revisiting from time to time were the system in use. Please refer to the Pilot section of this document for more on server support issues.
Rapid development
Licensure
Community
Launchpad
Wiki
2. Hardware This particular project has a strong reliance on numerous, inexpensive hardware. For a country like Rwanda was important to look for hardware which is readily available in-country but still was capable of displaying readable information and accept data input in a manner which was effecient for the volunteers. While there was much discussion about hardware during this project, no single model was ever identified.This is quite important for this project for development. At this time our development focused on least-common denominator hardware and thus is a web-based front-end. However, as explored below, the platform selection can allow for far more interesting interaction. What must be clear for any future implementation is whether available hardware is more important than the development concerns. At this time Rwanda is very limited in the models of phones available. As we were working closely with Qualcomm we tended to focus on the phones available through Rwandatel (the CDMA driven network), however if MTN (the GSM carrier) were looked at the models available would be vastly superior.
2.1 Costs Mobile phone costs in Rwanda tend to run similar to their exact counterparts in Europe, keeping in mind that they are utilizing much older models than Europe currently has available. Pricing for phones ranges from as low as $40(US) to $500(US) with the $500 model being a smart-phone with a full keyboard (though this model is normally not readily availble).Considering just the original pilot plan for working with two different health clinics in Rwanda we would have been working with between 20 and 60 vounteers if it had been fully rolled out. While that would have covered quite a few villages (3 to 6 volunteers per village) it still would have been very small in comparison to the number of clinics and villages throughout the country. The costs for phones to accomplish that would be quite high.
2.2 Available Platforms The most prominant phone brand in all of Rwanda is Nokia. Nokias, for the most part, run on the Symbian operating system. This system is the leading installed embedded operating system for phones worldwide (46% of all phones use Symbian). Symbian's application layer is an implementation of Java ME (J2ME). The distinct problem however is that the older model, smaller phones often do not have a similar application layer which, in our case, meant that we would not have been assured of having Java available had we chosen it.Having said that, for sustainability's sake as well as to combat poor coverage in certain areas, we would recommend further development to focus on Java and phone which utilize it in the application layer.Of particular note is the OpenROSA[#FOOTNOTE-2 2] project. OpenROSA is an open-source effort to reduce duplication of effort in the area of mobile data collection. More specifically it is a data collection application toolkit for J2ME with its first implementation having a strong focus on OpenMRS usage. Intrahealth has contributed to discussions on the development of OpenROSA with the Last Mile Initiative as the prime example of the needs we had for the toolkit.
2.3 Lifecycle One consideration when thinking of hardware is the lifecyle of a mobile phone. Small, somewhat fragile devices such as phones are bound to encounter some problems and are typically easier to replace than repair. This can have a fairly large impact on the sustainability of the project.Replacement costs for lost or broken phones must be worked into the costs of rolling out to any area. One rule of thumb might be to suggest that for every three operational phones there should be funds available to purchase one replacement. The choice of three to one being based on the fact that for each small village there would be up to three volunteers working at one particular time.
3. Mobile Network During the development cycle of this project most of our focus was on Rwandatel due to our relationship with Qualcomm who are the makers of the CDMA network technology which Rwandatel uses. Most of the information below is based on this focus and could be quite different if MTN, or even both networks were considered for rollout.
3.1 Carriers The two main carriers in Rwanda are Rwandatel and MTN. While we focused mostly on Rwandatel, it is important for sustainability to keep an eye on both especially when considering the growth of the networks in the more rural areas of the country. Rwandatel - Rwandatel's history is one which is divided almost equally between being state-owned and private. It is clear that the government does not want to own the business as it has sold it off quickly after resuing it from certain failure. Currently a majority stake of the company is owned by a Lybian investment firm but there are constant rumors of its sale to many different companies, most European. Rwandatel is also the country's wired phone and internet provider in the country which brings with it some great benefit. In terms of this project this was most useful in that Rwandatel had offered to host any servers for the project. Since they are the main internet provider in the country this is about as good as can be asked for in terms of bandwidth and stability. MTN - It is safe to say that MTN is the more stable of the two companies. It is a South African based company which provides mobile coverage in many countries throughout Africa. In fact, in most countries in which it has a presence, it tends to be the leading provider.
3.2 Coverage Coverage in Rwanda is quite good for both mobile networks. However, the areas in which the higher-end technologies that provide higher bandwidth are generally only located in Kigali and the areas just outside Kigali. There are exceptions to this though which, for Rwandatel, can be seen on the Rwandatel Mobile Coverage Map (2007) on the LMI wiki[#FOOTNOTE-3 3]. Despite the smaller areas outside of Kigali, the higher bandwidth technologies are not readily available despite the mobile coverage as a whole being quite good.We do not have a similar map for MTN and the situation may be quite different for them. Furthermore, both networks continue to grow and are upgraded frequently. This situation may be completely different in a few years.
3.3 Partnerships The approach we took with this project relied heavily on the mobile network companies. In our case, we approached Rwandatel and had conversations about their role in the project. The two most important parts for the growth of this project were airtime and hosting. Airtime, which is detailed below, while cheaper than many countries, could be expensive were the client to stay as it is and work mostly with browsing technologies. However, a partnership with the mobile company in which they donate or discount the airtime used in the project would save a great deal of money. One particular question raised by Rwandatel was whether or not the volunteers would be using these phones for their personal usage when not working on the project. They were not in favor of this idea although we had looked at it as one incentive for the volunteers to actually do the work. Estimating the time it would take for the workers to do the work and getting just that amount of airtime was one idea explored to answer this question. Rwandatel was also ready to offer us hosting services which were referred to previously. Again, in a country where hosting can be very unstable, we determined that Rwandatel would provide the most stable offering.
3.4 Costs For mobile network access the costs certainly do depend on any parntnerships which could be formed with the two main companies working in Rwanda. However, to get an idea of what kind of costs would be associated with normal usage, both companies work at roughly the same price breakdown:
Time Period | Pre-pay | Pay-as-you-go |
Peak | $.16/minute | $.18/minute |
Off-peak | $.12/minute | $.16/minute |
If we were to spread this out across multiple phones throughout the country it would get expensive and could possibly go beyond what the mobile carriers are willing to donate. However, the numbers which we were estimating for an initial pilot did not seem to pose a problem for Rwandatel in terms of donating the airtime, especially when coupled with the important nature of the work for the welfare of the country.
4. Pilot
4.1 Ministry of Health
4.2 Volunteers
4.3 Training
4.4 Support Structure
4.5 Costs
Conclusions
- http://openmrs.org/wiki/OpenMRS
- http://www.openrosa.org/
- http://wiki.ihris.org/wiki/upload/RURA_coverage_Regional_boundaries.xls
Addendum: Rwandatel mobile coverage map - 2007 [[1]]
Press Plan
Last Mile Initiative Rwanda IntraHealth International, SRA, Qualcomm DRAFT Media Plan as of 12 May 2008
- Goal
Utilize local and international media attention to support the project. Especially to increase access to community support resources including open source developers and user groups and potential local partners in the areas of health and telecommunications.
- Stakeholders
Qualcomm
SRA and USAID
IntraHealth (IH)
Rwanda Ministry of Health (MOH)
- Activities
Develop efficient control and approval system for public materials. Meet with Qualcomm, SRA and Rwanda Ministry of Health (MOH) to determine boundaries and requirements for communicating with the public. Identify required terminology and logos. Identify PR contact from each organization. PR contacts to provide approval for release of information and serve as point of contact for media.
Due date: by end of May
Develop project launch joint release for US and local distribution. Collect quotes from community health workers and Ministry staff for use in releases. Post on IntraHealth (IH) website and other partner’s websites. Release to IH professional and media lists. Launch release to highlight in-country needs and how system will meet those needs through personal stories, opportunities for local collaboration and international partnerships.
Suggested release date: May 28th at the Global Health Council
Official pilot launch event to happen at the end of September once the pilot has started OR at the end of the pilot in January 2009. Official pilot launch to include an event at community facility where local leaders, partners and media are invited.
Develop case studies for distribution in the US and Rwanda. Collect stories from community health workers, Twubakane staff and Ministry staff for use in release. Prepare images to accompany release. Post on IntraHealth (IH) web site. Release to local and regional media including Kigali’s New Times, AllAfrica.com and BalacingAct-Africa.com. Also, release to IH professional and media lists and selected international and regional contacts. Pilot release to have the greatest press emphasis and to highlight how the creative use of appropriate, ubiquitous technologies can have a significant impact on critical health issues. Release to emphasize personal stories, collaboration with local partners and potential impact both locally and regionally. This would be an ongoing activity throughout the pilot.
Target three to four key media contacts for larger international media coverage. Using materials developed for media releases, cultivate selected high-level press contacts for maximum coverage. As possible, prepare special stories and photographs to create unique, compelling story line. This can be done during the official launch.
Include LMI project information on existing IH and partner online resources. Online resources include reference on IH Informatics site and blog. Integrate LMI code and developer resources into existing IH tools for open source development community (Wiki, LaunchPad). Publicize within larger open source community including user groups, conferences and other support resources.
Provide success stories and articles for newsletters including Wireless Reach’s quarterly.
Include this project in brochures, video submissions and speaking points for executives.