Series: Digital Health Platform — Handbook
World Health Organization (WHO)
The International Telecommunication Union (ITU)
This is an excerpt of the report “Digital health platform handbook: building a digital information infrastructure (infostructure) for health — WHO — ITU, 2020), focusing on “Section 2 — Digital Health Platform Overview”.
Joaquim Cardoso MSc
Digital Health and AI Institute
Digital Health Platform (DHP) and Artificial Intelligence (AI)
March 29, 2022
Table of Contents (TOC)
2.1 What is a DHP?
2.2 Why is a DHP needed?
2.3 What are the benefits of implementing a DHP?
2.1 What is a DHP?
A digital health platform is a common digital health information infrastructure (infostructure) on which digital health applications are built to support consistent and efficient healthcare delivery.
The infostructure comprises an integrated set of common and reusable components that support a diverse set of digital health applications.
The components consist of software and shared information resources to support integration, data definitions, and messaging standards for interoperability (see Figure 1).
Figure 1: How a DHP interacts with external applications and users
The external digital health applications can be software programs, digital tools, or information systems such as EHRs, supply chain systems, insurance systems, and patient-engagement apps.
By supporting interoperability, the underlying infostructure ties different components and external applications together into a streamlined and cohesive whole.
The DHP allows one digital health application or system to work with other applications and systems, — helping these software share health information and data about patients, health workers, health systems, and even commodities and equipment, such as medical devices and pharmaceuticals.
As a result, other clinic departments, such as radiology or the laboratory, gain access to patient data that may have previously been available only at the admitting desk.
Moreover, relevant patient or health commodity information can be shared with health system entities outside the clinic and throughout the organization served by the DHP, including regulators, pharmacies, insurers and funders, suppliers, referral clinics, and health ministries.
Although facilitating the exchange of health information is a key purpose of a DHP, many DHPs also have broader goals.
For example, a DHP can support, encourage, and enforce best-practice workflows across multiple external applications. So if WHO issues new guidelines for an antiretroviral regimen, workflow functionality built into the DHP can alert both the clinician and the pharmacist serving an HIV-positive patient. The alert pops up automatically once health workers input the specific treatment regimen into the different external applications that the clinician and pharmacist use.
How does the DHP work?
The DHP usually operates behind the scenes with the external digital health applications and systems that people use rather than directly with users.
To understand this, a distinction is made between digital health software that are external to the DHP and DHP components, the software and digital tools inside the DHP.
A user such as a lab technician or a clinician interacts with an external application or system, not with the internal DHP components. Instead, these components are used by the external digital health applications and systems. Therefore, the DHP remains hidden from the user (see Figure 1).
In this way, the DHP functions like the backstage staff at a theatre performance; while the audience views the actors on stage, the actors rely on stage managers, prop masters, and others to make the performance run smoothly and spectacularly.
A DHP component provides individual functionality internal to the DHP, either a software service like authentication or a shared information resource like a health facility registry.
These components are core technology services that are typically required by all digital health applications implemented throughout the organization or sector that the DHP serves.
These components allow information to be created, accessed, stored, and shared by the external applications and systems.
The following are examples of these core services:
· authentication services
· registry services
· terminology services and reference data
· workflow support services.
External digital health applications and systems link to and share these components on the DHP, without needing to integrate directly with one another.
The external digital health applications and systems interact with the DHP components through published standards-based interfaces, which can be application programming interfaces [APIs] and web services.
External software interacting with the DHP through one of these interfaces knows that it must communicate in a predefined way or follow predefined steps to carry out a specific process through the DHP. The application or system will follow this interaction without necessarily knowing the technical details of how the DHP processes its communication with the application.
Is there only one type of DHP, or are there many variations?
The DHP can exist in many forms.
· Some platforms more tightly integrate services, tools, and systems into common workflows.
· Others, however, comprise a loose federation of external systems, linked via DHP components, such as only mediation and common base data standards.
Case studies throughout the handbook and in the Annex describe how countries have implemented systems similar to a DHP. These examples range from sophisticated, mature platforms to simple platforms that are only starting to emerge.
For example, Canada implemented the Electronic Health Record Solution [EHRS] to enable health workers to exchange patient information across the country. This mature platform operates under the principle of storing data in a common place.
Individual software applications at point-of-service [PoS] delivery put a copy of the information they capture about a patient in a set of repositories that are managed as part of the infostructure, without the applications having to interact or integrate with one other (see Appendix A: ‘Canada case study’ for more information).
In Liberia, the Ministry of Health [MoH] implemented mHero to connect its human resource information system [HRIS] with the Short Message Service [SMS] platform RapidPro so that messages could be exchanged directly with health workers during the Ebola outbreak in 2014.
Although mHero is early in its development, the MoH is looking to expand it to interoperate with other systems and applications (see Appendix A: ‘Liberia case study’ for more information).
How does a DHP change over time?
The DHP is expected to evolve and mature.
Each DHP begins with the core set of components necessary to initially support the digital health applications or systems you wish to integrate via the DHP at first.
These initial components may be very basic, but they will become more sophisticated as the digital health applications and systems that use the platform increase in number or complexity, or as the DHP supports more health services and programmes.
To help you define a roadmap and overall benchmarks for DHP maturation, DHP maturity models are introduced in Section 6: ‘DHP Implementation’.
How does the DHP connect with other digital platforms such as e-government?
The DHP usually does not exist in isolation within a country. Public sectors other than health care also use ICTs to support the delivery of social and economic services or e-government initiatives.
These initiatives may be in the planning stages or already under way in many countries.
Estonia: Building off existing architecture to launch a new e-health platform
In 2005, the Estonian Ministry of Social Affairs launched a new e-health platform to create a unified national health information system [HIS].
This system linked public and private medical records, gave patients access to their records, and connected to other public information systems and registries.
The project, funded by the European Union and the Estonian government, sought to increase efficiency in the health system, make time-critical information accessible for clinicians, and develop more patient-friendly healthcare services.
Four e-health technologies were phased in: EHRs, digital images, digital registration, and digital prescriptions.
Estonia built on existing public information technology infrastructure and common registries in use to create an architecture for this new platform.
The ministry built interoperability and security components to support key business processes involved in the four e-health technologies, including data entry, storage, registration, search, notification, and presentation.
Estonia also leveraged its previous experience implementing many cross-institutional digital integrations, including e-banking, e-taxation, and e-school, among others.
Estonia’s use of unique identifiers to create digital identities for all residents benefited the project as well.
To help integrate systems and institutionalize the DHP, the DHP can — and should — leverage some of the technologies provided by e-government initiatives.
For example, e-government systems may provide core functionality that the DHP requires, such as unique identifiers for citizens that can be used to identify patients as well as individual health workers.
Elements from other systems may be repurposed, such as enrolment mechanisms for registering citizens with e-government programs.
DHP implementers may be able to take advantage of hardware and software vendors or telecommunication networks already in place for e-government initiatives.
2.2 Why is a DHP needed?
In the past decade, the public health sector has seen a tremendous increase in the use of digital health, the application of ICT to public health and care service delivery through data, images, and other forms of digital information.
Digital health information systems can be found throughout a country’s health infrastructure in the form of web-based services, mobile devices, or more conventional software applications and systems.
Digital health systems can help manage and improve the quality of care in a broad range of settings, from community clinics to long-term care facilities.
These systems support essential public health functions, such as gathering surveillance data during disease outbreaks, serving as repositories for vital statistics and population health data, and tracking service delivery data to aid resource and health commodity planning.
Digital health also helps health workers follow the best-practice guidelines and algorithms established for delivering high-quality care.
In addition to these service delivery functions, digital health can support essential operations in every health system, namely administering finances, managing and developing human resources, and procuring and maintaining commodities and equipment.
Digital health systems can also support the management of payments and insurance, an important method for helping decrease administrative charges by providers and the risk of fraud FIGURE
For the individual user, mobile computing technologies, such as cell phones, tablets, and personal health devices [PHDs], have spawned the rapid growth of specific-purpose software applications [‘apps’] that provide or track health information.
With these apps, patients receive messages about health education and reminders of appointments and medication schedules, clinicians engage in telemedicine, and users monitor health indicators, such as blood pressure and exercise data.
These health apps are moving the point of care out of the doctor’s office and to the patients themselves.
With the adoption of these technologies offered by digital health systems, a tremendous volume of digitized information is produced.
In principle, such data can be made available, searched, and analysed to support informed decision-making at all levels.
Unfortunately, easy access to the data is constrained by the design of many existing systems, resulting in islands of isolated information that have yet to generate efficiency and improve health outcomes as hoped.
Current infrastructure challenges in implementing digital health
Siloed digital health systems have emerged because most digital health implementation projects occurred independently.
Different information systems have been deployed within the same country or even within hospitals under the same umbrella organization.
In many low-resource settings, philanthropic organizations have funded vertical programmes that implemented one-off information systems to solve a single problem or to support a specific health area such as human immunodeficiency virus [HIV] prevention, care, and treatment.
Many of these systems were not designed based on an underlying architecture that ties different components together into a streamlined and cohesive whole.
This missing architecture resulted in the lack of interoperability amongst information systems, as well as devices.
Interoperability is the ability of systems, applications, and devices to communicate ‘in an unambiguous and predictable manner to exchange data accurately, effectively, and consistently; and to understand and use the information that is exchanged’.
Instead of following this principle, many of the deployed applications and systems use proprietary software and do not apply validated standards. This poor practice prevents integration and stifles expansion to other systems and technologies.
Even more recently, when open standards have been developed to solve this problem, these standards are not being adopted or consistently used.
Because digital health implementation projects occurred independently of one another in many countries, they are not aware of other applications or systems that provide or need the same data.
These software were also not designed to communicate and share information with one another.
Siloed applications and systems have generated the following problems:
· Poor data management
· Burden on health workers and administrators:
· Absence of system-wide ICT impacts
· Wastage of digital health resources
· Constraints to innovation
· Distraction from building national systems and infrastructure:
· Poor data management: Access to the large amount and varieties of valuable digital information that has been captured is often limited to the application or system that directly captured it. Since such applications and systems do not refer to people, places, things, or concepts in a standardized manner, data sharing and consolidation is difficult to do. As a result, broader use of this information is hindered. To add to the problem, information must still be input manually into multiple applications in some countries. Lack of consistency in data entry and coding decreases data quality and creates opportunity for errors. Such problems can cause health workers and administrators to make poor decisions, compromising public health and patient safety.
· Burden on health workers and administrators: Requiring health workers and administrators to use multiple, unconnected digital health applications adds unnecessary burdens to their work. For example, a health worker may have to log in to multiple applications or systems with different access methods and user identities, even while doing work that is essentially interrelated. This duplicated effort creates confusion, increases errors in data entry, and takes the health worker away from providing quality services to patients.
· Absence of system-wide ICT impacts: The implementation of digital health initiatives do not often yield positive results because of funding requirements or the complexity of the problems being addressed. In some cases, ICT investments are mandated to address just one problem in an information system, even though multiple inefficiencies and gaps exist. If the problem is one part of a multifaceted issue or a multistep process, the system as a whole will not see the positive outcomes of the initial solution. Such practices result in lost opportunities for leveraging ICTs to improve system-wide workflows.
· Wastage of digital health resources: Public funds, including government resources and grants from philanthropic or aid organizations, are often used to pay for different digital health projects with overlapping, yet incompatible, functionalities. Multiple projects have repeatedly defined software requirements for the same set of functionality that is common across contexts instead of pooling resources and working with a shared core set of technologies. These vertical projects often aim to save money by focusing on just one aspect of the information system. However, high legacy costs ensue when systems need to be integrated, requiring more monies to redesign and re-engineer the technologies. In addition to wasting public resources, these vertical projects often duplicate time and effort.
· Constraints to innovation: Private-sector and non-government software developers primarily wish to create digital health innovations. However, because of the siloed design of current infrastructure in many countries, developers often must devote time and resources to re-creating basic code and technologies that are common to multiple digital health applications. This work slows their efforts to truly innovate with their applications and systems — a problem that hinders progress in digital health.
· Distraction from building national systems and infrastructure: Focusing on the creation of standalone applications inhibits the development and deployment of national systems. This problem is made worse by the amount of resources and effort required to maintain many incompatible information systems. This problem undermines the government’s ability to focus on the core functions of health service delivery.
2.3 What are the benefits of implementing a DHP?
Implementing a DHP is a key way to facilitate standards and interoperability.
A DHP also enhances and accelerates the development of digital health services and applications as part of a wider national e-health strategy.
How does the DHP benefit information technology administrators in health organizations and software developers who create external applications and systems for health workers and consumers?
The DHP simplifies information exchange within the health sector. The platform allows a user of an external application or system, such as a health consumer using an app on a mobile device, to access information gathered by other digital health software without requiring those tools to integrate directly with one another, or even to be aware of one another.
By providing a foundation of common components to digital health applications and systems, the DHP accelerates the development of new software as well as the rollout of improvements to existing software. Software developers produce more efficiently because their applications and systems only need to know how to connect to and interact with the DHP components as part of a workflow.
Developers can also make their external end-user applications and systems simpler, or ‘light’, because they do not need to build the common complex processes embedded in the DHP components, which are considered ‘heavy’.
This benefit frees developers to focus on creating easy-to-use and efficient apps for health consumers, health workers, and administrators.
Developers can also ensure that their software gathers information that is consistent, understandable, and accessible to other healthcare programmes and services.
What benefits does the health sector gain from DHP implementation?
A DHP is expected to accelerate innovation in integrated and interoperable digital health solutions, enabling the health sector to achieve its health and care goals in a more predictable, efficient, and cost-effective manner — and with reduced risk.
To this end, a well-designed DHP supports the wider health sector in improving the following:
· overall quality and continuity of care
· adherence to clinical guidelines and best practices
· efficiency and affordability of services and health commodities, by reducing duplication of effort and ensuring effective use of time and resources
· health-financing models and processes
· regulation, oversight, and patient safety resulting from increased availability of performance data and reductions in errors
· health policy-making and resource allocation based on better quality data.
Canada: Developing the Electronic Health Record Solution [EHRS] Blueprint
Canada Health Infoway conceptualized an architecture for implementing largescale, national EHR solutions, resulting in an architecture called the EHRS Blueprint.
The Blueprint is an early example of a DHP. The Blueprint offers an information system architecture, describing how each PoS application can connect to the shared infrastructure platform, or infostructure, through an interoperability layer called a Health Information Access Layer.
Using agreed-upon standards facilitates these connections and interoperability.
The design approach taken is for each Canadian jurisdiction (province or territory) to implement an operational information infostructure.
This infostructure allows a large number and variety of PoS software systems to either capture or access clinical and administrative information about citizens and the health services provided to them.
The architecture does not require individual software applications operating at the PoS delivery to interact or be integrated with one another. Instead, each software application saves a copy of the information it captures about a patient into a set of repositories that the infostructure manages — a key principle of the EHRS architecture.
The EHRS Blueprint has been used as a foundation for Infoway’s programmatic approach to funding DHPs across the country. Adherence to the Blueprint concepts and approaches determines funding eligibility for e-health projects.
Today, Blueprint based information systems implemented by the health ministry support new digital health initiatives across the country.]
Source: Canada Health Infoway, Inc. (2006). Electronic Health Record Solution Blueprint: an interoperable EHR framework.
See original publication
Digital health platform handbook: building a digital information infrastructure (infostructure) for health. Geneva: World Health Organization and International Telecommunication Union, 2020. Licence: CC BY-NC-SA 3.0 IGO.