Data Security

Data security in Antigen Plus encompasses multiple layers of protection for patient health information (PHI), reagent data, test results, and system configuration. This section describes the encryption mechanisms, connection string security, data integrity controls, and intentional data modifications implemented to protect the confidentiality, integrity, and availability of blood banking data.

Database Encryption Overview

Antigen Plus implements a defense-in-depth encryption strategy with multiple independent layers:

Client-side PHI encryption - Patient data encrypted before leaving the workstation
Data in transit encryption - TLS protection for all network communications
Database-level encryption - Transparent Data Encryption (TDE) or BitLocker for data at rest
Connection string encryption - Protection of database credentials

Each layer provides independent protection, ensuring that compromise of one layer does not expose patient data.

Client-Side PHI Encryption Architecture

Antigen Plus implements client-side encryption that ensures patient data is encrypted on the workstation before transmission to the database server. This architecture applies to both Azure and on-premise deployments and provides zero-knowledge protection - neither Antigen Plus nor database administrators can access PHI without the customer’s private encryption keys.

Encryption Components

Patient Key (Symmetric Encryption Key):

A unique AES-256 symmetric encryption key (called the “patient key”) is generated for each customer database
The patient key encrypts and decrypts all patient-identifying information and test results
The patient key itself is stored in the SQL database but is encrypted using the customer’s RSA-2048 public key
The patient key can only be decrypted using the customer’s private key, which resides on customer workstations and is never transmitted to Antigen Plus or the database server

RSA Key Pair:

Generated during application registration
Private key stored in Windows Cryptographic Key Store on each workstation
Public key transmitted to Antigen Plus servers and stored in the database
Private key never leaves customer network

Record-Specific Salt:

Each patient record has a unique random salt value
Salt prevents pattern analysis and thwarts brute-force decryption attempts
Ensures identical patient information produces different ciphertext

Encryption Process

When Writing Patient Data:

User enters or imports patient information on workstation
Antigen Plus application generates unique random salt for each patient record
Application retrieves encrypted patient key from database
Application uses private key from Windows Cryptographic Key Store to decrypt patient key
Application uses decrypted patient key and record-specific salt to encrypt PHI fields using AES-256
Encrypted PHI transmitted over TLS connection to database server
Database stores encrypted PHI (database server cannot read this data without the customer’s private key)
Additional encryption layers at the database level (TDE for Azure, TDE or BitLocker for on-premise)

When Reading Patient Data:

Application retrieves encrypted patient record from database over TLS connection
Application retrieves encrypted patient key from database
Application uses private key from Windows Cryptographic Key Store to decrypt patient key
Application uses decrypted patient key and record-specific salt to decrypt PHI fields
Decrypted PHI displayed to authorized user on workstation
Decrypted patient key and PHI exist only in workstation memory, never written to disk in plaintext

What Data Is Encrypted

Fields Encrypted with Patient Key (AES-256):

Patient name
Patient identifiers (medical record numbers, blood bank numbers)
Date of birth
Any other patient-identifying information
Test results and clinical observations

Fields NOT Encrypted with Patient Key:

Reagent information (not PHI)
User account information (usernames, roles)
System configuration
Audit logs (contain user actions but not decrypted PHI)

Zero-Knowledge Security Properties

The client-side encryption architecture ensures:

Antigen Plus cannot access customer PHI - Private keys never leave customer network
Database administrators cannot read PHI - Patient key is encrypted with customer’s public key
Microsoft Azure cannot read PHI (for Azure deployments) - Patient key cannot be decrypted without private key
Protection from server compromise - Even if database server is compromised, PHI remains encrypted
Protection from legal subpoena - Antigen Plus cannot provide decrypted PHI without customer cooperation

Critical Key Management Requirements

{: .important} Loss of all copies of the private key results in permanent, unrecoverable loss of access to all patient data. The encryption is designed such that data cannot be recovered without the private key.

Required Actions:

Maintain secure backups of private keys from Windows Cryptographic Key Store
Store private key backups separately from database backups
Consider formal key escrow procedures with secure off-site storage
Test key recovery procedures at least annually
Document key backup locations and recovery procedures
Restrict access to key backups to authorized personnel only
When decommissioning workstations, ensure private keys are securely transferred or backed up before system wipe

Key Backup Location:

The private key file (.APCompanyKey) is saved during software registration and should be backed up to a secure location. The key is also stored in the Windows Cryptographic Key Store on each workstation.

For complete details on the client-side PHI encryption architecture, see Security Architecture: Protected Health Information (PHI) Encryption.

Data in Transit Encryption

All network communications between Antigen Plus and database servers are encrypted using Transport Layer Security (TLS).

TLS Configuration

Azure SQL Database:

TLS 1.2 or higher required for all connections
Connection endpoint: *.database.windows.net (TCP port 1433)
TLS negotiation occurs automatically
Certificate validation ensures connection to legitimate Azure SQL servers
Microsoft manages TLS certificates

On-Premise SQL Server:

TLS 1.2 or higher recommended for all connections
TLS must be explicitly enabled and configured on SQL Server
Self-signed certificates or PKI-issued certificates can be used
Configuration steps provided in deployment documentation
Certificate validation should be enabled for production environments

TLS Security Benefits

Prevents eavesdropping - Network traffic cannot be read by third parties
Prevents tampering - Data cannot be modified in transit
Server authentication - Verifies connection to legitimate server
Works with client-side encryption - Provides defense in depth

Security Considerations

Even with TLS encryption, Antigen Plus implements client-side PHI encryption to provide additional protection. This ensures that:

PHI is never transmitted in plaintext, even within TLS tunnel
Database administrators cannot intercept PHI from network traffic
Compromise of TLS certificates does not expose patient data
Database backups cannot be read without private keys

For network configuration details, see Deployment Security: Network Requirements and Firewall Configuration.

Data at Rest Encryption

Database-level encryption protects data stored on disk, providing an additional layer of security beyond client-side PHI encryption.

Azure SQL Database

Transparent Data Encryption (TDE):

Automatically enabled for all Antigen Plus Azure-hosted databases
Encrypts entire database, backups, and transaction log files
Encryption is transparent to applications
Microsoft manages TDE encryption keys
No customer configuration required

Azure Infrastructure Security:

Physical security of Azure data centers
Network isolation and Azure Virtual Network integration options
Azure monitoring and threat detection services
Geo-redundant storage options

On-Premise SQL Server

Organizations hosting their own SQL Server databases are responsible for implementing data at rest encryption. Two primary options are available:

Option 1: Transparent Data Encryption (TDE)

Encrypts entire database at the file level
Available in SQL Server Enterprise Edition and some other editions
Transparent to applications (no code changes required)
SQL Server manages encryption/decryption automatically
Encryption keys must be backed up separately from database backups

TDE Configuration Requirements:

Create Database Master Key in master database
Create certificate for TDE
Create Database Encryption Key in user database
Enable encryption on the database
Backup certificate and private key to secure location
Test certificate restoration as part of disaster recovery procedures

Option 2: BitLocker Drive Encryption

Encrypts entire disk volumes containing database files
Available on all supported Windows Server versions
Protects all files on the volume (not just database files)
Operating system handles encryption/decryption
Recovery keys must be securely backed up

Best Practice:

Use TDE or BitLocker (or both) for HIPAA compliance
TDE provides granular database-level protection
BitLocker provides broader disk-level protection
Both options recommended for high-security environments
Either option satisfies regulatory requirements for encryption at rest

Encryption Layers Summary

Security Layer	Azure Deployment	On-Premise Deployment
Client-side PHI encryption	✓ AES-256, customer-controlled keys	✓ AES-256, customer-controlled keys
Data in transit encryption	✓ Required (TLS 1.2+)	✓ Recommended (TLS 1.2+)
Database-level encryption	✓ TDE (Microsoft-managed)	✓ TDE or BitLocker (customer-managed)
Antigen Plus access to PHI	✗ No (zero-knowledge)	✗ No (zero-knowledge)
Database admin access to PHI	✗ No (customer controls private keys)	✗ No (customer controls private keys)
Recovery from private key loss	Permanent data loss	Permanent data loss

For complete encryption architecture details, see Security Architecture: Protected Health Information (PHI) Encryption.

Connection String Security

Database connection strings contain sensitive credentials (usernames, passwords, server addresses) and must be protected from unauthorized access.

Connection String Storage

Default Storage:

Connection strings stored in connections.config file in the application installation folder
By default, stored in plaintext (readable by anyone with file system access)
This is suitable for development and testing but not recommended for production

Connection String Encryption (On-Premises Databases Only)

Note: The following information applies only to on-premises database deployments. For cloud (hosted) databases, connection strings are never stored on the workstation and do not require local encryption.

Administrators of on-premises systems can encrypt connection strings to protect database credentials:

Encryption Process (On-Premises Only):

Open Antigen Plus as an administrator.
Navigate to the File menu → Save configuration.
The application generates an encrypted version of connections.config.
This encrypted file uses the workstation’s cryptographic key.
Replace the plaintext connections.config in the installation folder with the newly encrypted file.

Important Considerations:

Encryption key is workstation-specific.
Each workstation must encrypt its own connection strings with its own key.
Encrypted connection strings from one workstation cannot be used on another.
The encryption process must be performed on each workstation individually.
Users will not be able to view plaintext connection strings after encryption.

Security Benefits:

Protects on-premises database passwords from casual file system access.
Prevents users from extracting credentials from the connections.config file.
Reduces risk of credential theft in the event a workstation is compromised.
Works alongside other measures (such as file permissions and disk encryption).

Limitations:

Does not protect against malware operating as the logged-in user.
Does not prevent extraction via memory dumps or advanced attacks.
Should be part of a defense-in-depth approach (including endpoint security and privileged access management).

For complete instructions, please see the Save configuration option in the File Menu documentation.

Connection String Best Practices (On-Premises Only)

Encrypt connection strings on all production workstations with on-premises database connections.
Use Windows Authentication when possible (to avoid storing passwords in connection strings).
Restrict file system permissions on the installation folder to prevent unauthorized access.
Use least-privilege database accounts – grant only necessary permissions.
Rotate database passwords regularly as required by your organizational policy.
Monitor database access for unusual or unauthorized connection attempts.
Use separate database accounts for different applications or functional roles.

Cloud database users: These best practices do not apply, as connection strings are not stored locally on workstations for cloud deployments.

Data Integrity Controls

Antigen Plus implements multiple controls to ensure the integrity and accuracy of data throughout its lifecycle.

Database-Level Integrity Controls

ACID Transaction Controls:

All database operations use SQL Server transactions
Changes are committed atomically (all or nothing)
Failed operations are rolled back completely
Prevents partial or inconsistent data states
Ensures referential integrity is maintained

Foreign Key Constraints:

Prevent orphaned or inconsistent records
Ensure relationships between tables remain valid
Enforce referential integrity at the database level
Cannot delete referenced records without first removing dependencies

Check Constraints:

Validate data ranges and formats
Ensure numeric values are within acceptable ranges
Prevent invalid data from being stored
Examples: expiration dates, antigen typing values, test result scores

Data Validation:

Input validation before data is written to database
Format checking for patient identifiers and dates
Range checking for test results
Prevents injection of malicious or malformed data

Application-Level Integrity Controls

Reagent Data Validation:

All imported reagent data validated against expected formats and ranges
Manufacturer lot data verified against published specifications
Antigen typing data checked for internal consistency
Invalid or suspicious data flagged for review

Test Result Validation:

Test results must conform to configured scoring system
Check cell thresholds enforced when configured
Results linked to specific reagent lots for traceability
Reagent expiration dates validated before use

Patient Data Validation:

Patient demographics validated for format and completeness
Date of birth checked for reasonableness
Required fields enforced based on configuration
Duplicate patient detection available

Audit Trail for Data Integrity

Change Tracking:

All patient information edits require a reason
User, date, and time recorded for all modifications
Cannot edit historical data without creating audit record
Audit trail cannot be deleted or modified by users

User Attribution:

Every saved panel records the user who created it
Reviews and approvals tracked by user and timestamp
User activity log captures all PHI access
Enables investigation of data integrity issues

Version Control:

Panels saved with timestamp and user identification
Historical versions preserved for regulatory compliance
Cannot delete panels less than 10 years old
Ensures long-term data integrity and availability

Access Control for Data Integrity

Role-Based Restrictions:

Read-only users cannot save data (prevents unauthorized modifications)
Save panels users cannot edit reagent data
Full access users can modify reagent data but not patient information
Administrators have full access with full accountability

Separation of Duties:

Data entry separated from data verification
Review function separate from testing function
Administrative functions restricted to administrators
Reduces risk of intentional or accidental data corruption

For more information on access controls, see Authentication and Authorization: Role-Based Access Control.

Intentional Data Modifications

Antigen Plus includes intentional data modifications for specific antigens when necessary for patient safety. These modifications are documented, traceable, and based on scientific evidence.

D-Variant Cell Safety Override

Background:

Some reagent cells are listed as D-positive (D+) on manufacturer package inserts but have D variants (Partial D or Weak D types) that are not serologically appropriate for ruling out Anti-D antibodies. These cells have missing epitopes or low antigen density that make them unsuitable for antibody exclusion.

Automated Safety Override:

When Antigen Plus detects that a manufacturer has annotated a cell as having a D variant:

The software automatically marks the D status for that cell as “Unknown” in the database
This prevents the algorithm from generating invalid antibody rule-outs based on inconclusive data
The cell cannot be used to rule out Anti-D antibodies
This modification is applied automatically during lot import

User Experience:

Users may observe D-positive cells appearing as “Unknown” for the D antigen
This discrepancy between manufacturer labeling and Antigen Plus display is intentional
The override protects patient safety by preventing false rule-outs
No user action is required; the override is automatic

Traceability:

Override is based on manufacturer annotations in source data
Original manufacturer data is preserved for reference
Changes are consistent and reproducible across all workstations

Scientific Basis:

D-variant cells are unsuitable for Anti-D rule-out because:

Missing epitopes may not react with certain Anti-D antibodies
Low antigen density may produce false-negative results
Use of D-variant cells could lead to incorrect antibody identification
Patient safety requires conservative interpretation (marking as Unknown)

For complete details on this and other exclusion rules, see Exclusion Policy in the User Guide.

Other Data Integrity Features

Blank Antigens:

Blank antigens cause the known positive antithetical partner to be considered heterozygous for exclusion
Blank antigens themselves are not considered positive or negative
Will not be considered for exclusion
This conservative approach prevents false rule-outs

Manufacturer Data Corrections:

Occasionally manufacturers issue corrections to reagent lot data
Corrections can be imported via lot update downloads
All data modifications are logged in the audit trail
Users should verify critical data against manufacturer documentation

Data Security Best Practices

Encryption Best Practices

Maintain Private Key Backups:
- Back up .APCompanyKey file immediately after registration
- Store backups in multiple secure off-site locations
- Use formal key escrow procedures with documented access controls
- Test key recovery procedures annually
- Document key backup locations and recovery procedures
Enable Database-Level Encryption:
- Azure customers: TDE is automatic, no action required
- On-premise customers: Enable TDE or BitLocker on database servers
- Back up TDE certificates separately from database backups
- Test database restoration with encrypted backups
Secure Data in Transit:
- Verify TLS is enabled for all database connections
- Use TLS 1.2 or higher exclusively if possible
- Ensure certificates are valid and not expired
- Monitor for TLS connection failures
Encrypt Connection Strings:
- Use Save configuration to encrypt connection strings on all workstations
- Restrict file system access to installation folders
- Use Windows Authentication when possible to avoid storing passwords

Data Integrity Best Practices

Regular Backups:
- Implement automated daily database backups (on-premise customers)
- Store backups in secure off-site location
- Test restoration procedures regularly
- Maintain backup retention consistent with regulatory requirements
- Azure customers: Verify point-in-time restore settings are appropriate
Audit Log Review:
- Regularly review user activity logs for suspicious patterns
- Investigate unexpected data modifications
- Export audit logs periodically for long-term retention
- Include audit review in security incident response procedures
Data Validation:
- Verify imported reagent data against manufacturer documentation
- Investigate discrepancies between expected and actual data
- Review automated safety overrides (e.g., D-variant cells) for understanding
- Train users on the importance of accurate data entry
Access Control:
- Assign minimum necessary privileges to each user
- Regularly review and update user access levels
- Disable accounts for departed employees immediately
- Monitor for privilege escalation attempts

Compliance Considerations

The data security measures implemented in Antigen Plus support compliance with:

HIPAA Security Rule:

Encryption of PHI at rest and in transit (required)
Access controls and audit logging (required)
Integrity controls to prevent improper alteration (required)
Transmission security for ePHI (required)

HIPAA Breach Notification Rule:

Encrypted PHI may be excluded from breach notification if decryption keys are not compromised
Client-side encryption provides additional assurance for breach notification analysis

FDA 21 CFR Part 11:

Electronic records with audit trails
Electronic signatures for reviews and approvals
System access controls and user authentication
Data integrity and validation controls

AABB Standards:

Reagent data traceability and version control
Quality control documentation
Standard operating procedure compliance support
Review and approval workflows

Data Security Checklist

Use this checklist to ensure comprehensive data security:

For additional security information, see:

Security Architecture - Detailed encryption architecture
Deployment Security - Database security configuration
Authentication and Authorization - Access control details