Supplier Due-Diligence Checklist for Patient Monitors: Network Integration Evidence

A patient monitor is rarely bought as a stand-alone box. Once it is connected to a hospital network — admission-discharge-transfer feeds in, vital-sign observations out, central stations and electronic record charts downstream — a large part of the product's usable behaviour is defined by the supplier's interfaces, documentation and support model, not by the front panel. This checklist turns that dependency into a set of verifiable items you can put in an RFQ and score in a supplier evaluation file. It assumes you already have the commercial and clinical shortlist; the focus here is the evidence a supplier must show before the device is allowed to touch a clinical network.

1. Start from your own network and interface requirements

Due diligence without a stated requirement degenerates into collecting brochures. Before contacting suppliers, write down what the monitor has to connect to and under what constraints:

Integration direction. Does the monitor need to receive patient demographics and encounter identifiers (ADT), send observations (results), or both? Bidirectional integration is materially harder to validate than one-way result export and should be specified as such.
Topology and segmentation. Which VLAN or clinical network segment will devices sit on? Is wireless required at the bedside, and if so on which bands and with which authentication (enterprise WPA2/WPA3, certificate-based)?
Downstream systems. Central monitoring, electronic medical record, clinical data repository, alarm management, and any device integration platform already in place — with versions where you know them.
Site constraints. Number of beds, expected concurrent connected devices, network change windows, and whether the site's own IT and biomedical engineering teams will perform installation or the supplier will.
Regulatory context. Whether the device will be placed on the market in a jurisdiction with premarket cybersecurity obligations (for example the US, where FDA's statutory cyber-device requirements under FD&C Act section 524B have applied to premarket submissions since 29 March 2023, including a software bill of materials).

Write these as numbered requirement IDs. Every piece of evidence you request later should map to one of them, otherwise the evaluation file fills with material nobody will read.

2. Interface specification: the documents to demand, not the promises

Ask for documents, with revision or version numbers and dates, rather than statements that the monitor "supports HL7". The following are the core artefacts:

Item	What it must contain	Why it matters to the buyer
Interface specification / interface control document	Message types and trigger events supported (e.g. HL7 v2 ORU^R01 for observations, ADT for demographics), segment and field usage, required versus optional fields, code systems used for observations	Lets your integration team estimate mapping effort before purchase, and shows whether the supplier has a stable, versioned interface rather than site-specific customisation
Conformance statement	Declared profiles, transactions and options; known deviations and limitations	The basis for testing against your requirements; deviations found later are usually expensive
Standardised terminology coverage	How device parameters are coded and mapped (for example use of ISO/IEEE 11073 nomenclature and Rosetta terminology mapping as applied in IHE's Device Enterprise Communication profile, transaction PCD-01)	Determines whether downstream systems can interpret parameters consistently across device makes
Network and security description	Ports and protocols used, outbound/inbound direction, encryption in transit, authentication method, account and certificate management, logging capabilities	The evidence your IT security review needs; without it the device cannot be risk-assessed
Software bill of materials (SBOM)	Component inventory in a machine-readable format, with versioning and update cadence	Needed for vulnerability management, and a premarket requirement for cyber devices in the US
Patch and lifecycle policy	Security update cadence, supported-version window, end-of-support notice period, whether updates are field- or service-applied	Connected devices age badly if the supplier's update commitments are vague

If a supplier cannot produce a versioned interface document for the exact model and firmware you are buying, treat everything else about interoperability as unverified. Firmware version matters: the interface behaviour of the same model can change between releases.

3. Joint risk and responsibility: who owns the connected system

IEC 80001-1 addresses the risk management of a medical IT network that incorporates medical devices — that is, the connected network, not just the device. Ask suppliers how they participate in that process in practice, and get answers in writing:

Do they supply a network risk assessment input pack (device characteristics, data flows, known hazards, recommended mitigations) that your organisation can fold into its own risk file?
Which party is responsible for configuration control, and how are configuration changes on the device audited?
What happens on a network change — for example a new wireless controller, a firewall rule change, or an EMR upgrade? Is re-validation included, chargeable, or excluded?
Who is the named technical escalation contact, and what is the response expectation for a suspected cyber incident involving the device?

Beware of suppliers who describe connectivity purely as an installation task. In a networked clinical environment, connectivity is a shared responsibility with a documented division of labour.

4. Verification evidence: test before you commit

Claimed interoperability should be demonstrated. Ask for, or write into the contract, a verification sequence with defined pass criteria:

Installation qualification (IQ): documented network requirements, port list, address and VLAN assumptions, and a checklist proving the environment meets them.
Operational qualification (OQ): message exchange tested in a non-clinical environment for the agreed message types, with evidence of correct patient-context association, timestamps and units.
Failure-mode testing: behaviour when the network drops, when the downstream system is unavailable, when messages are delayed, and on reconnect. Specifically ask whether observation data is buffered locally, for how long, and whether duplicates or gaps can occur.
Results handling: how the device or gateway behaves if message delivery fails — silent data loss in a monitor interface is the kind of defect that is invisible until it is a clinical governance problem.

Ask for the supplier's own test report and the test environment description; do not substitute a reference site demo for a documented test against your requirement list.

5. Alarms, timing and clinical safety at the interface

When monitors are networked to a central station or alarm distribution system, alarm handling becomes an interface property. Applicants should check:

Which alarm conditions are transmitted, in what priority scheme, and whether priority is preserved end-to-end.
Latency and timeout values for alarm distribution, and how the system behaves under network congestion.
Whether alarm settings on the device can be changed remotely, and how those changes are logged.
Evidence of testing for alarm delivery under the operating modes you will actually use.

Do not accept a verbal assurance that alarms are "real time". Ask for the documented latency figures and the conditions under which they were measured.

6. Security, patching and incident response

For connected devices, cybersecurity due diligence is not a separate chapter — it is part of the supplier's capability assessment. Request:

Evidence of how the supplier identifies and remediates vulnerabilities, including disclosure policy and advisory notifications.
The supported-version matrix: how many firmware generations are patched simultaneously, and the notice period before a version leaves support.
Whether security patches require a service visit, a USB procedure, or can be applied over the network, and the tested rollback path.
Documentation of default credentials and the supported method to disable or change them at deployment.

Match this against your own patching capacity: a supplier with a good policy still needs a buyer able to execute it. If your organisation cannot patch bedside devices on a quarterly cadence, say so during evaluation and negotiate a service option that covers it.

7. Delivery, commissioning and after-sales terms to pin down

Connectivity work often sits awkwardly between the device supplier, the network integrator and the hospital's IT team. Close the gaps in the contract:

Scope of integration services. What exactly is included — interface build, mapping, testing, go-live support, training of biomedical and IT staff — and what is billed as change request.
Acceptance criteria. Tie payment milestones to documented test results against your requirement IDs, not to delivery dates.
Escalation and support hours. Clinical networks run around the clock; confirm support coverage and response times for interface faults separately from hardware faults.
End-of-life and migration. Data export availability if you change platforms, and the supplier's commitment on interface compatibility during a platform transition.
Subcontractors. If a third-party integration gateway is part of the offer, name it in the contract and confirm who holds the support obligation.

8. Red flags in network integration claims

"HL7 supported" with no version, message types or conformance statement.
Interface documentation that is only available after purchase, or only as a screenshot from a reference site.
Any suggestion that your hospital's network risk assessment is the supplier's responsibility, or vice versa.
No stated supported-version window or end-of-support notice period.
Custom, site-specific interface builds presented as standard, which locks future sites into bespoke code.
Refusal to state latency figures for alarm distribution.

None of these are automatically disqualifying, but each should trigger a documented clarification before award rather than a verbal reassurance.

9. A usable checklist for the evaluation file

Copy the items below into your scoring sheet, one row per requirement ID, with columns for request date, document reference and version, evidence accepted (yes / partial / no) and follow-up action:

Interface specification for the exact model and firmware, versioned and dated.
Conformance statement with declared profiles and known deviations.
Observation coding and terminology mapping approach.
Network and security description: ports, protocols, direction, encryption, authentication.
SBOM and vulnerability disclosure process.
Patch cadence, supported-version matrix and end-of-support notice.
Network risk assessment input pack and documented responsibility split.
OQ test report covering message exchange, patient-context association and reconnect behaviour.
Documented alarm distribution latency and behaviour under congestion.
Integration service scope, acceptance criteria and change-request rates.
Interface-fault support hours, escalation path and response times.
Data export and migration commitment at end of life.

The output of this exercise is not a score alone: it is a short list of open items that must be closed in the contract. Where evidence is missing at award, convert it into a contractual deliverable with a date, rather than assuming it will appear at commissioning.

Sources

IHE International, Device Enterprise Communication (DEC) profile, transaction PCD-01, HL7 v2 messaging with ISO/IEEE 11073 terminology — ihe.net
IEC 80001-1, Application of risk management for IT-networks incorporating medical devices — webstore.iec.ch
US FDA, FD&C Act section 524B cybersecurity requirements for cyber devices, applicable to premarket submissions from 29 March 2023 — fda.gov
HL7 International, version 2 messaging standard documentation — hl7.org