If you are a software developer or integrate software for Health, this article may be of your interest.

It is not easy to offer differentiating solutions to your clients. Integrating software is often very complex and often not very rewarding.

You know, a perfect integration is one that you do not notice. But if the integration fails …

Fortunately, things are changing. Software development is beginning to be industrialized, and little by little most of us will stop developing and we will be assembling pieces of software, like someone assembling a car or an Ikea piece of furniture.

In this process, the APIs are being key. In this article we will answer the question: what APIs may be of interest to me as a software developer for Health?.

What’s the use of using APIs for my healthcare software?

 

Why an API? For several reasons, but we will highlight the following:

1. It is a guarantee, being a piece of software that works in production in many companies all over the world.
2. It drastically reduces my development time.
3. It drastically reduces my development costs, since API costs are based on pay-per-use. Depending on the number of end users that my clients have, I can adjust my costs in a coherent and optimized way. Moreover, I can design different sales strategies to assume this cost in my margin or transfer it to the final customer.

Depending on the type of software you are developing, you may be more interested in some APIs than others. We can segment the types of health software in many ways. We will start from the following 4 fields:

1. EMR, EHR, HIS software. The software used by a health center for the management of the center itself, patients, History, pharmacy, laboratory, warehouse, etc.
2. Telemedicine platforms, patients Tele monitoring, etc.
3. Software for certain medical specialties: ophthalmology, dentistry, diagnostic imaging, oncology, etc.
4. Health and Wellness Apps.

Let’s see just a few examples in each scenario.

If you develop or integrate EMR, EHR, HIS software for health

 

We will start with a Natural Language Processing API (one of the many applications of Artificial Intelligence in Health).

This type of API allows me to extract in real time standard structured information from the free text that the doctor writes during a consultation or a diagnostic report. An extraordinarily important and useful information for the management of the center and for the improvement of the healthcare practice.

Another interesting option would be an API that allows me to store the Electronic Health Record (EHR) in the cloud in a secure and standard way, in accordance with the OpenEHR standard.

This type of APIs allows me not only to save on storage and infrastructure for the management of the EHR, but also greatly boost my options for interoperability between centers and with the patient, while simplifying requirements and costs in future projects related to this topic.

We will also mention an API to support the Medical Prescription.

This type of API helps the doctor to automatically identify possible risks associated with the patient’s profile, possible medications to be prescribed, safe alternatives, etc.

My clients would also be delighted if I could facilitate the dictation of reports by voice, through a voice recognition API.

With this API, physicians who use my software will be able to perform diagnosis reports by image, or during an intervention, without touching a single key and optimizing their time.

Can you imagine the power that my software would have if I combine this API and the Natural Language Processing API so that the report was encoded in real time just as it was dictated?

I leave the idea there.

The list can be very long, but I’ll finish this section with an electronic signature API.

Patient admission, informed consent for a surgical intervention, data protection policy, etc., etc. This functionality is totally consistent with the implementation of an EHR. What is the point of using paper documents just for one signature? Electronic Health Records imply electronic signatures.

If you develop telemedicine and telemonitoring platforms

 

We will start with the most obvious: an API for the management of the medical Agenda.

When a doctor joins a Telemedicine platform, he needs a simple and agile way to maintain and publish the available slots in his/her Agenda.

Developing this functionality from scratch, today, does not make any sense. It only raises the costs of development and maintenance.

There are APIs that allow you to easily integrate solutions 100% functional and fully operational in the hands of thousands of users. The doctor who uses your platform will find this topic perfectly covered and in a completely satisfactory way.

In the field of patient telemonitoring, an huge revolution is taking place. There are APIs to monitor the patient’s data and behavior already available to integrate in your software. For example, patients with:

• Diabetes
• Cardiopathies
• Alzheimer’s
• Parkinson’s
• Elder people at home, for the remote follow-up of routines

and a long etcetera that grows every day.

This type of APIs is making the difference between the Healthcare of the past and the Healthcare of the future.

Using them in your software will allow your clients to offer health care services that were unthinkable not long ago, and surely many doctors only expect them with a high associated cost.

They will love knowing that it fits their budget like a glove in their hands.

This type of APIs usually involves the use of devices in the patient’s home. That is why more and more manufacturers of these devices are realizing that integrating their APIs into medical software is an excellent way to increase their sales, because the doctor who has the possibility of monitoring their patients will become an active prescriber of their devices (literally).

If you develop software for certain medical specialties

 

There are very advanced APIs for very specific needs in specific medical specialties. To name a few:

An ophthalmologist will find it very interesting to have software that can help in the early diagnosis of Glaucoma or in the early diagnosis of blindness.

• A cardiologist will find very useful software capable of processing an electrocardiogram and detect arrhythmias in seconds.
• An endocrinologist will value very positively having real-time alerts in the remote monitoring of the diabetic patient.
• A geriatrician will find extremely useful software that provides real-time alerts for remote monitoring of patients with Alzheimer’s and remote monitoring of patients with Parkinson’s.
• A radiologist will be pleased to know that your software is capable of identifying micro lesions in images for the early diagnosis of certain pathologies.

And the list grows and grows every day.

If you develop Health and Wellness Apps

 

If you develop software in this field, you know that you have millions of potential users around the world.

It is the perfect scenario for a model based on using advanced APIs on a pay-per-use basis. It is relatively easy to calculate the average usage per user and set a very attractive price for the App, so that I get margin on the cost of using the APIs that give the App its main value.

In this scenario I may be interested in adding to my App for the diabetic patient, an API that responds to the user with suggestions, recommendations and risks totally personalized and according to their glucose curve.

I can also be interested in developing an App that incorporates different APIs that manage alerts for different types of patients, and that the user activates the cases he/she has in his/her family. Parents, siblings, couple, children, etc.

I may also be interested in an API that shows the users of my App the basic data of their EHR, or their medical appointments, or that reminds them what medication they should take, based on their active prescriptions.

Conclusions

 

Today, developing software without using APIs is as anachronistic as wanting a car and ordering it to be designed and manufactured from scratch.

It is much more expensive, it takes much longer to be ready, the chances of making mistakes are very high, and most likely we miss the latest technological advances available for not knowing them or for not being able to assume their development.

In Health there are thousands of advanced APIs around the world. We have the responsibility to enrich the software that we put in the hands of health professionals and the citizens for our Health care.

But there are some important barriers:

1. You have to know their existence and find those APIs
2. You will need all the necessary tools to learn how to use them and understand them
3. Likewise, you have to have the necessary tools to integrate them into our software
4. Finally, you have to find a cost model that is compatible with budgets of all kinds in the health sector

The good news is that all these barriers are resolved with Nubentos, the API Marketplace for Health.

In Nubentos we are doing the search for you. While you develop the software that we use for our health care, we are bringing together the best APIs in our platform so that you have them all easily located.

Nubentos includes into its platform the tools you need to understand the APIs, their documentation, their methods, their parameters, everything you need. You can do tests without touching a line of code.

Nubentos also gives you the tools that enable you to integrate the APIs in your Healthcare software, in a simple way.

In Nubentos you have the most efficient cost model possible. Because it gives you all these tools at no cost, and brings you the best and most advanced Healthcare APIs under the pay-per-use model.

It also allows you to manage your subscriptions according to the consumption segments you estimate for your customers, so that you can manage different costs for different types of customers, with different budgets, and therefore with different prices.

I’m sure you can think of a thousand ways to use and combine the APIs that we have mentioned in this article as an example.

What APIs would you like to use in your Healthcare software? It is possible that we have identified it, and we can prioritize its incorporation into our Digital Health Catalog.

Tell us in the comments, down here.