## 2 Materials and Methods
### System Architecture
#### 2.1.1 Modular Layered Design  
To handle the complexity of healthcare data and decision processes, the system is organized into distinct layers, each responsible for specific tasks. This layered approach follows principles of separation of concerns and makes the system more maintainable and extensible. The main layers include the following:  
1. **Data Ingestion and Pre-processing Layer. ** This layer continuously captures structured and unstructured data from EHR tables, HL7/FHIR messages [44], and device telemetry. Apache Kafka [45] handles high-throughput streaming, while validation and normalization routines standardize vitals, labs, and other structured fields. Clinical free-text passes through NLP pipelines, and medical images follow standard pre-processing before archival. All events have persisted in the big-data store and forwarded in a unified schema to downstream analytic services, shielding models from source heterogeneity and supporting interactive-latency inference. 2. **Big Data Management and Storage Layer. ** All data (both raw and processed) as well as intermediate results need to be stored and managed efficiently. We incorporate a big data framework (e.g., Hadoop/Spark ecosystem) to handle this. Key aspects of this layer: * **Data Lake and Warehousing. ** A distributed file store holds raw ingested data (Bronze layer in medallion architecture terms) and refined data (Silver/Gold layers) in parquet/orc formats. Structured data may also be stored in a relational warehouse for easy query (SQL) access, while text embeddings or time-series might reside in a NoSQL or specialized time-series database for fast retrieval. * **Parallel Processing. ** Apache Spark v3.5.0 is used for heavy analytics [46; 47] that can be parallelized, such as scanning through millions of records to find similar past cases (for retrieving relevant precedents for a current patient). This ensures the system can be scaled to handle enterprise-level EHR datasets and not just small samples. * **Indexing and Search. ** For unstructured text, we maintain indexes (possibly leveraging Elasticsearch or Solr) to Support Information retrieval. This is particularly useful if the CDSS includes a knowledge base of medical guidelines or past case summaries: when the Decision Engine needs to gather supporting evidence for a recommendation, it can query these indexes (with the help of the LLM to formulate the query) to fetch relevant documents or data points. * **Data Lifecycle and Security. ** This layer also enforces data retention policies and encryption at rest. It tags data with metadata for provenance (which is important for auditing--knowing which source a particular piece of information came from). Access controls ensure that only authorized components or users can retrieve sensitive data, aligning with hospital IT security policies. 3. **FL Layer. ** Once data is preprocessed and ready for model training or updating, the FL layer comes into play for model development in a collaborative but privacy-preserving manner. In a multi-center deployment, each hospital (or clinic) runs an instance of the learning algorithm on its local data. Rather than sending raw patient data to a central server, each site computes updates to the model (e.g., gradient updates) using its local data. A central coordinator (which could be on-premises at a lead institution or in a secure cloud) collects encrypted model updates from the sites and aggregates them (for example, by averaging weights--akin to federated averaging). Only the aggregated model--which now has learned from all participating sites--is sent back to each hospital. This way, the global CDSS model benefits from a wide range of clinical cases (improving its generalization), yet no sensitive patient data ever leavesthe source institutions' control.