## 2 Materials and Methods
### Deployment Scenarios
#### 2.2.1 Integration with Clinical Data Sources  
A successful deployment hinges on seamless data flow from clinical systems into the CDSS. Hospitals typically have disparate systems for different data types:  
* **EHR Systems.** These are the primary sources of structured data (patient demographics, encounter info, vital signs, lab results, medication orders). Our CDSS can be deployed alongside the EHR, either on premises or on a secure cloud that interfaces via HL7/FHIR APIs. In practice, this means subscribing to the feed of updates of the EHR: for example, using the FHIR Subscriptions API or database triggers that send new entries (like a lab result posting) to the Data Ingestion Layer. We designed an adapter that listens for new triage notes and vital signs in the EHR of the hospital and pushes them into Apache Kafka topics for processing. This adapter maps EHR data fields to the internal schema of the CDSS (ensuring, say, that \"blood_pressure_systolic\" in the database of Hospital A is recognized as the systolic BP in our system).
* **Laboratory and Imaging Systems.** If not fully integrated into the EHR, lab and radiology systems can independently send data. Deployment involves setting up interface engines that route lab results to the CDSS. For imaging, the system might receive a notification that an imaging study is available, and possibly a report text once a radiologist has read it. Those reports can be fed to the LLM layer for analysis (e.g., detecting a mention of \"acute fracture\" in an X-ray report to raise the urgency for an orthopedic consult).
* **IoT and Wearable Data.** In advanced deployments, patient-worn devices or remote monitoring systems provide continuous data (heart rate, glucose levels, etc.). The CDSS uses an IoT broker (such as MQTT [59] via Eclipse Mosquito [60]) to ingest this streaming data. For instance, if a patient in an observation unit has a wearable ECG, the signal can be streamed, and the digital twin layer of our system will update the status of the patient continuously. A rule might trigger if a dangerous arrhythmia is detected, generating an immediate alert through the CDSS UI.
* **Public Health and Knowledge Databases.** Deployment can also include connecting to external knowledge sources or risk calculators. For example, linking to a national poison control database for triage in toxin ingestion cases, or pulling frequently updated COVID-19 prevalence data from public health APIs to adjust triage decisions during an outbreak. These integrations are scenario-dependent; our architecture foresees a Knowledge Base Service that can be configured to fetch such external data and provide it to the Decision Engine when relevant.
* **Ontology-Mapping and Terminology Service.** A critical aspect of integration is data normalization. Each source might use different coding systems (ICD, SNOMED CT, LOINC, etc.). In deployment, we include a terminology service that maps synonyms and codes to a common reference. Real-world clinical systems rarely speak the same \"vocabulary.\" Laboratory feeds use LOINC, medication orders rely on RxNorm, diagnoses may arrive as ICD-10-CM [61], while downstream reasoning modules expect the richer semantics of SNOMED CT. The OMTS bridges these gaps by performing four functions as shown in Table 3. Figure 4 presents a Sankey-style workflow of the OMTS. Heterogeneous code systems--ICD-9, ICD-10, LOINC, RxNorm, MeSH [63], UMLS [64], and institution-specific local codes--enter from the left, flow through the four OMTS modules (code normalization, ontology alignment, semantic enrichment, and quality assurance), and emerge as unified SNOMED CT/HL7 FHIR CodeableConcepts. These standardized concepts feed the DSE, which in turn supplies the downstream LLM pipeline.