We developed a clinic management platform for a leading medical technology company

The chords of a favorite song. The patter of rain. The laughter of your loved ones. Your own voice. Everyday sounds help us create memories. Connect ourselves with the rest of the world. Discover the things we love. Become who we are.

Still, according to statistics from the World Health Organization, more than 1.5 billion people suffer from hearing loss. That’s almost 20% of the global population.

This is a burning problem that only tends to get worse over time. Our client is a leading hearing implant company that aims to put this to an end.

The challenge: Creating the platform from the ground up

The client is focused on implementing hearing devices into the human brain, enabling patients to regain the ability to hear. They already had a platform for managing clinics, employees, and the implants they produce.

However, as their requirements continued to grow over time, they decided to build a new one – from the ground up. Satisfied with our collaboration on previous projects, they chose us as their tech partner.

Our primary goal was to develop a new application that would have the same purpose as their previous solution but be more intuitive, visually appealing, and easier to scale. They also wanted to introduce roles into the system, which were intended to have specific permissions for using the application and to enable device activation.

The solution: Increased transparency and user-friendliness

The client was looking for a partner who would understand the specific requirements of the industry, as well as the roles within the system, their permissions, and the various stages of the device activation process. To meet their needs, we created a team of healthcare industry experts consisting of software and DevOps engineers.

Assigning roles in the system

During the first phase, we discussed the roles and permissions in the system. We established them to ensure each administrative level has appropriate permissions and responsibilities based on their scope of operation. They were divided into:

• Global admins – have complete control over all clinics and employees;
• Area admins – have authority over clinics and employees within a specific area;
• Country admins – responsible for clinics and employees within a particular country;
• Clinic admins – have the authority only over the employees at the clinic they were assigned to.

Device activation: Introducing roles into the system

On the device side, each hearing implant had to be created first. During the creation process, the clinic where the device would be used was selected, along with the designated usage mode and the specific user (medical specialists) who would be using it.

Once the device was created, a request for its activation was sent. The request could be either accepted or rejected. If the request was accepted, the device was activated by uploading an activation file (obtained internally from the client's computer) onto the application.

Our application communicated with an external service provided by the client's device licensing company. If the data in the activation file matched the device's information, the device was successfully activated and ready for use.

Introducing a completely new API

We used a Modular Monolith architecture to ensure an easy transition to a microservice architecture. That way, we made sure that the application is easier to scale and adapt to the client’s requirements in the future.

The combination of Modular Monolith and Clean Architecture makes this API maintainable and stable. The database remains PostgreSQL (as with their previous system), but with the new setup, we are using Entity Framework as the ORM. The entire API is supported by unit, integration, and architectural tests.

Building the front end from scratch

We created the platform’s front end from the ground up. While the front end of the previous app was in Angular, the new one was developed using the Nextjs framework – the React framework originally used for server-side rendering.

To make sure the client can use a range of separate applications within the same git repository, we used the Mono Repo platform, which is developed using the Turborepo Monorepo technology.

In addition to the Nextjs application, we also use the Reusable UI React library, which can also be used as a package in other applications.

The entire front end, as well as the API and the database, have been migrated from AWS to Azure.

Results: Increased user experience

We made a significant difference in the code quality and functionality of the application. It has panned out to be much faster, simpler, and more intuitive, which has significantly improved the user experience. Above all, we managed to future-proof it, making it easier to scale and maintain as the client’s goals change.

The full tech tech

Back end

.NET

PostgreSQL

Front end

Nestjs

React

Turborepo

Storybook

Hosting

Azure