Fire Arrow Compliance Architecture

GDPR: what you can demonstrate, and where Evoleen takes responsibility

GDPR puts you on the hook for lawful basis per access, data minimisation, data subject rights, and demonstrable accountability. The technical foundation for each of those is in the deployment, in a form that survives an audit rather than just looking good in a policy document.

Every access is tied to a real FHIR identity, which is what 'lawful basis per access' actually requires when a regulator wants to know who saw what and on what basis. Field-level redaction, paired with explicit blocklists on the search parameters and reference traversals a role can use, makes data minimisation an enforced property rather than a guideline, so analytics consumers, sponsor-side reviewers, and downstream agents see only what their role permits, even when they get creative with search.

Evoleen Technology can take the data-processor role under an agreed DPA when we host the deployment for you; otherwise the data stays in your environment and you remain controller and processor in the same hands. Lawful basis, DSR procedures, and deletion remain your call as data controller in either case. Fire Arrow makes them executable; the policy stays yours.

HIPAA: Security Rule safeguards, mapped to what Fire Arrow does

For US deployments under HIPAA, the Security Rule's technical safeguards map directly to properties of the deployment. Access control: deny-by-default rules tied to a real FHIR identity, with the same rule covering REST, GraphQL, and SQL-on-FHIR. Audit controls: every authorised request logged with the resolved identity, the rule that matched, and the operation. Integrity: server-side enforcement of every access decision, with no client-trusted parameters that could be tampered with to widen access. Transmission security: TLS for client traffic; encryption at rest sits at the database layer your team operates, where the controls are well-understood and inspectable.

Where the deployment makes Evoleen Technology a business associate (typically when we host Fire Arrow for you), Evoleen signs the BAA as part of the engagement and operates the environment under its own controls. For self-hosted deployments, Evoleen does not handle PHI and a BAA is not in scope; the BAAs you need are between you and the providers operating your environment.

MDR and IEC 62304: third-party software you can put in your design history

If your product is qualified as a medical device under the MDR, Fire Arrow lives inside an IEC 62304 software lifecycle, and you need design history and traceability for the parts of the software you do not write yourself. The standard calls this third-party software SOUP (Software of Unknown Provenance), and it is one of the harder pieces of an MDR submission to assemble from public sources alone.

Evoleen Technology can supply Fire Arrow under its own quality management system, with versioned configuration (rules and identity mappings expressed as FHIR resources, deployment expressed as container images), documented requirements, reproducible builds, and change history. The third-party-software dossier lands as a supplier deliverable rather than something your team rebuilds from scratch. Self-hosting under your own QMS is equally supported, with the same artifacts shipped as supplier deliverables.

Clinical safety classification, risk management, and clinical evaluation for the intended use of the device remain with you; Fire Arrow does not change the device classification or the risk file. What it changes is how much of the software-of-the-device dossier you have to assemble yourself.

European Health Data Space: FHIR-native means EHDS-ready at the data layer

EHDS (EU 2025/327) puts FHIR at the centre of European EHR interoperability: your data model needs to speak the European Electronic Health Record Exchange Format, and the secondary-use scheme assumes interoperable health data as its starting point. Fire Arrow stores everything as standard FHIR R4 to begin with, so EHDS-flavoured exports and cross-border integrations are a question of mapping and access rules, not of migrating off a proprietary schema under deadline pressure.

The wider EHDS scope (secondary use of health data, EU-level data infrastructure, data altruism mechanisms) is decided at the deployment and policy layer, where you and your DPO determine what data flows where and on what basis. The access boundary and the audit record for those decisions live on the Fire Arrow side; the decisions themselves are yours.

FAQ