IoMT testing services

What actually breaks in a device that lives on somebody else's network?

The device meets traffic nobody designed it to meet. A hospital owns the segment an Internet of Medical Things device sits on. It sets the segmentation, runs the scanners, schedules the wireless upgrades, and changes all three without telling the manufacturer. The failures that define this product class are the ones where no line of your code changed and the device stopped behaving as its file says it behaves.

The routine security sweep is the first of them. A covered entity performing the risk analysis at section 164.308(a)(1)(ii)(A) is assessing risks to the electronic protected health information it holds, and the estate it assesses includes every address on the clinical subnet. Your device answers that traffic. If it reboots, drops its session or stops publishing while the sweep runs, a clinical event has been produced out of an administrative one, and the finding lands on the hospital's report where you never see it.

The second is the segment moving under the product. A port closes, a proxy is inserted, certificate pinning meets a middlebox, or the device is put behind network access control that it was never asked to authenticate to. Nothing in the device has failed. It runs, it draws power, it shows a screen, and the observations stop arriving at the system that was supposed to receive them.

Time is the third. The timestamp on an observation is clinical data, and it comes from a clock the hospital sets. A device that accepts a bad time source without complaining writes a defensible reading against an indefensible time, and the error survives into the chart.

The fourth is patient association. A device is bound to a patient somewhere outside the device: at an admission message, at a worklist query, at a barcode scan by whoever set the device up. The binding then has to survive a bed swap, a discharge, a transfer and a cable moved from one bay to another. Where it does not, the reading is accurate and the chart is wrong, which is the hardest defect class in this product type to detect from inside your own code.

The fifth is the one that reaches the regulatory file directly. IEC 62304 clause 4.3 assigns a software safety class from the risk of harm after risk control measures external to the software system are taken into account, and its NOTE 1 gives hardware, an independent software system and health care procedures as examples of such external measures. A device sitting in a ward has all three available, which is why its class is often lower than a comparable piece of software with no hardware around it. Each of those three belongs to somebody else's organisation and can change without a release note.

Which rules reach a device you ship into a network you do not control?

The EU MDR makes you write the network down and then publish it. Annex I GSPR 17.4 requires that "Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended." The same requirement returns as an information obligation at Annex I Section 23.4(ab), which puts those minimum requirements into the instructions for use.

Those two sections set up the collision this product class lives inside. You specify an environment, you publish the specification in the instructions for use, and you hold no authority over the environment a customer actually provides.

EU MDR Annex I requirements, IEC 62304 SOUP clauses and HIPAA transmission security, each set against what it binds in a connected medical device.

Where the obligation sits	What it binds in a connected device
Annex I GSPR 17.4	The minimum hardware, IT network characteristics and IT security measures needed to run the software as intended
Annex I Section 23.4(ab)	The same set again, as text in the instructions for use, where a customer reads it
Annex I GSPR 17.1	Repeatability, reliability and performance in line with the intended use, with means adopted for the single fault condition
Annex I Section 4	The order of risk control: safe design first, protective measures second, information for safety last
IEC 62304 clause 5.3 and clause 7.1	Requirements for each SOUP item with the hardware and software it needs, and the evaluation of its published anomaly list
45 CFR 164.312(e)(1)	Transmission security over the same wire, judged on the customer's side of it

IEC 62304 applies to the software inside the box and stops at the edge of it. Its field of application at 1.2 states that the standard "does not cover validation and final release of the medical device, even when the medical device consists entirely of software", and NOTE 3 of that subclause points embedded software at related product standards, naming IEC 60601-1 and IEC 82304-1. A product with dedicated hardware therefore sits under a different product standard from software that is itself the device, while both answer to the same life cycle clauses underneath. Which of those clauses bind, and at which class, is set out under what IEC 62304 asks of software testing.

ISO 14971 reaches the security question by its own scope, which names risks related to data and systems security alongside electricity, moving parts and usability, and by its definition of harm at 3.3 as injury or damage to the health of people, or damage to property or the environment. A device that leaks, corrupts or stops delivering data is inside that definition without any argument about patient injury.

FDA attaches a caveat to its recognition of that standard which belongs on any test plan for a connected device. Under recognition number 5-125 for ISO 14971:2019, FDA writes that the standard defines risk as the combination of the probability of harm and its severity, that its premarket cybersecurity guidance "explicitly states this probabilistic model does not apply to cybersecurity, substituting exploitability, the feasibility and technical means by which a vulnerability can be exploited, as the operative basis for security risk estimation", and that standards referencing risk for cybersecurity purposes should reflect the distinction. The record cites 21 USC 360n-2 and the guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", issued February 2026. Two different estimation methods therefore feed one risk file, and a device team that runs a single probability column has quietly picked one of them.

FDA's recognition record for IEC 62304 lists twelve relevant guidances, and two of them are addressed at this class specifically: "Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices", issued September 2017, and "Postmarket Management of Cybersecurity in Medical Devices", issued December 2016. FDA marks the list as examples. How the European route reaches the same software is covered under EU MDR software requirements.

Why does a vulnerability in a third party component become a design question?

Because the component was already inside your regulatory file before the vulnerability was published. On any other product a defect in a dependency is a finding with a version bump behind it. Here the dependency is a SOUP item, and IEC 62304 has two standing obligations attached to it: clause 5.3 asks for the functional and performance requirements each SOUP item has to meet, plus the hardware and software that item needs to work, and clause 7.1 asks for an evaluation of published anomaly lists, deciding which known defects could contribute to a hazardous situation in your device.

A newly disclosed vulnerability is a new entry on a list you already committed to evaluating. The evaluation has an outcome, the outcome is a decision, and the decision is filed.

What the decision may be is constrained. Annex I Section 4 of the MDR fixes the order of risk control: eliminate or reduce risks through safe design and manufacture, then take protective measures including alarms where appropriate, then provide information for safety through warnings, precautions and contra-indications. Publishing a security advisory sits at the bottom of that list. Choosing it means recording why the two options above it were not available, which is a design argument written after the fact.

If the answer is a code change, the change travels through machinery built for a product that is placed on the market once. IEC 62304 carries software maintenance as its own process at clause 6, with 6.1 Establish software maintenance plan, 6.2 Problem and modification analysis and 6.3 Modification implementation, and software problem resolution as a separate process at clause 9, running from 9.1 Prepare problem reports through to 9.8 Test documentation contents. The standard's own Introduction names clause 8 and clause 9 as "two additional PROCESSES considered essential for developing safe MEDICAL DEVICE SOFTWARE". Neither closes while the product is still on sale.

Who patches a device that is already in a hospital?

Neither party can finish the job alone. The hospital owns the fleet and cannot rebuild your firmware. You can build the fix and cannot reach the device. Every correction travels as a controlled release into an installed base whose maintenance window somebody else schedules, and the regulatory obligations run while it travels.

MDR Article 83(1) requires a post-market surveillance system for each device, proportionate to the risk class and appropriate to the type of device, and Article 83(2) requires that system to be suited to actively and systematically gathering, recording and analysing data on quality, performance and safety throughout the device's entire lifetime. Article 84 makes the plan behind it part of the technical documentation under Annex II. This is the machinery that a coordinated disclosure inbox has to feed.

Annex III Section 1(a) names six information sources the plan must collect, and two of them are where a security report arrives: feedback and complaints provided by users, distributors and importers, and publicly available information about similar medical devices. A vulnerability published against a component another manufacturer also ships is, by that second indent, an input to your own surveillance before anybody reports it against your product.

Article 83(3) then lists eight uses the collected data must be put to. Three of them cost engineering time directly: updating the design and manufacturing information, the instructions for use and the labelling; identifying needs for preventive, corrective or field safety corrective action; and detecting and reporting trends under Article 88. The paragraph then closes with the sentence that converts a security response into document work: the technical documentation shall be updated accordingly.

Two definitions decide how much of this reaches you. Article 2(64) defines an incident to include any malfunction or deterioration in the characteristics or performance of a device, and also "any inadequacy in the information supplied by the manufacturer". An instructions-for-use section describing network conditions that no longer hold is inside that phrase. Article 2(65) defines a serious incident by outcome: death, temporary or permanent serious deterioration in a person's state of health, or a serious public health threat.

Trend reporting under Article 88 is the obligation this class trips over silently. It attaches to a statistically significant increase in the frequency or severity of incidents that are not serious, measured against the foreseeable frequency for that device over an observation period, and Article 88(1) requires the methodology for determining that increase and the observation period itself to be specified in the post-market surveillance plan. A fleet whose reconnection failures climb after a customer upgrades its wireless infrastructure is a trend question answered by a document written years earlier. Where the product's claim rests on a stream arriving from a patient's home rather than from a device on a hospital's own network, remote patient monitoring testing covers that shape instead.

What has to be exercised that a bench test never reaches?

The conditions the device will meet in a building you do not own. Each item below is a run, and each produces a record. The list is short because it covers only the part a functional suite leaves out, and every entry exists because the environment belongs to the customer.

• Test every network condition your instructions for use name under Annex I Section 23.4(ab). Then test the device outside those conditions, because a customer will run it there.
• Run a port scan and an unsolicited traffic profile against the device on the bench. Record what the device does. File the result as a verification record.
• Remove the network segment while the device is in use. Return it. Check the state the device presents to the person standing beside it during the gap.
• Give the device a wrong time source. Read the timestamp on the observation after it lands in the receiving system.
• Change the patient association at the source. Confirm the device follows. Discharge the patient. Move the device to another bed. Repeat the check.
• Take each external risk control the safety class depends on and remove it. Record what the device does without it.
• Build one row per SOUP item. Pin the version. Name the anomaly source. Record the decision made about each published anomaly.
• Install an update the way a biomedical engineering team would install it, with no access to your build system and no engineer of yours in the room.
• Exercise each peer system named in the customer contract, in the pairing the contract names.

What does an IoMT device connect to, and where does the evidence thin?

Whatever the hospital already runs, which means the interfaces are decided by the buyer and not by the product. A bedside monitor or a diagnostic instrument publishes observations into a records system over HL7 v2. An imaging device speaks DICOM to a modality worklist source and an archive. A companion application on top of either one usually speaks FHIR R4 to a patient-facing API.

On the HL7 v2 side the relevant message is the one chapter 7 was written for. The chapter describes the transaction set for "sending structured patient oriented clinical data from one computer system to another", with the common use being to transmit "observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) (the filler), to the ordering system", and it states that one OBX segment is transmitted for each component of a diagnostic report, such as an EKG or an obstetrical ultrasound. Table 0354 records that the ORU_R01 structure is used by the R01 trigger event alone, so the coverage arithmetic here is simpler than on an admission feed. The harder work is that a device is the filler, and the fields it fills are units, reference ranges and observation identifiers that the receiving system will interpret under its own local dictionary.

On the DICOM side the device holds real identifiers rather than a claim. PS3.6 Table A-1 registers Modality Worklist Information Model FIND as 1.2.840.10008.5.1.4.31, Modality Performed Procedure Step as 1.2.840.10008.3.1.2.3.3 and Storage Commitment Push Model as 1.2.840.10008.1.20.1, alongside the Storage SOP Classes an imaging device writes under. A requirement that says the device is DICOM conformant gives a tester nothing to assert on, and DICOM conformance testing requirements sets out what the Conformance Statement has to name instead.

The MDR supplies the reason the evidence has to run per pairing. Article 2(25) defines compatibility as the ability of a device, including software, used together with other devices in accordance with its intended purpose, to perform without losing or compromising the ability to perform as intended, to integrate or operate without modification of any part of the combined devices, or to be used together without conflict, interference or adverse reaction. Article 2(26) defines interoperability as the ability of two or more devices to exchange information and use it for the correct execution of a specified function without changing the content of the data. Both are properties of a combination, so neither can be demonstrated by testing the device on its own, and the combinations are chosen by whoever bought it.

That is where the evidence thins. The peer is a production system inside a customer's estate, running a version and a configuration you cannot get an instance of, and the traffic that would prove the pairing carries real patient data. Whether a capture from that peer can be handed over for testing, and on what terms, is its own negotiation and it runs on the customer's clock. Open it early, at how we work with protected health information.

Where does IoMT testing go wrong?

• The instructions for use name network conditions under Annex I Section 23.4(ab) that no test has ever been run against, so the first verification of that text happens in a hospital.
• The safety class rests on external risk control measures that IEC 62304 clause 4.3 permits, and no artefact records what those measures are or who in the customer organisation owns them.
• The SOUP inventory is generated from a package manifest, so it has versions and no anomaly source, which leaves clause 7.1 unanswered on every row.
• Security findings are ranked on a vendor severity score and never restated as a hazardous situation in the device's own risk file.
• Time is treated as infrastructure, so no test exists for what the device records when the clock it trusts is wrong.
• The patient association is tested once, at setup, and never against a discharge, a transfer or a device moved between beds.
• The device is tested against a simulator of the receiving system, and the pairing named in the customer contract is never exercised.
• The post-market surveillance plan fixes an observation period for trend reporting under Article 88, and nothing in engineering reads that number when a fleet's reconnection failures start climbing.
• Update installation is demonstrated by an engineer with access to the build system, who is not the person who will perform it.

What do we run against a connected medical device?

Work starts from the environment statement instead of the feature list. The minimum hardware, network characteristics and IT security measures your instructions for use already publish under Annex I Section 23.4(ab) become the first test matrix, and the conditions outside that statement become the second, because a customer will produce them whether or not the file admits them.

The SOUP inventory is built next, per item, with a version pinned and an anomaly source named against each row, so that a disclosure arriving six months later lands on a row that already exists. Beside it we write the change rule: which classes of change reopen which evidence, agreed before a security fix forces the question under time pressure. Each external risk control the safety class depends on is named, attributed to an owner in the customer organisation, and tested by removing it.

What that produces is a file in which a published vulnerability has a route: from the anomaly list, to the hazardous situation it could contribute to, to the decision recorded against it, to the run that shows the decision held on a named build. How those runs are executed and traced is covered under medical device software testing.

The clause numbers, article numbers and quoted phrases on this page were checked on 2 September 2026 against the primary text of each standard and regulation. The FDA guidance titles and issue dates are as listed on FDA's own recognised consensus standards records for IEC 62304 and ISO 14971:2019.