Sample paper
Word Count: approximately 2,100 words
Scope Statement
The report presents a requirements analysis and high-level design for a real-time health monitoring subsystem within a larger hospital patient monitoring system, whose purpose is to continuously collect vital sign data, analyse it for abnormalities, and alert healthcare providers to concerning readings. Functional requirements include per-patient monitoring profiles and alert thresholds, real-time clinician dashboards, and provider notification integration; non-functional requirements include high availability, sub-second processing and alert latency, and healthcare data privacy and security compliance. The subsystem is to be developed using an agile methodology with ongoing clinical end-user collaboration.
Subsystem Description
Each patient is configured with a monitoring profile specifying which vital signs to track and their acceptable ranges based on age, diagnosis, and care plan. Data is collected from bedside devices -- cardiac monitors, pulse oximeters, blood pressure cuffs, and sensor-equipped smart beds -- via wired or wireless connections, polled every one to five seconds, and ingested using HL7 or FHIR protocols. Each reading is compared against configured thresholds; a breach triggers an immediate visual and auditory alert in the central monitoring application plus a mobile notification to on-duty providers. Alerts continue firing until acknowledged or resolved, automatically escalating to additional providers if unaddressed within a configured window. All raw data, threshold analysis results, alerts, and acknowledgements are persisted in a clinical data repository for incorporation into the electronic medical record and retrospective analysis.
Refining the Description with Generative AI
Generative AI queries addressed common continuously monitored vital signs (heart rate/rhythm, respiratory rate, SpO2, blood pressure, temperature, with additional invasive monitoring for critical care patients) and how alert thresholds are determined (standardised reference ranges, deviation from patient baseline, diagnosis, care level, and clinician judgement, including compound rules combining multiple parameters). The critique identified gaps: the need to account for multiple concurrent monitoring channels per parameter, the risk of alarm fatigue from poorly calibrated thresholds, insufficient specificity on compound alert rule types, and the need for integration with computerised provider order entry systems to capture provider-specified thresholds directly.
Data Flow Diagrams
The context diagram identifies six external entities: bedside devices, an HL7 interface engine, the centralised monitoring application, a mobile device gateway for alert delivery, the clinical data repository, and the electronic medical record. The Level 1 DFD decomposes the subsystem into four processes -- Ingest Vital Signs (parsing HL7 messages into an operational data store), Analyze Vital Signs (comparing readings against per-patient thresholds and generating abnormality alerts), Manage Alerts (handling notification, acknowledgement, and escalation), and ETL Monitoring Data (moving data into the clinical data repository) -- connected by flows including vital sign measurements, abnormality events, and alert lifecycle data.
Control Flow Diagrams
Key control flows include Abnormality Detected (emitted when a reading violates thresholds, activating Manage Alerts), Alert Created (activating notification delivery), Alert Updated (when a new abnormality correlates to an existing alert, potentially raising its severity), Alert Acknowledged (deactivating further notification and escalation), Alert Escalated (triggered by an unacknowledged timeout, notifying the next provider tier), and Patient Monitoring Change (activating or deactivating monitoring on admission, discharge, or transfer).
Process Specifications
The Assess Vital Sign process specification retrieves a patient's monitoring profile and thresholds, then applies vital-sign-specific branching logic: for heart rate and respiratory rate, readings outside critical bounds raise a Critical abnormality, while readings outside warning bounds (but within critical bounds) raise a Warning; SpO2 uses a low-side-only threshold structure; and blood pressure evaluates both systolic and diastolic bounds independently, raising the higher of the two resulting severities.
Control Specifications
The alert lifecycle state machine begins in Monitoring, transitioning to AlertDetected on an abnormality event, then to Alerting.Unacknowledged once a new alert is created (saving it to the alert store and sending initial notifications). From there it moves to Alerting.Acknowledged on a provider acknowledgement, or to Alerting.Escalated if the acknowledgement timeout expires (triggering backup provider notifications), with escalated alerts still able to reach Acknowledged. A new abnormality while already alerting updates severity without creating a duplicate alert. The process returns to Monitoring once vital signs normalise, closing the alert and sending resolution notifications.
Conclusion and Next Steps
The artefacts presented lay the foundation for a scalable real-time health monitoring solution intended to improve patient safety by enabling earlier detection of deterioration. Recommended next steps include stakeholder and IT validation, detailed technical specifications and interface control documents, a build-versus-buy evaluation, end-to-end workflow testing across device categories, scalability testing under simulated high-volume scenarios, integration with clinical research databases for future predictive analytics, and a single-unit pilot before enterprise rollout.
References
Escobar, G. J., Liu, V. X., Schuler, A., Lawson, B., Greene, J. D., & Kipnis, P. (2020). Automated identification of adults at risk for in-hospital clinical deterioration. New England Journal of Medicine, 383(20), 1951-1960. Escobar et al., 2020 Fung, N. L., Jones, V. M., Bults, R. G., & Hermens, H. J. (2014, November). Guideline-based decision support for the mobile patient incorporating data streams from a body sensor network. 2014 4th International Conference on Wireless Mobile Communication and Healthcare (MOBIHEALTH) (pp. 312-315). IEEE. Kopetz, H. (referenced within Laplante, 2011, on requirements engineering for real-time systems). Laplante, P. A. (2011). Requirements engineering for software and systems (2nd ed.). CRC Press. Lewandowska, K., Weisbrot, M., Cieloszyk, A., Mędrzycka-Dąbrowska, W., Krupa, S., & Ozga, D. (2020). Impact of alarm fatigue on the work of nurses in an intensive care environment -- a systematic review. International Journal of Environmental Research and Public Health, 17(22), 8409. Lewandowska et al., 2020 Pressman, R. S. (2005). Software engineering: a practitioner's approach. Palgrave Macmillan. Tucker, N., Stoffel, J. M., Hayes, L., & Jones, G. M. (2020). Blood pressure management following acute ischemic stroke: a review of primary literature. Critical Care Nursing Quarterly, 43(2), 109-121. Tucker et al., 2020