GDPR Art. 30 requires a
controller to keep a record of its processing activities, and Art. 30(2)
requires a shorter one from a processor acting on a controller’s behalf. Both
records are the organisation’s, not the software’s. This page is a template for
the part a FerroEHR deployment contributes: the activities the software
performs by design, with the fields it can answer already filled and the fields
only you can answer marked.
FerroEHR is software rather than a controller or a processor, so nothing here
is a record on anyone’s behalf. It is a starting draft that saves you reading
the source to find out what the server does with personal data.
Copy the activity tables below into your own register and fill the three
columns nobody but you can fill: the purpose your organisation processes
for, the lawful basis it relies on, and the recipients it discloses to.
Delete any activity your deployment has switched off. Activities 6 and 7 are
off by default and only apply if you turned them on.
The identity fields Art. 30(1)(a) asks for are yours in every case:
Field
Value
Controller (name, contact)
your organisation
Joint controllers, if any
yours
Representative in the Union, if applicable
yours
Data protection officer
yours
Processors engaged
yours: the PostgreSQL operator, and any object store, message broker, terminology server or identity provider the deployment is configured against
yours: the care or research purpose the repository serves
Categories of data subject
Patients and other record subjects; the health professionals recorded as composers, performers and participants
Categories of personal data
Clinical content as the operational templates define it, in the ehr schema and its cold archival tier. Special-category health data under Art. 9. The subject appears as an opaque pseudonym once [privacy] subject_namespaces is declared
Recipients
yours: whoever the API is exposed to. The software discloses nothing on its own
Third-country transfers
yours: wherever the deployment and its backups run
Retention
No automatic expiry. Content leaves only by an administrator’s deletion; archiving moves it to the cold tier without expiring it
Security measures
Least-privilege database roles per pseudonymisation domain; a data-minimisation pass over every write; FORCE ROW LEVEL SECURITY for tenant scoping; TLS; authentication and layered authorization
yours: the reporting, cohort or operational purpose queries serve
Categories of data subject
As activity 1
Categories of personal data
Whatever the query projects out of stored clinical content
Recipients
yours
Third-country transfers
yours
Retention
Results are not stored. Stored query definitions are, as AQL text
Security measures
Queries run on the clinical credential only, so no query can reach the demographic or linkage domain; the planning gate refuses constructs the active specification generation does not define; result caps and statement timeouts bound one query’s reach
Note
No threshold is applied to a result set. A query returning one row about one
rare condition is served like any other. Small-cell suppression is designed
alongside the cross-domain cohort query and is not built:
#3159.
Holding who the record subjects are, and resolving a person to their record where a caller is entitled to
Categories of data subject
Patients, and the parties a record refers to
Categories of personal data
Parties in the demographic schema with names, addresses and contacts as the template defines them; protected national identifiers sealed in national_identifier; the party-to-EHR map in linkage, which holds identifiers and a validity period and nothing else
Recipients
yours
Third-country transfers
yours
Retention
Parties leave only by an administrator’s deletion. A linkage mapping is never deleted: a merge or a split closes its period and opens a successor
Security measures
Three schemas under three roles, revoked from each other in both directions and checked at boot; AES-256-GCM sealing with a keyed HMAC-SHA-256 digest for lookup, under per-domain and per-tenant subkeys; the one crossing runs in the application over two pools and writes an access record
Recording who reached what, which EHDS Annex II 3.2 requires of an EHR system and which NEN 7513 specifies the content of for Dutch deployments
Categories of data subject
The record subject, and the person who accessed the record
Categories of personal data
Per access: the accessing person and organisation, the roles held, the object and its domain, the outcome, the declared purpose of use, the configured legal basis and the time. Refusals are recorded too, unattributed where no principal was established
Recipients
yours: the local repository, plus any syslog or FHIR-feed Audit Record Repository configured
Third-country transfers
yours
Retention
[audit.store] retention_days, 0 meaning forever, reaped hourly otherwise. Where an active identifier rule names a jurisdiction with a registered floor, a shorter value is refused at boot
Security measures
Records are hash-chained and verifiable with audit.verify_audit_chain(); the runtime role may insert and stamp delivery and nothing else; the audit schema sits outside all three pseudonymisation domains; the syslog feed can run over RFC 5425 TLS with a client certificate
Telling downstream systems that a commit happened, when [events] is enabled
Categories of data subject
Record subjects, indirectly
Categories of personal data
A PHI-free envelope: the contribution id, the EHR id, the commit instant, and per version the object id, kind, version number, change type and template. No clinical content
Recipients
The configured AMQP broker, and whoever consumes from it
Third-country transfers
yours: wherever the broker runs
Retention
Published rows pruned after [events] retention_days, seven days by default
Security measures
Written in the same transaction as the commit it announces, so there is no event without its commit; optional TLS to the broker; the envelope carries identifiers, so a consumer still has to authenticate to the API to read anything
Exchanging mapped resources with FHIR systems, when [fhir] is enabled
Categories of data subject
Record subjects
Categories of personal data
Whatever the registered mappings project, which is clinical content and therefore Art. 9 data. Outbound emission is PHI-bearing, unlike the change-event envelope
Recipients
The configured broker or FHIR peer
Third-country transfers
yours
Retention
Nothing is stored by the façade beyond the mappings themselves and an outbound cursor
Security measures
Mappings are data an administrator registers, so what leaves is what someone configured rather than a default; the façade is a targeted surface with no free-text search and no _include; TLS to the peer