Cryopreservation research often works on material that came from a person: oocytes, sperm, embryos, cord blood, tissue biopsies, primary cell isolates. Once a vial leaves the freezer and its record enters a LIMS, an electronic lab notebook or a PostgreSQL table, the ethical status of the material travels with the data. WIA-CRYO-010 Phase 4 does not contain a dedicated privacy section. What it does contain is the plumbing that decides whether privacy and consent obligations can be honored in practice: adapters from LIMS, ELN export plugins, instrument feeds, JSONB storage, role definitions, audit records, nightly backups, alert rules and test suites.
This chapter reads that plumbing through the lens of research ethics and data protection. Two limits apply. First, the Phase 4 text defines no consent fields, no legal-basis fields and no patient identifiers. Where this chapter describes consent handling, it describes a pattern that implementers must build around the standard, not something the standard specifies. Second, the legal frameworks below are summarized only at the level of well-established principles. Your institution's counsel and ethics committee decide how they apply to a given study.
The integration points that matter most are these:
In Korea, the Bioethics and Safety Act governs research involving human subjects and human-derived materials. Embryos, gametes and related materials fall under particular scrutiny, and the Act ties research to institutional ethics review and to written informed consent. The review body is the institutional review board (IRB), referred to in the statute as an institutional bioethics committee. General personal-information duties under Korea's Personal Information Protection Act sit alongside it.
For a cryopreservation lab the practical consequence is that an experiment record is rarely only a technical object. Before an experiment on human-derived material is created, there is normally an approved protocol. The experiment must stay within that protocol's scope: the material types, the purposes, the sharing arrangements and the retention period. The IRB approves a protocol, not a database, so the integration team needs a way to prove that data flowing through the adapter belongs to an approved study.
A workable review procedure for an integration project has these steps:
When a European site contributes to or reads from a shared WIA-CRYO-010 repository, the GDPR applies to any record that relates to an identifiable person. Health and genetic data belong to the special categories of personal data. Processing them requires a lawful basis plus an additional condition, and scientific research is one recognized condition, subject to safeguards. Several GDPR concepts map directly onto the integration design.
HIPAA applies to covered entities (such as providers and health plans) and to business associates acting for them. It protects individually identifiable health information. A cryopreservation program embedded in a hospital, a fertility clinic or a biobank affiliated with one often falls inside it. Research use of such information is normally permitted through one of three routes:
De-identification can follow either of two methods: removing a list of eighteen identifier categories (the Safe Harbor method), or a statistician's expert determination that re-identification risk is very small. Two points from that list bear directly on this standard's records. The identifier categories include dates more specific than the year, so a precise assessmentTime on a record linked to a patient is a re-identification concern. They also include any unique code that could be used to link back, unless that code is not derived from the person's information and its re-identification key is never disclosed. A sample identifier that embeds a medical record number fails that test.
The Security Rule adds administrative, physical and technical safeguards, such as access control, audit controls and transmission security. Phase 4's role definitions, audit log and TLS requirement are the technical expression of those obligations, though the standard itself does not claim HIPAA compliance.
Phase 4 describes the data flow as a LIMS feeding an adapter, which produces standardized JSON-LD for a repository. Its mapping table is deliberately short:
{
"lims.sample_id": "sampleId",
"lims.operator_name": "operator",
"lims.test_date": "assessmentTime"
}Each line is a privacy decision. The mapping of lims.sample_id to sampleId is safe only if the source identifier is already a pseudonym. If a LIMS builds its sample numbers from patient or donor numbers, the adapter should translate them through a lookup that stays inside the source institution. The mapping of lims.operator_name to operator moves the name of a staff member into a shared repository. Staff are data subjects too, and a European employer needs a basis for exporting their names. A pseudonymous staff code with a local directory is the more defensible choice. The mapping of lims.test_date to assessmentTime is a timing field. It is usually harmless for technical analysis, but it is exactly what HIPAA Safe Harbor and re-identification attacks on small cohorts care about.
The ELN path has a different risk. The Phase 4 plugin sketch builds a document with @context, @type, experimentId and title, and the ellipsis in the example hides whatever else the plugin copies. Entry titles and narrative text are written by people in a hurry and sometimes contain donor initials or clinic references. An export plugin should transmit only structured fields, apply a title policy, and fail visibly when a field does not validate, rather than copying free text silently.
Instrument exports raise a similar issue. The flow cytometry example references a raw file (sample001.fcs) next to the structured results. FCS files carry their own header keywords, and operators sometimes put sample or donor names there. Check the raw file's metadata before it is attached to a shared record, not only the JSON that describes it.
Informed consent for research on human-derived material is specific. The participant agrees to defined uses, defined sharing and a defined retention period, and may withdraw. Typical consent forms address the nature of the research, the material collected, risks and benefits, confidentiality, secondary use, sharing with other institutions, storage duration and the right to withdraw. The exact list depends on the statute, the IRB template and the study, and the Phase 4 text does not enumerate it.
The standard's experiment records therefore need to be tied to consent without containing it. A defensible pattern is:
sampleId.The same mechanism supports provenance, the ability to show where a result came from and under what authority. The Phase 4 annexes list W3C PROV-DM among the informative cross-walk references, and a provenance graph that links an experiment to its approved protocol answers the question an auditor or IRB will ask: what permitted this data to exist?
Data classification is an implementer's policy decision. The standard does not define classification levels, so the three levels below are an illustrative pattern, not part of WIA-CRYO-010.
| Level | Typical content | Handling |
|---|---|---|
| Restricted | Anything that can re-link a code to a person: lookup tables, consent register, raw files with identifying headers | Stays at the source institution; not replicated to the shared repository |
| Controlled | Pseudonymous experiment records, viability results, protocol parameters tied to human-derived material | Role-restricted access, audit logged, encrypted at rest and in transit |
| Open | Published schemas, aggregate statistics with no small cells, reference method descriptions | May be cached and served publicly |
Phase 4 supplies the role model that enforces the middle level. Its example defines three roles:
roles:
- name: researcher
permissions: [read, write:own]
- name: data_manager
permissions: [read, write:all, delete:own]
- name: admin
permissions: [read, write:all, delete:all, admin]The write:own and delete:own scopes are the practical ethics feature. A researcher who can alter only their own records cannot quietly change another team's results. Note, however, that read is unscoped in all three roles. A site handling human-derived material will probably need to narrow it by study or protocol, so that a researcher on one approved project cannot read another project's records. Separating the admin role from the people who analyze data also prevents the person with delete rights across the system from being the same person whose results are in question.
Phase 4 names three cryptographic baselines: AES-256 for data at rest, TLS 1.3 for data in transit, and bcrypt hashing for API keys. For privacy purposes they cover different threats. Encryption at rest limits the damage from a lost disk or an exposed database snapshot. Transport encryption protects the temperature-logger publisher, the bulk import and the API from interception. Hashed API keys mean that a stolen credential table does not hand over working keys. None of these controls prevents an authorized insider from reading what they are allowed to read. That is the job of the access model and the audit trail.
The audit record in the standard is compact:
{
"action": "UPDATE",
"resourceType": "Experiment",
"resourceId": "exp-2025-001",
"userId": "user-123",
"timestamp": "2025-01-21T10:15:00Z",
"changes": {...}
}It answers who did what to which resource and when. Two cautions follow. The changes object can itself contain regulated content if it records before-and-after values, so the log needs the same protection as the data it describes. And userId and resourceId should be opaque identifiers, because a log that reads like a patient list defeats the pseudonymisation applied everywhere else.
One paragraph of governance overhead applies here. The standard's annexes group deployments into conformance tiers, ask that a deployment's tier be declared in its OpenAPI document, and require the highest tier to keep evidence for at least seven years. The annexes also say that where a regulator demands longer retention, the deployment policy must extend it. That arrangement matters to ethics and privacy only because the retained evidence is mostly audit data, and the retention clock for audit data has to be reconciled with the deletion promises made to participants.
The 3-2-1 rule in Phase 4 asks for three copies of the data, on two media types, with one copy off-site. The sample script dumps the cryo_research database with pg_dump, compresses the result and copies it to an S3 bucket. This is good resilience engineering, and it creates three separate privacy questions.
The PostgreSQL design helps here. Each experiment is a single row with a JSONB document, so removing one participant's experiments is a bounded query rather than an archaeology exercise. The expression indexes on @type and on the lifecycle status let a data manager find, for example, every record in a given state when a withdrawal or an ethics hold arrives. The MongoDB validator that requires @context, @type and experimentId and pins the context pattern guards against another privacy failure: documents of unknown shape that nobody has reviewed for identifiers.
Breach rules are set by statute, not by this standard, but the monitoring in Phase 4 determines whether a breach is noticed. Under the GDPR, a controller must notify the supervisory authority of a personal-data breach without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to risk individuals' rights. HIPAA's Breach Notification Rule requires notice to affected individuals without unreasonable delay and no later than 60 days after discovery, with further notices to regulators in defined cases. Korean law likewise requires notification to data subjects and the authorities in defined circumstances. A practical response runbook has these steps:
userId.The monitoring section of Phase 4 tracks response time, error rate, ingestion rate and storage usage, and includes two sample alert rules. One is a high error rate. The other is low_viability_detected, which notifies a researcher when viability falls below 70%. The second illustrates a privacy trap, because the notification is an email. Alert messages should reference the opaque experiment identifier and a link into the access-controlled system. They should never include donor details in the message body. Ingestion-rate and error-rate dashboards should also be aggregated across tenants without exposing any one site's data.
Testing completes the picture. Phase 4 shows unit tests for the viability calculation, integration tests that post an experiment and expect a 201 response with an experimentId, and load tests against the experiments endpoint. Add privacy-specific tests to the same suites. Submit a record with a disallowed identifier and confirm it is rejected. Export an ELN entry and confirm that free text is stripped. Run the bulk import with a withdrawn code and confirm it is refused. Load tests should use synthetic data, never copies of real participant records.
The central point of this chapter is that ethics and privacy requirements land in specific places in the integration architecture. The Bioethics and Safety Act and the IRB decide whether a study, and therefore a data flow, may exist. GDPR and HIPAA decide how identifiable information may move, be stored and be shared. The adapter's mapping table, the ELN plugin, the role definitions, the audit record, the backup script and the alert rules are where those decisions become either enforced or merely documented.
Three themes recur. First, pseudonymous codes, coarse dates and structured fields keep most of the repository out of the most sensitive regulatory territory, but only if the adapters are disciplined about what they copy. Second, consent has to be checkable and withdrawable, which means a register outside the shared repository and a deletion path that reaches backups. Third, audit evidence and participant deletion have to be reconciled by design rather than by exception. The standard's own open questions point at the unresolved areas: privacy-preserving aggregation of telemetry and alignment of retention rules across jurisdictions.
The next chapter moves from the rules that constrain these systems to how they are deployed and run day to day. The role model, the audit trail and the backup rotation described here become the baseline that operational routines, capacity decisions and incident handling must respect.