FastClinic is designed for private multi-specialty clinics operating under EU law. Patient data protection, auditability, and interoperability are product requirements—not afterthoughts.
This page separates verified demo capabilities from production requirements and future integration work.
The public demo and repository contain no protected health information. They demonstrate appointments, patient and party relationships, consent-gated communications, billing, recall, reporting, and a read-only AI assistant using synthetic records.
Production deployments require an EU/EEA residency profile, encryption and key management, fine-grained access control, append-only audit evidence, retention controls, incident response, and processor agreements.
FastClinic is not currently ISO 27001 or ISO 27701 certified, the public demo is not a production EHR, and this page is not a legal compliance guarantee for a deploying clinic.
The production architecture and operating model are being shaped around the following commitments.
A clinic remains responsible for its lawful purposes, national clinical-record obligations, and patient-facing processes. FastClinic's role depends on the deployment and contract.
Health-care condition. GDPR Article 9(2)(h) may support processing for health care or the management of health systems where its conditions and relevant EU or Member State law are met. It does not replace the need to document the Article 6 basis and local rules.
AI boundary. Before any model receives real patient data, the deployment must resolve provider location, contracts, international transfers, minimisation, retention, human oversight, and purpose limitation. EU-hosted or local models are preferred.
EHDS establishes the European Electronic Health Record exchange format and future common specifications for interoperability and logging. FastClinic plans to use FHIR R4 as its primary implementation spine, with HL7 Europe, IPS, and national profiles applied by adapters.
| FastClinic concept | FHIR R4 mapping | Adapter responsibility |
|---|---|---|
| Subject of care | Patient | National identifiers, demographics, and required extensions |
| Guardian or contactable party | RelatedPerson / Patient.contact | Relationship coding, authority, representation, and consent attribution |
| Appointment and visit | Appointment / Encounter | National status, referral, location, and workflow profiles |
| Diagnosis and performed care | Condition / Procedure | Terminology bindings, code systems, and specialty rules |
| Payer and coverage | Coverage / Organization | Insurance identifiers, eligibility, claims, and private-pay rules |
| Clinician and clinic | Practitioner / PractitionerRole / Organization | Professional registries, authentication, and organisation identifiers |
| Consent and audit evidence | Consent / AuditEvent | Local consent regimes, purpose, provenance, and disclosure policy |
The current public API includes a FHIR R4 read surface over synthetic data. Production write paths, national profile certification, and live spine connections remain gated.
Adapter targets below are discovery candidates, not implemented integrations or delivery commitments. The first production pilots will determine sequence and exact conformance scope.
Map Estonian identifiers and terminology, current document exchange, emerging FHIR R4 assets, professional access, representation, and secure national exchange requirements.
Official TEHIK overview ↗Support the transition in which CDA R2 remains common while Kanta introduces FHIR progressively, including national profiles, code sets, testing, certification, authorisation, and logging requirements.
Official Kanta FHIR roadmap ↗Follow gematik's FHIR R4 implementation guides for ePA services, Telematics Infrastructure identities, audit events, terminology, and applicable conformity assessment.
Official gematik FHIR guide ↗Map Dutch care information models and FHIR R4 profiles, then implement the MedMij trust framework and supplier qualification where patient-mediated exchange is in scope.
Official Nictiz MedMij overview ↗The target control system combines technical safeguards, operating procedures, supplier governance, and evidence that can be reviewed by clinics and auditors.
Fine-grained RBAC, least privilege, MFA and SSO options, secure sessions, and professional-identity hooks for national adapters.
Append-only evidence for clinically and administratively significant actions, monitoring, backups, incident response, and recoverability testing.
ISO 27001 and ISO 27701 are target frameworks, informed by ISO 27799 health-security guidance and NIS2 supply-chain and risk-management expectations. They are not current certifications.
MDR / SaMD boundary. Scheduling, billing, records, and operational recall are not intended to diagnose or recommend treatment. Patient-specific decision support will remain gated and separately assessed before release; features with a medical intended purpose may require medical-device compliance.
The system is being designed to help clinics locate a person's data, explain its provenance, export it in structured form, and apply restriction or erasure where legally required. Clinical retention duties and legal holds remain enforceable.
For minors and represented adults, communications and rights workflows use the appropriate guardian or authorised party relationship instead of assuming the subject of care is directly contactable.
Synthetic pipeline, subject/party model, consent gates, balanced ledger, evaluation suite, and multilingual product surfaces.
EU-only deployment profiles, RBAC, encryption defaults, audit matrix, retention and legal holds, DPIA/processing-record/DPA templates, and structured export.
R4 read surface, Patient $everything, validation, and an offline NHS adapter (UK Core + GP Connect STU3). Live PDS and GP Connect stay gated on onboarding.
Patient portal primitives, stronger identity, ISO gap analysis, NIS2-aligned playbooks, additional adapters, and continuous EHDS monitoring.
National requirements and EHDS implementing acts will evolve. Adapter conformance must be checked against the authoritative version in force for each deployment.
Contact the FastClinic team. The formal Data Protection Officer or privacy contact for production services is still to be designated.
This page describes design intent and current capabilities. Formal certifications, legal assessment, and specific national registrations or notifications remain the responsibility of the deploying clinic and will be documented as they are achieved.