Security considerations


OpenSpecimen is a Java Spring and REST API based application. It is designed to handle highly sensitive data such as patient identifiers, demographics, clinical information, images, test results, etc. This document explains the security considerations used in OpenSpecimen to achieve this.

Latest technology stack

OpenSpecimen is built using the latest versions of all the technology platforms used internally. This includes Tomcat, Apache, Oracle, MySQL, Java, etc.


OpenSpecimen supports (and highly recommends) using SSL enabled webserver to ensure encrypting data over the network.


OpenSpecimen has an in-built user management module. For tighter security, adopters can consider integrating OpenSpecimen with their institution's LDAP (e.g., Active Directory). This will also avoid users having to remember multiple user names and passwords.

Password protection

Note: This does not apply if user accounts are integrated with the Customer's Identity Providers (IdP).

Where N is configured as per the Customer's needs. 

  • Password should be of length N characters (default 8)
  • Password complexity defined via RegEx as per customer needs (default: one capital, one number, )
  • Cannot be the same as the last N passwords
  • Password expiry every N days
  • Passwords are never emailed in free text
  • Passwords are stored in a one-way encrypted format

Account Protection

Where N is configured as per the Customer's needs. 

  • Accounts are locked after N failed attempts
  • Accounts are locked after N days of inactivity

PHI Handling

Users can be restricted not to view PHI data using the roles and privileges module.


Login Audit

Every login and logout session is recorded, including failed login attempts. 

Data manipulation audit

Every action that results in data being changed is audited (i.e., create, edit, delete). The audit information contains:

  1. Timestamp
  2. User id
  3. IP address
  4. Record id
  5. In the case of edit: old value and new value

Currently, audit reports will have to be generated either directly from the database or via REST API calls. There is no user interface for the same. Building a UI driven audit reporting module is present in our product roadmap.

Reporting audit

Every time a user runs a report, a log is maintained, which includes information like:

  1. User ID
  2. Timestamp
  3. Report ID
  4. Internal SQL generated