Device Interfacing & Integration Policy

Product: Caresoft eICU  •  Version: 1.1  •  Effective: 01/04/2026

This Policy governs how bedside medical devices are connected to the Caresoft eICU Platform, who is responsible for what, and what must be validated before any device data is used clinically. It forms part of the Master Services Agreement and must be read with the Intended Use & Clinical Safety Statement.

1. Scope

This Policy applies to every bedside device connected to the Platform at every deploying site — patient monitors, ventilators, anaesthesia machines, infusion devices and any other source of physiological data — and to the edge agents, gateways, cabling and network segments used to carry that data.

2. Validated device scope

Only devices that appear on the site-specific validated device list may be interfaced and relied upon clinically. A device qualifies for that list only when the specific make, model, software/firmware version and interface mode has passed bench validation and site acceptance testing under Sections 7 and 8.

Current product-level supported scope:

Explicitly out of Phase 1 scope: Philips DEI over RS-232, waveform capture, and any device requiring a proprietary licence or gateway not procured by the hospital.

3. Unvalidated devices

Connecting an unvalidated device to the production Platform without written agreement is a breach of this Policy and of the Master Services Agreement, and voids Caresoft's representations in respect of the affected data.

4. Interface architecture

• Edge agent — runs on hospital-side hardware, one supervised process per device, performs protocol decoding, local buffering and upload.
• Store-and-forward — data is buffered locally on network interruption and uploaded with idempotent batch identifiers, so replay does not duplicate records.
• Authenticated ingest — every upload is HMAC-signed. Unsigned or wrongly signed batches are rejected and logged.
• Heartbeat — each agent reports liveness, buffer depth and clock offset. A watchdog raises an integrity alert on missed heartbeats.
• No inbound path to devices — the architecture provides no route by which the Platform, the command centre or Caresoft can transmit to a device.

5. Network and infrastructure requirements

The hospital must provide and maintain:

• A segmented device/biomedical VLAN, isolated from general user traffic, with documented firewall rules permitting only the required flows.
• Edge agent hardware meeting the published specification, on protected power (UPS), in a secured location.
• Stable connectivity from edge agents to the Platform, with the bandwidth and latency stated in the site design.
• Cabling, serial adapters, converters and connectors of appropriate medical-grade quality, installed so as not to create a trip, traction or electrical hazard at the bedside.
• Electrical safety compliance for anything connected to a patient-connected device, verified by biomedical engineering.
• NTP service reachable by all edge agents and devices supporting it (Section 9).
• Monitored alerting so that edge agent or gateway failure is noticed by hospital IT, not only by Caresoft.

6. Responsibility matrix

R = responsible   S = supports   A = accountable/approves

7. Validation protocol

Each device make/model/firmware/interface combination is validated against a documented protocol before it may be added to any site's validated list. The protocol covers at minimum:

1. Procurement and documentation — protocol specification, conformance statement, licence for the data output where required.
2. Connection — physical and logical connection established without altering device configuration.
3. Parameter identification — every parameter mapped to the correct internal code, with units confirmed. Unit mismatches and vendor-specific codes explicitly checked.
4. Value accuracy — displayed device value compared against Platform-received value across the clinical range, including boundary and out-of-range values.
5. Special values — handling of null, invalid, artefact-flagged, out-of-range, "searching", and probe-off states verified. These must not be presented as valid numbers.
6. Timestamp fidelity — device time versus received time, drift measured.
7. Sampling behaviour — interval, jitter and burst behaviour characterised.
8. Disconnection — behaviour on cable pull, device power-off, network loss and device standby; confirm the Platform shows a gap rather than a stale value.
9. Reconnection and replay — buffered data uploads correctly with original timestamps, no duplication, no reordering error.
10. Load — sustained operation at expected bed count for a defined period without degradation.
11. Alarm independence — confirm device alarms are unaffected by connection and continue to function normally.
12. Negative testing — malformed messages, wrong signature, wrong device identity, clock skew beyond tolerance — all rejected and logged, none silently accepted.

Results are recorded in a signed validation report retained by both parties.

8. Site acceptance testing

• Bench validation does not substitute for site testing. Every site executes a site acceptance test (SAT) per device type, on the actual units and network in use.
• The SAT must be witnessed and signed by the hospital's biomedical or IT owner and by the clinical owner.
• No device may be relied upon clinically until its SAT is signed.
• The SAT record identifies each device by serial number, model, firmware version, bed, edge agent and interface mode.
• Failures are recorded, remediated and re-tested. A partially passing SAT does not permit clinical use of the failing parameters.

9. Time synchronisation

• All servers, edge agents and time-capable devices must synchronise to a common, reliable time source. Indian deployments should use NPL or NIC time servers.
• Edge agents measure and report clock offset with every heartbeat. Offsets beyond the configured tolerance raise an integrity alert.
• The documented rule for reconciling device time against server time is recorded per site and must not be varied without change control.
• Data received with skew beyond tolerance is flagged and must be reviewed before clinical reliance.
• All timestamps are stored with explicit time zone. Date entry and display must be unambiguous; ambiguous date formats are not permitted anywhere in the interface or in exports.

10. Bed, device and patient attribution

• Device data is attributed to a patient by bed, over closed time intervals, informed by ADT.
• The bed–device mapping must be accurate at all times. Any physical move of a device between beds must be recorded in the Platform before or immediately after the move.
• Human-entered associations override automatic association.
• On transfer, association is closed on the old bed and opened on the new one. Data recorded before the patient arrived on a bed is never attributed to them.
• Where attribution cannot be determined, samples are quarantined and stored, and may be reclaimed automatically when late ADT arrives. Quarantine is not data loss, but quarantined volume must be monitored — a rising count indicates an ADT or mapping problem.

11. Integrity monitoring

The Platform records and surfaces its own integrity state. The hospital must assign responsibility for reviewing it:

12. Data gaps and quarantine

• Gaps are recorded with start, end and cause where determinable, and are visible in the interface and in exports.
• Exported reports carry a data-completeness indicator. Reports covering a period with significant gaps must not be presented as a complete record.
• Buffered data arriving after an outage is inserted at its original timestamp. Users reviewing a period must re-check it after an outage is resolved.
• Data is never silently discarded. Anything that cannot be attributed is stored in quarantine.

13. Change control and re-validation

Where a change is made without notice and data integrity is affected, remediation is chargeable and Caresoft's representations in respect of the affected data do not apply.

14. Biomedical and vendor coordination

• Some device vendors require a licence, licence key, licensed interface module or vendor engineer attendance to enable data output. Procuring and paying for these is the hospital's responsibility unless the Order states otherwise.
• Caresoft will support vendor discussions and provide technical requirements, but has no contractual relationship with the device vendor and cannot compel vendor cooperation or timelines.
• Where a vendor declines to enable or document an interface, that device cannot be integrated. This is not a Caresoft failure and does not entitle the hospital to a remedy under the SLA.
• Devices under vendor AMC must not be modified in any way that voids the AMC. Connection to the Platform is passive and should not do so, but the hospital must confirm this with the vendor.

15. Security of the device network

• The device network segment must be isolated, access-controlled, and not routable from general hospital user networks or the internet except as required for Platform ingest.
• Edge agent credentials and HMAC keys are secrets. They must be stored securely, never shared, and rotated on personnel change or suspected compromise.
• Physical access to edge agents and gateways must be restricted.
• Any suspected compromise of the device network, an edge agent, or ingest credentials must be reported to Caresoft immediately at [email protected] , and is also subject to the CERT-In reporting obligations described in the Privacy Policy.
• The hospital must not install unapproved software on edge agent hardware or repurpose it for other functions.

16. Decommissioning

• When a device is retired or removed from interfacing, its association intervals are closed, its entry is marked inactive, and it is removed from the validated device list. Historical data remains attributed to the patients it was recorded for.
• Edge agent hardware being retired must have its buffer flushed and confirmed uploaded, then be securely wiped before disposal or repurposing.
• Removal of a device must be recorded with date, reason and the person authorising it.

17. Records to be maintained

Both parties retain, for the life of the deployment plus the retention period in the Master Services Agreement:

• Validated device list per site, with model, firmware, serial number, bed and date validated.
• Signed bench validation reports and site acceptance test records.
• Change notifications and re-validation records.
• Named clinical, technical and biomedical owners, with contact details, kept current.
• Integrity review records where the site's governance process requires them.
• Incident reports and their outcomes.

18. Contact

Device integration: [email protected]
Patient safety incidents: [email protected] and 7400390415 — immediate
Security: [email protected]
Caresoft Systems Private Limited, 311, Mahesh Industrial Estate , Silver Park, Mira Road East , Thane -401107,
CIN U72900MH2022PTC387875.