Got feedback or spotted a mistake?

Leave a comment at the end of this page or email contact@krishagni.com

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Current »


Overview

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.

HTTPS/SSL

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

Authentication

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.

Audit

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


  • No labels