Privacy Policy
Effective date: 12 June 2026
This policy explains how Bitsort ApS processes personal data in connection with Codon, a clinical terminology management service (a FHIR R4 terminology server). It is written to meet the information duty in GDPR Article 13.
Who we are and our role
Codon is operated by Bitsort ApS (CVR 37759333), Tobaksvejen 20, 2860 Søborg, Denmark, trading as TheraponSystems. For questions about this policy or your personal data, contact privacy@bitsort.io.
We act in two distinct roles:
- As data controller for the account, billing and operational data we process to provide and secure the service — described under “Data we process” below.
- As data processor for any personal data you process through the service on your own behalf, including clinical free text submitted under the optional PHI de-identification add-on. That processing is governed by the Data Processing Agreement (DPA) signed with each customer, who remains the controller for it.
Data we process
Terminology data (non-personal)
Clinical terminology codes, display texts, hierarchies and cross-system mappings from published standards (SNOMED CT, ICD-10, LOINC, SKS and others). This is reference data and contains no personal information.
Account and operational data (controller role)
As controller we process the personal data below — with the purpose, legal basis and retention period for each:
| Data | Purpose and legal basis | Retention |
|---|---|---|
| User accounts (email, name, password hash, OAuth/OIDC subject) | Authentication and account management — contract performance (Art. 6(1)(b)) | Until account deletion or tenant erasure |
| API key identities (user ID) | Authentication and authorisation — contract performance (Art. 6(1)(b)) | Until the key is revoked or tenant erasure |
| Billing data (plan, Stripe customer reference, invoices, usage records) | Invoicing and contract performance — Art. 6(1)(b); and legal obligation (Art. 6(1)(c), bookkeeping) | 5 years (Danish bookkeeping law) |
| Audit log (hash-chained who/what/when metadata, user ID) | Security and accountability — legitimate interest (Art. 6(1)(f)) and legal obligation (Art. 6(1)(c)) | Retained — see the retention exception below |
| API request logs (masked IP) | Security monitoring — legitimate interest (Art. 6(1)(f)) | 30 days |
| Mapping audit fields (createdBy, reviewedBy — user ID) | Regulatory compliance and traceability — legal obligation | Lifetime of the mapping; history ledger retained |
| AI suggestion consent records | Consent for AI mapping suggestions — Art. 6(1)(a) | Lifetime of the mapping |
| Problem reports from the website (IP, user agent) | Bug fixing — legitimate interest (Art. 6(1)(f)) | 90 days |
User identity fields (email, name, OAuth subject) are stored application-layer encrypted (AES-256-GCM) in addition to the disk- and transport-layer encryption described below.
Patient data (PHI) — only with the PHI add-on
The base Codon product processes no patient data. Customers using only terminology services (lookup, validation, mapping, search, value sets) never submit patient records, clinical notes, person-linked diagnoses or biometric data, and we process none.
Customers who have contracted the PHI de-identification add-on (a separately contracted feature requiring a signed DPA) submit clinical free text — which may contain special-category health data (GDPR Art. 9) — for de-identification. For that processing:
- The clinical text is processed in memory and is not retained: it is not written to the database, search index or application logs.
- All processing runs locally on our infrastructure. No clinical text is sent to any external AI provider or other third party.
- The single opt-in exception is the consistency-pseudonym store, which lets the same patient receive the same pseudonym across documents; these mappings are encrypted under the customer tenant's own key and are deleted — and rendered cryptographically unrecoverable — on tenant erasure (GDPR Art. 17).
- De-identified output is pseudonymised personal data under GDPR, not anonymised data; the customer, as controller, remains responsible for how it is used.
For this processing we act solely as processor under the customer's DPA. Data-subject requests concerning it should be directed to the customer (the controller); we assist per the DPA.
How we protect your data
- Encryption in transit. TLS 1.3 with HSTS enabled.
- Encryption at rest. LUKS / provider-encrypted block storage (AES-256), plus application-layer AES-256-GCM under a per-tenant key hierarchy for sensitive fields — so one tenant's data can never be decrypted with another tenant's key. Backups are AES-256 encrypted with point-in-time recovery.
- Tenant isolation. Cryptographic (distinct per-tenant keys) layered over PostgreSQL Row-Level Security on every tenant-scoped table.
- Access control. Role-based and per-resource access control, JWT and API-key authentication, optional per-tenant mandatory MFA, brute-force lockout and token revocation. API keys are accepted only in request headers, so credentials never appear in access, proxy or browser-history logs.
- Tamper-evident audit log. A hash-chained, append-only log records who changed what and when — metadata only, never clinical content, passwords or secrets.
- Log minimisation. IP addresses are masked before storage (last IPv4 octet zeroed) and clinical codes are redacted from request logs.
AI processing
AI-assisted features can run fully locally: in a sovereign deployment all inference stays on the deployment's own infrastructure. On this hosted evaluation, the text-generation assists (mapping suggestions, form assist) use an EU-resident model provider, disclosed in-product under the EU AI Act Art. 50. Clinical NER and PHI de-identification always run locally and never leave the deployment — no clinical text or PHI is sent to any external AI service by default, enforced in software. Embedding-based similarity runs on local infrastructure. The X-AI-Consent header is required for AI mapping suggestions as a clinical-safety acknowledgement.
Recipients and sub-processors
All terminology data and all PHI-add-on data are stored and processed on infrastructure hosted in Scandinavia. In the default configuration the following processors receive limited operational personal data:
| Processor | Purpose | Location | Personal data and transfer safeguard |
|---|---|---|---|
| Hetzner Online GmbH (hosted service); self-operated for sovereign / on-premise deployments | Server hosting / infrastructure | Germany / Finland (EU/EEA) | Stored data stays on EU/EEA infrastructure, encrypted as above — no transfer safeguard needed. Sovereign/on-premise deployments run on the customer's own or Bitsort-operated infrastructure |
| Stripe Payments Europe Ltd | Payment processing and billing | Ireland (EU) | Name, email, payment and invoice data; onward transfer to Stripe, Inc. (US) under EU Standard Contractual Clauses |
| Brevo (Sendinblue SAS) | Transactional email (verification, magic links, password reset, notifications) | France (EU) | Email address and name — EU/EEA, no transfer safeguard needed |
| Friendly Captcha GmbH | Bot protection on sign-up | Germany (EU) | Anonymised request signals, no account data — EU/EEA, no transfer safeguard needed |
On this hosted evaluation, text-generation assists use an EU-resident AI model provider, disclosed in-product under the EU AI Act Art. 50; no clinical text or PHI is sent to it. Sovereign / on-premise deployments use local inference only, with no external AI processor. Optional terminology-source downloads (for example from the US National Library of Medicine) are inbound content downloads only — no personal data is sent.
Sovereign mode
Codon supports a sovereign deployment profile in which the service refuses to start if any outbound integration (Stripe, Brevo, Friendly Captcha, remote AI) is configured. Under sovereign mode the only remaining recipient is the hosting provider, and no personal data leaves the EU/EEA under any circumstance.
Cookies and local storage
Codon uses only strictly necessary cookies — those required to sign you in, to protect requests against cross-site request forgery, and, during card payment, to prevent payment fraud. We set no analytics, advertising or tracking cookies and do not profile you. Because every cookie we use is strictly necessary, no consent banner is required under the ePrivacy rules and none is shown.
| Name | Purpose | Lifetime | Category |
|---|---|---|---|
nexus_session | Holds your signed-in session (HttpOnly; not readable by scripts) | Until the session expires or you sign out | Strictly necessary |
csrf | Cross-site request forgery protection (double-submit token) | Until the session expires or you sign out | Strictly necessary |
__stripe_mid, __stripe_sid | Set by Stripe.js on the billing page when you make a card payment, for payment-fraud prevention | Session (__stripe_sid) up to 1 year (__stripe_mid) | Strictly necessary (set only when you pay) |
We also store your light/dark theme preference in your browser's local storage. This is a functional preference, contains no personal data, and is never transmitted to us. The sign-up bot-protection widget (Friendly Captcha) is cookieless by design.
Your rights
Under GDPR you have the following rights. To exercise them, contact privacy@bitsort.io; we respond within 30 days (GDPR Art. 12(3)).
- Access (Art. 15). Request all data associated with your account.
- Rectification (Art. 16). Account details are self-service editable; contact us for anything else.
- Erasure (Art. 17). Individual: account deletion, with audit fields (createdBy/reviewedBy) anonymised. Tenant-level: full erasure deletes every tenant-scoped row in one transaction and cryptographically shreds the tenant's encryption key, rendering the tenant's encrypted data — including backup copies, once pre-erasure backups age out — permanently undecryptable.
- Portability (Art. 20). A tenant export endpoint streams your complete data set as machine-readable NDJSON; mappings are additionally exportable as FHIR ConceptMap JSON or CSV.
- Object (Art. 21). Object to processing based on legitimate interest.
- Restrict (Art. 18). Restrict processing while a complaint is resolved.
For personal data processed under the PHI add-on the customer is the controller — direct such requests to the customer; we assist per the DPA.
Retention exception — audit log
The hash-chained audit log is not deleted on erasure. Removing entries from the middle of the chain would break the tamper-evidence guarantee for all customers. Retention rests on GDPR Art. 17(3)(b) and 17(3)(e) (legal obligation — security and accountability under Art. 32 and Art. 30); audit entries contain who/what/when metadata only and never the personal content that was erased.
Complaints
You have the right to lodge a complaint with a supervisory authority. The lead authority is Datatilsynet (the Danish Data Protection Agency), Carl Jacobsens Vej 35, 2500 Valby, Denmark — www.datatilsynet.dk.
Changes to this policy
We will notify customers of material changes to this privacy policy at least 30 days before they take effect.
Contact
Data protection contact: dpo@bitsort.io
General privacy enquiries: privacy@bitsort.io