Secure AI Systems for Clinical Trial Data: A Practical Design Guide

Introduction

Every organization deploying AI in clinical research eventually reaches the same question: who owns the audit trail? It sounds procedural until a regulatory inspector asks which model version generated a specific output, what preprocessing was applied to its inputs, and how you can demonstrate the training data was not tampered with. The gap between deploying AI in clinical research and actually securing it against real-world threats is wider than most trial teams realize, and it becomes visible at exactly the wrong moment.

Clinical trial data is among the most commercially sensitive and regulatory-consequential information generated anywhere in healthcare. Patient safety records, efficacy endpoints, adverse event logs, and investigational product data carry both legal liability and scientific integrity implications that extend years beyond trial close. Introducing AI into that environment does not just add capability; it expands the attack surface, complicates validation requirements, and creates new categories of failure that traditional GCP frameworks were not designed to anticipate.

The IBM Security Cost of a Data Breach Report 2024, based on analysis of 604 organizations across 17 industries, found that the healthcare sector recorded the highest average breach cost of any industry for the fourteenth consecutive year, reaching $9.77 million per incident ^[1]. Clinical trial environments sit within that ecosystem, and they carry additional exposure: trial data is irreplaceable. A corrupted randomization database or a poisoned safety signal model cannot always be reconstructed.

This article describes a coherent architecture for designing secure AI systems in clinical trial contexts, covering the threat categories, applicable regulatory requirements, and the technical and governance controls that make AI trustworthy in a GCP-regulated environment.

Why Clinical Trial AI Creates a Distinctive Security Problem

Most enterprise security frameworks were designed around protecting data from unauthorized access. That threat model is necessary but incomplete when AI is involved in clinical research, because the most dangerous failures in clinical AI are not always thefts; they are corruptions.

Three properties make clinical trial AI distinctly difficult to secure.

The first is data sensitivity. Trial data contains individually identifiable health information subject to HIPAA, GDPR, and in many jurisdictions, specific national health data laws. Under HIPAA, AI systems that access, process, or transmit electronic protected health information (ePHI) are subject to the same access control, audit, minimum-necessary, and encryption provisions that apply to any covered function accessing PHI ^[2]. The HIPAA Security Rule does not distinguish between human and automated access; the covered entity's obligations follow the data, not the actor.

The second is regulatory reliance. AI outputs in clinical trials feed directly into regulatory submissions. An AI model that flags a safety signal, assigns an eligibility classification, or drafts a protocol deviation report is generating information that regulators at FDA, EMA, and other agencies will evaluate. The standard for data reliability is 21 CFR Part 11, which requires validated computerized systems with secure, audit-ready electronic records for electronic records created or maintained to satisfy a predicate rule requirement, such as those under 21 CFR Parts 312, 314, or 320 governing clinical study submissions ^[3]. This creates a specific challenge for adaptive AI: Part 11 and FDA's guidance on computerized systems require that changes be validated before implementation, but AI models that learn and update may shift behavior without a formal code modification, requiring organizations to define explicit performance thresholds that trigger revalidation ^[3],[4],[11]. (FDA guidances, including the Part 11 scope guidance ^[4] and the AI draft guidance ^[11], represent the agency's current thinking and are not themselves binding; the binding obligation derives from 21 CFR Part 11 as a regulation.)

The regulatory burden is not uniform across AI use cases in clinical development. FDA's Clinical Decision Support Software guidance (January 2026) distinguishes software that meets all four statutory Non-Device CDS criteria from device software functions subject to FDA regulation ^[20]. At the highest level of burden: AI that replaces or overrides a clinician's independent decision without allowing independent review of the underlying logic may qualify as a medical device. Tools used in clinical trial operations, such as AI-assisted eligibility screening, randomization support, or automated regulatory document generation, typically fall outside that category but remain regulated trial systems subject to GCP and 21 CFR Part 11. Sponsors and CROs should determine which classification applies to each AI tool before committing to a compliance architecture, because the documentation requirements, validation standards, and inspection expectations differ materially.

The third is the multi-party architecture. A typical Phase III trial involves a sponsor, one or more CROs, dozens to hundreds of sites, central laboratories, an IRT vendor, a CTMS provider, and increasingly a data science platform. Each boundary between these parties is a potential entry point for unauthorized access or data tampering. Decentralized trial designs and direct-to-patient data collection add further exposure.

The Threat Picture: What AI-Specific Attacks Look Like in Clinical Research

Standard cybersecurity threats, phishing, credential compromise, and ransomware, remain highly relevant. Stolen and compromised credentials were the most common initial attack vector in the 2024 IBM breach analysis, accounting for 16% of incidents, with these breaches taking an average of nearly ten months to identify and contain ^[1]. But AI systems in clinical research face an additional category of threat that has no analog in traditional data management.

Data Poisoning

Data poisoning occurs when an attacker introduces manipulated samples into an AI model's training data, causing the model to produce incorrect outputs in specific, attacker-controlled scenarios while appearing to perform normally on standard validation tests. A 2026 analytical study published in the Journal of Medical Internet Research examined data poisoning vulnerabilities across healthcare AI architectures and modeled scenarios in which attackers with access to as few as 100 to 500 poisoned samples could compromise healthcare AI systems, with attack success rates in modeled scenarios typically at or above 60% ^[5]. Critically, the study found that attack success in these analytical scenarios depended on the absolute number of poisoned samples rather than their proportion of the total training corpus, suggesting that larger datasets do not inherently provide protection. The authors estimated that detection delays in distributed or privacy-constrained clinical environments commonly range from six to twelve months, and may extend longer in federated or heavily restricted data environments ^[5].

In a clinical trial context, data poisoning scenarios include tampered source data introduced during electronic data capture, modified training sets for AI-based eligibility screeners, and altered patient data in adverse event classifiers. The consequences range from biased efficacy estimates to undetected safety signals.

Adversarial Attacks

Adversarial attacks exploit weaknesses in model robustness by introducing subtle, targeted perturbations to input data at inference time. The goal is to cause the model to produce a specific incorrect output without triggering anomaly detection. In a clinical AI context, this could mean modifying imaging data or a sensor waveform in a way that is imperceptible to a human reviewer but causes a diagnostic model to misclassify a safety-relevant finding.

NIST's January 2024 publication on adversarial machine learning (NIST AI 100-2) provides a taxonomy of these attacks and documents their applicability to AI systems in safety-critical domains ^[6]. The same document positions adversarial robustness as a core trustworthiness property, alongside reliability and privacy, and identifies inference-time evasion attacks as among the hardest to detect because they do not require access to the training pipeline. For clinical trial applications, the NIST AI RMF also designates adversarial attack vulnerability as a recognized risk class requiring active governance, monitoring, and mitigation in the AI system's Measure and Manage functions ^[8].

Model Inversion and Intellectual Property Theft

Model inversion attacks allow adversaries to reconstruct training data from model outputs, creating privacy breaches even when the underlying data is never directly accessed. For trials involving rare disease populations or genomic data, this presents a serious re-identification risk. IP theft through model extraction, where an attacker queries a deployed model extensively to reconstruct its parameters, threatens the commercial value of AI developed for competitive drug programs.

Regulatory Framework for Secure Clinical AI

No single regulation governs AI security in clinical trials. Compliance requires satisfying a layered stack of requirements that were written for different purposes but collectively define the minimum standard.

21 CFR Part 11 and the Validation Obligation

21 CFR Part 11 establishes FDA's requirements for electronic records and electronic signatures in regulated clinical trial environments ^[3]. The core controls include system validation to ensure accuracy, reliability, and consistent performance; audit trails that are secure, computer-generated, and time-stamped; access controls limiting system use to authorized individuals; and operational system checks to enforce sequencing where required. ICH E6(R3), whose principles and Annex 1 reached ICH Step 4 on January 6, 2025, and were adopted by EMA in July 2025 and published as final FDA guidance on September 9, 2025, reinforces and expands these obligations significantly. The revised guideline strengthens and formally codifies the "audit trail" definition for computerized systems, requiring that the audit trail show initial entry and changes to data fields, by whom, when, and where applicable, why ^[9]. ICH E6(R3) also introduced a Data Governance section that makes sponsors explicitly responsible for overseeing the entire data lifecycle, including audit trails, secure data transfers, record retention, and destruction protocols, across all systems under their control ^[10].

The challenge with AI-specific validation is that adaptive models can shift behavior between formal validation cycles. FDA's January 2025 draft guidance on the use of AI to support regulatory decision-making (a non-binding document open for public comment) acknowledged this explicitly, recommending a credibility framework that addresses model design, data quality, and performance monitoring as ongoing rather than one-time activities ^[11]. The guidance aligns with NIST AI RMF principles: valid, safe, secure, accountable, explainable, privacy-protective, and fair ^[12].

NIST AI Risk Management Framework (AI RMF)

The NIST AI RMF, published in January 2023 and expanded through 2024 and 2025, organizes AI risk management into four functions: Govern, Map, Measure, and Manage ^[8]. FDA has explicitly cited the NIST AI RMF as a reference standard for AI use by external sponsors and investigators in its April 2026 Request for Information on AI-enabled early-phase clinical trial optimization ^[12]. For clinical trial AI, the framework's Govern function, which establishes accountability, policy, and oversight structures across the AI lifecycle, is where security architecture decisions have the highest downstream regulatory impact. The Measure function, which requires analysis of AI risks including bias, adversarial vulnerability, and performance drift, applies directly to the model security considerations described in the previous section.

On July 26, 2024, NIST released the Generative AI Profile (NIST-AI-600-1), identifying unique risks specific to generative AI and proposing corresponding mitigations, a document with direct relevance to AI-assisted regulatory writing tools operating in clinical development ^[8].

EU AI Act: High-Risk Classification and What It Requires

The EU AI Act, Regulation (EU) 2024/1689, entered into force on August 1, 2024, and applies to AI systems placed on the market or put into service in the EU regardless of where the developer or operator is located ^[13]. AI systems functioning as safety components of products subject to EU MDR 2017/745 or IVDR 2017/746 third-party conformity assessment, covering MDR Class IIa, IIb, and III devices and equivalent IVD classes, are classified as high-risk under Article 6(1). The Act's implementation timeline is phased. Under the original schedule, Annex III standalone high-risk AI obligations were set to apply from August 2, 2026, and Article 6(1) product-embedded systems from August 2, 2027. On May 7, 2026, the European Parliament and Council reached a provisional political agreement under the Digital Omnibus package that defers the Annex III deadline to December 2, 2027, and the Article 6(1) deadline to August 2, 2028 ^[21]. As of this writing, the provisional agreement was pending formal adoption and publication in the Official Journal of the EU before taking legal effect. Organizations planning compliance programs should track formal adoption and confirm the operative timeline before setting internal milestones.

The EU's Medical Device Coordination Group has issued guidance (MDCG 2025-6) clarifying this interplay and confirming that Article 8 of the Act allows AI-specific testing, documentation, and procedures to be integrated into existing MDR conformity processes to reduce duplication ^[14]. High-risk classification under the Act imposes requirements that go beyond MDR/IVDR: mandatory data governance documentation, transparency provisions, human oversight requirements, post-market monitoring, and explicit cybersecurity controls. Article 15 of the regulation requires that high-risk AI systems be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity, and must perform consistently throughout their lifecycle. For sponsors conducting trials with EU sites or generating submissions for EMA, this creates a compliance layer requiring its own documentation that should be coordinated with, but kept distinct from, the clinical trial master file.

Technical Security Architecture: What Good Design Looks Like

Regulatory compliance establishes a floor; secure architecture is built above it. The following controls are drawn from recognized security standards including NIST SP 800-53 Rev. 5, HIPAA Security Rule requirements, and documented best practices from clinical research cybersecurity guidance.

Access Control and Authentication

Role-based access control (RBAC) limits system interaction to authorized users with permissions appropriate to their trial role. For AI systems processing ePHI or trial data, RBAC must be implemented at both the application layer and the underlying data layer, with access logs maintained in a tamper-evident format. NIST Special Publication 800-63-4, which superseded SP 800-63B in August 2025, defines Authentication Assurance Level 2 (AAL2) as requiring two or more authentication factors and recommends it for online services where personal information is made available; federal agencies use this framework to select appropriate assurance levels, and it is widely referenced in GxP and healthcare security programs when determining baseline authentication requirements for systems handling ePHI or regulated trial data ^[15].

The principle of least privilege applies to AI agents as directly as it does to human users. An AI model that produces eligibility determinations should have read access to the data fields relevant to eligibility, and no further. Horizontal privilege is a common misconfiguration in early-stage clinical AI deployments that creates unnecessary exposure.

Audit Trails: Beyond Compliance Minimum

ICH E6(R3) defines the minimum audit trail requirements. Secure design goes further. An audit trail for clinical AI should capture not only the data inputs and outputs of the model at each inference event, but also the model version in use at the time, the data pipeline state, and any preprocessing transformations applied before the model received its input. This creates a complete reconstruction path for any AI-generated output, which is the standard a regulatory inspector will apply when reviewing AI-assisted submissions.

Audit trail records must be immutable and separately secured from the application data they describe, so that an attacker who compromises the primary data store cannot retroactively alter the record of what happened to it. Time-stamp synchronization across systems, a practical challenge in multi-site trials, should be addressed during system design rather than remediated during inspection preparation.

Encryption and Data Transmission

All ePHI at rest and in transit should be protected using cryptographic controls consistent with the security control baselines in NIST SP 800-53 Rev. 5, which specifies protection of information at rest (SC-28) and transmission confidentiality and integrity (SC-8) as required controls for moderate and high-impact systems ^[7]. Clinical trial AI pipelines frequently involve data handoffs across organizational boundaries: from site EDC to central repository, from data management platform to AI inference engine, and from AI output to regulatory submission system. Each handoff is a potential exposure point and should be treated as such in the security architecture.

Privacy-Preserving Training Approaches

Where AI models are trained on patient-level clinical trial data, privacy-preserving machine learning techniques can substantially reduce re-identification risk. Federated learning allows model training across multiple institutional datasets without centralizing raw patient data, with each participating site training on local data and contributing only model weight updates to a global model ^[16]. A 2025 study published in JMIR AI implementing the Personal Health Train federated infrastructure confirmed that model weight updates and gradient exchanges in federated learning can still expose information about institutional data if not further protected, underscoring that federated learning alone does not fully resolve privacy risk ^[17].

Differential privacy, which introduces calibrated noise into the training process to provide mathematical guarantees against individual re-identification, addresses that residual risk. Research published in Scientific Reports in 2025 demonstrated feasibility of combined federated learning with differential privacy for a cancer diagnosis application across multi-institutional data, achieving competitive diagnostic accuracy while maintaining strong privacy guarantees ^[18]. The practical tradeoff is performance degradation at high privacy budgets, a calibration that requires explicit decision-making by the trial team.

These techniques do not eliminate the need for traditional data governance; they complement it. Federated learning does not resolve the audit trail question, and differential privacy does not substitute for access controls.

Governance: The Layer That Makes Technical Controls Work

Technical security controls fail without human governance structures to enforce them. For clinical AI, the governance requirements go beyond standard information security.

AI Governance Program Elements

A sponsor or CRO deploying AI in a clinical trial should maintain written documentation covering the intended use of each AI system, its training data provenance and quality assessment, the validation strategy and revalidation triggers, performance monitoring thresholds and escalation procedures, incident response protocols specific to AI system failures, and a change control process that distinguishes superficial updates from changes that require revalidation. This documentation does not need to be in the TMF, but it needs to be accessible on regulatory inspection and should be explicitly referenced in the study-level quality management plan.

ISPE's GAMP AI Guide, published in 2022, provides a practical framework for applying these governance principles in regulated pharmaceutical environments, including guidance on how to characterize AI systems for validation purposes and how to scope the validation effort proportionately to risk ^[19].

Human Oversight Requirements

Both the FDA draft guidance on AI for regulatory decision-making and the EU AI Act's requirements for high-risk AI systems include explicit human oversight provisions. AI should augment human judgment in clinical research, not replace it. For outputs that feed regulatory submissions, a qualified human reviewer must be in the decision loop, with that review documented in a way that attributes the final determination to a named responsible person. The FDA's draft guidance frames this as the difference between AI that informs clinician or reviewer judgment (lower regulatory burden) and AI that replaces it (potential device classification and corresponding validation requirements) ^[11].

This is not a limitation to be minimized. The appropriate scope of human oversight is a design decision that should be made at the protocol level, before a single line of system architecture is drawn.

Vendor Management

ICH E6(R3) places explicit obligations on sponsors when they outsource trial activities to CROs or technology vendors ^[10]. The sponsor remains accountable for data integrity and security across the ecosystem, regardless of who operates the systems. This means vendor qualification audits should specifically assess AI security architecture, audit trail integrity, validation documentation, and breach response procedures. Vendor contracts should include specific provisions addressing AI system change notification, access control requirements, and data handling obligations aligned with applicable privacy law.

How Kitsa Fits Into Secure Clinical AI Design

Kitsa builds AI tools purpose-designed for clinical research operations. KScribe supports AI-assisted generation of regulatory documents including protocols, informed consent forms, investigator brochures, DSURs, and CSRs. KScreener supports FHIR-based patient pre-screening and eligibility matching. Sponsors and CROs evaluating AI tools for GCP-regulated workflows should conduct vendor qualification due diligence, request current security and compliance documentation from Kitsa directly, and assess product capabilities against their organization's validated system requirements before deployment.

Key Takeaways

• Healthcare data breaches cost an average of $9.77 million in 2024, the highest of any industry for fourteen consecutive years, and clinical trial data carries additional liability because it is often irreplaceable ^[1].
• 21 CFR Part 11 validation requirements apply to AI systems operating in regulated trial environments, and the challenge is that AI models that adapt may change behavior between formal validation cycles, requiring organizations to define explicit revalidation thresholds tied to performance monitoring ^[3],[11].
• ICH E6(R3), finalized at ICH Step 4 and adopted by FDA in September 2025 and EMA in July 2025, strengthens and codifies audit trail requirements for computerized clinical trial systems as part of its expanded GCP data governance provisions, and introduces a Data Governance section making sponsors explicitly responsible for data security and traceability across all systems under their control, including those operated by CROs and technology vendors ^[9],[10].
• In analytical scenarios modeled by a 2026 JMIR study, data poisoning attacks on healthcare AI systems succeeded with as few as 100 to 500 manipulated samples, with attack success rates in modeled conditions above 60% and estimated detection delays of six to twelve months; the authors note these scenarios reflect realistic insider-access threat models rather than confirmed clinical-trial incidents ^[5].
• The NIST AI RMF's four functions (Govern, Map, Measure, Manage) are cited directly by FDA as the reference standard for AI governance in clinical trial contexts, and NIST released a Generative AI Profile in July 2024 addressing risks specific to generative AI tools ^[8],[12].
• The EU AI Act (Regulation (EU) 2024/1689) classifies AI systems functioning as safety components of MDR-covered medical devices as high-risk, imposing cybersecurity, data governance, transparency, and human oversight requirements above and beyond MDR/IVDR obligations. A provisional Digital Omnibus agreement reached May 7, 2026, deferred the Annex III standalone deadline to December 2, 2027, and the Article 6(1) product-embedded deadline to August 2, 2028, pending formal adoption ^[13],[21].
• Privacy-preserving approaches including federated learning and differential privacy reduce re-identification risk in AI model training on patient data, but they do not replace access controls or audit trail requirements; they complement them ^{[16],[17],[18]}.

FAQ

References

1. [1]IBM Security and Ponemon Institute. "Cost of a Data Breach Report 2024." IBM, 2024. https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
2. [2]U.S. Department of Health and Human Services. "Summary of the HIPAA Security Rule." HHS, 2024. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
3. [3]U.S. Food and Drug Administration. "21 CFR Part 11: Electronic Records; Electronic Signatures." Code of Federal Regulations, Title 21, Part 11. FDA.
4. [4]U.S. Food and Drug Administration. "Part 11, Electronic Records; Electronic Signatures: Scope and Application." FDA Guidance for Industry, August 2003. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
5. [5]Gicquel M et al. "Data Poisoning Vulnerabilities Across Health Care Artificial Intelligence Architectures: Analytical Security Framework and Defense Strategies." Journal of Medical Internet Research, January 2026. https://www.jmir.org/2026/1/e87969
6. [6]National Institute of Standards and Technology. "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations." NIST AI 100-2, January 2024. https://doi.org/10.6028/NIST.AI.100-2
7. [7]National Institute of Standards and Technology. "Security and Privacy Controls for Information Systems and Organizations." NIST Special Publication 800-53, Revision 5. September 2020. https://doi.org/10.6028/NIST.SP.800-53r5
8. [8]National Institute of Standards and Technology. "AI Risk Management Framework (AI RMF 1.0) and Generative AI Profile (NIST-AI-600-1)." NIST, 2023 and July 2024. https://www.nist.gov/itl/ai-risk-management-framework
9. [9]International Council for Harmonisation. "ICH E6(R3) Guideline for Good Clinical Practice." ICH Step 4, January 6, 2025. FDA final guidance posted September 9, 2025; EMA effective July 23, 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/e6r3-good-clinical-practice-gcp
10. [10]ACRP. "FDA Publishes ICH E6(R3): What It Means for U.S. Clinical Trials." Association of Clinical Research Professionals, September 2025. https://acrpnet.org/2025/09/16/fda-publishes-ich-e6r3-what-it-means-for-u-s-clinical-trials
11. [11]U.S. Food and Drug Administration. "Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products." FDA Draft Guidance, January 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
12. [12]U.S. Food and Drug Administration. "AI-Enabled Optimization of Early-Phase Clinical Trials Pilot Program; Request for Information." Federal Register 2026-08281, April 2026. https://www.federalregister.gov/documents/2026/04/29/2026-08281/ai-enabled-optimization-of-early-phase-clinical-trials-pilot-program-request-for-information
13. [13]European Parliament and Council of the European Union. "Regulation (EU) 2024/1689 (Artificial Intelligence Act)." Official Journal of the European Union, L 2024/1689, July 12, 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401689
14. [14]MDCG and European AI Board. "AIB 2025-1 / MDCG 2025-6: FAQ on Interplay between MDR, IVDR, and the AI Act." European Commission, June 19, 2025. https://health.ec.europa.eu/latest-updates/mdcg-2025-6-faq-interplay-between-medical-devices-regulation-vitro-diagnostic-medical-devices-2025-06-19_en
15. [15]National Institute of Standards and Technology. "Digital Identity Guidelines: Authentication and Lifecycle Management." NIST SP 800-63B-4, August 2025. https://pages.nist.gov/800-63-4/sp800-63b.html
16. [16]Pati S, Kumar S, Varma A, et al. "Privacy Preservation for Federated Learning in Health Care." Patterns (N Y), July 12, 2024; 5(7):100974. https://www.sciencedirect.com/science/article/pii/S2666389924000825
17. [17]Choudhury A et al. "Advancing Privacy-Preserving Health Care Analytics and Implementation of the Personal Health Train: Federated Deep Learning Study." JMIR AI, February 2025. https://ai.jmir.org/2025/1/e60847
18. [18]Alzubaidi L et al. "Federated Learning with Differential Privacy for Breast Cancer Diagnosis Enabling Secure Data Sharing and Model Integrity." Scientific Reports, April 2025. https://www.nature.com/articles/s41598-025-95858-2
19. [19]International Society for Pharmaceutical Engineering. "GAMP Artificial Intelligence Guide." ISPE GAMP, 2022. https://ispe.org/publications/guidance-documents/gamp-ai-guide
20. [20]U.S. Food and Drug Administration. "Clinical Decision Support Software: Guidance for Industry and FDA Staff." FDA, January 2026 (re-issued January 29, 2026). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
21. [21]Council of the European Union. "Artificial Intelligence: Council and Parliament Agree to Simplify and Streamline Rules." Council of the EU Press Release, May 7, 2026 (updated May 18, 2026). https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/