When you engage ME-TA — statistical services, or the ME-TA SCE on the Metawebservice platform — your regulatory duties stay yours. This page states, requirement by requirement, how we read each requirement, to what degree we assess it as fulfilled, and which QMS or validation document records the basis for that assessment.
21 CFR Part 11 & EU Annex 11, clause by clause · ICH E6(R3) & E9 · GAMP 5 / FDA CSA
ISO 13485 supplier clauses · FDA QMSR · EU IVDR performance-study articles
EU AI Act, article by article · EMA expectations · the P22 controls behind them
Art. 28 processor duties, article by article · intra-EEA · 24-hour notification
For sponsors running clinical development under ICH and FDA/EMA expectations. The QMS maintains a combined 21 CFR Part 11 / EU Annex 11 checklist for the platform; the tables below state its conclusions per requirement.
| Requirement | Assessment | Interpretation and documentation |
|---|---|---|
| §11.10(a) — validation | Met | Interpretation: the system must be validated for accuracy, reliability and consistent intended performance, including the ability to discern invalid or altered records; per FDA's Scope & Application guidance the validation duty attaches to your intended use, so your use-level validation remains yours and starts from our documentation. Documented in: Validation Master Plan (1-5.1), requirement specifications per component (1-5.2.x), Validation Report per release (1-5.3); altered-record discernment via content-hash verification and versioning is specified in the client RS. |
| §11.10(b) — accurate & complete copies | Met | Interpretation: records must be exportable in human-readable and electronic form for inspection. All records, deliverables, and logs are downloadable per study; nothing exists only inside the platform. Documented in: requirement specifications (export functions); P06. |
| §11.10(c) — protection & retention | Met | Interpretation: records must remain retrievable and unaltered through the retention period. Encrypted storage (AES-256, AWS KMS), weekly-minimum backups with restore verification, retention to the contracted period (up to 25 years supported), 30-day export window at contract end. Documented in: P06 (retention, backup), P14 (export window), VMP (storage architecture). |
| §11.10(d) — limiting system access | Met | Interpretation: authorisation is yours to grant; technical restriction is the platform's to enforce. Unique identities; passwordless portal authentication (SSO or email OTP); study-scoped grants controlled by your administrator; per-session credentials scoped to the study's storage path; 90-day inactive-account removal. Documented in: P07 (§7.11 authentication, session bounds); API and frontend requirement specifications. |
| §11.10(e) — audit trails | Partly met | Interpretation: the rule text requires secure, computer-generated, time-stamped trails of actions that create, modify or delete records, prior entries never obscured, retained as long as the records — this we assess as met: application-level audit trail plus AWS CloudTrail, and every file change preserves the full prior version. FDA's 2024 Q&A (Q12) additionally reads the components as user ID and role, old value → new value, and reason for change. Reasons for change are not currently captured, and verification that every record class satisfies the old/new-value component is in progress. Documented in: requirement specifications (audit trail, versioning); the component verification will be recorded in the validation set when complete. |
| §11.10(f) — operational sequencing checks | Met | Interpretation: where order of steps matters, the system must enforce it. Job execution runs under explicit execution order and dependency tracking; stale-dependency detection prevents out-of-sequence results. Documented in: client and API requirement specifications (job engine). |
| §11.10(g) — authority checks | Met | Interpretation: each operation must check that this user may perform it. Role- and study-scoped permission checks on every operation; per-session credentials scoped to the study. Documented in: P07; API requirement specification. |
| §11.10(h) — source/device checks | Met | Interpretation: the validity of the data-input source must be checkable. File synchronisation verifies content integrity by hash between client and server; versioning records every change. Documented in: client requirement specification (sync design). |
| §11.10(i) — education, training, experience | Met | Interpretation: the duty covers those who develop, maintain, or use the system — our personnel are our share; your users are yours. Documented CVs and qualifications; training within 30 days of assignment; GCP training records. Documented in: P15; training records available on request. |
| §11.10(k) — documentation controls | Met | Interpretation: system documentation must be distribution-controlled and revision-controlled with change history. QMS and system documentation are version-controlled; effective documents never change in place — every revision is a new version. Documented in: P02 (document control), P09 §9.5 (change records), P18 (SDLC). |
| §11.30 — open-system controls | Met | Interpretation: we classify the platform as a closed system under §11.3(b)(4) — access is controlled by the parties responsible for the records' content (ME-TA and your administrators). If you classify hosted systems as open, the classification has no control consequence here: the additional open-system measures (encryption in transit, TLS 1.2+) are in place regardless. Documented in: P07; VMP (architecture). |
| Subpart C (§§11.50–11.300) — electronic signatures | Not met | Interpretation: Subpart C governs electronic signatures where they are executed; the platform executes none, so no platform record is an electronically signed record and §§11.50–11.300 are not engaged. We assess "not met" rather than "not applicable" because not implementing is a design decision, open to your review. In place instead: every action is attributable (unique identity plus audit trail), and formal signatures are executed in controlled QMS document processes. Documented in: requirement specifications (no signature function); P02 (document signing practice). |
| Section | Assessment | Interpretation and documentation |
|---|---|---|
| 1 — Risk management | Met | Interpretation: validation extent and data-integrity controls must follow documented risk assessment through the lifecycle. Risk assessments precede infrastructure, platform, and policy changes; validation depth is risk-based. Documented in: P04; VMP (risk-based test strategy). |
| 2 — Personnel | Met | Interpretation: qualified personnel with defined roles and access. The Qualified Person role does not arise — no batch-related activity exists. Documented in: P15; P07 (roles and access). |
| 3 — Suppliers & service providers | Met | Interpretation: formal agreements and documented assessment of suppliers; audit information available on request. AWS, the primary supplier, is assessed and under GDPR DPA and BAA. Documented in: P05; vendor assessment records; P03 yearly review (supplier certifications re-checked annually). |
| 4 — Validation | Met | Interpretation: lifecycle validation with traceable requirements, change-control records, and reported deviations, plus a system inventory and description. Documented in: VMP (1-5.1), requirement specifications (1-5.2.x), traceability matrix (1-5.2.8), Validation Report (1-5.3). |
| 5 — Data (built-in checks) | Met | Interpretation: electronic exchange with other systems needs built-in correctness and security checks. Client–server exchange uses hash verification and versioning; no manual re-keying between systems. Documented in: client and API requirement specifications. |
| 6 — Accuracy checks | Met | Interpretation: the section covers critical data entered manually; checks on your own data entry are yours. Our share — the analyses and outputs we produce — passes two-level QC (statistician plus independent peer). Documented in: P19 (QC procedure). |
| 7 — Data storage & backup | Met | Interpretation: physical and electronic protection, with backup integrity and restore verified and monitored. Documented in: P06; Validation Report (restore verification). |
| 8 — Printouts | Met | Interpretation: clear printed/human-readable copies of stored data (8.1) — provided by the export functions. 8.2 concerns batch-release records, which do not exist at ME-TA (see section 15). Documented in: requirement specifications (export). |
| 9 — Audit trails | Partly met | Interpretation: GxP-relevant creation, change, and deletion must be recorded, and the reason for change or deletion of GxP-relevant data should be documented. The recording is in place (application audit trail, versioning); a reason-for-change prompt is not currently implemented — reasons live in the study's change documentation rather than in the trail itself. Documented in: requirement specifications (audit trail); the gap and its handling are recorded in the QMS conformance checklist. |
| 10 — Change & configuration management | Met | Interpretation: changes only through a defined, controlled procedure. All infrastructure as code; production changes only via the release pipeline with recorded two-person approval (CEO + DPO) and version-tagged releases. Documented in: P09 (§9.5 approval records), P18. |
| 11 — Periodic evaluation | Met | Interpretation: periodic confirmation that the system remains in a valid, compliant state, covering functionality, incidents, upgrades, security, and validation status. Documented in: P03 (yearly review — the 2025/2026 review is signed and filed); P08 (periodic platform reviews). |
| 12 — Security | Met | Interpretation: physical and logical access restriction, with authorisation changes recorded and operator identity captured on data changes. Logical: unique identities, passwordless portal authentication, scoped short-lived tokens. Physical: AWS data-centre controls (inherited, certified) and office access control. Access-authorisation changes are recorded in the audit trail. Documented in: P07, P10; P05 (AWS certifications). |
| 13 — Incident management | Met | Interpretation: all incidents reported and assessed; root cause of critical incidents identified and feeding corrective action. Documented in: P11 (incidents and complaints, root cause, corrective-action route), P12 (breach, 24-hour notification). |
| 14 — Electronic signature | Not met | Interpretation: same position as Part 11 Subpart C above — no in-system electronic signatures; attributable actions plus controlled QMS document processes instead. Documented in: as for Subpart C. |
| 15 — Batch release | Not applicable | Interpretation: the section governs systems recording certification and release of batches by Qualified Persons. No batches, certification, or Qualified Person exists in a statistical computing environment — the requirement's object is absent, not argued away. Documented in: the QMS Part 11 / Annex 11 checklist records this as one of its two not-relevant rows (both batch-related). |
| 16 — Business continuity | Met | Interpretation: continuity provisions appropriate to the system's criticality, with recovery time based on risk. Documented in: P13 (disaster recovery, automated redeployment from infrastructure-as-code, tested restore). |
| 17 — Archiving | Met | Interpretation: archived data must stay accessible, readable, and intact, surviving system change. Storage is file-based and format-open; retention and export are contractual. Documented in: P06; P14. |
| Framework | Assessment | Interpretation and documentation |
|---|---|---|
| ICH E6(R3) GCP | Met | Interpretation: GCP duties reach ME-TA through your delegation; sponsor oversight remains yours. Our share: qualified, GCP-trained staff, QC'd programming, and records that make your oversight and inspection readiness practical. Documented in: P01 (framework), P15 (training), P19 (programming and handover). |
| ICH E9 / E9(R1) | Met | Interpretation: statistical principles including pre-specification. SAP finalised before unblinding; randomisation codes sealed; deviations documented; programs validated. Documented in: P20; P19. |
| Expectation | Assessment | Interpretation and documentation |
|---|---|---|
| Risk-based assurance | Met | Interpretation: assurance effort proportionate to risk, per GAMP 5 2nd ed. and FDA's CSA guidance (final, February 2026). Documented in: VMP (GAMP categorisation: infrastructure Cat 4, application Cat 5; risk-based test strategy). |
| Leveraging supplier assurance | Met | Interpretation: CSA supports basing your validation on supplier validation plus supplier evaluation; our documentation is structured for that. CSA's own scope limit — it does not cover design V&V of device software functions — is respected in how we cite it. Documented in: VMP, requirement specifications, Validation Reports (available on request). |
For medical-device and IVD manufacturers engaging ME-TA for performance-evaluation statistics or the ME-TA SCE. ME-TA is not a device manufacturer and places no regulated product on the market; under your QMS we are a supplier, and the rows below assess ME-TA's supplier side of each clause.
| Clause | Assessment | Interpretation and documentation |
|---|---|---|
| §4.1.5 / §7.4 — outsourced processes & purchasing controls | Met | Interpretation: your duty is to control ME-TA proportionate to risk; our share is supplying the evidence that control needs — the public policy set, validation documentation, audit access, and quality-agreement terms. Documented in: P01–P22 (public); VMP and Validation Reports; our own supplier controls in P05/P08. |
| §4.1.6 / §7.5.6 / §7.6 — software validation | Met | Interpretation: your QMS must validate software used in it, proportionate to risk (FDA's CSA guidance renders these clauses, including for SaaS). Our supplier-side validation evidence supports the supplier-leverage route; which of the three clauses governs a statistical service environment in your QMS is an interpretive question we settle in the quality agreement. Documented in: VMP (1-5.1), requirement specifications, Validation Reports. |
| §4.2.4 — control of documents | Met | Interpretation: supplier documentation must be version-controlled with effective dates; revisions create new versions. Documented in: P02. |
| §4.2.5 — control of records | Met | Interpretation: records retained per your retention requirements — IVDR-scale timelines (10 years+) supported by contract; audit trail preserved with the records. Documented in: P06. |
| §7.3 — design & development | Met | Interpretation: design controls and the design history file are yours; statistical deliverables we produce become your design evidence. Our share is a traceable, reproducible environment so you can independently verify that evidence, as FDA expects for third-party data. Documented in: platform traceability (requirement specifications); P19/P20 (QC and statistical procedure). |
| §8.2.2 — complaint handling | Met | Interpretation: complaints about ME-TA deliverables or service need a defined route at ME-TA and cooperation with your complaint file. A complaint procedure distinct from incident handling is effective: definition, inbound channel, classification, reportability determination, corrective-action route. Documented in: P11 v03 (effective 11 AUG 2026), §11.4. |
| §8.4 — analysis of data | Met | Interpretation: valid statistical techniques with documented rationale — for ME-TA this is the service itself: documented methods, sample size justifications, two-level QC. Documented in: P19, P20. |
| §8.5.2 / §8.5.3 — corrective & preventive action | Partly met | Interpretation: a supplier is expected to operate corrective and preventive action on its own quality issues. Corrective action operates today through the incident-and-complaint procedure (root cause, corrective route). A standalone CAPA procedure with preventive-action trending does not yet exist; establishing it, together with a formal nonconformity procedure, is an open action item in the QMS's management review. Documented in: P11 v03 (current route); the signed 2025/2026 yearly-review action register (the open item). |
| §8.2.4 / §5.5.2 — internal audit & management representative | Partly met | Interpretation: a functioning internal-audit cycle and a named management representative. The audit programme is defined and the yearly management review is current (2025/2026 signed). Executing the next internal-audit cycle and formalising the management-representative appointment are open action items from that review; current status available on request. Documented in: P08 (programme); P03 and the signed 2025/2026 yearly review. |
| Provision | Assessment | Interpretation and documentation |
|---|---|---|
| §820.7 / §820.10 — ISO 13485 incorporated | Met | Interpretation: your QMS must comply with ISO 13485:2016, which reaches ME-TA through your supplier controls — assessed clause by clause in the table above. Documented in: as per the ISO 13485 rows. |
| Supplier-audit records inspectable | Met | Interpretation: the former §820.180(c) exception for supplier-audit reports is not carried into the QMSR, so your audit records about ME-TA are FDA-inspectable. Our evidence pack and audit answers are written with that in mind. Documented in: public QMS; audit-access terms in the quality agreement. |
| Provision | Assessment | Interpretation and documentation |
|---|---|---|
| Art. 57(3) — valid, reliable, robust data | Met | Interpretation: studies must be designed and analysed so the data are scientifically valid, reliable, and robust — for the statistical share: documented methods, pre-specified analyses, two-level QC. Documented in: P20, P19; engagement SAPs and study plans. |
| Art. 68(3) — recorded, processed, stored so data can be "accurately reported, interpreted and verified" | Met | Interpretation: the record-keeping standard for performance-study information. The SCE keeps every dataset, program, log, and output versioned and attributable from raw data to reported result. Documented in: requirement specifications (versioning, audit trail); P06. |
| Art. 68(4) — protection of data | Met | Interpretation: technical and organisational measures against unauthorised access, alteration, or loss — the same control set as the Part 11 and GDPR tables. Documented in: P07, P06; VMP (security architecture). |
| Art. 68(2) — sponsor monitoring | Met | Interpretation: the monitoring plan and monitor are yours; our share is monitor access to the traceable record — transfers, dataset lineage, program logs. Documented in: P07 (access model). |
| Annex XIII §2.3.2(j)/(p) — statistical design & data management in the plan | Met | Interpretation: the study plan must state the statistical design and data-management arrangements; we author or review these sections in engagements. Documented in: engagement study plans; P20. |
| Annex XIII §2.3.3 — data exclusions with rationale | Met | Interpretation: the report must document deviations and exclusions with rationale — standard reporting practice in our deliverables. Documented in: P19/P20 (reporting and deviation documentation). |
| Art. 10(7) / Annex XIV — retention (10 years+) | Met | Interpretation: retention is contracted to your IVDR timeline; storage supports up to 25 years. Documented in: P06; the engagement contract. |
ME-TA's base service is deterministic — SAS/R compute with no AI. AI-assisted production exists only as a per-engagement election, governed by the QMS's AI-usage policy (P22, effective 02 JUL 2026) and a dedicated DPA addendum.
| Provision | Assessment | Interpretation and documentation |
|---|---|---|
| Art. 6 / Annex III — high-risk classification | Met | Interpretation: high-risk status attaches to the Annex III use cases, which concern decisions about natural persons. AI at ME-TA assists statistical programming and documentation drafting; a human statistician owns every analytical conclusion; no decisions about natural persons are made; patient-level data is excluded from AI processing. We assess the use as not high-risk, with review triggers defined (including the Commission's final classification guidelines). Documented in: the Article 6(4) self-assessment record (available on request); P22. |
| Art. 6(4) — documented self-assessment | Met | Interpretation: a non-high-risk determination must be documented. The determination, the conditions it depends on, and its review triggers are recorded. Documented in: the Article 6(4) self-assessment record. |
| Art. 50 — transparency (applies since 2 Aug 2026) | Met | Interpretation: AI involvement in produced content must be disclosed. AI-assisted production only occurs when you elect it under a signed addendum, so disclosure precedes use; deliverables from AI-elected engagements are identified as expert-reviewed, AI-assisted work. Documented in: the DPA AI addendum; P22. |
| Art. 4 — AI literacy | Met | Interpretation: staff using AI must understand its limits and the applicable rules. Documented in: P22 §22.12; training records (P15). |
| Chapter V — general-purpose AI model duties | Not applicable | Interpretation: provider duties attach on placing a model or system on the market. ME-TA places none; the self-hosted inference server serves ME-TA's own work only. Documented in: P22 (approved inference paths and architecture). |
| Expectation / control | Assessment | Interpretation and documentation |
|---|---|---|
| EMA reflection paper on AI (final, Sept 2024) | Met | Interpretation: AI in the medicinal-product lifecycle is expected to be validated, auditable, under human accountability, with pre-specification before unblinding. Documented in: P22 §22.6 (human oversight, output validation); P20 (pre-specification); the same two-level QC as deterministic work (P19). |
| Patient-data boundary | Met | Interpretation: patient-level data must not reach AI processing. Enforced by a two-category data boundary and a three-stage architecture in which the AI stage can only receive permitted content. Documented in: P22 §22.4 (categories), §22.5 (enforcement). |
| EU-only inference | Met | Interpretation: client-work inference stays in the EU. Approved paths: AWS Bedrock in EU regions (zero retention) or ME-TA's self-hosted server on Danish hardware; no client content on consumer AI tools. Documented in: P22 §22.3; P21 (sub-processors). |
| Customer control of AI use | Met | Interpretation: AI use is configurable per engagement, down to complete prohibition; conversation history is purged at engagement close. Documented in: P22 §22.3.5/§22.3.6; the DPA AI addendum. |
The draft EU GMP Annex 22 (AI) is not in force and is not assessed above; its direction — no generative AI in critical decisions, human-in-the-loop with records for non-critical use — matches the P22 pattern. The full data-flow picture, including the AI election, is on the Data Processing page.
ME-TA is a data processor under Art. 28 for the clinical data you entrust to us, and a controller only for limited business-contact data.
| Provision | Assessment | Interpretation and documentation |
|---|---|---|
| Art. 28(3) — processing contract | Met | Interpretation: processing under a contract carrying the Art. 28(3) elements — instructions, confidentiality, security, sub-processor terms, assistance duties, deletion/return, audit rights. Documented in: the standard DPA template (tailored per engagement under counsel review); P21. |
| Art. 28(2)/(4) — sub-processors | Met | Interpretation: sub-processors disclosed, changes notified in advance, obligations flowed down. 30-day change notice; the DPA schedule and the QMS list are kept aligned. Documented in: P21 §21.11; DPA sub-processor schedule. |
| Art. 30(2) — records of processing | Met | Interpretation: processor records of processing activities per engagement. Documented in: engagement records; the standing architecture is described publicly on the Data Processing page. |
| Art. 32 — security of processing | Met | Interpretation: technical and organisational measures appropriate to the risk. AES-256 at rest, TLS 1.2+ in transit, unique identities with passwordless portal authentication, least privilege, weekly-minimum tested backups, encrypted managed workstations with EDR. Documented in: P07, P06; VMP (security architecture). |
| Art. 33/34 — breach notification | Met | Interpretation: the controller must be able to meet its 72-hour duty; our commitment is notification within 24 hours of discovery, with defined investigation and reporting timelines. Documented in: P12. |
| Art. 35 — data-protection impact assessment | Met | Interpretation: the DPIA is yours where required; our share is the processing and architecture descriptions that populate it, pre-written. Documented in: the DPA package (architecture and validation appendices). |
| Chapter V (Arts. 44–49) — transfers | Not applicable | Interpretation: Chapter V is triggered by a transfer out of the EEA. None occurs: the client-work chain is intra-EEA (AWS eu-west-1; EU-only AI inference paths), so no transfer mechanism is needed. Documented in: P21 (EU-region commitment); the Data Processing page. |
| Data-subject rights (Ch. III) | Met | Interpretation: responding to data subjects is the controller's duty; our share is assistance — locating, exporting, and deleting on instruction within the retention rules. Documented in: the DPA (assistance clauses); P06/P14 (export and deletion). |
The policy set is public at policy.me-ta.dk. Validation documentation, audit arrangements, and quality-agreement terms are available on request — tell us which framework you qualify against and we will map our evidence to your checklist, including the current state of the partly-met rows.
contact@me-ta.dk