Engineering challenges at Alan — circa 2020
It has been more than a year since our last article on the engineering challenges we are facing. A year is a long time for a fast pace company like ours.
We have improved our document processing, reimbursement speed, and much more. Of course those challenges are not “done”, there is still a lot to improve.
For 2020 and 2021 our goal is to build the first layers to be the personal healthcare partner, which means to:
- Scale our health insurance offering for companies in Europe
- Become the personal healthcare partner starting with narrow verticals
Here, we will focus on the engineering challenges that are derived from those company goals.
The first one contains the follow up of what we achieved last year with scaling up our French insurance system and enabling real time pricing for French customers.
As we want to be present across Europe, that also means to open new countries and new health care systems.
The second goal implies first, and always, to improve our security and privacy. Becoming the personal healthcare partner goes through providing a doctor chat, and a personalization of the user experience.
Last, as the team will grow we will have a larger engineering team with a larger impact.
Scaling up our French insurance offer
Performance: From naive to scaling
Our strategy has always been to go up-market to provide health insurance for French companies.
In 2017, we were targeting companies with up to 20 employees. Performance was not an issue, even with naive implementations. Not so naive in fact, we were optimizing for speed of iteration.
In 2018, we had clients of up to 200 people. A few tweaks on the most expensive queries, and voilà! It was not really a challenge.
In 2019, we reached companies with up to 1000 people. Dashboards loading started to get slow, it could reach 1 minute in the worst cases! That’s not up to the level of experience we want to have.
So you can imagine how in 2020 (and further, 2021, when it’s 1000s of employees), it’s critical that we care more about performance.
We started an internal task force to re-architecture our back-office to handle thousands of employees. They first started to pick the “low hanging fruits”. It resulted in a 2–3x times improvement of load time. That’s not enough when your baseline is 60s!
The next steps will require more work with big changes of architecture of our front-end applications and the ways they interact with our back-end.
Going further on automation
We have an internally built claim engine, that allows us to compute how much we need to reimburse, to whom, based on different types of input (documents, structured data flows, manual inputs).
Today we are able to handle 90% of our claims automatically, without human intervention. Tomorrow we want to be able to reach 95%, and continue pushing the limits.
This enhanced automation means investments in parsing documents (using OCR technique or heuristics, either in-house or through APIs), building more intelligence in conflict resolution (with rules, or through machine-learning).
All of that needs to be done while increasing the performance of the engine, as volume is growing. Sometimes the load destabilizes our databases. It means potentially switching infrastructure, re-architecturing key pieces.
These are only the first steps of many changes we will need to do, for Alan to be able to support more users and customers.
Real time pricing for French customers
As we grow upmarket, we need to be able to price custom insurance contracts quickly. This enables our sales to proactively and interactively create custom contracts per customer. We won’t say much more on this, this article is a good example of an engineering challenge we’ve had.
We still have a lot of challenges there to make it scale and make it even more precise.
Opening to new countries and new health care systems
2020 is the year we opened Alan in other countries: Spain, and Belgium. It is a huge challenge for the whole company. We need to build teams in two new countries, and build a product for two vastly different markets. Of course, this also brings engineering challenges.
Before 2020, our code base was tailor made for the French market and health system. In 2021, our code base will be components that can be enabled for any country. A good example is Alan Maps. It’s a feature being developed for France, but it is something that is also needed for Spain and Belgium. How can we make sure that each new feature we do will be international by default.
This brings questions on how to share components, while adapting them for local needs. And this question needs to be addressed for our web front-end, mobile applications, and back-end applications.
Another good example is our French claim engine. With the opening of Belgium, we’ve decided not to rely on an external partner from day 1. This means that we will need a claim management system for Belgium, where the health system is pretty different from France. And maybe we’ll need another claim engine for a third country?
Improving our security and privacy
2020 showed us, again, that security is not a nice to have. It is a must have. At Alan, security needs to be one notch stronger than comparable companies. It is one of our core principles: “Personal data is personal. Medical data is even more personal.”
We want security to be understood as a feature and an enabler, not resented as a constraint upon our engineers. We require all of them, whatever their specialty, to have security in mind and build privacy by design into all projects. We do our best to comply with the legal requirements of GDPR. We won’t be stopping there and we will continue to progress on our journey towards being recognized as the best platform for health data.
Managing access to data internally
As our business grows, we are introducing structure in our processes to compartmentalize access, make sure only authorized people can access data, while at the same time avoiding the pitfall of creating a bureaucracy that would grind to a halt. This is posing a number of challenges in managing identities, roles and authorizations, as well as classifying data and making sure its confidentiality is preserved across the entire processing chain, at all levels of the infrastructure.
In order to support the creativity of our development and data science teams, we are facing two additional challenges:
- Generating relevant but anonymous test data
- Extracting meaningful signals from production data without compromising our members’ privacy
Enabling anonymous healthcare
Since health data is very personal, we don’t want to be, as a company, in the position where we can access data we shouldn’t have access to, such as discussions with a doctor.
That’s why we’re doing a push towards end-to-end encryption of messages in our medical chat. It creates a few challenges on what we should fully encrypt to keep a balance between providing services and extreme privacy.
Ultimately, a goal could be to provide anonymous healthcare, where you can get answers, without having to fear to ask questions.
Personal healthcare partner
Doctor chat
We want Alan to be the personal healthcare partner for our users, not only an insurance company.
One of our first features around this is the upcoming “doctor chat”. A safe place where you can ask any health related questions to real medical doctors.
As we said above, this security is built-in. But here we need more than just security, we are talking health related conversations that could have a big impact on the life of our users. Conversations that we don’t want anyone at Alan to be able to see. Only our user and the medical doctor must have access to this. The feature is current in beta testing (“you may have used it!”) with thorough security features we worked with our in house doctor to create. The feature includes full end-to-end encryption for all conversation content.
A key challenge there is to be building a discussion tool where doctors can access the different questions and be as efficient as possible to answer them.
It’s quite novel to be building that type of tool directly with doctors!
Personalization of the user experience
Becoming the personal healthcare partner for our users means that we must be able to personalize the user experience. We don’t want to be a generic healthcare provider, we want to be your healthcare provider.
That means that we need to personalize the experience, by:
- Using algorithms (sometimes as simple as a decision tree) to determine when to send reminders to go to the doctor
- Determining personas for which we can propose specific contents
- Building mechanisms to propose gated content depending on the persona, while making sure the experience makes sense
Larger engineering team, larger impact
By the end of 2020 we plan to double our engineering team, from 40 to 72 engineers. This will also bring technical and non-technical challenges to our team. We want to release more often and in a safer way. So how can we scale our technical environment to achieve this?
We already reduced the time from commit to production from 30 minutes to 15 minutes. But how can me make it 10 minutes, or even 5 minutes? Without compromising the quality.
Furthermore, we all work in a distributed way. This means we need to ensure that all engineers are delivering quality products code that any other engineer in the company can take over.
To sum up
This list is not complete nor carved in stone. As I’m writing this conclusion, we already have more new challenges we want to tackle: personalisation of the health experience, scaling of our databases, etc.
Stay tuned for more in depth article on our organisation and challenges 👋
