What Fintech API Experience Can Teach Us About HealthTech

Questions like:

– What exactly is an API?
– How do different health systems communicate with each other?
– What does interoperability really mean?
– Do I need to know how to code before I can work in Digital Health?

There is already a full course developed around some of these areas, and some people are currently learning through it, but I thought it would also be useful to publicly break down some of these concepts in simple terms based on the questions I keep receiving.

So, over the next couple of weeks, I’ll be writing about digital health APIs from a product, public health and health-financing perspective, focusing on how connected systems can improve access, data exchange, implementation and service delivery.

I’m calling the series:

APIs Behind Digital Health

And I think a good place to start is with something I already work with regularly:

What can HealthTech learn from the way APIs are used in FinTech?

First, what exactly is an API?

API stands for Application Programming Interface.

The name sounds technical, but the idea is actually simple.

An API allows one system to communicate with another system in a structured way.

For example, imagine you use a money-transfer application.

The app you are looking at may not itself own the bank account infrastructure, identity-verification service, exchange-rate service or payment network being used behind the scenes.

Instead, the application may connect to several other services through APIs.

One API may verify your identity.

Another may provide the exchange rate.

Another may initiate the payment.

Another may confirm whether the transaction succeeded.

To you as the user, it looks like one simple application.

Behind that application, however, several systems may be communicating with each other.

The same idea applies to healthcare.

Think about a patient visiting a hospital

A hospital may use one system for patient registration.

The laboratory may use another system.

The pharmacy may have another.

An insurance company may have its own platform.

A government health programme may also have a separate reporting system.

Now imagine that none of these systems can communicate.

The patient registers at the hospital and provides the same information again at the laboratory.

The laboratory prints the result.

Someone manually enters part of the result into another system.

The pharmacy cannot automatically see the prescription.

The insurer needs another document before confirming coverage.

The hospital later has to prepare another report for a government agency.

There is technology everywhere, but the systems are still disconnected.

This is where APIs become important.

With the right architecture, APIs can help these systems exchange information securely and in a structured manner.

For example:

Instead of every organisation operating as a separate digital island, systems can begin to work together.

And this is one of the biggest lessons I think HealthTech can take from FinTech.

Lesson 1: A good digital product does not have to build everything itself

One thing working with API-driven financial products taught me very quickly is that you rarely need to build every capability from scratch.

A FinTech product may rely on specialised providers for:

• identity verification;
• banking infrastructure;
• payments;
• foreign exchange;
• compliance checks;
• virtual accounts;
• notifications; and
• transaction monitoring.

The product brings these different services together to create the experience the customer eventually sees.

HealthTech products can work in a similar way.

A digital health platform might connect with:

• hospital information systems;
• laboratories;
• pharmacies;
• insurance systems;
• appointment systems;
• medical devices;
• identity services;
• payment providers; and
• public health databases.

The important product question therefore becomes less about:

“How do we build everything?”

and more about:

“What systems already exist, and how should our product communicate with them?”

Lesson 2: Reliability matters even more than the interface

A beautiful interface is useful.

But in FinTech, if the transaction behind the interface fails, the beautiful design means very little.

The same principle applies to HealthTech.

Imagine a doctor requesting a patient’s laboratory result and the system displays an old result because an API failed silently.

Or a prescription is sent to the wrong patient record.

Or a health application receives incomplete information but displays it as complete.

These are not simply technical inconveniences.

In healthcare, they can affect clinical decisions.

That means HealthTech teams need to think seriously about things such as:

• what happens when an API fails;
• what happens when information is incomplete;
• how errors are communicated;
• whether transactions can be retried safely;
• how systems confirm that information was actually received; and
• how activities are logged for later review.

FinTech spends a lot of time thinking about these things because money is involved.

HealthTech needs the same discipline because people’s health is involved.

Lesson 3: Every action needs a clear trail

In financial systems, it is important to know what happened to a transaction.

Who initiated it?

When was it initiated?

What amount was involved?

Which account was affected?

Did it succeed?

Did it fail?

Why did it fail?

Healthcare systems need the same type of traceability.

Who accessed a patient’s information?

What information did they access?

Was anything changed?

When was it changed?

Which system provided the information?

Who authorised the action?

This becomes especially important when different organisations and platforms are exchanging sensitive health information.

Good HealthTech infrastructure should therefore think about audit logs, permissions, authentication and accountability from the beginning.

Lesson 4: Identity is a bigger problem than many people realise

In FinTech, identifying the correct customer is fundamental.

You do not want money credited to the wrong wallet or withdrawn from the wrong account.

Healthcare has a similar challenge.

If a patient visits different hospitals, laboratories or pharmacies, how do those systems know they are dealing with the same person?

What happens if one system records:

Oluwatobi Emmanuel Amonimo

another records:

Tobi Amonimo

and another records:

Amonimo Oluwatobi E.

Now add differences in phone numbers, addresses, date formats and identification numbers.

Connecting APIs is one part of interoperability.

Correctly identifying the patient across those systems is another problem entirely.

This is why digital health discussions eventually move beyond APIs into areas like data standards, patient identification, interoperability and health information architecture.

Lesson 5: Security cannot be added at the end

In financial technology, API security is taken seriously because systems are moving money and sensitive financial information.

Healthcare APIs deal with something equally sensitive: people’s health information.

A HealthTech API therefore needs to answer questions such as:

Who is requesting this information?

Are they authorised to see it?

What exactly are they allowed to see?

Has the patient provided the necessary consent?

How is the information protected while it moves between systems?

What happens if someone tries to access information they should not have?

Building the API is only one part of the job.

Building the right controls around it is just as important.

Lesson 6: APIs do not automatically mean interoperability

This is one of the most important distinctions.

Two healthcare systems may both have APIs and still struggle to communicate properly.

Why?

Because one system may describe information differently from the other.

One may call something patient_id.

Another may use member_number.

One system may represent gender one way.

Another may represent it differently.

One may record a diagnosis using one coding system while another uses something completely different.

So simply saying:

“Our platform has an API.”

does not necessarily mean:

“Our platform can work properly with other healthcare systems.”

This is where healthcare standards such as FHIR become very important.

I’ll explain FHIR separately in this series because it deserves its own discussion.

Where health financing also comes in

This is another area I find particularly interesting.

Healthcare is not only about clinical information.

Someone eventually has to pay for the service.

That may be:

• the patient;
• an insurance company;
• an employer;
• a government programme;
• a donor;
• or another financing mechanism.

Think about a simple insurance journey:

Every step involves information moving between different organisations.

APIs can help make those processes faster and more transparent.

This is where some of the infrastructure we already understand from FinTech can become useful in health financing: payments, identity, verification, transaction tracking, reconciliation and automated workflows.

Of course, healthcare has additional complexities around clinical information, privacy and patient safety, so we cannot simply copy a FinTech system and call it HealthTech.

But there is a lot we can learn from the thinking behind these systems.

The bigger point

When people hear Digital Health, it is easy to immediately think about mobile apps, telemedicine or AI.

But some of the most important work happens underneath the interface.

How does information move?

How do systems identify the same patient?

How does a laboratory send results to a hospital?

How does an insurer confirm eligibility?

How does a pharmacy receive a prescription?

How does a government health system receive reliable facility data?

How do all these systems communicate without exposing information to the wrong people?

These are infrastructure questions.

And APIs are one important part of answering them.

As public health increasingly becomes digital, I believe more public health professionals need at least a basic understanding of how these systems work.

You do not necessarily need to become a software developer.

But if you are going to design, manage, regulate, evaluate or implement digital health programmes, understanding what happens behind the screen can make a huge difference.

In the next article in APIs Behind Digital Health, I’ll break down another important question:

Why having an API does not automatically mean your health systems are interoperable.

Have a question or something to add to this series? Drop a comment under this post on LinkedIn. If you found it useful, please reshare so more people can join the conversation.

Respond to the post on LinkedIn.