- Austausch & Vernetzung
- Wissen & Lernen
- Advocacy
- Unsere Themen
Von Steven C. Uggowitzer, Sima C. Newell, Dykki Settle, Alice Liu and David J. Hagan
“I, ____________, in the presence of these my betters and my equals in my Calling, bind myself upon my Honour and Cold Iron, that, to the best of my knowledge and power, I will not henceforward suffer or pass, or be privy to the passing of, Bad Workmanship or Faulty Material in aught that concerns my works before mankind as an Engineer, or in my dealings with my own Soul before my Maker.”- from the Canadian Obligation of an Engineer, written by Rudyard Kipling (1922)
Just as medical doctors take the Hippocratic Oath as they graduate into their profession, so do many engineers solemnly promise to carry out work to the highest quality, recognizing that any errors may put lives at stake. Given this sharing of fundamental values, engineering is a profession that could be leveraged even further towards public health information systems to address opportunities created by the fusion of the early and relatively informal eHealth and mHealth paradigms into the more mature and complex one that is Digital Health. Recently, the World Health Assembly (WHA) adopted a key resolution on Digital Health, urging member states to assess and prioritise the scale-up of the implementation of digital technologies towards the “universal access to health for all”. (WHA 71.1, 2018)
In his article on managing public health systems, Josh Ruxin, stated ten years ago that “In public health, just as in any other collective endeavor, management matters”. (Ruxin, 2008) It has become clear over the ensuing years that for national health systems and services to achieve health related national targets and the global Sustainable Development Goals, engineering matters too.
Disciplines such as systems design and engineering should be, and in some cases already are, being mainstreamed into the delivery of digital health solutions and by extension the amplification and acceleration of health services.
When looking at digital health through the lens of other industries that require collective cooperation amongst sometime competing stakeholders – the global internet, travel, and finance sectors come to mind, standard approaches to the design and development of technological solutions for the associated challenges have long been seen as advantageous to foster seamless systems interoperability, integration and overall market growth (examples of systems and collaboratives include SABRE, SWIFT, AMADEUS, IETF, INTERAC).
In all these endeavors, collectively understood approaches to funding, designing, building and sustaining systems are key to innovation and growth worldwide. Digital-centric methodologies, such as enterprise architecture, systems engineering and modern agile approaches to software engineering have shown their mettle, and these same approaches are increasingly relevant and important to the field of Global Digital Health, where global interest increases the opportunities for improved health outcomes.
In this article, we draw on our experiences both with different platforms including DHIS2, iHRIS, OpenSRP and the OpenHIE interoperability architecture, and in the roll-out of national health information systems (e.g. Sudan, Eritrea, Tanzania, South Africa), and the delivery of smaller health data projects in fragile settings (Ukraine conflict, Palestine, Syrian Conflict, West Africa and DRC in the Ebola response). Through these experiences in delivering digital health solutions (including all elements from strengthening governance and leadership, strategy and investment, policy and compliance, infrastructure, standards and interoperability, services and applications and human capacity-building) we’ve identified several challenges, many of which reflect a lack of core architectural and engineering capability, skills and funding and sometimes even total lack of awareness of the relevance and importance of these fields.
We propose, based on an emerging collaborative environment around digital health, what we see as key evolutions within the community’s approach that will drive digital health forward most effectively and efficiently, avoiding silos and allowing each solution, in each setting, to achieve health goals with the greatest efficiency available today. We strongly believe current national and global health goals are not achievable without the combined benefits offered by these technologies and professional approaches.
Public health is a multidisciplinary field whose goal is to prevent disease, promote health, and improve the quality of life in communities and entire populations through education, promotion of healthy lifestyles, and research. The 2018 Resolution of the 71st World Health Assembly on Digital Health paves the way forward, and laudibly extends the cohort of skills needed to address global health challenges (such as those mentioned in the SDGs) and support national health systems in all countries. The text of the Resolution is mindful and inclusive of the essential technological skills and expertise which must be provisioned and sustained.
The resolution further tackles the digital divide in health, urging Member States, as well as WHO to ensure that digital health solutions are developed in more coherent and sustainable ways:
As systems implementers and engineers, we see an implicit requirement for meeting these and other clauses in the Resolution is to ensure scaled up and agreed approaches to architecture and engineering are broadly introduced into the design, development and management of digital health solutions.
Fortunately a number of key initiatives are already underway with aligned and burgeoning donor support that are setting the trend towards such approaches to digital health, including AeHIN, WHO Health Data Collaborative (HDC), DH&I Working Group of the HDC, Digital Square (PATH & USAID), Standards and Interoperability Lab (ADB & AeHIN), DHIS2 and the HISP Network of partners, and OpenHIE, to name just a few.
It is first important to distinguish between architecture, particularly Enterprise Architecture, and systems engineering. These two mature disciplines are foundational to successful complex digital implementations, ensuring that the health information system remains robust and cost-effective over time.
Enterprise Architecture, following methodologies such as TOGAF (The TOGAF Standard), is a means to achieve a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives, often using digital technology. It elaborates the purpose behind and the context for what digital health solutions are required and the business processes into which they will fit within the overall health system. With the WHA’s urging of member states to “assess their use of digital technologies for health, including in health information systems at the national and subnational levels, in order to identify areas of improvement, and to prioritize, as appropriate, the development, evaluation, implementation, scale-up and greater utilization of digital technologies” (WHA 71.1, 2018,emphasis added), Enterprise Architecture is the discipline with the defined methodology to support such assessments and prioritizations when looking towards digital solutions.
Enterprise Architecture will be essential to meeting the resolution points including “promoting equitable, affordable and universal access to health for all,” and “promotion of people-centered health and disease prevention and in order to reduce the burden on health systems.” (WHA 71.1, 2018) Both these requirements imply the need to fully describe the end-to-end health information system in an architectural framework to ensure appropriate solutions work in concert towards providing both people-centered solutions as well as demonstrating an increased efficiency in the overall health system.
An essential component of a larger Enterprise Architecture, Systems Architecture, narrows in on the overall design of a given system, or digital health solution, and provides the design for the main components. (An analogy between the two disciplines might be that Enterprise Architecture is more along the lines of urban planning, whereas systems architecture is more analogous to developing the blueprints for a given building, within the established urban plan.)
In contrast, Systems Engineering focuses on how to design and manage complex systems over their life cycles. Just as drugs can have either beneficial or detrimental interactions with each other, so can software and hardware components working together in a system. The systems engineer defines and manages the set of components that work best together in order to deliver the overall digital health solution(s) commissioned. His or her work involves developing and defining all the technical specifications for how to build, code, test and implement all the main components. The systems engineer is also mindful of the roadmap over time of the various components, with an eye to simplifying the operational management of the complete system, as components are updated with new releases at varying intervals.
It is our experience that these roles have been rarely, if ever, explicitly called for in the digital health projects we have been involved in, unlike expectations in other sectors. The WHA Resolution on Digital Health provides the framework and opportunity to bring these disciplines formally to the table in supporting the work of Member States to develop appropriate Digital Health strategies, ecosystems and solutions.
Put pragmatically, public health has moved into an age where the calling for Universal Health Coverage arguably demands a huge volume of transactional data, in effect recording and tracking individual information at the source / facility to facilitate care pathways. This data is then aggregated into reports at higher levels for Monitoring & Evaluation (M&E) of health services and public health planning. The requirement for both transactional and aggregate data imposes a need to strengthen architecture and governance. Such volume of transactions and data in digital health platforms implies reliance on technology and systems that are operational every day and across locations, not just at periodic intervals to support a reporting system for monitoring and evaluation purposes. For such a health information system to work reliably, efficiently and securely meeting the public trust, it must be architected and engineered correctly at the outset.
We have observed five key challenges in digital health solution implementations through our work. These issues transcend the particular choice of technology and have been present to one extent or another in every location we have worked. In each case, these challenges threaten successful deployment and hamper the most effective use of the solutions put in place.
The ubiquitous challenge in limited resource settings has to do with on-boarding, training and retaining qualified technology managers and engineers – for project management, business process analysis, end-user support, but also for network operations, infrastructure management, as well as software and applications development. Even more important is to ensure, from the outset, the right digital health leadership capacity to establish and lead the encompassing governance mechanisms and environment that will enable these engineers and process managers to be successful. It is important to note that these skills are needed irrespective of where the systems are actually hosted, in order to oversee and manage the ultimate solution. In effect, a lack of human resources capacity in these areas and/or the ability to finance these skills on an on-going basis frequently presents challenges to sustaining a solution, particularly in low resource or fragile settings.
Many different skills are required for a fully functioning digital health system, including systems engineering, development operations, infrastructure management, change management, as well as the application-level skills (including project management, software engineering, computer science, and user experience design). In practice, however, these different skills are often lumped together within a Ministry of Health into the general qualifier of “the IT person” or “the technology person”, when in reality the disciplines are just as different as psychiatry is from orthopedics (yet both are “medical doctors”). These skills need to be planned, supported, brought together and given a seat at the larger health governance table (via a Chief Information Officer, Chief Technology Officer or similar role) when any decisions regarding health systems implementation (including digital health solutions) are being discussed. Such an approach will be essential to delivering on the digital health strategy agreed by member states at the World Health Assembly.
Often, ministries of health struggle to identify clearly the type of engineering capacity they require, to bring on board qualified staff, and then to retain them. Over the last decade, we have witnessed several instances where the Information Technology (IT) capacity of a given Ministry for an entire country rests on the shoulder of three or fewer staff, who rarely have the seniority or mandate to drive a national digital health transformation. In addition, the private sector salaries of skilled IT staff can be several times the salary for the same staff within the Ministry of Health, making it difficult to retain staff. The current situation of human resources management for engineering and technology staff is unique to digital health in many ways. In other fields, it is rare for network, communications or software engineers to be so closely involved with so many diverse stakeholders in health service delivery, human resources in public health, and in governments and related offices.
In the private sector, it is typically the role of product and project managers to provide the interface between the end-user of an application and the engineering team that will build and maintain it. Right now, in global digital health, often due to skills scarcity, it is the engineers themselves who must have well honed sensitivities to political drivers, to public health needs and to the local infrastructure challenges, along with sound core engineering knowledge, and up-to-date technical skills maintained through regular implementation. The current demands of working in global digital health appear quite unique in this way – in other sectors, systems engineers focus on engineering, not stakeholder engagement, project management, requirements development, architecture, or the specific needs of the public health community.
The second challenge results from the procurement process, particularly for hardware, but also related to the acquisition of software and services.
In order to encourage interoperability and integration, the information systems architecture, layered over the architecture of the infrastructure, must be developed by staff with the correct technological competencies in conjunction with the design of the digital health solution, before components of the solution are procured. Then elements can be bought, configured and deployed in ways that are streamlined and effective in the local context, ensuring availability of the digital health solution that is aligned with the full-scale deployment, as well as information security and interoperability with any related systems, locally or once data is aggregated. These are mature disciplines, used in other sectors, that should be increasingly relied on and folded into the health sector as well.
We have seen time and again that infrastructure procurement is very often viewed as a project-related capital expenditure, and is often done prior to detailing some of the key requirements for digital health solutions (i.e. in the absence of the enterprise or systems architecture). In fact, infrastructure decisions can and should be made in the aggregate, across projects, addressing issues regarding national data sovereignty, the options for hosting on or off-site or in the cloud, the ability to provision more efficient service and support arrangements, and ensuring that the infrastructure supports the aggregate of digital health solutions together. Even cloud solutions require competent engineering staff to oversee and manage the service provided to ensure cost-optimized, appropriate solutions are developed and maintained. Often overlooked are also opportunities to engage with other sectors and actively leverage broader multisectoral infrastructure investments towards a more scaled, cost-optimized implementation.
In vertical-project-driven situations, we currently see that hardware configurations (including from specific, preferred vendors) may be set in stone that are not well adapted to the requirements of the health information system and/or the digital health solution implementation that is specified after the purchase. It may be, for example, that there is not enough memory for the number of transactions to be stored, or that the hardware does not easily permit running test and training environments as well as production (live) systems. In some settings, the need for backups (of critical patient transaction data) is simply forgotten at the time of hardware procurement, or spares for simple items such as fans are not available. Solutions may be locked in for several years to a preferred vendor which does not provide adequate products for the next stage of scaling-up.
Moreover, the timing of procurement in many ministries of health are governed by annual cycles that haven’t changed much in over fifty years, where simply ordering a spare part, or more memory can take up to a year to work its way through the internal processes. Such procurement issues are compounded in fragile settings were embargos or other border-control issues mean that bringing new equipment into a country can be difficult once a problem is discovered and its solution (in terms of products needed) is identified.
For systems engineers reading this, to put it in more technical terms – the specifications for virtualization, memory, power management, environmental controls, storage solutions, power continuity and hot or cold spares of any type of equipment, etc., are absolutely needed for the solution before the procurement is finalized and the goods are delivered and received. These needs should be driven by the overall architecture and approach to the digital health solution, in context, including the security context and the linkage and interoperability with other systems (e.g. logistics) or sectors.
It is the very difference in language and its precision that creates a precarious gap between what is mandated by public health officials and what can be effectively delivered by architects and engineers.
The third challenge is that the way the global digital health community approaches the classification and funding of projects currently leads to a piecemeal approach to the underlying technology and does not naturally incentivise resolving the two challenges raised above. Instead, funding for both systems procurement and staff are often done on a project-by-project basis, with no means to request funding for the enterprise architecture that should govern the overall approach to the solution.
One example is with the new, and robust, WHO Classification of Digital Health Interventions. (WHO/RHR/18.06) This is a thorough, carefully thought through classification developed through a consultative process to provide an initial approach to bringing together diverse communities aiming to “support a dialogue between public health practitioners and technology-oriented audiences”.
While recognizing how far forward the community has come with having any taxonomy at all, from the implementations we have been involved with, this classification does not yet go far enough towards bridging the gap between public health practitioners and technology specialists. Key architectural and engineering elements are missing entirely: infrastructure, for instance, is nowhere to be found in the categorizations. Information security and privacy, which are at the core of any architectural decision for a health information system of any sort are also not addressed. In a future version, a provision to support layering new systems on top of foundational ones, to identify and categorize the technology choices already in place, and to understand the information security – and data privacy – requirements will make for a much stronger implementation.
Another example is the Digital Health Atlas which provides a global registry of digital health projects. Here too, there is no obvious provision for, nor classification of, core infrastructure projects related to digital health. Ultimately, the way projects are currently classified, funded and delivered often puts their engineering teams in a position of doing the IT equivalent of having to dig under a foundation to put drainage in for a building, when simply having provisioned for drainage at the outset, before pouring the foundation, would have been easier, more cost effective and yielded better results.
One of the more recent benefits of DHIS2 is offering the potential to store both aggregate and disaggregate data (via the DHIS2 ‘tracker’ module) together in a single system. Previously, different systems would have to be installed and maintained separately for each purpose. The new challenge arises however, in ensuring an appropriate model for security and access control, especially when platforms are built as repositories for patient-level records. We have frequently encountered implementations where both patient-level information and aggregate data for monitoring and evaluation dashboards are stored in the same system and on the same machine with inadequate consideration of data protections, privacy and security.
There is a need to separate conceptually – in each digital health solution design – the business intelligence (for monitoring and evaluation, and reporting) functions which operate at the aggregate data level from patient-level information collection and management. The ability to architect one system to provide both patient-level data collection and aggregate reports for decision making is an efficient model to promote as it avoids duplication of hardware, software and data-entry. Yet, it also requires the attention of professional IT expertise to carefully address architecture, including for well adapted security models.
Governance that determines and ensures appropriate access to different types of health information by different actors at different levels is essential, and the systems must then be architected to align with the applicable safeguarded structures. There is no reason for any non-clinical individual to ever have access to patient-specific information, and there are technological solutions to ensure this segregation of access is strictly enforced. However, such solutions require careful consideration and architecture from the outset, to ensure they are aligned with the specific needs of the implementation in question. Currently, no framework exists to guide and ensure this separation of functions in digital health solution implementations.
The final challenge to be considered is around the different cultures of collaboration. There is a mirror in the digital health community of what is going on globally following the “information revolution”. The use of information for decision-making, the increasing ability to tap into bigger-data, and the ability for transparency about service delivery all the way to the patient (as well as increased use of social media and the resulting “fake news” movement) implies a complete shift in traditional power structures. Ismail, Malone and van Geest take a deep dive into this massive transformation and the pressures it puts on organizations and their structures in their 2014 book, Exponential Organizations. (Ismail et al, 2014)
The practical reality is that through the course of human history, knowledge and information have frequently represented a means to achieve and preserve power. There is a rich body of knowledge regarding the cultural aspects driving information use, sharing and power dynamics; one example is Hofstede’s Cultures and Organizations: software of the mind [8]. It is important to recognize that the drive to collaborate, to share, to build on what already exists, is not necessarily aligned with the prevailing cultures and incentive structures in health systems management.
Yet the value of digital health solutions lies in the very ability to provide online collaboration tools and transparent access to real-time (aggregate) information. This allows everyone from policy-makers to clinicians to take informed action in all areas, including service delivery, supply-chain, logistics and human resources. Using data for evidence-informed action is at the heart of ultimately ensuring universal access and health for all. This level of collaboration and transparency may, however, run counter-current to traditional power structures, and care must be taken to respect the cultural sensitivities and nuances around decision making and authority. The presence of technology in and of itself, no matter how robust, will not result in collaboration. It is through supporting organizations to adopt change and providing demonstrable benefits to each actor that these tools ultimately take root and can be used to their fullest capacity.
One example of how systematic architectural and engineering approaches has transformed digital health is DHIS2. The growth curve over the last twelve years shows how DHIS2 in particularly has been brought to scale in over sixty countries, impacting over 2 billion people (Figures 2 and 3).
The scale-up of DHIS2 is an example of how architecture and engineering of an application has brought it up to an international-scale software platform. There is central funding to support DHIS2 as an enterprise application, in order to manage its releases. The platform and the community around it has been built in such a way that country needs are linked to the release cycle of the application, allowing for an open, collaborative approach to developing and managing the platform. Countries that may not have had the capacity to architect, engineer or maintain such an application on their own are benefiting from a system and community that has a global footprint. The University of Oslo, which is the custodian and steward of the DHIS2 application, has a software engineering department focused specifically on this public health application, with central funding dedicated to its management and development, aggregating needs that cut across specific countries or programmes. The economies of scale follow naturally from this central investment. PEPFAR itself has adopted DHIS2, recognizing broad acceptance of this platform and the economies of scale.
That said, we still note that while DHIS2 has been well architected, engineered and operated as an application, the same discipline is needed to design, manage – and secure – each country’s infrastructure on which DHIS2 runs. However, we may learn from the approach to DHIS2 in order to consider additionally how to address the challenges at the infrastructure management level for its deployment and for that other, related or interoperable, digital health solutions.
DHIS2 offers a ubiquitous solution for health management, collecting and aggregating defined health management indicators that can be used for the planning and management of health services. DHIS2 is often the first starting place for countries seeking to establish a digital solution for managing and supporting national health systems and services.
The next step is typically a series of investments from donors and partners who establish health-area-specific applications. These may include HIV, TB and/or maternal health registries, community health worker mobile applications, sporadic health record implementations, and so forth.
These investments often create a chaotic space. Country stakeholders are incentivized to take these investments and implementations – as any help is better than no help, but they rarely start with the digital health leadership positions, capacities and governance structures that allow them to plan and manage these investments as part of a comprehensive whole. This, and poor historical behavior on the part of investors and implementers have led to a highly fragmented and uncoordinated landscape in countries, frequently inhibiting rather than adding to a comprehensive and well planned national digital health ecosystem.
The now widely recognized Uganda Measles Map highlights the fragmented digital health investments in Uganda circa 2011 – many of which had not engaged or been registered with the Uganda Ministry of Health. This survey ultimately led to a moratorium by the Ministry on new eHealth pilots.
The challenges to governance of national digital health implementations are evident, and the resultant lack of national ownership inhibits the ultimate uptake and sustainability of these investments. Even more concerning is the burden on national stakeholders of supporting the convergence of any of these fragmented investments that do sustain into a rationalized and well-architected whole. It is critical for the investments that can afford a broader vision beyond their specific health area to imagine an architecture that will foster interoperability and convergence rather than silos.
One example of a project that has taken this broader approach is the Bill and Melinda Gates Better Immunization Data (BID) Initiative led by PATH. While the emphasis for BID was the development of an immunization registry to track and support immunization services, the system was architected and engineered to take advantage of existing information resources in the country and create the opportunity for existing or future investments to interoperate with and build on the BID platform.
When BID began investing in development and deployment of the Tanzania Immunization Registry (TImR), it would have been easy to focus on TImR alone. Instead, in close collaboration with national stakeholders and other investors in Tanzania systems, BID identified other critical systems in the immunization information system value-chain. Systems such as the national DHIS2 implementation, a national Health Facility Registry, RapidPro - a national mobile SMS communications platform, and the national Vaccine Information Management System were identified as important component systems that could support an immunization registry.
BID worked with these partners and stakeholders to architect a platform, and invested in an interoperability layer and a client registry in addition to the TImR system. The Initiative then invested in connecting the component systems through the interoperability layer, fostering not only the exchange of data essential for immunization, but also creating reusable components and architectures for other connections and use cases as well. Ultimately BID is now moving to scale in Tanzania under Government of Tanzania leadership, with the government planning to eliminate redundant paper registers and all of the associated printing and shipment costs in favor of the BID platform.
BID investment in the Zambia Electronic Immunization Register (ZEIR) in Zambia as well follows a similar architected approach, connecting an ecosystem of established and proven global goods into a cohesive, extensible, and scalable whole.
This architected approach relies not on a single siloed investment, but leverages many investments across the national digital health ecosystem creating a resilient model not dependent on any single investor or implementer. When combined with appropriate investments in national digital health leadership, governance and technical capacity, these architected approaches create the greatest opportunity for system resilience, national ownership, sustainability and scale.
Having taken note of several challenges, as well as some examples and opportunities for the way forward, we can look to the global community for collaboration towards solutions. Indeed, at the global level, unprecedented collaboration has already taken shape and major actors work closely together, for example through the Health Data Collaborative and via new co-financing models such as that of Digital Square. This collaboration leads to more rational approaches, more efficient use of resources and ultimately to better health information and improved health outcomes. There is also a breakthrough in that many actors with engineering or equivalent backgrounds are operating in the digital health sphere and cross-pollination between these disciplines is now beginning to take effect. It is through this ongoing and expanded collaboration that the above challenges will ultimately be met.
We know from other sectors that taking a holistic approach yields more robust and more cost-effective long-term solutions, as exemplified by the BID Initiative investments in Tanzania and Zambia, which both include appropriate spending on architecture, design and engineering. It is our intention, by highlighting some of the challenges we have encountered, and some of the good practices noted as well, to open a dialogue around this need in order for the digital health community to come together around recommendations and solutions.
We believe that two main approaches would make a significant difference in addressing these issues. First, investment strategies should be adapted to include budget lines in digital health for developing the overall architecture, to bring on board the ongoing systems engineering skills, and for the training required to keep these skills current. Indeed, now that there has been a growing awareness and donor alignment on efforts to spend coherently on digital health, through the newly launched Donor Alignment Principles for Digital Health Investment following the earlier Principles of Digital Development, it is an excellent moment to ensure even greater relevance of spending on digital health capacity building, without simply burying technology into an IT line under another vertical health activity.
The second approach would be to systematically fold a greater emphasis on engineering into the already strong collaboration within the wider digital health community, including in major international organizations. Such an approach will lessen gaps in understanding and drive towards stronger, more collaborative interdisciplinary approaches that will yield more cost-effective, and robust solutions throughout the sector.
The challenges we identified are frequently reflected in what amount to hidden, inflated costs to the health information system. For example, we have seen, on the technology side, what has already been recognized as wastage in duplicative efforts by investing only in vertical funding channels. In one instance, in one location, in a single room, we saw three computers: one running DHIS2 for the health information system, one running the TB monitoring platform, and the third running a separate HIV tracking system. There were three contracts with three different solutions providers to manage and maintain the machines, platforms and software applications. The inefficiency of this scenario should be fairly obvious; it becomes multiplied several-fold when data is required to be drawn from all three systems and presented together – i.e. when interoperability is required, and a fourth platform is put in place to draw on the three that were never designed from the outset to connect together seamlessly.
A second issue is that core engineering is perhaps not very exciting or glamourous as a budget line. It is often assumed to be a “solved problem” or is otherwise ignored. We also note confounding factors such as the ubiquity of mobile phone penetration which we would argue is often misperceived as a surrogate for a given location’s Information and Communications Technology (ICT) capacity and sophistication. The reality couldn’t be further from the truth. While all kinds of new innovations attempt to catch the hearts and minds of the donor community – drones to deliver medicines in remote locations, mobile applications to rapidly report and confirm stock-outs, or situation rooms to monitor HIV treatment in the offices of senior officials – the practical reality is that core systems architecture and engineering is the foundation upon which all data systems must run. Without investing in the foundation, very few of the digital health solutions will attain their highest potential impact, and even fewer of the true innovations will easily or cost-effectively be brought to scale, nationally, regionally or globally.
Based on our experience and implementations, we would propose that digital health requires its own budget line and funding allocation, at the same level as putting in place a comprehensive vaccination programme or developing and implementing a national plan on HIV. This allocation should follow a larger national digital health investment roadmap, such as the one developed by the Tanzania government with the support of the BMGF Data Use Partnership, which in this case provided a framework that was aligned with BID Initiative described above. Such a costed investment roadmap is an essential national digital health governance tool, supporting the governments to coordinate their own budgets and different donor investments into a coordinated national digital health ecosystem. Priority investments into digital health governance, human capacity, and enterprise architecture reinforce other recommendations of this article.
In order to optimize investments while securing greater interoperability and improved outcomes, we would put forward that funding proposals should not be accepted if the engineering components and related human resources requirements are not included in a digital health grant application. Such an approach would of course demand qualified people to evaluate the engineering components of the proposals, and that those making the proposal have the requisite knowledge, assistance and/or guidelines.
Within the digital health budget line and associated funding proposals, we would suggest that the following should be included:
Including these types of considerations into the budgets for digital health would pave the way significantly for addressing the challenges noted previously around the limitations of the procurement cycles and the under-resourcing of staff in all areas of systems engineering.
Beyond a holistic approach to funding, collaboration further supports the breaking down of even long-standing silos between the public health community and the implementation and operations teams behind digital health solutions. We would suggest that, following some leading examples of the positive effects of strong collaboration between engineering and public health in developing digital health ecosystems, there is a need to work together to develop further guidelines, reference examples, case studies and standards, adapted for LMIC contexts, so that digital health solutions are appropriately architectured, engineered and implemented. Such collaboration also supports strong and transparent governance.
One notable example of regional collaboration has been paved by AeHIN, with its leadership in the recent conference on Interoperable Digital Health for Universal Health Coverage conference. Through its GAPS framework (Figure 8), AeHIN has continued to provide a structured approach that drives capacity building for digital health. The GAPS areas directly address many of the challenges that we have identified. It is through just such collaboration and collaborative networks involving public health specialists and engineers together that great strides may be made towards more impactful, coherent, and sustainable digital health solutions.
Other significant partners such as GIZ have also taken a holistic approach in their support to national digital health strategy and implementation. One example is in Bangladesh, where GIZ noted the following about the collaborative process between the information systems specialists and the public health staff, and the investment in capacity building for engineering skills, allowing a production system with access from and queries by thousands of people:
“Technical advisors from GIZ supported the customisation of DHIS2 and OpenMRS for use in public health facilities in Bangladesh and worked with the MIS unit to train health personnel at all levels to submit routine data electronically, via DHIS2. Through on-the-job capacity building, technical staff at the MIS unit have learned to manage the servers, maintain and update the software, and address hardware and software queries from thousands of users.” (Birdsall, 2014)
Similarly, regarding digital health work in Nepal, GIZ noted the following “key learnings” [13]:
“Analysis of key learnings from bilateral cooperation on digital health in Nepal has highlighted the following as drivers of progress and national ownership in digital health development:
An overarching vision for a digital health ecosystem. Such a vision is essential for developing a national digital health strategy and guiding its implementation. In Nepal, the introduction of the OpenHIE framework has helped to articulate this vision, which is set out in key policy and strategy documents such as Nepal’s National e-Health Strategy (2017).
The development of digital capacities, knowledge and understanding among key health sector stakeholders. A combination of high-level and timely advocacy, strategic and technical advice, mentoring and coaching, and the facilitation of peer-to-peer learning have proved effective at enabling government stakeholders to take the lead in Nepal’s digital health development, becoming strong advocates for the potential of digitalisation to empower decision-makers and to drive health reform.
Taking a systems approach to digitalisation in the health sector. The Nepali-German Health Programme works with partners to identify health system challenges that can be addressed through the intelligent adoption of open-source digital technologies, and supports their introduction and scale-up. The systems approach is iterative and places a high value on reflection, ensuring learning is continually incorporated into strategies and plans.”
Not only do these lessons reflect many of our own implementation experiences and observations, they also demonstrate a willingness to be open and share such findings across the community. This kind of collaborative, inclusive, learning-driven approach is key to ensuring strong digital health solutions in all LMIC settings.
In the spirit of collaboration, the authors welcome feedback and engagement around the theme presented in this article: that engineering and public health skills must coexist in order to develop the best possible, most cost-optimized digital health ecosystem(s). Digital transformation has affected all sectors, and with the recent WHA resolution on Digital Health (WHA 71.1), an even greater emphasis must be put towards the architecture, engineering and related disciplines that ensure the quality, longevity and scalability of the solutions delivered within the health sector.
Several challenges have been presented, including skills gaps, misalignment of procurement cycles, gaps in digital health taxonomies, insufficient focus on information security and required shifts in power structures towards greater collaboration. We have also noted many recent success stories that pave the way forward towards addressing these issues. In essence, we have found that a more holistic approach is needed, both by implementing adapted funding structures for digital health ecosystems that include governance, architecture and engineering as core elements, and by building on the many examples of genuine, successful national, regional and global collaboration in the digital health community.
Many of the challenges, fundamentally, should be viewed as growing pains in a maturing field. With a few small exceptions, over the last ten years, the relative underinvestment in digital solutions for low resource environments has stifled or limited:
■ the engagement of robust and experienced enterprise architecture and engineering teams;
■ the development of sustained capacity building and certification programs in engineering and architecture positions and skills;
■ effective communication and collaboration between siloed digital health investments to ensure appropriately coordinated (and interoperable) approaches.
In effect, digital health is a maturing market, growing beyond its earliest stages. As a community, we need to work collaboratively to steward it to the next level, where it will have a greater transformative impact on people’s lives. Digital health also represents a growing market, with an economic life cycle that is one of abundance – there is no scarcity in this area that would require protections over frameworks, solutions or implementations, and for this reason, collaborative approaches are best suited to the tasks at hand. We are seeing an increasing number of actors taking forward collaborative work, with positive effects.
The examples we have cited highlight what is possible when the appropriate levels of investment, along with the appropriate prioritization of these important professional capacities are brought to bear on national health priorities and goals. The examples of other industries’ progress in digital transformation, and the resultant gains, as well as the growing collaboration within the digital health sector should excite global health professionals, and encourage ever increasing collaboration between national stakeholders and the global health and digital professions. The health and well-being of millions rely on these investments, and as a global community, the responsibility for these lives exhort us to address these challenges with the very best skills and capacities we can bring to bear.
eSHIFT Partner Network / HISP Geneva
The eSHIFT Partner Network is a Swiss-headquartered not-for-profit association established in 2012 to support health informatics development and innovation, to help great ideas scale into the national health systems of low and middle income countries. As a strategic digital health organization focused on engineering scalable health informatics systems, eSHIFT also hosts HISP Geneva, the Swiss node of the Health Information Strengthening Programme, which is the network of global partners supporting DHIS2 and improvement of health information systems in low and middle income countries. In providing technical assistance at both global and national levels, especially in fragile settings, it has become readily apparent to us that while the term “innovation” draws significant attention, core mature disciplines including architecture, engineering and operational support are often overlooked (and underfunded) in the efforts to bring good ideas and successful pilots to scale.
