GDPR
GDPR-Compliant FHIR Backend
GDPR puts the controller on the hook for lawful basis per access, data minimization, data subject rights, and demonstrable accountability. Fire Arrow turns each of those from a policy promise into a deployment property: identity-attributable audit, server-enforced minimization, and EU residency without architectural changes.
What you can build
- Article 5 principles backed by the deployment
Lawful basis, purpose limitation, data minimization, accuracy, storage limitation, and integrity each have an enforcement point in the architecture rather than a paragraph in a policy.
- Right of access and portability as a standard operation
Article 15 and Article 20 are answered by the FHIR Bulk Data $export operation at the Patient scope. Structured, machine-readable NDJSON of the patient compartment, scoped by the same authorization rules as regular reads. No custom exporter to build or maintain.
- No lock-in at the data layer
The data model is FHIR R4. A system-level $export reloads into any conformant FHIR server, so the controller can change processors, hosting regions, or vendors without rewriting the data they hold.
- Data subject rights as scoped FHIR operations
Access, rectification, erasure, and portability are FHIR operations against the patient compartment. The per-subject access log is a query, not a forensic exercise.
- EU residency without architectural changes
Fire Arrow runs on any database and any hosting region. EU-only residency is a deployment configuration, not a separate edition.
What you get out of the box
Who this is for
European digital health teams and DPOs building products that process special-category health data and need a FHIR backend whose architecture can be defended in a supervisory authority review.
Clinical applicability
A DiGA app processes patient self-reported outcomes, clinician notes, and device data. Patients see and export their own data. Sponsors see anonymized aggregates. The DPO can produce a per-subject access report from the audit log without a database dump.
Lawful basis as a property of the request
GDPR requires a lawful basis for every processing activity. For health data, special-category processing under Article 9 needs an additional condition (typically explicit consent, treatment purpose, or a legal obligation). The hard part for software is recording the basis at the point of access, not at the point of data collection.
Fire Arrow records access in identity-resolved terms. The Patient role, the Practitioner role, the Researcher role, and the Service role are each tied to a basis the controller has documented. The audit log captures which role accessed which resource under which rule, which gives the basis a paper trail that survives DPO review and supervisory authority audit.
Right of access (Art. 15) as a Patient $export
Article 15 obliges the controller to provide the data subject with a copy of their personal data on request, in a structured format. For a healthcare product these requests arrive a few times a year per active user and a smaller number of times per ex-user. Without a built-in path, every product writes its own exporter and maintains the list of resources it covers as the product evolves.
The FHIR Bulk Data $export operation at the Patient scope answers the request directly. The patient compartment is the FHIR-defined set of resources tied to a Patient. A patient-scoped token, or a service identity acting on the patient's behalf, calls $export, the server produces NDJSON, and the controller hands the result to the data subject. The set of resources covered is decided by the authorization rule for the patient role, not by an extra exporter component, so adding a new resource type to the product does not require updating a parallel DSAR pipeline.
For smaller, single-snapshot requests the synchronous Patient/$everything operation returns the same compartment as a FHIR Bundle. Either form is structured and machine-readable in the sense Article 15 requires.
Right to portability (Art. 20) and the absence of FHIR vendor lock-in
Article 20 goes further than Article 15. It gives the data subject the right to receive their data in a structured, commonly used, machine-readable format and to transmit it to another controller. The format has to be one another controller can actually read.
FHIR R4 is that format. It is the European interoperability standard adopted under the EHDS Regulation, the de-facto interchange format for health data in the EU and beyond, and the only format common across the major EHRs and FHIR backends. NDJSON output of FHIR R4 resources is consumable by any conformant FHIR server. The portability obligation is satisfied by running the same operation that already covers Article 15.
The same property holds at the operator level, which is the practical answer to data-layer lock-in. A system-level $export produces the operator's full FHIR dataset as NDJSON. Any other FHIR R4 server can ingest it via the corresponding $import operation or via transaction Bundles. The receiving server can be a different deployment of the same product, a different cloud region, or a different vendor's product. Data residency, processor changes, infrastructure migrations, and vendor transitions all become operational projects rather than data-rewriting ones, and the controller retains the supplier-change flexibility GDPR expects.
Caveats worth planning for: standard $export returns current state; resource history, Binary attachment payloads, and any non-standard extensions need to be handled explicitly if they are part of the system of record. Current-state portability is the baseline; full historical fidelity is a per-deployment decision driven by what the source server exposes and what the target accepts.
Rectification, erasure, and the audit per subject
Rectification is a write under the patient compartment, scoped by the same rules. Erasure is a FHIR delete scoped by rule, with the retention exceptions the controller is required to honour (legal hold, billing, IEC 62304 traceability) encoded in the rule set rather than embedded in application code.
Each operation is recorded against the resolved identity in the same audit stream as regular FHIR access. The per-subject access report a DPO needs is a query against that audit log, not a separate forensic exercise.
EU residency and processor relationships
Fire Arrow runs in the region the operator chooses. For EU customers a typical deployment runs in an EU region of the chosen cloud or on-premise. There is no telemetry to a vendor backplane and no SaaS control plane that ships data outside the deployment boundary.
When Evoleen Technology hosts Fire Arrow for a customer, Evoleen is the processor under a DPA signed as part of the engagement. Subcontractor relationships flow down to the infrastructure provider. Self-hosted deployments keep both controller and processor inside the customer's organization.
Related docs
FAQ
Is Fire Arrow GDPR compliant?
Compliance applies to the controller and the processing activity, not to a single component. Fire Arrow gives the controller the architectural primitives that make Article 5 obligations enforceable in the deployment. The lawful basis, the purposes, and the policies remain the controller's responsibility.
Do you sign a Data Processing Agreement?
Yes for Evoleen-hosted deployments where Evoleen Technology is the processor. For self-hosted deployments Evoleen does not process customer data and a DPA with Evoleen is not in scope.
How are Article 15 data subject access requests fulfilled?
Patient-level $export returns the patient compartment as NDJSON, scoped by the same authorization rule that covers regular Patient reads. For smaller cases the synchronous Patient/$everything operation returns the same compartment as a Bundle. Both forms are structured, machine-readable FHIR R4 and require no per-product DSAR exporter. The audit log captures the request and its scope.
Does this satisfy Article 20 portability to another controller?
Yes, in the technical sense Article 20 requires. The output is FHIR R4 in NDJSON: a structured, commonly used, machine-readable format that any conformant FHIR server can ingest via $import or transaction Bundles. Whether a specific transmission to another controller meets all of Article 20's conditions (consent or contract basis, technical feasibility, no adverse effect on others' rights) is a controller-side legal assessment; on the technical side the data leaves the server in the format the regulation calls for.
What if we need to change FHIR backends or hosting providers?
System-level $export produces the operator's full FHIR dataset as NDJSON. Any conformant FHIR R4 server can ingest it. The receiving server can be the same product in a different region, a different deployment of the same product, or a different vendor's product. Data residency, processor changes, infrastructure migrations, and vendor transitions become operational projects rather than data-rewriting ones, which is the kind of supplier-change flexibility a controller is expected to retain.
What about the right to erasure?
FHIR delete operations are scoped by rule. The retention exceptions (legal hold, billing records, IEC 62304 traceability) are encoded in the rule set rather than embedded in application code. The audit log records the request, the decision, and the timestamp.
Can data leave the EU?
Only if the deployment is configured to allow it. Fire Arrow itself does not ship data anywhere outside the deployment boundary. Cross-border transfers are a deployment decision driven by the controller and recorded in the relevant agreements.
