Backend as a Service is a relatively new approach to app design. It places the emphasis on designing your API first, forcing you to consider what you really need to implement. In addition, for specific scenarios like eHealth apps, a BaaS can help you to quickly and easily ensure compliance with GDPR and HIPAA.
Once upon a time, developing mobile and web apps was quite straightforward. You decided what devices you wanted to support. Then you engaged frontend developers to create each app. At the same time, you would recruit a backend engineer to work with the frontend team and develop the APIs they need. You could call this approach the app-driven model of development.
More recently, people have started to use an alternative approach. First, you define exactly what functionality you want your app to have. Then you create the backend services and API to deliver this. Finally, your frontend developers create apps that consume those APIs. This approach is described as the API-driven development model.
Here we look at why the API-driven model produces better results for eHealth applications. We also explain how this leads to the concept of backend as a service.
The architecture of an application
Nowadays, both web and smartphone applications tend to have similar architectures. Users interact with the frontend, which may be a mobile app, tablet app or web application. All the data is processed and stored on the backend, which may also include services such as a load balancer. Joining the two is an API (application programming interface) which is responsible for sending and receiving data, handling logins, etc.
Nowadays, your backend is usually the “brains” of your application. It hosts the algorithms that process and handle the data. However, this isn’t always true, and some apps do their data processing on the end device, with just the results uploaded to the backend. This is often the case with eHealth apps. Typically, backends are hosted “in the cloud” using a service such as Google Cloud or AWS. However, for eHealth applications, the backend may be on a server hosted inside a hospital.
RESTful API design
Most current approaches to API design are based on the work done for web services. This resulted in two distinct approaches to APIs. The first uses SOAP (simple object access protocol) an XML-based messaging format designed to exchange data between your frontend and backend. SOAP messages have a set of headers but are then encapsulated in HTML headers for transmission. This double encapsulation, coupled with the relative inefficiency of XML makes SOAP unpopular with developers. The alternative is to use REST APIs (representational state transfer). REST directly embeds the data as a text object inside HTML. Often, the data is formatted using JSON (JavaScript object notification). JSON is a simple human-readable format. Almost all modern APIs are RESTful.
Why develop your API first?
There are several key benefits to developing your API and backend before your frontend. For a start, it means frontend engineers don’t have to keep reinventing the wheel. This approach makes you consider what functionality you really need. And also what functionality you can actually deliver. It also makes it easy to consume backend services from 3rd parties and integrate these into your own application. Finally, it makes it much easier to handle important external constraints like GDPR or MDR.
Build what you really need
When you start by building a frontend, it is easy to end up deciding you MUST have certain functionality in your app. You also often end up with each frontend engineer asking for the database they are most familiar with. So you quickly end up with several databases all doing the same thing.
Integrating services
Many applications integrate some form of external services for handling e.g. payments, maps data or two-factor authentication. The majority of these services will provide you with an API to interact with. It makes sense to design your API to function in a similar fashion.
Build compliant software
Medical and eHealth software is tightly regulated and has to comply with numerous regulations and standards. Things like GDPR, HIPAA, MDR, etc. Implementing and tracking these sort of constraints is far easier on the backend. It also means you only have to do it once.
What does API-first mean?
The key thing when following an API-first design is to establish exactly what your application will be doing. This includes understanding what data it will handle, what processing it needs to perform and what it will need to display to the end-user. Next, you need to understand what constraints you will be working under. For eHealth applications, this will often include the new MDR, GDPR and HIPAA. Finally, you can start to create your backend services and APIs.
Backend as a Service
Nowadays we are used to everything being delivered “as a Service”. This delivery model has revolutionised many aspects of technology. The boom in apps could never have happened without IaaS. Likewise, the surge in SaaS has transformed countless business processes and made the most advanced tools available to startups and small businesses. Coupling the API-first development model with the *aaS delivery model gives you backend as a service (BaaS). Here, certain core functionality for your app is delivered by a 3rd party via an API. This API can be simply integrated both with your existing backend and your frontend.
The benefit is you get to use mature and stable software components in your application without the need to develop them yourself.
Chino.io delivers GDPR & HIPAA compliance, as a service
The Chino.io platform delivers you a GDPR and HIPAA compliant Backend as a Service. Our APIs manage several critical aspects for you:
- Data security. We make it easy to implement both encryption and pseudonymization. These are key data security techniques for both GDPR and HIPAA.
- User management. Our OAuth2 as a Service API makes it simple to manage users, offering you fine-grained access control.
- Consent tracking. Via the Chino.io API or by using the Consenta.me service, which is designed to track and control user consents via a simple plugin Consent tracking is a key aspect of GDPR compliance.
- Audit Trail. Tracking operations on data and users is mandatory to be able to re-build the history in case of legal disputes. Chino.io provides an immutable audit trail, and in addition it provides API so you can decide what to store as part of the Audit Trail.
- Right to be forgotten. One of the central aims of GDPR is to give users control over how and where their data is used. When users request it, you need to be able to prove that you have deleted their data.
All these services are essential if you are collecting health data under either GDPR or HIPAA. By themselves, each of these could take weeks or even months to develop and integrate with your application. Or you could do it in days by using Chino.io.
