drd doctors online - Technical Case Study

What is drd?

drd is a platform that offers telemedicine services and access to Austrian general practitioners (family doctors). It allows its users to search for specialized doctors and improves the traditional way of accessing medical services through real-time patient-doctor communication with the help of online video consultations without waiting time. 

The app provides end-to-end encrypted documents, thus ensuring the privacy of the user’s medical records. 

What is its mission?

Personal strokes of fate made Clemens Billek and Karin Krömer aware of the importance of immediate and uncomplicated access to doctors that can offer treatment easily. 

It creates the first point of contact for patients with medical questions and offers the chance to get immediate assistance.‍

What is its goal?

The goals of drd are to digitize and simplify anyone’s access to a doctor. 

Users have the chance to:

• Have a telemedical consultation with a general practitioner via an encrypted video consultatio 
• Store securely and easily access medical records (eg, sick certificates or prescriptions)
• Search all the specialists registered in Austria

drd creates the first point of contact for patients with medical questions and offers the chance to get immediate assistance. Within their patient account, users can manage all their medical documents in one place.

Founder’s insight

What is something that you, Clemens, would have wanted to know in the entire process (from idea to market)?

What we learned from this experience is that good planning is essential in the entire process of developing a product. 

The project was more complex than anticipated and the planning was critical. We ended up having a very tight timeline for the features that were needed. 

We took a risk by starting the project having this setback. The hardest thing to accept was the fact that it had to go live too early. powever, if we hadn’t done this, maybe we would never have started it.

What would you do differently now?

There are many things that I would do differently now. powever, I assume that this is normal and necessary as it s part of the learning process. I would have insisted on more realistic planning before the start. 

‘We are lucky to have Linnify as a technical partner. They are always looking for efficient solutions that meet our needs. They want us to succeed and go above and beyond to help us bring this product to the market. They are true experts in digital products.’ - Clemens Billek, Co-Founder of drd 

Technical standpoint

What can users expect from drd?

The web platform offers its user:

• Access to medical consultations via browser
• In-platform video conferencing between patients and doctors
• Prompt response time from the doctors
• End-to-end encryption of medical records
• Multiple patients account administration (a limited number of sub-accounts can be added for other family members, such as children, and grandparents)
• Instant issuing of medical documents, digitally signed by the doctors
• Efficient payment system, discounts, and benefits

‍

What were drd’s technical challenges regarding the structure and functionalities?

Challenge #1 End-to-end encryption

This was a technical challenge for the web development team. They had to do a lot of research to find the optimal solution for this challenge, which met the security and reliability needs of drd.

‍

Linnify's Solution

Asymmetric Keys

Our solution was a standard encryption solution using asymmetric keys: a public and a private key. 

Together, they are used to encrypt and decrypt messages. 

The users share their public key with others to encrypt sensitive data while using the private one to decrypt it.

Mental demo

Let’s say the patient wants to send a message to a doctor. 

The patient takes the doctor s public key and encrypts the message they want to send to them. After the doctor receives the message, they take the private key (that only they know) to decrypt the message from the patient. 

When the doctor replies, they simply repeat the process, but they change the messages’ direction, encrypting it using the patient's key. 

This brings extra security. If someone might try to compromise the server and read the messages, they would fail as they lack the private key to decrypt the message. Only the user with the private key will be able to do that as they are the only ones to know it.

‍

Challenge #2 In-app video streamline

Although we were experienced in streaming features, this was a particular challenge as drd’s in-app video streamline resembled more of a Skype session rather than an in-app live stream. 

While working on this feature, we encountered other issues that had to be solved. These included connectivity issues and empty conference room availability.

This was a challenge due to the fact that the video call had to remain active in case one of the users disconnected suddenly. The call would end only five minutes after one user has disconnected.

‍

Linnify’s Solution

Confidential

This was a challenge due to the fact that the video call had to remain active in case one of the users disconnected suddenly.

The call would end only five minutes after one user has disconnected.

We managed to find a way to respond to this particular challenge but we need to keep it confidential. If you’re facing a similar challenge with your digital product, remember we are one email away.

‍

Challenge #3 Real-time communication

Live communication between the doctor and the patient was mandatory. The doctor had to receive a consultation request immediately. Once they initiated the call, any of its changes of state should notify the relevant stakeholders of interest. 

That is why a real-time communication feature was essential in this case. 

‍

Linnify’s solution

Pusher

We used a real-time communication service named Pusher. 

Each resource of interest gets associated with a communication channel. 

In that specific channel, change event notification messages were triggered on the server.

‍

Challenge #4 Payment system

This was a technical challenge for the backend development team. The payment system was a highly complex one including:

• Different subscription plans
• One-time payments
• Multiple payment providers
• Partner program promotions & benefits
• Promotional codes

‍

Linnify’s solution

Stripe & Drei 

We chose to take an approach that does not revolve around a single payment provider. At the moment, the app has two different payment providers: Stripe and Drei. 

drd has different partner programs that can be activated in various ways: promo codes, certain email patterns, or access keys. 

Access to online consultations can be granted by either activating a monthly subscription or paying for a one-time consultation.

‍

Decrypt the specifics of drd’s overall challenges and solutions:

Adapting to clients’ needs

Initially, the application was first envisioned as a mobile app to then be transformed into a web platform. 

Tight deadline

Features such as the in-app video streamline, secure payment system, and end-to-end encryption were difficult ones that, normally, would require much more time than the significantly short timeframe at the disposal.

Limited resources

Taking into account the time and budget constraints,  the initial team allocation involved only one front-end developer and one back-end developer. The complex and challenging issues mentioned required considerable time and effort. Given the tight deadline, in some of the development phases, we added more developers to the team, especially for the frontend part.  

‍

Linnify’s solution to achieve the product’s goals

Linnify had to prioritize sharp clarity and organization. 

As we rewrote the code from scratch, the team focused on:

• Time efficiency
• Scalability
• Bug prevention

The Linnify team is a product mindset team. This mentality creates and constantly improves our clean code creation guidelines and best practices. The final result was a much more stable application built on a scalable infrastructure.

Discover drd’s main features

Feature 1 Secure documents access

• Personal medical documents
• Doctor-issued medical records
• Encrypted documents
• Issued documents must be digitally signed by the doctors

Feature 2 Video streamlining and consultation 

• Real-time communication between the patient and the doctor
• In-platform video conferencing 
• Prompt response time from the doctors

Feature 3 Multiple payment providers and subscription systems

• Efficient and complex payment system
• Access to online medical consultation through a subscription plan or a one-time consultation payment
• Includes two different payment providers

‍

Technology Frameworks - Angular and Django

Technology Pros & Cons

Angular

Pros:

• Reactive programming
• Modular software architecture
• Typescript-based: cleaner code & higher scalability

Cons: 

• Coding requires more attention
• Complex conceptual elements
• Limited SEO options

‍

Django

Pros: 

• Fast development and implementation
• Integrated admin dashboard
• Integrated ORM

Cons:

• Performance issues due to slow request waiting time
• Does not support multi-processing
• Somewhat rigid when deriving from standard preset architecture

‍

Conclusion

drd is a solution to the shortage of affordable medical doctors in Austria. 

Now, anyone can have easy access to General Practitioners without waiting.

This is the first Austrian telemedical platform.

Discover drd: https://drd.at/en/