Amy-Term
← Back to documentation

GDPR & Privacy Statement

This statement describes how Amy-Term is designed to support GDPR-compliant deployments, and what remains the responsibility of the deploying organisation.

Scope Data Roles Lawful basis Minimisation Retention Security Rights Governance
Practical framing: Amy-Term is a terminology and terminology-federation platform. In its intended configuration it stores and distributes terminology artefacts (CodeSystem, ValueSet, ConceptMap), which are generally non-personal data. GDPR relevance arises primarily from user administration, audit/telemetry, and any optional integration patterns.

1. Purpose and scope

Document date: 2025-12-26 Applies to: UI + API + federation Default: non-patient data

This statement covers how Amy-Term supports GDPR-aligned deployment controls. It is not a substitute for the Controller’s legal analysis, Record of Processing Activities (RoPA), or a Data Protection Impact Assessment (DPIA) where required.

Not a patient record system: Amy-Term is not designed to store patient records. If the deployment ingests patient identifiers, clinical content, or special category data, the Controller must perform a DPIA and define lawful basis, retention, access controls, and safeguards appropriate to that processing.

2. Data categories potentially processed

Administrative (typical)

  • User account data: username; optionally email; roles; password hashes; timestamps.
  • Session/auth metadata: session identifiers; login events; role assertions.
  • Federation metadata: node identity; namespace identifiers; bundle identifiers; signatures; audit trail.

Operational (typical)

  • Application logs: timestamp; endpoint path; HTTP status; correlation ids (if used).
  • Security/audit logs: admin actions (create user, publish content, capture/export bundles).
  • Infrastructure logs: reverse proxy / WAF / load balancer logs (deployment-specific).

What should not be logged

  • Patient identifiers or clinical payloads in request/response bodies.
  • Secrets such as API keys, database passwords, signing keys.
  • Full request headers that may contain authentication tokens.

3. Roles and responsibilities

  • Controller: typically the deploying organisation (hospital network, ministry, national service owner).
  • Processor: if a third party hosts/operates Amy-Term on behalf of the Controller, the operator is typically a Processor.
Operational ownership: define who owns user lifecycle, audit review, backup/restore, incident response, and federation governance (signing keys, rotations, trust onboarding).

4. Lawful basis (typical)

The lawful basis depends on the Controller’s context. Typical bases for the platform’s own administrative processing include:

  • User accounts and access control: performance of a contract and/or legitimate interests (security and access governance).
  • Operational and security logs: legitimate interests (service security, incident response, reliability).
Reminder: if special category data is introduced by an integration pattern, Articles 6 and 9 analyses become relevant and will be deployment-specific.

5. Data minimisation and default configuration

  • Store only the minimum administrative fields needed for authentication/authorisation and auditability.
  • Limit log verbosity; avoid request-body logging.
  • Use role separation (Viewer vs Admin) to minimise access to admin-only functions.
  • Apply namespace governance to prevent cross-tenant or cross-region data mixing.
Operator checklist (copy/paste) 
# Minimum GDPR-aligned operational defaults
# 1) Do not log request bodies (especially for FHIR endpoints)
# 2) Enable time-based log rotation + deletion
# 3) Use TLS for non-local deployments
# 4) Enforce least-privilege DB roles
# 5) Separate admin and viewer roles

6. Retention

  • Logs: retain according to deployment policy (recommended: time-based rotation and automatic deletion).
  • User accounts: retained for the life of the deployment or until deleted by an authorised administrator.
  • Federation audit records: retained according to governance/audit policy defined by the Controller.
Recommendation: align retention with purpose. Security telemetry should be long enough for incident detection and forensics, but not indefinite by default.

7. Security measures (technical and organisational)

  • Role-based access controls and session-based authentication for the UI.
  • TLS recommended for all non-local deployments.
  • Database backup/restore procedures; least-privilege database roles.
  • Federation bundle signing and verification to protect integrity during distribution.
  • Change control for terminology updates and federation distribution (approvals, release notes, auditability).
Useful documentation links

8. Data subject rights

Data subject rights requests (access, rectification, deletion) are handled by the Controller. For Amy-Term, this typically applies to user account data and operational logs relating to identified staff members.

  • Define a process for account removal/deactivation and role review.
  • Define a process for log redaction or extraction where applicable (deployment-specific).

9. Contact and governance

  • Assign a service owner (Controller) and, if applicable, a Processor operations owner.
  • Define procedures for account lifecycle, incident response, backup, and audit review.
  • For larger deployments: maintain RoPA; conduct DPIA where required; document federation governance and key management.

Document: gdpr_privacy.html