Encryption in transit and at rest
Traffic is encrypted with current TLS. Stored data and backups are encrypted at rest, with managed key rotation.
Data protection by design
How data is handled
The platform is built around the principles common to modern privacy law, so the same design holds wherever it is deployed.
- A lawful basis and, where it applies, consent is captured and recorded for every use of personal and health data
- Data minimisation: only the data needed for care and operations is collected
- Purpose limitation: data is used for the reasons it was collected, not quietly repurposed
- Patient rights are supported: access, correction, export in a portable format, and erasure where the law allows
- Retention periods are configured per jurisdiction and enforced by the platform
- Each organisation on the platform is logically isolated, so one tenant never sees another tenant data
Security
Security controls
These controls are part of the product and its infrastructure, not optional add-ons.
Access control
Role-based access per site with least-privilege defaults, and configurable password, multi-factor and session-timeout policies.
Audit trail
Every create, edit, view and delete of a record is written to an append-only log that users cannot alter.
Tenant isolation
Each organisation data is isolated, and access is scoped to the site and role of the signed-in user.
Backups and recovery
Automated backups with off-site and separate-region copies, and a documented, tested recovery plan.
Monitoring
Platform activity is monitored, with alerting on unusual access patterns and administrative actions.
Secure file handling
Uploaded files are validated, stored in private object storage and served through short-lived signed links.
Secure development
Changes go through code review and automated checks before release, and dependencies are kept current.
Interoperability
Standards it speaks
Built on international health-data standards so it exchanges data with the systems and instruments you already run.
FHIR R4 HL7 v2 DICOM ICD-11 LOINC SNOMED CT Lab analyser interfaces (LIS) Insurance claim formats (national and private schemes)
Configurable
Configured to your jurisdiction
The regulatory layer is set to your country and your health authority, so the platform fits your regulator rather than the other way round.
- Data residency: the hosting region is chosen to meet local requirements, with a hybrid option where sensitive data stays on site
- Retention and archival rules are set to your health authority requirements
- Breach-notification timelines and recipients are set to your regulator
- Patient identifier formats, consent wording and statutory report layouts are configured per country
- Processing terms and any required local agreements are handled as part of onboarding
If something goes wrong
Incident response
A defined process runs on discovery of a security or privacy incident. Notification timelines follow the rules of your jurisdiction.
01
Detection and classification
On discovery, the event is triaged and its severity and likely scope are assessed.
02
Containment
The first priority is to limit exposure and stop any ongoing access.
03
Investigation
We establish the scope, the cause, and which data and organisations are affected.
04
Notification
Affected organisations and regulators are notified within the timelines your jurisdiction requires.
05
Post-incident review
A written review records what happened and the corrective actions taken.
What Quecorex secures
The platform, its infrastructure, its code, encryption, backups, monitoring and the security of the hosting environment.
What your organisation manages
Your users and their roles, local configuration, who is granted access to which records, and staff training. Onboarding sets out where the line sits.
Security and privacy contact
We respond to data-protection and security enquiries, including requests from patients exercising their rights through a provider.