What APIs Actually Do in a Digital Health Product

APIs are behind many of the digital health experiences we use every day. But what exactly are they doing, and why should health professionals, product managers and digital health practitioners understand them?

In the first article in this series, What FinTech API Experience Can Teach Us About HealthTech, I shared some lessons I have learnt from working with APIs in financial technology and why similar thinking matters as we build connected digital health systems.

But there is a more basic question worth answering:

What does an API actually do inside a digital health product?

If you are coming from public health, medicine, nursing, research or health administration, the word API can sound unnecessarily technical.

It is often discussed as though it belongs exclusively to software developers.

It doesn’t.

You may never write the code that connects an API, but if you work in digital health, understanding what APIs do can completely change the way you think about digital products, health data and interoperability.

Let’s make it practical.

Start With a Simple Health Scenario

Imagine that you use a mobile application that allows you to book a laboratory test.

Inside the app, you:

1. select the laboratory test you need;
2. choose a nearby laboratory;
3. make a booking;
4. receive confirmation;
5. complete the test;
6. later see the result inside the same application.

From the user’s perspective, everything appears to happen inside one application.

But behind that simple experience, several different systems may be involved.

The mobile app may belong to one company.

The laboratory may use an entirely different Laboratory Information System.

Payments may be handled by another provider.

Patient records may sit within a hospital’s Electronic Medical Record system.

Notifications may be delivered using another service entirely.

Yet somehow, these systems need to exchange information and trigger actions.

This is where APIs come in.

An API Is Essentially a Controlled Way for Systems to Communicate

API stands for Application Programming Interface.

In simple terms, an API defines how one software system can request information or an action from another system.

WHO’s digital transformation guidance describes APIs as interfaces that allow one system or application to access the features or data of another, while defining both the interaction and how information should be structured.

Think about our laboratory example.

The health app might ask:

“What laboratory locations are available near this patient?”

Another system responds with a list.

The app might then say:

“Create a laboratory booking for this patient at 10:00 AM.”

The laboratory system processes the request and returns:

“Booking created successfully. Reference: LAB23458.”

Later, the app might ask:

“Is the result for LAB23458 available?”

The laboratory system could respond:

“Yes. Result completed.”

That request-and-response relationship is at the heart of how many APIs work.

The user doesn’t see any of these conversations.

They simply see a button, confirmation message or laboratory result on their screen.

APIs Sit Behind the Interface

One of the most important things to understand about digital products is that the screen you see is not necessarily where everything is happening.

When you click:

Book Appointment

View Result

Verify Insurance

Request Prescription

Check Eligibility

Pay

or

Connect Wearable

the application may be communicating with one or several external systems behind the scenes.

The interface is what the user sees.

The APIs help systems do the work behind it.

Consider a digital health platform that lets a patient book an appointment.

The screen might simply show:

Dr Adeyemi
Cardiology
Tuesday, 10:30 AM
[Book Appointment]

But clicking that button may trigger an API request containing information such as:

• patient identifier;
• practitioner identifier;
• clinic;
• date;
• time;
• appointment type.

The hospital system receives the request, checks availability and responds.

If successful, the patient sees:

Appointment confirmed.

A seemingly simple action on the screen has just triggered a conversation between systems.

APIs Can Retrieve Information

One common job of an API is retrieving information.

Imagine a clinician opens a patient’s profile and wants to see their recent laboratory results.

The clinical application could send a request to another system asking:

Give me this patient’s laboratory results.

If the requesting user has the appropriate permission, the system can return the allowed information.

This might include:

• test name;
• date;
• result;
• units;
• reference range;
• status.

The application then presents that information in a readable format to the clinician.

The underlying data may have come from somewhere entirely different.

APIs Can Also Send Information

The communication does not only flow in one direction.

A digital health application might need to send new information to another system.

For example, a blood-pressure monitoring application might record:

Blood pressure: 148/94 mmHg

and send the measurement to a clinical system.

A hospital discharge application could send updated information to a primary-care provider.

A community health worker application might submit household data to a central information system.

A pharmacy application could submit a medication-dispensing event.

In each case, the API defines what information can be sent, how it should be structured and what happens after it is received.

APIs Can Trigger Actions

Sometimes the API isn’t simply exchanging data.

It is asking another system to do something.

For example:

Send an appointment reminder.

Create a patient record.

Verify health-insurance eligibility.

Generate a prescription request.

Schedule an appointment.

Initiate a payment.

Register a new healthcare provider.

Notify the clinical team of an abnormal result.

This is one reason APIs are so important when designing digital products.

We are not simply connecting databases.

We are connecting workflows.

Understanding Endpoints

When people first encounter API documentation, one of the first technical words they usually see is endpoint.

An endpoint is essentially a specific address through which a particular API capability can be accessed.

For example, imagine a fictional health API containing:

GET /patients/123

That could mean:

Retrieve the patient whose identifier is 123.

Another endpoint might be:

GET /patients/123/observations

which could mean:

Retrieve clinical observations associated with this patient.

Or:

POST /appointments

which could mean:

Create a new appointment.

The exact structure differs between APIs, but the underlying concept is straightforward.

The endpoint tells the system where the request should go.

GET, POST, PUT, PATCH and DELETE

You will also commonly see terms such as:

GET

POST

PUT

PATCH

DELETE

These are HTTP methods commonly used by REST-style APIs.

You do not need to become a software developer to understand what they generally represent.

GET usually retrieves information.

POST usually submits or creates something.

PUT/PATCH generally update existing information.

DELETE can remove something where the API permits it.

So:

GET /appointments

could retrieve appointments.

While:

POST /appointments

could create one.

Understanding just this small amount already makes API documentation far less intimidating.

Then There Is the Data Itself

When systems communicate through APIs, information needs to be structured in a predictable way.

One very common format is JSON.

You might receive something that looks like this:

At first glance, this can look like programming.

But simply read it as information organised into labels and values.

Patient ID = 12345.

First name = Ada.

Appointment date = 4 November 2026.

Status = confirmed.

That is essentially what the system is communicating.

A public-health professional, digital-health product manager or implementation specialist who can look at a simple JSON response and understand what it means is already better positioned to work effectively with technical teams.

You don’t need to write the code.

But you should increasingly be able to understand the conversation.

Healthcare Makes This More Complicated

Now we arrive at one of the most important differences between building a simple consumer application and building connected digital health systems.

Imagine Hospital A represents a patient’s sex as:

M

while Hospital B uses:

Male

and another system uses:

1.

Technically, all three systems may have APIs.

They may even successfully send information to one another.

But do they understand the information in the same way?

Not necessarily.

Now imagine that one hospital calls a laboratory test:

Hb

another calls it:

Haemoglobin

and another represents it using a standard clinical code.

Or imagine one hospital identifies a patient using a hospital number while another uses a national identifier.

This is where the conversation moves beyond APIs into interoperability.

An API Does Not Automatically Mean Interoperability

This is a distinction every digital health professional should understand.

Two systems having APIs does not automatically make them interoperable.

APIs can provide the mechanism through which information moves.

Interoperability requires the systems to also agree on things such as:

• how information is structured;
• what the information means;
• how patients and organisations are identified;
• what terminology and codes are used;
• who is authorised to access the information;
• what workflows should happen after information is exchanged;
• what organisational and governance agreements apply.

WHO identifies data interchange and interoperability as a specific digital-health capability involving APIs, messaging standards and interoperability platforms.

This is where standards such as HL7 FHIR become important.

Where FHIR Comes In

FHIR stands for Fast Healthcare Interoperability Resources.

It is a healthcare information-exchange standard developed by HL7.

FHIR represents health information through reusable structures known as resources.

Examples include:

Patient

Observation

Encounter

Practitioner

Organization

Medication

and many others.

FHIR can use REST-style API interactions, making some of the concepts we have just discussed directly relevant to healthcare interoperability.

WHO’s SMART Guidelines, for example, use FHIR-based implementation guides to help represent clinical and operational guidance in standardised, machine-readable formats.

Imagine two different health applications.

Without agreed standards, each organisation might develop its own completely different structure for patient information.

With an agreed FHIR implementation, both systems have a common foundation for representing concepts such as a Patient or Observation.

That doesn’t eliminate every interoperability challenge.

But it gives systems a much stronger common language.

Security Matters Even More in Health

There is another important question:

Should every application be allowed to request every patient’s information?

Obviously not.

Health information is sensitive.

This means APIs need mechanisms for determining:

Who is requesting access?

and

What are they allowed to do?

This introduces concepts such as:

• authentication;
• authorisation;
• API keys;
• access tokens;
• OAuth;
• permissions;
• role-based access;
• audit logs.

If a laboratory API technically works but allows anybody on the internet to retrieve patient results, we have not built a successful integration.

We have built a serious security problem.

A good digital-health integration therefore isn’t simply:

“Can System A talk to System B?”

It is also:

“Should System A have access?”

“Who authorised it?”

“What data can it see?”

“How long should that access last?”

“Can the organisation identify who accessed the information later?”

These are product, governance and health-system questions as much as they are engineering questions.

APIs Also Create Dependencies

Suppose your digital health product relies on an external laboratory API.

What happens if that API goes offline?

What happens if the provider changes an endpoint?

What happens if the response suddenly takes 30 seconds instead of one second?

What happens if an authentication token expires?

What happens if the laboratory changes the way a particular field is represented?

What happens if duplicate patient records exist?

Integrations introduce dependencies.

This means product teams need to think about:

• error handling;
• downtime;
• retries;
• validation;
• monitoring;
• version changes;
• fallback processes;
• support ownership.

Again, APIs are not simply a developer issue.

They affect the entire product experience.

What This Means for Digital Health Professionals

If you are a doctor, nurse, pharmacist, public-health professional, researcher, programme manager or health administrator, you do not necessarily need to learn software development.

But if you want to work seriously in digital health, there is enormous value in understanding questions such as:

Where does this information come from?

Which system owns it?

How does our application retrieve it?

What happens when the user clicks this button?

Which external system does this feature depend on?

What information needs to move between the systems?

Who should have access?

Are the systems simply connected, or genuinely interoperable?

Those questions make you a much stronger contributor to a digital-health project.

The same applies to product managers.

A requirement such as:

“The clinician should be able to view external laboratory results.”

sounds simple.

But immediately, a good product team should ask:

Which laboratory?

How do we identify the patient?

Is there an API?

What information does the API return?

How do we authenticate?

Do we have the patient’s permission?

How are tests represented?

How do we handle an unavailable result?

Can the clinician distinguish preliminary from final results?

Do we store a copy of the result or retrieve it whenever requested?

That is how a feature becomes a real digital-health product requirement.

You Can Learn This Without Becoming a Developer

This is one of the reasons we created the LifeDev Digital Health Academy.

Many people working in health understand the health problem but feel lost when conversations move into APIs, JSON, interoperability, FHIR, product requirements or technical implementation.

On the other side, many technology professionals understand software but have limited exposure to how health systems, clinical workflows, health information and implementation actually work.

Digital health needs people who can help bridge that gap.

Our flagship 8-Week Digital Health Product & Implementation Programme takes you through that journey practically.

You will learn how digital health products move from a health problem to a product concept, how APIs connect systems, how health data moves, why interoperability matters, where FHIR fits, how AI is being applied in health, and what it actually takes to implement a digital solution inside a real health environment.

And we do not stop at explaining APIs with diagrams.

In the API module, learners complete a guided Postman exercise where you make an actual API request, inspect the response, identify the endpoint, HTTP method and status code, and read the returned JSON yourself.

You do not need to be a software developer.

The objective is not to turn everyone into an API engineer.

The objective is to make sure that when you sit in a digital-health meeting and someone starts talking about endpoints, integrations, JSON, authentication or FHIR, you understand what is happening and can contribute intelligently.

Explore the Digital Health Product & Implementation Programme

The Bigger Picture

APIs may sound like a technical subject.

But underneath the technology is something much more important:

information needs to move.

A patient moves between healthcare providers.

A laboratory produces a result that a clinician needs.

A community health worker collects information that a public-health programme needs.

A pharmacy needs to understand a prescription.

An insurer needs to verify eligibility.

A wearable device produces information that may support monitoring.

Different organisations and systems need to coordinate around the same person and the same health journey.

APIs are one of the mechanisms that make those connections possible.

But APIs alone are not enough.

We also need common standards, shared meaning, appropriate governance, good product design, privacy, security and workflows that actually work for the people delivering and receiving healthcare.

That is where digital health becomes much more than building an app.

It becomes the work of connecting people, information, technology and health systems.

And that is the level at which we need more professionals to understand digital health.

Continue Learning

This article is part of LifeDev Health Technologies’ APIs Behind Digital Health series.

Previous: What FinTech API Experience Can Teach Us About HealthTech

Next: FHIR Explained for Product Managers and HealthTech Founders

In the next article, we will look more closely at FHIR, why it matters in digital health, how resources such as Patient, Observation and Encounter are structured, and what product managers and HealthTech founders actually need to understand when planning integrations.

Want to move beyond reading about digital health and start understanding how these systems work in practice?

Join the LifeDev Digital Health Academy and explore the 8-Week Digital Health Product & Implementation Programme.

The programme takes you through digital health products, APIs, health data, interoperability, FHIR, AI, privacy, implementation and product management through practical lessons and exercises.

You will also complete a guided Postman exercise where you make and inspect an API request yourself, even if you are not a software developer.

Explore the Programme & Enrol

Learn the concepts. Understand the technology. Build practical experience.