Technical Implementation

The Rett Syndrome Patient Registry is designed to be an efficient, GDPR-compliant, and modular platform for onboarding, managing, and analyzing patient and contact information. This document provides an overview of the main technical building blocks and the tools in use, allowing contributors to understand the project context and identify areas where they can provide input or support.

High-level architecture

The high-level architecture integrates a mix of cloud services and third-party tools to provide a secure and scalable environment. The architecture diagram below illustrates the main components and their interactions:

High-level-architecture diagram


1. Content Management System (CMS) - WordPress

The WordPress CMS serves as the public frontend for the registry, handling public-facing content and facilitating initial data intake via forms. This CMS setup is chosen for its simplicity, ease of maintenance, and extensive plugin ecosystem, making it ideal for hosting and managing content updates.


2. Front-end for users

We will implement a private area for users to login and maintain their profile. It will also allow users to create, edit and delete patient records.


2. Secure Authentication - Auth0

The registry employs Auth0 for passwordless, secure authentication. Auth0 simplifies login management, allowing for secure access without traditional passwords, and supports two-factor authentication (2FA) for added security.


3. Orchestrator - Azure Functions

Azure Functions act as the backend for the registry system, managing key processes such as data validation, storage, form submissions, and file uploads. Serving as the backend for PowerApps, Azure Functions support CRUD operations and enable real-time data interactions. They are triggered by events like form submissions, file uploads, and PowerApps requests, processing and securely routing data to Azure SQL or Blob Storage as needed.

This serverless, scalable setup ensures efficient processing while adapting to demand, maintaining high performance, and supporting seamless integration across the registry system.

3.1. Azure Functions endpoints

The following endpoints serve various aspects of the patient registry, providing CRUD functionality directly accessible by PowerApps and other components. This approach eliminates the need for separate “PowerApps” endpoints by standardizing interactions across all user-facing components.

3.1.1. User Onboarding

3.1.2. Patient and Contact Management (CRUD)

These endpoints handle all CRUD operations, making them directly usable by PowerApps and other components.

3.1.3. File Management

3.1.4. Survey and Data Collection

3.1.5. Notifications and Reminders


4. Storage

4.1. NoSQL database - Azure Cosmos DB

The primary database for the registry, Azure Cosmos DB stores patient, contact, and relationship data securely. It offers flexibility for structuring longitudinal data and supports scalability for future analytical needs.

4.2. File storage - Azure Blob Storage

Azure Blob Storage securely stores uploaded files (e.g., genetic reports) linked to patients. Blob Storage provides scalable and secure file management, essential for large files and GDPR-compliant storage practices.

4.2.1. Access Management

Blob Storage access is secured with several key controls:
* SAS Tokens: Temporary access is granted using Shared Access Signatures (SAS), generated by the backend to restrict file access based on user roles.
* Role-Based Access Control (RBAC): RBAC ensures that only specific system components, like backend services, can write or delete files, with limited permissions granted as needed.
* Network Restrictions: Private endpoints and firewall rules restrict access to known IPs within our virtual network, minimizing exposure to the public internet.

4.2.2. Encryption

To ensure data protection, Blob Storage applies encryption both at rest and in transit:
* Encryption at Rest: All files are encrypted automatically using Microsoft-managed keys (AES-256).
* Encryption in Transit: HTTPS/TLS encryption secures data transfer to and from Blob Storage, protecting data confidentiality during upload and download.


5. AI/ML Operations

5.1. Genetic Reports Analysis

We utilize AI/ML operations to analyze genetic reports, specifically to extract Mecp2 mutations. These mutations are then added to the patient profile, enhancing the accuracy and comprehensiveness of patient data.


6. Admin frontend - PowerApps

PowerApps serves as the internal admin interface for managing and reviewing patient registry data. This platform allows authorized administrators to perform CRUD operations and view reports in a user-friendly, customizable interface.


7. Reporting & Analytics - PowerBI

Power BI is used for reporting and analytics, providing a comprehensive view of patient demographics, registry growth, and survey results. It integrates directly with Azure SQL for seamless data access and visualization.


8. Notification Service (Email and SMS) - SendGrid/Twilio

To ensure effective communication with registry users, SendGrid is used for email notifications, and Twilio for SMS alerts (e.g., for two-factor authentication). These tools support both initial onboarding communications and ongoing engagement.


9. Networking

All Azure services are configured within a secure Virtual Network (VNet) to enhance security, ensuring all internal services communicate over private IPs. Additionally, a firewall limits traffic to only authorized IPs.


10. Other Azure services

Application Insights for Monitoring

Azure Application Insights provides logging, diagnostics, and performance monitoring for Azure Functions and other backend services. It supports real-time insights, helping to optimize performance and troubleshoot issues.