How the WHO Classifies Digital Health, and Why a Shared Vocabulary Matters

The World Health Organization sorts digital health tools by a plain question: whom does this technology serve. Rather than filing a product under its brand or its underlying software, the classification names the discrete job the tool performs and identifies who benefits from it: a client, a health worker, a system manager, or the shared data layer beneath them all. The point is not to rank products or bless them as safe. It is to give people from very different fields a common language for describing what a tool actually does.

Key points#

• The WHO scheme classifies by function and by user, not by product name or technology.
• Four groupings organize the field: clients, health workers, health system managers, and cross-cutting data services.
• The first version appeared in 2018; a second edition in 2023 widened the scope to interventions, services, and applications.
• The classification describes what a tool is for. It does not judge whether the tool works, whether it is safe, or whether a regulator treats it as a medical device.

The problem it was built to solve#

Picture a single planning meeting: a ministry official, a software engineer, a nurse, a program funder, and someone who installs systems in rural clinics. Each of them says "the app," and each means something different. One imagines a reminder that reaches patients. Another pictures a decision aid for staff. A third is thinking of a dashboard that tracks medicine stock. When the words slide around like this, the analysis slides with them. Two programs assume the other is covering a gap, so the gap stays open. Two tools that sound different turn out to do the same job, so the duplication goes unnoticed.

A taxonomy fixes the vocabulary before the argument starts. The WHO's basic unit is deliberately small: a discrete function, one specific thing the technology does toward a health goal. That framing does real work. A single application might send vaccination reminders, flag a low medicine stock, and forward records to a national registry. Those are three functions serving three users. Naming each one separately keeps the conversation honest, instead of collapsing everything into "the app."

Four groupings, sorted by who is served#

The framework's first cut is by user, and that is precisely what lets it travel across countries and disease areas.

Clients#

Clients are the people using or seeking health services, including the family members who care for them. Tools in this group reach individuals directly: appointment and medication reminders, health education and behavior-change messaging, a channel to report a symptom or lodge feedback, and access to one's own record. The test is simple. Does the tool touch the person seeking care?

Health workers#

This grouping serves the workforce delivering care. It covers decision support that surfaces the right guideline at the moment of a visit, digital checklists and protocols, registers for enrolling and following patients over time, provider-to-provider telemedicine, and training delivered on a phone or tablet. The common thread is a tool that helps a worker complete the clinical or public-health task in front of them.

Health system managers#

Managers run the machinery of care rather than deliver it hands-on. Their tools handle logistics: supply chains and stock levels, staff scheduling, facility and equipment tracking, and the financing and reporting that keep a service open. A stock-out prevented by a good supply dashboard is invisible to the patient, yet it is exactly the failure that empties a clinic shelf.

Data services#

The fourth grouping cuts across the other three. Data services are the shared plumbing: collecting, storing, exchanging, and analyzing information. Registries, data interchange between systems, geolocation, and the ability to visualize what has been gathered all sit here. It is the least visible layer and often the most consequential, because a client tool or a worker tool is only as trustworthy as the data feeding it.

Why a common language earns its keep#

Sorting by user does something subtle: it separates the health job to be done from the technology used to do it. That separation is what makes comparison fair.

Suppose two programs both promise to "improve childhood immunization with mobile technology." The sentence tells you almost nothing. Run each through the framework and the picture sharpens. One turns out to be client reminders plus a worker register; the other is a manager-facing stock tool plus a data feed to a registry. Now you can ask the right question of each. Do the reminders change whether children show up? Does the register change what the nurse records? Does the stock tool cut the days a clinic runs dry? Different functions demand different evidence, and naming the function is the first step toward picking the right yardstick.

The vocabulary also moves across borders. A classification anchored to universal functions, such as reminding, supporting a decision, managing a supply, or exchanging data, describes a tool in a large teaching hospital and one in a small district clinic using the same words. That is what lets a health ministry, a researcher, and a funder in different countries look at the same catalog and reason about coverage and overlap without first fighting over definitions.

The limits deserve equal candor. A classification tells you what a tool is meant to do. It says nothing about whether the tool works, whether it is safe, or whether it should be paid for. Those belong to evidence and to regulation, each with its own methods.

Where description hands off to regulation#

The WHO scheme is descriptive; a regulator asks a different question: is this software function a medical device, and if so, what oversight applies? The two systems complement each other, and a shared vocabulary smooths the handoff.

Take clinical decision support, which sits squarely in the health-worker grouping. In the United States, the 21st Century Cures Act laid out criteria that can place certain decision-support software outside the medical-device definition. They turn on whether the software analyzes a signal or an image, whether it rests on recognized medical information, whether it advises a professional rather than a patient, and whether that professional can review the basis for a recommendation for themselves rather than simply defer to it. Other regulators, through frameworks for software as a medical device and for real-world evidence, pose their own versions of the same underlying questions. None of that displaces the WHO classification. It builds on the same instinct: describe the function precisely, then decide how much scrutiny it warrants.

If you are weighing a digital health tool, the order of operations matters. Name the function and the user with the WHO vocabulary. Then ask what evidence would show it works, and which regulatory category it falls into. Getting the description right first is what makes the harder questions answerable.