Intended Use & Clinical Safety Statement

Product: Caresoft eICU (tele-ICU platform)  •  Version: 1.1  •  Effective: 01/04/2026

This statement defines what the Caresoft eICU platform ("the Platform") is intended to do, who may use it, in what environment, and — critically — what it must not be relied upon for. It is issued by Caresoft Systems Private Limited and forms part of the agreement with each deploying hospital.

1. Intended use

The Caresoft eICU Platform is intended to aggregate, transmit, store, display and trend physiological and clinical data originating from connected medical devices and from hospital information systems, and to present that data to authorised clinical personnel at the bedside and at a remote command centre, in order to support the remote observation, documentation and clinical review of critically ill patients.

The Platform additionally supports clinical documentation, shift handover, workflow coordination, retrospective review, reporting and audit.

The Platform is an adjunct to, and not a replacement for, direct bedside clinical assessment, bedside physiological monitoring, and the clinical judgement of qualified healthcare professionals.

2. Intended users

The Platform is not intended for use by patients, families, or untrained personnel, and is not a patient-facing product.

3. Intended environment

• Hospital intensive care units, high-dependency units and step-down units, and a remote command centre operated by or for the hospital.
• Deployed on a hospital-controlled or hospital-approved network meeting the requirements in the Device Interfacing & Integration Policy.
• Under an established clinical governance structure with a named clinical owner at each site.

The Platform is not intended for use in ambulances or patient transport, in home care, in the operating theatre as an anaesthesia record where a validated AIMS is required, or in any environment where the network path or bedside supervision cannot be assured.

4. Patient population

Adult patients admitted to a critical care area under the care of the deploying hospital. [Paediatric and neonatal patients: state explicitly whether in or out of scope. If derived scores such as NEWS2 are used, note that NEWS2 is not validated for patients under 16, in pregnancy, or in some other populations.]

The Platform makes no assessment of whether a given patient is appropriate for remote monitoring. That determination is a clinical decision made by the responsible treating team.

5. What the Platform does

• Acquires numeric physiological data from connected, validated bedside devices via an on-site edge agent.
• Buffers data locally during network interruption and forwards it when connectivity is restored (store-and-forward).
• Attributes device data to a patient encounter using bed-based association informed by admission, discharge and transfer data.
• Stores, trends and displays numeric data with drill-down, and exports it to Excel and PDF.
• Computes documented derived values, including early warning scores, from stored data.
• Raises configurable secondary notifications to designated personnel.
• Supports clinical documentation, handover and scheduled reporting.
• Maintains an immutable audit trail of access and clinical actions.
• Records and surfaces its own integrity state — device sync health, downtime, clock drift, data gaps and quarantined samples.

6. What the Platform is NOT for

7. Alarms and notifications

• Notification thresholds are configured by the hospital and are the hospital's clinical responsibility. Caresoft does not set, recommend or validate clinical thresholds for any individual patient.
• Notification delivery is recorded in the Platform. Absence of a delivery record does not imply the underlying clinical event did not occur.
• Recipients, escalation paths and acknowledgement expectations must be defined by the hospital in a written escalation protocol before go-live.
• The Platform does not replicate device alarm states. A Platform notification is derived from transmitted numeric data, not from the device's own alarm engine.
• Alarm fatigue is a recognised patient safety hazard. The hospital is responsible for reviewing notification volume and tuning thresholds accordingly.

8. Latency, gaps and data integrity

• Data displayed is near-real-time, not real-time. End-to-end latency depends on device polling interval, edge agent cycle, network conditions and server load. Typical latency at a correctly configured site is [x] seconds; it is not guaranteed and may be materially longer.
• Network interruption causes buffered data to arrive late, in a batch, with original timestamps. Displayed trends may therefore fill in retrospectively.
• Data gaps are recorded and surfaced. A flat or absent trend does not mean the patient was stable — it may mean no data was received. Users must check the sync health indicator before drawing any conclusion from the absence of data.
• Clock drift between device, edge agent and server is measured and logged. Timestamps may be adjusted per the documented time-synchronisation method. Where drift exceeds the configured tolerance, affected data is flagged.
• Samples that cannot be attributed to a patient are quarantined and stored, not discarded, and may be reclaimed when attribution information arrives late.

9. Patient–device attribution

• Human-entered associations take precedence over automatic ones.
• The hospital must ensure ADT information is accurate and timely, and that bed and device moves are recorded promptly.
• Clinicians must confirm that displayed data corresponds to the intended patient before acting on it, particularly after any transfer.
• Where attribution is uncertain, the Platform quarantines data rather than guessing. Quarantined data is visible to administrators and must be reviewed.

10. Early warning scores and derived values

• Derived values, including NEWS2 and any other score the Platform computes, are calculated from data available to the Platform at the time of calculation. If a parameter is missing, stale or wrongly attributed, the score is unreliable.
• Scores are screening and triage aids. They are not diagnostic, are not validated for every population, and must be interpreted in clinical context by a qualified clinician.
• The scoring method, parameter set, and handling of missing values are documented in [docs/SCORING.md]. Any hospital-configured variation from the published method is the hospital's clinical responsibility and must be recorded.
• A score is never a substitute for examination. A normal score does not exclude deterioration.

11. Clinician responsibility

12. Limitations and contraindications

13. Deployment prerequisites

The Platform must not be used clinically at a site until all of the following are complete and documented:

• Device interfacing validated per the Device Interfacing & Integration Policy, with a signed site acceptance test for every device type.
• A named clinical owner and a named technical owner appointed at the site.
• A written escalation protocol defining who is notified, by what route, and what response is expected.
• A written downtime procedure (Section 15) issued to all clinical areas.
• Notification thresholds reviewed and approved by the site's clinical governance process.
• All users trained and recorded (Section 14).
• Time synchronisation verified across devices, edge agents and servers.
• ADT feed validated, or manual admission workflow agreed for pilot operation.

14. Training requirements

• No user may be granted clinical access without completing role-appropriate training, recorded with date and trainer.
• Training must cover: intended use and limitations in this document; the meaning of sync health and data-gap indicators; patient–device attribution and the transfer workflow; notification behaviour and its limits; the downtime procedure; and escalation.
• Refresher training at least [annually], and on any material change to the Platform.
• The hospital maintains the training record and is responsible for ensuring only trained users hold clinical access.

15. Downtime and fallback

• On loss of the Platform, clinical areas revert immediately to bedside monitoring and paper or HIS-based documentation. Bedside alarms are unaffected by Platform downtime.
• The command centre must not assume that absence of notifications means absence of events. Loss of data flow is itself an escalation trigger.
• Buffered data arriving after restoration must be reviewed for events that occurred during the outage.
• Planned maintenance is notified in advance; the site decides whether additional bedside cover is required during the window.

16. Regulatory status

The Platform is supplied for use in accordance with this statement. Use outside the stated intended use is off-label, is at the deploying hospital's sole risk, and voids any representation made by Caresoft as to suitability.

17. Incident reporting and vigilance

• Any incident in which the Platform contributed, or may have contributed, to patient harm, a near miss, incorrect data attribution, a missed or spurious notification, or loss of clinical data must be reported to Caresoft immediately at [[email protected]] and by phone to [number].
• Reports must include: site, date and time with time zone, patient identifier as permitted, bed and device, what was displayed, what was actually the case, and the clinical consequence.
• Caresoft will acknowledge within [4] hours, investigate, preserve relevant logs and audit records, and provide a written finding within [10] working days, or an interim report if the investigation is longer.
• The hospital remains responsible for its own incident reporting to its clinical governance body, accreditation body and any regulator, and for patient disclosure obligations.
• Where a defect affects other sites, Caresoft will issue a field safety notice to all affected hospitals.
• Neither party may destroy or alter logs, audit records or device data relating to a reported incident until the investigation is closed.

18. Change control

• Changes affecting intended use, scoring methods, notification behaviour, attribution logic or the validated device list are clinically significant and are notified to sites at least [30] days in advance, with a description of the clinical impact.
• Clinically significant changes may require re-validation, re-training or re-approval by the site's clinical governance process before the site adopts them. The site decides.
• Emergency changes addressing a patient safety defect may be deployed faster; sites are notified immediately with the reason.
• This document is revised whenever intended use or limitations change. Sites must withdraw superseded revisions from clinical areas.