Put Each Connectivity Requirement Into Contract Language

Use these clauses when you draft an RFP or a purchase contract for an institutional device: one clause for each requirement area of the integration contract, plus a roadmap clause that makes any capability promised for later enforceable. Procurement and counsel adapt them, and HTM, IT, and security supply the specifics; “Hospitals Should Make Connectivity the Default for Institutional Device Purchases” introduces them.

These are sample clauses in plain contract English. They aren’t legal advice. Adapt each one with your counsel to your contract, your jurisdiction, and the device class, and replace every bracketed placeholder. The Health Sector Coordinating Council’s Model Contract-Language for MedTech Cybersecurity (version 2, November 2025) supplies detailed cybersecurity clauses. It contains no clauses on data portability, API rights, or cloud exit, so the API, exportability, and data ownership clauses below have no industry template behind them, and neither does the roadmap clause.

Data semantics:: The vendor shall deliver documentation of every data element the device emits, including its meaning, units, range, time source, and quality indicators, updated with each software release. Supported workflows:: The vendor shall list each workflow the device supports through its interfaces, name the receiving system for each, and demonstrate each one in the Buyer’s test environment before acceptance. Identity:: Each device shall carry a unique, persistent, machine-readable identity on every interface and record, and the vendor shall document how the device identifies its components, accessories, consumables, and software versions. Patient and device context:: The vendor shall document how the device associates each record with a patient, specimen, or workflow instance, how a user confirms and ends that association, how the device marks records created without a confirmed association, and how such a record is later attached to a patient as a logged, attributable event. Event and state models:: The vendor shall document the device’s events, states, and accepted commands, and shall make current state and events available through a documented interface. Application programming interfaces:: The vendor shall provide a documented, versioned interface for reading device data and state, shall support each interface version for at least [period] after its successor is released, and shall give the Buyer [period] written notice before retiring any version. Standards support:: The vendor shall state which standards and profiles each interface implements, with their versions, and shall provide any conformance test results. Security:: The vendor shall deliver with each release a current, machine-readable software bill of materials, a current MDS2 form, and a list of network ports and interfaces; shall maintain a coordinated vulnerability disclosure process; and shall notify the Buyer of any vulnerability affecting the device within [period] of confirming it. Lifecycle support:: The vendor shall state in writing the support period and end-of-support date for the device and its software, shall give the Buyer [period] written notice before end of support, and shall provide a documented process for transferring risk to the Buyer if the device remains in service after that date. Failure behavior:: The vendor shall document, and demonstrate before acceptance, the device’s behavior when each of the following is unavailable: the enterprise network, the domain name system, the identity provider, the vendor’s cloud service, the gateway, the time service, valid credentials, a complete software update, and any remote AI service. The vendor shall demonstrate that therapy changes, alarm acknowledgment, and stopping a therapy never depend on the identity provider or on a credential that can expire, and shall document how the device and the receiving system each show that the connection between them is lost. Update behavior:: The vendor shall deliver only authenticated updates, support staged installation and rollback, document behavior when an update is interrupted, and install nothing during clinical use or an active process cycle without the Buyer’s approval. Observability:: The vendor shall expose device health, software version, configuration, connectivity state, self-test results, synchronization state, and security events through a documented interface, and shall export logs in a documented format that the Buyer’s security monitoring tools can consume. Exportability:: The vendor shall enable the Buyer to export, at any time and at the end of the contract, all data that the device and any vendor-hosted service hold about the Buyer’s operations, in a documented machine-readable format, through an authenticated export path whose every use the device or service logs, without vendor assistance and at no added charge. Exports that contain patient information are handled under the Buyer’s existing privacy and data-handling agreements with the vendor. Data ownership and use:: The Buyer controls the data generated by its use of the device. The vendor shall use that data only for the purposes listed in [schedule], shall not sell it or use it to train models without the Buyer’s written consent for that use, and shall not use security controls to prevent the Buyer from accessing it. Roadmap commitments:: Where the Buyer accepts the device below a required capability, the vendor shall deliver [capability] to every installed unit by [date] at no added charge. If the vendor misses that date, the Buyer may [remedy: withhold [amount] of the price until delivery, take a service credit of [amount] per [period] of delay, or end the contract for the affected units on [terms]].

When a vendor strikes a clause, ask why: capability, liability, or price. Take each capability gap back to the No Connectivity, No Purchase Checklist. Decide whether the gap needs an exception record or ends the evaluation. Don’t trade a capability gap away for a discount.