# DIKWP-Driven Artificial Consciousness for IoT-Enabled Smart Healthcare Systems
## 5 Prototype Implementation
### Evaluation Metrics  
Given the goals of our system, we identified several key metrics to evaluate:  
* Anomaly Detection Accuracy: How well the system detects the injected health events. Since we know the ground truth of events in the synthetic data, we measure standard classification metrics as shown in Table 2:  
From these, we compute detection accuracy (Acc), precision (P), recall (R), and F1-score (F1):  
\[\text{Acc}=\frac{TP}{TP+FP+FN}, \tag{1}\]  
\[\text{P}=\frac{TP}{TP+FP}, \tag{2}\]  
\[\text{R}=\frac{TP}{TP+FN}, \tag{3}\]  
\[\text{F1-Score}=2\times\frac{\text{P}\times\text{R}}{\text{P}+\text{R}}, \tag{4}\]  
We break down performance by event type (falls, arrhythmia, etc.) to see if any particular scenario is problematic.  
* Communication Overhead: We log the amount of data transmitted between the edge and cloud. This is measured in kilobytes (KB) or megabytes per day. We also note the number of messages per minute. We will compare two modes: our DIKWP semantic  
\begin{table}
\begin{tabular}{c c} \hline
**Event Type** & **Description** \\ \hline Tachycardia & In one segment, we raised heart rate to 120-150 bpm for 5 min to simulate an arrhythmia or stress event. \\ Hypotension & Dropped blood pressure significantly for a short period (e.g., 90/60 mmHg from a baseline of 120/80) to simulate dizziness or dehydration onset. \\ Fall & At a random time, we inserted an accelerometer “spike” pattern indicating a fall (in practice, a high acceleration followed by inactivity). \\ Fever & Increased body temperature to 38.5 \({}^{\circ}\)C for a few hours to simulate infection. \\ \hline \end{tabular}
\end{table}
Table 1: Descriptions of injected specific events.  
\begin{table}
\begin{tabular}{c c} \hline
**Metric Type** & **Description** \\ \hline True Positives (TP) & System correctly issues an alert for a real event. \\ False Positives (FP) & System issues an alert when no real event is present (false alarm). \\ False Negatives (FN) & System fails to alert when an event occurred. \\ \hline \end{tabular}
\end{table}
Table 2: Descriptions of standard classification metrics.  
compression vs. a hypothetical \"raw data\" mode. The expectation is that our method drastically reduces bytes sent [50].
* Latency: The time from an event happening (e.g., a sensor reading crosses threshold) to the appropriate action (alert) being taken. In particular, compare edge-local action vs. if it had to wait for cloud. This metric validates the responsiveness of the system [49].
* Energy Impact (indirectly): We do not have actual battery measurements, but we estimate that reducing communication and performing local processing affects device battery life. We approximate energy cost by counting CPU cycles for processing vs. bytes transmitted (since radio transmission often costs more energy than computing on modern devices).
* Explainability and User Feedback: This is qualitative. We present the explanations generated for each alert to a small group of medical students (in a hypothetical review) to gauge if they find them understandable and useful. While not a full user study, it gives insight into the clarity of our semantic outputs.
* Robustness: We test scenarios where the network is unreliable (simulate packet loss or delays) to see if the system still performs. For example, what if the cloud is unreachable? Does the edge still handle things and later sync when back online? We track how many actions occur while cloud disconnected and if any information is lost or queued.