## 2 Materials and Methods
### System Architecture
#### 2.1.1 Modular Layered Design
The system can roll back to a prior stable model if a newly deployed one has issues. * **Automated Testing. *
* Similarly to software testing, we maintain a suite of test scenarios (clinical vignettes with known correct outputs) to rapidly verify that any model update does not break core functionality or violate clinical constraints. * **Continuous Learning. *
* In the long run, as clinicians use the system, their feedback (e.g., whether they accepted or overrode a recommendation) can be fed back into model training. The pipeline could schedule periodic retraining (say monthly) using accumulated new data and feedback, thereby improving the models iteratively. This approach reflects the core principles of a learning health system, where continuous feedback loops refine clinical knowledge and practice [51]. * **UI Layer. *
* The UI is the touchpoint between the CDSS and the clinicians (doctors, nurses, etc.). It is designed to be intuitive and fit within clinical workflows to avoid alert fatigue or disruption. Key features of the UI include the following:
* **Dashboard for Triage Nurses. *
* Displaying incoming patients with their vital signs and any alerts. For each patient, if the system has a triage suggestion, it is shown (e.g., color-coded by severity). The nurse can provide input (confirm or adjust
the triage level) and add additional notes, which the system will record--and possibly send back to update the model (with clinician approval). * **Physician View. ** Where a doctor can query the system for diagnostic support. They might see a summary of the case of the patient compiled by the LLM (including relevant past history, flagged abnormal findings, etc. ), and a list of differential diagnoses or management suggestions. The physician can click on any suggestion to see supporting evidence (e.g., guideline links), which could include references to clinical guidelines or similar past cases. * **Alerting Mechanism. ** Critical alerts (like a patient in the waiting area whose condition is deteriorating according to live-streamed vitals) are prominently displayed or even sent to clinicians' mobile devices if integrated. * **Feedback and Override. ** The UI allows clinicians to easily override the recommendations of the system (with a required reason entry, for accountability). It also encourages them to mark if recommendations were useful or if any error is observed, capturing valuable feedback data. The design emphasizes that the CDSS is an aid, not a replacement for clinical judgment. * **Compliance and Monitoring Layer. ** Given the sensitivity of healthcare, the architecture includes a dedicated layer for compliance, audit, and performance monitoring. Our privacy impact assessment follows the practical guidelines for m-health apps under GDPR articulated by [PERSON] et al. [52]. All data processing components enforce access controls and anonymization where appropriate. For example, when sending data to the LLM layer or to the federated server, patient identifiers are stripped and replaced with pseudonyms or hashed IDs. The system maintains audit logs of who accessed what data and what recommendations were made, which is essential for both troubleshooting and legal purposes (e.g., tracking decisions in case of adverse outcomes). We also incorporate monitoring tools that continuously track system uptime, latency of data flows, and model performance metrics (such as the percentage of cases where the triage level of the AI agreed with the final triage of the clinician). If any anomalies are detected--e.g., a sudden spike in disagreement rates or a component failure--this layer triggers an alert to system administrators. To maximize scientific reuse while preserving privacy, all datasets ingested by the CDSS undergo a structured FAIRification workflow that aligns with the generic-yet-domain-agnostic model of [PERSON] et al. [53] and its health-data extension by [PERSON] et al. [54]. Previous research has also explored GDPR-compliant expert systems that integrate ontologies for triage and disease detection [55].