Our Commitment to Security and Data Protection

We understand the importance of security and privacy, especially when dealing with patient-related applications. Here we outline the key measures we take to protect the system, user accounts, and the data processed within our application. Our system is classified as an FDA 510(k) cleared and HIPAA compliant medical device and we adhere to strict protocols to ensure its integrity and the confidentiality of information.

Data Handling and Privacy Practices

  • Data is processed and stored within our secure network infrastructure. We do not utilize intermediary or external third parties for processing or storing core application data, nor is data commingled with that of other organizations on our primary servers.

  • For collaborations involving data sharing, we establish formal agreements, such as Business Associate Agreements (BAAs) or equivalent contracts, to define responsibilities and safeguard data according to regulatory requirements.

  • In Transit: All data transmissions, including login credentials and application data, are secured using robust encryption protocols (HTTPS with TLS 1.3, employing 256-bit AES encryption). We utilize trusted third-party Certificate Authorities (Let's Encrypt) for managing encryption certificates.


    At Rest: Currently, application data stored within the database is not encrypted at rest.

  • Database backups are retained for 2 weeks. Audit logs are maintained indefinitely. We do not use removable media (like USB drives) for processing or storing application data. Procedures for secure data sanitization prior to media reuse or disposal are handled according to internal standards, though specific partner data sanitization might not be applicable if data isn't stored on removable media designated for them.

  • Daily backups are performed using our secure cloud infrastructure. Backup media is managed within the secure cloud environment and is not transported offsite physically.

User Authentication and Access Control

  • Access to the system strictly requires unique, individual user IDs and passwords. Shared or guest accounts are not permitted.

    • Complexity: A minimum password length (8 characters) is enforced by the system.

    • Storage: Passwords are never stored in plaintext. We store securely hashed versions of passwords using bcrypt, which incorporates salting for enhanced protection.

    • Transmission & Display: Passwords are protected during transmission using TLS encryption and are masked by default when entered by the user.

    • Reuse & Lockout: The system currently does not enforce password history restrictions (prohibiting reuse) or account lockouts after multiple failed login attempts. Passwords are not required to be changed at fixed intervals.

    • Clinicians: Access requires completion of specific training and certification, after which an authorization code is provided to create an account.

    • Patients: Patients receive a unique code and link to create their account upon providing a valid prescription, or clinicians can create anonymized patient accounts directly.

  • The system employs RBAC to ensure users can only access appropriate information. Clinicians can view data for their assigned patients, while patients can only view their own data.

  • When an employee departs, a standard operating procedure is followed to immediately revoke system access and privileges.

  • Access controls are implemented at the file and directory level on the underlying infrastructure (AWS EC2 instances), managed through IAM policies and specific permissions. SSH access for developers requires key authentication and is tiered based on roles.

  • No external service providers or contracted organizations require direct access to the application or system for support or other functions.

System Security, Operations, and Resilience

  • Our server-side code is written in Python, which inherently protects against certain vulnerabilities like buffer overflows. Error handling is implemented carefully on both the application and server sides to prevent the disclosure of sensitive information in error messages or logs

  • The application utilizes JWT (JSON Web Tokens) for managing user sessions instead of traditional cookies. These tokens are generated securely and used for authentication. The system does not currently implement automatic session termination after a period of inactivity

    • Events Logged: Key system and application events are audited, including database record creation/modification, successful user logins, and application errors.

    • Log Information: Each audit event captures the timestamp, user ID, and specific actions taken (e.g., button presses, API calls).

    • Protection & Retention: Audit logs are stored securely in AWS databases with strict access controls limited to authorized personnel. Logs are retained indefinitely.

    • Review: While logs are continuously monitored for errors, a formal review process for security patterns is planned for quarterly implementation

    • Patching: We have a defined Cybersecurity Management Plan. Updates and patches are validated internally and with a select beta group before wider release. There is no fixed schedule for patching, but processes ensure applicability and criticality are assessed. Automated vulnerability scanning is performed on the server backend using tools like smgrep and bandit.

    • Security Alerts: We have processes to receive and act upon new security alerts relevant to the system, including reporting protocols compliant with medical device regulations (e.g., FDA 21 CFR part 803).

    • Malware Protection: The system leverages cloud-native security features (AWS VPC security groups, network ACLs, AWS WAF) and mandatory HTTPS encryption to protect against malicious code and unauthorized network access.

    • Security Assessments: Formal security assessments and penetration tests by independent third parties are under consideration for future implementation.

  • The system utilizes AWS Virtual Private Cloud (VPC) for network isolation. Additional measures like AWS Security Groups (firewall rules) and AWS Shield (DDoS protection) are planned or in use. Secure SSH with key authentication provides remote access for authorized developers only and with limited rights.

  • We maintain technical documentation regarding system components (OS, software versions, databases) and security processes. A formal change management process, following relevant guidelines (IEC), ensures that all system changes are tested, approved, and documented. Significant changes impacting security controls will be communicated as agreed upon with partners.

    • Incident Response: A documented incident response plan is in place.

    • Recovery: Leveraging AWS's fault-tolerant architecture, the target restoration time in case of interruption is typically within 6 hours. Regular backups of system and user data are performed using AWS services.

    • Disaster Recovery (DR): While a separate, formal DR plan and alternate processing site are not currently maintained, we rely on the inherent redundancy provided by AWS multi-Availability Zone capabilities. Formal testing of backup restoration and DR drills are planned for future implementation.