This post was originally published in the JHU Global mHealth Initiative’s Digital Roundup Vol11 August 2016
As we’ve heard numerous times, “mobile health” is becoming just “health.” My positions over the past few years have focused on integrating SMS, IVR, handset applications and platforms across the health landscape. I have seen the need for clinicians to have access to patient interactions that happened in the field and contributed to massive infrastructure investments. I feel that we’re at a tipping point where many people on the ground want to integrate mobile phones with health programs and scale these systems across geographic boundaries. The point of service is shifting from traditional brick and mortar clinics to the field, where organizations are able to provide extensive care in a community. How can your project get there? I aim to share a sample evolution of projects that I’ve witnessed over the past few years.
The first step for an organization is to convert paper based systems to digital. This is a huge undertaking that primarily happens at the point of service. Moving from paper is a process that could take many months to years because it requires standardization and behaviour change across a large employee base. Understandably, this is the core requirement for gaining any benefit from analysis, aggregate reporting or interoperability. This challenge has been addressed by numerous point of service technologies in our field. We now have robust electronic health record systems in clinics, mobile form collection tools and browser based solutions that allow for information collection anywhere. The point of service is no longer defined by a building and is now defined as any place where an encounter takes place.
Reporting and Dashboarding
These exciting innovations have caused a boom in digital support services. As an organization moves from paper based workflows they begin to realize the value through reporting, aggregation and may be able to gain insight to their organization. Each point of service system has the ability to generate standard reports and dashboards with advanced reporting available through third party services. For example, standard reports can be found in Ona’s data menu or OpenMRS’s reporting module. These generic reporting systems aim to capture 80% of an organization’s reporting needs, fully understanding that it’s impossible to build a generic tool that meets all edge cases. Organizations often need to send the data to dedicated third party reporting systems for ad hoc querying and custom analysis.
As a sidebar, I have worked to define and quality control generic reports consumed by thousands of people at scale. The primary lesson I learned is that a single reporting system can not solve all of your reporting and dashboarding needs. Information needs to be acted upon at each level of the organization (frontline worker, management, executives, etc.), donors and government. Standard, custom, scheduled and ad-hoc reports all need to be generated to support the organization. Dashboards are often helpful to provide quick operational snapshots of indicators that can be easily consumed. Every actor in the organization should be able to identify the information they need to manage their day or workforce. Third party reporting systems make this possible.
Project and Operational Information Reporting
At this point, I feel it’s appropriate to define the blurry line between project and operational information. Project based information is information about the population you’re serving. If you’re collecting information on patients it may include the patient record, program enrollment information and indicators. Operational information is the information that ensures your organization can deliver the service at the right time and cost. Project based information often provides a feedback loop for operational information. For example, if a frontline worker sees 25 patients in a day, they collect project based information on those 25 patients. This information also lends itself for analysis on worker productivity. We’re able to create reports based on project information that supports how we do business. These reports are critical for distributed workforces.
There’s another classification of operational information that has to do with ensuring digital services are available, reliable and accurate. Digital service availability and reliability information is generally generated through third party monitoring systems that make sure web servers are active. These systems can respond if a digital service fails by automatically switching to a backup service or notifying an administrator. They often have embedded reports and dashboards for easy consumption of this information.
At this point, the organization is collecting information digitally and they have access to reports that inform on organizational activity. There are many activities happening on a day-to-day basis that ensure both the local and distributed workforce is achieving their targets. The distributed workforce requires regular communication, troubleshooting and mobile management to ensure their activities are actively managed with appropriate feedback provided.
Mobile workforce management has also become an important digital support service. Systems like CommCare and MagPi have workforce management built in to their mobile tools. Administrators are able to identify worker productivity, remotely troubleshoot issues with their field workers and provide feedback when needed. These management systems include standard reports that track logins, application activity, submissions by mobile worker and many more.
Of course, a core component of workforce management includes human resources and accounting services. I don’t have experience with this, but recognize that fully functioning teams work well when there are HR services that track timesheets, expenses and complete payroll. It’s definitely possible to create forms for the mobile workforce that captures all of this information, or use the standard reports to compare worker activity against what’s reported.
As I write this, I’m working on a team the supports interoperability between common health platforms (CommCare, DHIS2, OpenMRS). The core issue of interoperability focuses on moving information from your organization’s information systems so it can be used at a greater scale, or in a different context. For example, we have an active project where we connect field workers to the clinic in an attempt to improve clinic interactions with full program information.
Additionally, most health programs have the requirement to report information to centralized government or donor services. For example, many PEPFAR performers are required to submit aggregate project data to USAID’s Datim (DHIS2) server. These reports can be submitted through paper, a browser or automatically through a direct connection. There are a number of mechanisms to achieve interoperability, which should be an article topic of it’s own.
To conclude, we’re in a time where many projects are moving toward scale. I aimed to present my experiences with the evolution of projects from a paper based system to interoperable systems. It would be great to receive feedback on this view and identify if it resonates with the community.
Contact me if you'd like to talk about this post.
📅 29.08.2016 📁