At InSTEDD right now we are involved on a wide spectrum of projects. Many of our projects are short and grassroots-driven, such as our recent work with UNICEF using aerial photography to map environmental vulnerabilities in the slums of Rio de Janiero (see blog from our iLab Latin America: Part 1 and Part 2). In addition, many of our projects are longer and more complex as we help Ministries of Health or large NGOs lay the technology foundation that helps them meet better serve their country over the long run, such as our work in Cambodia and Rwanda.
These latter projects require more patience to see the impact and are sometimes more difficult to work on due to the time lines and the large number of stakeholders and interests involved. But, when done right, the long-term impact can be transformational.
We are lucky to be involved with Jembi, Regenstrief Institute and others on implementing such a project in Rwanda, under the leadership of Dr. Richard Gakuba, who works for the Ministry of Health as the National eHealth Coordinator. Dr. Gakuba is leading the charge transforming Rwanda’s Health Information System. A big part of this modernization is the implementation of shared health records, terminology services, and facility and provider registries. When this phase of the project is done, Rwanda will have a variety of independent, but interoperating, web services that implement these capabilities. It may sound like a 2002 buzzword to call it a “fabric”, but it evokes the right image: a supporting net of independent but inter-woven services.
Having a fabric of services makes a lot of sense in this context, starting with the impact of this architecture pattern on human and organizational dynamics. Distributing the ownership, management and maintenance of different areas of data is appropriate when the organization itself is made of different departments with different workflows, incentives, and management styles. Centralizing all these processes and information into a monolithic block would cause a collapse as the only entity able to change things would rapidly become a bottleneck. Just the provisioning and maintenance of one big system can be an insurmountable obstacle. Modularity allows piecemeal evolution.
Benefits
Having a “fabric” of services has many advantages:
Creating an Ecosystem – services and their data can get used by others to create new “value-add services”. For example, a facility registry could be extended with a call-in system to let immigrants get directions to nearby clinic in their own dialects. Enabling these value-add services (including mashups and client apps) allows the ecosystem of users (the general population, the local NGOs, the international ICT community, national and international private sector) to act like a gap-finder for better health services and businesses.
Potential for Big Data – Services provide a quantum leap over the traditional approach of keeping excel spreadsheets, access databases, and ad-hoc CSVs for research and retrospective data analysis. Data can be stored and versioned appropriately therefore simplifying future retrospective analysis. Taking advantage of these datasets comes with many challenges, however. For example, most countries do not have or enforce a framework where people opt-in to having their data stored, shared, and/or analyzed for research or commercial purposes. Rwanda has taken what I consider to be a great stance: All data that will be kept centrally about individuals has to be approved ‘column by column’ (using a relational metaphor). The data can be used only with scientific journal backed evidence that the information can be used to improve health outcomes within an actual project/program to do so. Notice this may turn some big data fans pale (“What, you are not saving everything centrally and then figuring out what to do with it?”), but I think it is a smarter place to start.
Steps to Open Government – While modest, the decision to have public data available as web services on the internet can be a milestone towards “open gov“. Opening up government data increases accountability, trust, and feedback loops. Many governments would probably prefer to pay lip service to open data principles rather than embrace them; but there are so many benefits to doing so in the health sector that it may be a great place to start.
Example Services
What are the services that could exist in such a fabric? The theoretical list runs long but here are some examples of the services we are dealing with in the real world:
- Facility Registry: A service to keep track of facilities, their admin information, the health services they provide, and data about their catchment population.
- Vital Registration: Service to keep track of births, deaths and Health ID management for the population (Note that a different ID assignment authority is needed: the United State’s practice of using a unified social security number for financial ID, health ID and immigration purposes is considered ‘bad practice’ by modern standards, and I am happy where we are working with people who are staying away from unified IDs).
- Shared Health Record: Services that keep track of individual people’s health data over time.
- Provider Registry: A service that tracks the institutions and individuals who are licensed to work in the health system. This can be enormously important for HR, education, and performance-based-financing work. Having a current provider registry also is a foundation for maintaining privacy.
- Terminology Registry: Services that collect, map and standardize the meaning of different words and fields. This makes it easier to see if the “blood pressure” field used in system A can be equated to “blood pressure” in system B (If the blood pressure is taken in different parts of the body in different conditions, the data semantics are different, regardless of the shared label).
- mHealth SMS, Voice and USSD gateway: Having these help consolidate agreements with operators & aggregators and provide a simpler way to manage collections of mHealth initiatives.
Of course, having many services makes it necessary to have better federated authentication/authorization capabilities (unless you want users to forget 10 passwords instead of only one) and to have some external services that act as controllers/orchestrators for complex multi-step operations (for example, someone dying or moving may trigger a cascade of operations on all the services above).
Good neighbors
To be good citizens of the fabric, the services have to play well with each other. Here are some expectations:
- Master vs Reference Data: Each service has clear ownership of master data versus what is reference, externally managed data which may be continuously updated from some external system.
- Accommodating Dynamic Changes: Services-especially the registries and shared health record — have to accommodate dynamic changes in information schemas and uses over time; and provide a good long-term versioning strategy.
- Updates and Queries: Services must expose a REST API or equivalent endpoints for state updates and queries, as well as expose a stream-of-events API (e.g. Atom/RSS feeds with some pingback/notification mechanism to allow other services to adjust themselves to the changes in real time or in batch mode).
- Compatibility: Services share compatible approaches to authentication/authorization/auditing and other crosscutting aspects.
For the work we are doing, Rwanda has chosen use cases in maternal-child health as the ‘red thread’ that will drive priorities in the project. Part of their well thought out strategy is to keep governance over the technology but rely on local and international partners to help build the technology instead of having an in-house dev shop within the Ministry of health.
InSTEDD contributes the Facility Registry
Rwanda is currently evaluating good starting points for the services discussed above. For the Facility Registry services, Rwanda is evaluating Resource Map, an InSTEDD tool that was originally developed in 2009 by our iLab Southeast Asia.
Resource Map evolved to help people make better use of their data. Data that isn’t used is stale, and stale data isn’t used. We have seen lots of projects and facilities collect and forget about the data as soon as its reliability became suspect. Tens of thousands of dollars per country are spent every year on collecting information that could have simply received minor updates from previous versions.
Originally, we called the tool ‘Dynamic Resource Map’ to emphasize the dynamic nature of the tool. We wanted to ensure that the tool supported making the data operational, not obsolete. Some key aspects of the tool include the ability to define your own layers, with ‘points’ or resources or reports on those layers (which are shown as different fields). The tool also has query and update features that can be done through SMS and smartphones (using Open Data Kit). The tool is designed to manage a resource database that happens to have a ‘geo’ component to it which adds critical behaviors on top of the typical alternatives of having semantic-less spreadsheets or generic GIS tools.
A real-world example of the value of the tool is its ability to track stocks of supplies for Malaria treatment at the health center level. The simplicity of being able to just text in your current stock and have it automatically trigger an alert to the folks in the capital that will send you more medicines is invaluable.
Seeing the individual or clustered facilities with your own icons or alerts based on your rules can give you a real-time operational picture that otherwise would be impossible to visualize. Other uses include tracking of information about water quality measured periodically at different pumps, and also it is useful for project tracking and monitoring & evaluation (M&E) data gathering.
Data that isn’t used is stale, and stale data isn’t used.
As with any InSTEDD tool since 2007, we took the perspective of providing a cloud ‘product’ that is generic and usable worldwide, that each user can configure to their needs. For example, folks can add their own fields, manage their own user permissions, and have total freedom to import and export their own data, etc. And with the APIs and import/export features, people can move the data to spreadsheets or to more specific tools like ArcGIS or GeoCommons as needed.
As we work with the Rwanda Ministry of Health on their eHealth foundation, our Resource Map tool will evolve to incorporate the experiences and feedback from the people using the tools. We will use their stories to maximize the benefit to the global eHealth/ICT4D community as we develop new versions over the upcoming months. In addition, we have started engaging with other amazing implementation partners so that this work can be incorporated into the shared commons of technology. We are excited about the changes that this initiative is already bringing in the front of APIs as well.
Back to Rwanda
He warns about making implementations of health programs revolve around evaluations (instead of make evaluations revolve around implementations) and gives an idea of the progress Rwanda has made in Maternal/Child Health, and how eHealth can help further MDG goals and health delivery.
He also reinforces the importance of starting small and working directly with your users as much as possible. Dr. Gakuba also recommends deploying simpler, smaller parts in a sequence versus going after large, complex technologies from the onset. Fortunately InSTEDD’s services-based approach is a perfect fit for that strategy, which allows the Ministry of Health to stay focused on priorities and gives a more iterative, agile frame to the project.
