Patient and participant data
If your research involves human subjects — patient samples, clinical trial data, donor records — anonymise the data before it enters Seal. Seal should store coded research data, never directly identifiable patient information.What to strip
Replace every direct identifier with a study code or participant ID. The mapping between codes and real identities stays in a separate, access-controlled system outside Seal.| Data element | Identifiable (do not store in Seal) | Anonymised (store in Seal) |
|---|---|---|
| Name | Jane Smith | PTX-0042 |
| Date of birth | 15 March 1987 | (removed — or age range if risk assessment permits) |
| Address | 123 Main St, Wellington | (removed entirely) |
| Phone / email | jane@example.com | (removed entirely) |
| National ID / NHI | ABC1234 | (removed entirely) |
| Sample label | ”Smith, Jane — blood draw 12/01” | PTX-0042-BLD-001 |
| Instrument file metadata | Patient name in FCS file headers | Participant code only — strip headers during export or use instrument software to configure coded output |
How to set this up
1. Define a coding scheme — assign each participant a unique, non-sequential code (e.g.PTX-0042, DON-1187). Use your institution’s existing participant registry or clinical database to generate and manage codes.
2. Configure instrument output — most instruments (flow cytometers, sequencers, plate readers) allow you to set sample identifiers at acquisition time. Enter the coded ID, not the patient name. For instruments that embed operator-entered metadata in file headers, configure the acquisition template to use codes only.
3. Build the linkage key outside Seal — the mapping from PTX-0042 → Jane Smith, DOB 15/03/1987, NHI ABC1234 lives in a separate system: a clinical database (e.g. REDCap), a restricted-access registry, or a dedicated institutional system. This system has its own access controls and audit trail. Seal never sees it.
4. Set up Seal templates with coded fields — during implementation, Seal’s templates are configured with fields for participant codes, sample barcodes, and study references — not names, dates of birth, or contact details. The template structure makes it impossible for users to accidentally enter identifiable data in the wrong place.
5. Barcode physical samples — every sample in Seal is tracked by a machine-readable barcode ID. Scientists scan barcodes to log receipt, storage location, retrieval, and disposal. The barcode links to the participant’s coded record in Seal, never to their identity.
6. Review before go-live — during validation, audit a sample of records to confirm no identifiable data has entered Seal. This is a standard implementation checkpoint.
What goes where
| Data | Where it lives | Example |
|---|---|---|
| Coded research data | Seal | Participant ID, sample barcodes, experiment results, instrument outputs, analysis files |
| Linkage key (code → identity mapping) | Separate system, outside Seal | Clinical database, REDCap, or institutional participant registry |
| Consent records | Your institution’s consent management system | Ethics approval reference numbers can be stored in Seal as metadata |
Why this approach works
- Low-risk by design — Seal holds coded data with no way to re-identify individuals. It falls outside the scope of most PII breach notification requirements.
- Safe support and troubleshooting — Seal’s support team assists with your platform without exposure to patient identities
- AI and search work safely — Seal’s search, dashboarding, and AI assistant operate on coded data only
- Regulatory alignment — satisfies GDPR pseudonymisation, HIPAA Safe Harbor de-identification, New Zealand’s Privacy Act 2020, and equivalent frameworks in other jurisdictions
Confidentiality scope and agreement
Prior to implementation, Seal and the customer establish a clear data confidentiality framework:- Data controller: the customer — responsible for classifying data sensitivity and ensuring compliance with applicable regulations
- Data processor: Seal — processes data only on behalf of the customer and according to their instructions
Regulatory framework
| Regulation | Scope | How Seal supports compliance |
|---|---|---|
| GDPR (EU) | Personal data of EU residents | Pseudonymisation, data minimisation, right to erasure via API, DPA available |
| HIPAA (US) | Protected health information | De-identification (Safe Harbor method), BAA available on request |
| Privacy Act 2020 (NZ) | Personal information held by NZ agencies | Coded data approach, data sovereignty options, breach notification support |
| PIPEDA (Canada) | Personal information in commercial activity | Consent-based processing, data export and deletion via API |
Implementation and testing
During implementation, use anonymised or synthetic data to validate workflows, integrations, and configurations. This allows full testing without exposing real sensitive information.- Anonymised data — mirrors actual data structure with all identifiers replaced by codes
- Synthetic data — generated data that simulates typical inputs and results
Data protection
Seal complies with applicable data protection laws and provides documentation for privacy assessments and audits. Additional security controls are available on request. See Data storage and security, Backup and disaster recovery, and Infrastructure for technical details.Any questions or privacy inquiries?Email support@seal.run.