If you are in the business of innovation in the health sector, or your service has use cases in the health sector, this article is of interest to you. You are probably already aware of the strategic importance that the “apification” of services and the “API-first” company concept have taken on. If so, read on because we present the 6 key features that your Health API must have.

“Apifying” your services, i.e. offering them through APIs, will allow you to reach more customers, simplify your integration in their applications, and gain an important competitive advantage. It will also allow you to save costs and open up new business and collaboration models for your company.

But adopting the “API-First” concept is no small matter.

An organisational architecture that places APIs at the centre of innovation and solution development makes them the main product on which the entire user experience is built from mobile applications and SaaS platforms.

In this architecture you must think of the client developer as the first user of your Health API, as they will be the one to test it and integrate it into your clients’ software, and the main artefact you must work on is the specification of the API in a contract. 

The first aspect that must be taken care of when developing a Business API and more specifically a Healthcare API is the API “contract”. Among the different existing languages for specifying the contract of an API, there is a clear winner in the industry: OpenAPI. 

Therefore, the starting point for defining and developing an enterprise API must be the specification of the Health API through a contract based on OpenAPI 3.X. This is a “de facto standard” in the industry, and the number of tools that support it is enormous.

We can start developing the definition with a simple editor and we can immediately distribute it to our development team to implement a prototype, to our QA team to implement testing and to the product development team so they can implement solutions based on that contract, even when there is no code implemented yet.

But what makes this contract so versatile and what needs to be taken into account? Let’s take a brief look at it.

First of all, it is necessary to complete purely formal aspects, such as the description of the API, a publication path for the development, testing and production endpoints, version control, etc.  An important aspect included in this section is the definition of the security and access levels to be used for resources and operations. This should be defined from the beginning in order to assign them to each resource. 

Secondly, the definition of the resources (object model) to be used, defining hierarchically the types of data that define them. At this point it should be noted that the resources of an API must be represented in JSON, and a plus is to accompany the data types with a reference to the JSON Schema. 

And finally the paths (URI) to the resources and the operations that can be applied to them. Basically the equivalent of a CRUD for the resources (Create, Read, Update, Delete)… 

But above all, all this should be accompanied by properties that allow us to describe and document each of these aspects in a formal and simple way. For example, we can add examples to the parameters in each request and to the responses received. 

Have we already mentioned that Nubentos is “openAPI compliant”?

The second section we need to pay attention to from the beginning concerns the architecture.

We must maintain a RESTful API architecture style and comply with the HATEOAS principle, respect the standards and RFCs that support the HTTP protocol, HTTP Error codes, headers and codes.

In the following link you can download a summary of the main HTTP error codes and in this short video we explain the most common ones.

All the APIs published in Nubentos are exposed in our platform as standard REST APIs. Therefore, we offer the technical standardization of any API for Health automatically.

When developing a Health API, a fundamental aspect is data security, at all levels.

Our Health API can be a gateway to very sensitive information and we must therefore ensure that we follow the best practices in terms of privacy and security regulations.

It is therefore advisable that our organization complies with the regulatory framework that applies in our country or to the type of service we provide. From GDPR, to CE Marking or HIPAA, to ISO 27001 and SOC 2 compliance reporting.

At a minimum, all of these will help us project enough confidence to allow you to handle our users’ data. But in many cases, they will be essential requirements for our potential clients in the healthcare sector to choose our solution.

At Nubentos we offer our clients all the information related to the regulations that the APIs published on our platform comply with.

In this way, we make it easier to do two things:

• That the best solutions in this area stand out from the rest.
• That our customers have the information they need to find the solutions they can use in their projects.

 

The first detail we have explained in this article is the contract. An element that introduces a very important layer of standardisation, but independent of the sector. We can say that it is a technical standardisation.

But speaking of the Health sector, there are numerous use cases that are covered by the most important standard in the industry: the HL7 family of standards and specifically its latest version, FHIR.

Adding a level of business standardisation like this to the design of your API is a very important added value for your solution. We could say that it will allow your service to “speak the same language” as most of the software products that manage the day-to-day running of a Hospital, practically all over the world.

It is not an essential feature, because in fact the health sector currently integrates many solutions that do not follow the HL7 standard. But incorporating this feature into your solution gives you a huge competitive advantage.

The difficulty lies in having the level of knowledge and experience necessary to carry out this standardisation and, above all, to maintain it.

Fortunately, at Nubentos we offer this possibility to the APIs published in our catalogue. We take care of the standard interface of your solution, so that potential customers of your API find it even more interesting and attractive compared to your competitors.

 

At the beginning of this article, we mentioned that in an API-first company there is a new type of user to take into account: our clients’ developers.

It is a mistake to neglect the importance of this technical user profile, because on many occasions it will be a profile close to the technical manager, or it will be the technical manager himself, and therefore will have an influence on the client’s decision-making. In addition, their feedback will serve to confirm or deny that your API is well designed and can be easily integrated into their software.

It is important to accompany your API with examples, ready-to-integrate code and corporate support that responds quickly to their questions, as well as test datasets.

Most commonly, and what any developer used to working with third-party APIs expects, is to offer sandbox environments for safe testing. The Observability of the actions performed with the API by providing adequate and traceable logs is another plus point.

What if your service is an AI model that is basically going to respond the same in a production environment as it does in a sandbox environment? Well, in these cases you should at least offer free access tiers that allow users to test your API without risk.

This is an issue to analyse in detail: what is more costly: to set up a sandbox environment that forces the response so that it cannot be used in a production environment, but allows users to test your service safely and separately from the production version? Or to allow free limited access to your production service, risking that the test use will harm the learning of your AI model?

In Nubentos all APIs offer access to a sandbox environment, or a freemium usage tier. In the AI models that abound in the Healthcare environment, we always advise you to invest effort in offering sandbox access to a separate version of the algorithm whose response is forced to, for example, the same result, or with a limitation in the use cases, etc.

Curiously enough, this is one of the aspects that is most often neglected in the design of a business API in general, and in particular for the health sector.

We often find companies that force the client to go through a manual process of registering and obtaining keys, in order to then be able to use the credentials obtained in the integration of their API in their software.

This approach is a half-hearted approach, and represents a missed opportunity to offer a true “white label” integration capability to your client, an increasingly common demand in the healthcare sector.

Above all, it seriously undermines the scalability of your API.

An API is your company’s online façade, and in order to be scalable and 100% integrable into any client’s software, it must offer the necessary resources to manage access control. The most widely used mechanism in the industry is OAuth2.

And related to access you must offer a number of additional ingredients, such as an SLA, technical support and business support. 

Finally, it is important that you can monitor and measure how your clients use your Health API through their integrations. You will have a source of valuable information about the most used and least used resources, the most demanded use cases, etc. You will be able to orientate the evolution of your service more closely to the needs of the market, and therefore, improve your product-market fit.

In Nubentos we have “as standard” the OAuth2 protocol for all the APIs published in our catalog, and we offer our providers a control panel to observe different aspects of the use of their APIs by the clients that integrate them in their products.

In this article we have gone through the 6 key features that your Health API should have. There are more details to take into account, and at Nubentos we have the technology, the business model, the expertise and the right partners to make your API ready for the digitalisation of the healthcare sector through APIs. A change that has already begun and that will increase in the coming years.

Publishing your API for the Healthcare sector on Nubentos allows you to use our highly scalable, standardized, sales and integration channel completely free of charge, and add our marketing and sales force to your project to attract more clients to your API, saving you the recurring effort of integrating it with each new client.

To start publishing your API in Nubentos, just access our wizard and register. We will be happy to study your case and guide you through the process.