InTouch Technical Whitepaper


Intouch is designed with multiple layers of protection, covering data transfer, encryption and application-level controls, all distributed across a scalable, secure infrastructure.

This document describes the Intouch application, as well as the infrastructure it runs on and the mechanisms employed to ensure reliable and secure service.


1. Application overview

All profiles, both patients and physicians, are protected by a user name (email address) and password. The application is running in a closed pilot and patients are invited to join Intouch by their physician. The patient receives a welcome email containing a temporary password which they are prompted to change upon first login.


  • Physician (user) is delegated a username and password for their profile by LEO iLab
  • User can create a new patient from the dashboard
  • User fills in patient information
    • Email
    • First and last name
    • Condition
    • Affected skin areas
    • Treatment
  • User schedules remote follow up consultation for the patient



  • User is invited by the physician to join Intouch
  • User receives a welcome email with a temporary password and links to AppStore and PlayStore
  • Upon first login user is prompted to change temporary password to a personal password
  • User is asked to complete the consultation by taking pictures of affected skin areas through a step by step guidance (these images then become available to the physician)
  • User is frequently asked to log the following in the period between consultation and follow up (subjective/qualitative input from patient):
    • Images
    • Moods
    • Alcohol consumption
    • Health levels/healthy diet
  • User is asked to answer single questions regarding their condition and treatment at every remote follow-up consultation
  • User can add other products being used for treatment
  • User can set treatment reminders
  • User can view profile, images taken and the date for their follow up consultation.
  • User can raise a question to the physician via the chat functionality
  • User can complete a follow up consultation with images and text on the set date


Patient profile:

  • First name
  • Last name
  • Age
  • Gender (optional)
  • Weight (optional)
  • Height (optional)
  • Condition
  • Treatment
  • Images of affected skin areas
  • Profile picture (optional)
  • Conversations with the physician (text)
  • Remote follow up consultations with the physician


Content & interactions:


  • A chat interface between patient and physician. The chat consists of text messages and images
  • A list of the patients invited to use intouch
  • Action items:
    • schedule remote follow up
    • review images & answers/questions from patients
    • change treatment
    • Prompt inactive patients (inactive log)
    • View patient’s log



  • A chat interface between patient and physician. The chat consists of text messages and images
  • A treatment history overview
  • Past treatments and current treatment
  • A progress overview of treatment and triggers (mood, alcohol, nutrition)
  • Scheduled follow up consultations and completion of follow up consultations
  • One-question surveys (anonymous feedback to be used for product improvements)
    • Asking specifically about the user experience and usability of intouch
      • I.e. ‘How often would you prefer to complete a log entry?’ and then present 2-3 input options
  • Clinical mini-survey during remote follow up procedure


2. Infrastructure


Figure 1: Intouch infrastructure overview


All components of the Intouch infrastructure (as shown in Figure 1) run on HIPAA-eligible Amazon Web Service products.

Processing services are run on AWS Elastic Cloud Computing (EC2) servers and data is stored in AWS Relational Database Service (RDS) databases. All data in databases are stored on encrypted disks and all communication from client browser and app is encrypted. Encryption details are described in section 3.

Images are stored in buckets on AWS Simple Storage Service (S3).

All servers and databases involved in running the Intouch application are located in Frankfurt, Germany.

The Intouch infrastructure is split in two main tiers;

  • tier 1: the core services and
  • tier 2: the Intouch services

The primary objective of isolating the core services in tier 1 is to protect personal information from unauthorized access. The core services also validate all requests to the Intouch services to prevent unauthorized access to Intouch functionality.

The core services handle all personal information.

The Intouch services handle all information other than personal that is relevant for operating Intouch, meaning treatments, conditions, messages, images and tasks.


Reliable services:

All services, both core and Intouch-specific, are continuously monitored for availability. In the case of unavailability, the core operations team is alerted to triage and fix the cause of the unavailability.

Moreover, logs from all services are monitored for intermittent errors which also generate alarms when errors are detected.

The system is load balanced and the performance of the system is monitored to scale the available resources behind all load balancers. In case of unavailability due to lack of resources, new resources are added seamlessly into the system to recover the performance.

All databases are redundant over multiple availability zones allowing fail-over without downtime upon failure of a single database instance.

All databases are backed up daily and allow point-in-time recovery within a one-minute resolution.


3. Data security and integrity


All user accounts must use a password. All passwords are encrypted using bcrypt. bcrypt uses a modified key setup algorithm which is timely quite expensive. This is called key strengthening, and makes a password more secure against brute force attacks, since the attacker now needs a lot more time to test each possible key. For this reason, bcrypt is chosen for password encryption over traditional hashing algorithms such as SHA-256.

Only hashes of passwords are stored.

When the user is created, the password is provided by the app (over HTTPS) and only the hash is persisted. This is a temporary password which must be changed before the account can be used.

When the user requests a change of password for an account using the email-address, an email with a one-time, time-limited access token is sent to the email address. This email contains a link to a form where a new password can be provided. This way, permanent clear text passwords for Intouch users are never displayed or stored.



All databases run in AWS RDS. The block storage and filesystems underlying the databases are encrypted using AES-GCM-256 and the communication with the databases is encrypted with SSL (AWS RDS security details)



All communication between the client app/browser and servers is done via HTTPS using a 2048-bit RSA public key with a SHA-256 signature algorithm.


Key management:

All encryption keys are issued and managed by AWS Key Management Service (cryptographic details).

Certificates are issued and managed by AWS Certificate Manager.

All operations on keys and certificates are authenticated, protected by two-factor authentication and audit logged into AWS CloudTrail.


4. Data privacy

Data decoupling and object access isolation:

Intouch data is decoupled from personal data and only the core operations team with access to both core and Intouch databases can couple the medical records and chat message with personal identifiable information.

Personal data is protected from unauthorized access by several security mechanisms, including authentication, encryption and authorization. Authentication and encryption are described above. Access to any protected object (such as personal data) is authorized by the owner of that object through permission grants. The identity service implements this security model at the database level, so any application-level access to protected objects is impossible without a grant.

Although the underlying authorization mechanism of the core service support granting access to personal and medical data, this feature is currently not implemented in Intouch.


Monitoring Intouch data for mentions of side-effects:

LEO Innovation Lab is legally obliged to monitor all communication for mentions of LEO Pharma products and potential side-effects. This monitoring is performed by a continuous process that checks for mentions of LEO Pharma products and alerts an internal side-effect reporting team in case of mentions of side-effects in the communication between doctors and patients.

This monitoring and reporting process works solely on the Intouch databases and does not have access to the personal identifiable data in the core databases, so the reports made will never contain personal data.


Audit logging:

Besides traditional application logging for troubleshooting the core services perform audit logging that reflect all access and changes to personal and user data. Since data is only accessible through authenticated requests, the audit log ensures traceability of all operations in the core service. All events are audited with the authenticated user, the accessed object and a timestamp. The audit log storage is append-only which ensures that audited events cannot be changed after-the-fact to maintain integrity of the log trail.

Data access by the core operations team:

Access to the databases underlying the core services is limited to the core operations team. This access is needed to operate, maintain and troubleshoot the database infrastructure.

The core operations team has access to the data in the core databases. Because of that, all queries to all databases (both core and Intouch databases) are logged and archived for auditing purposes. It is not possible to access the data without being an authenticated user and access to the individual databases is authorized through user management in AWS Identity and Access Management (IAM). All changes to user permissions are logged to AWS CloudTrail, and no user can elevate their own permissions to gain access to the infrastructure.