How to write a medical device interoperability test plan

What has to be in an interoperability test plan before anyone accepts it?

Four things a reader can check without your help: the boundary, the counterpart list, the assumptions stated as failable claims, and the record of what was left untested. The regulation that asks for the document also fixes its shape. MDR Annex II Section 6.1(b) names software verification and validation as one of six subject areas the test design, protocols, methods of data analysis, data summaries and conclusions have to cover, and describes the evidence as "the summary results of all verification, validation and testing performed both in-house and in a simulated or actual user environment prior to final release". The same indent adds that the information "shall also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer".

Three obligations fall out of that sentence, and each one is a section of the plan. The process is described as well as the results. Testing away from the bench is named in the text and therefore has to appear or be argued away. Coverage is counted across every configuration your own labelling claims.

The acceptance criteria at the top of the plan are best taken from the Regulation's own definition, because a reviewer already reads in those terms. MDR Article 2(26) defines interoperability as the ability of two or more devices, including software, from the same or different manufacturers, to "(a) exchange information and use the information that has been exchanged for the correct execution of a specified function without changing the content of the data, and/or (b) communicate with each other, and/or (c) work together as intended". Article 2(25) defines compatibility separately, and its second limb is the one integrations fail: the ability to "integrate and/or operate without the need for modification or adaption of any part of the combined devices".

Limb (a) is a test, in three parts. A specified function executes correctly on the received data, the content of the data is unchanged, and the receiving system is the place both are observed. A plan whose top-level criterion reads "the interface works" has thrown all three away.

Sections of a medical device interoperability test plan, the EU MDR provision behind each, and what a reviewer opens it to find.

Plan section	What obliges it	What a reviewer opens it to find
Operating environment	MDR GSPR 17.4	The minimum hardware, IT network characteristics and IT security measures the software needs, matched to what the instructions for use say under Annex I Section 23.4(ab)
Counterpart register	MDR Annex II Section 6.1(b)	Which systems, versions and configurations the summary results cover
Assumption register	The counterpart's own specification	Each thing the device takes on trust, and the test that would catch it being false
Untested cases	MDR Annex II Section 6.1(b), closing paragraph	A written rationale wherever no new testing was undertaken

GSPR 17.4 is worth reading beside the instructions for use, because the MDR says the same thing twice on purpose. The requirement is to "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", and Annex I Section 23.4(ab) repeats it verbatim as an item of information the instructions for use must carry. Whatever network conditions the plan tested under are the ones the label is promising. The full set of software obligations is laid out on what the EU MDR requires of software.

Where does the boundary of the device stop?

At the last thing you control, which is rarely where the architecture diagram stops. The register that answers this is one row per interface per counterpart per direction, and the standards decide how finely the rows split.

DICOM splits them further than most teams expect. PS3.2 Section 7 names four communication mechanisms an implementation may claim conformance to: the DIMSE protocol, DICOM Web Services, DICOM Media Storage, and DICOM Real-Time Video. Each is a separate claim with its own minimum requirements, so a product that speaks DIMSE to one peer and DICOM Web Services to another holds two claims and needs two sets of rows. Conformance below that level attaches to a Service-Object Pair Class, and one row expands into three further documents: PS3.2 Section 7.1.1 notes that conformance to a Standard or Standard Extended SOP Class "implies conformance to the related IOD outlined in PS3.3, the Data Elements defined in PS3.6, and the operations and notifications defined in PS3.7". A row that reads "DICOM storage" leaves the reader to guess which three documents were opened. What DICOM conformance actually covers sets out the four constituents a Conformance Statement has to declare.

HL7 v2 counts in the same direction. Its conformance methodology calls a conversation between two actors an interaction, binds each interaction to exactly one message profile, and calls a roundtrip a transaction. So the register unit is the interaction, and one downstream partner can occupy a dozen rows. The order in which those rows are then worked through is the subject of the seven passes of an HL7 v2 interface test.

For a software-only product, IEC 82304-1 puts the boundary question inside its requirements clause. Clause 4 has seven subclauses, and two of them are verification subclauses in their own right: 4.3 verification of health software product use requirements and 4.6 verification of system requirements, sitting directly under 4.2 and 4.5 where those requirements are written. Clause 6 then titles the two documents the standard expects by name, the validation plan at 6.1 and the validation report at 6.3. A plan that names the system requirements it verifies maps onto that structure without translation.

How do you write down what the device assumes about the other side?

As a sentence a single test can falsify, with the document it came from and the date that document was read. An assumption held in someone's head is the commonest defect in these plans, because it is invisible until the far end changes and nobody knows a change happened.

HL7 states the mechanism that produces most of them. A message profile is allowed to "reduce or eliminate the optionality (or openness) of the base standard", and the standard's worked example is an element that is optional in the base message definition and required in the profile. Constraints move one way only: an element that is required "cannot be relaxed, e.g., changed to Optional". So a field your device omits legitimately can be the field a receiving site refuses on, and both positions are correct. HL7 also records that sender and receiver hold their own profiles, that "the requirements or expectations of each application may, and often do, differ", and that the two sets have to be compatible for the interface to work at all.

DICOM produces the same class of assumption from the other direction. PS3.2 Section 6 states that an implementation need not employ all the optional components of the Standard, and that after the minimum requirements are met a conformant product may use whatever SOP Classes, protocols, Media Storage Application Profiles and Type 3 attributes its designed task needs. Two conformant products can therefore share nothing.

Each assumption row carries five cells: the element or behaviour, the statement in the affirmative, the source document with its version and the date it was read, the test that fails when the statement is false, and what the device does in that case. The fifth cell is the one that turns a documentation exercise into a design review, because "the device retries and the operator sees nothing" is an answer that has to go somewhere.

Write the claim in the right vocabulary as well. HL7's conformance methodology separates four terms a plan tends to use interchangeably: compliance, between a derived specification and the standard; conformance, between an implementation and a specification; compatibility, between two specifications; and interoperability, "the ability of implementations to exchange data and to use that data as intended to accomplish a desired task", with the note that "in theory, compatibility is a prerequisite for interoperability". A plan claiming conformance and a buyer expecting interoperability have agreed on nothing. Reconciling a published claim against the system that is actually running is a distinct piece of work, scoped under an interoperability testing engagement.

What does the hazard analysis add once a second system is in the loop?

Hazards that neither product owns alone. ISO 14971 defines a hazardous situation at 3.5 as a "circumstance in which people, property or the environment is/are exposed to one or more hazards", and clause 5.4 covers the identification of hazards and hazardous situations. A second system in the loop creates circumstances: the message that arrives twice, the value coerced in transit, the result filed against a patient identifier the far end rewrote, the feed that stops without an alarm anywhere.

Two subclauses of clause 7 exist for what happens next. 7.5 covers risks arising from risk control measures, which is where a retry, a queue or a reconciliation job belongs once you add one. 7.6 covers completeness of risk control, and clause 8 covers the evaluation of overall residual risk. The standard sets no threshold for any of it: its scope states that the document "requires manufacturers to establish objective criteria for risk acceptability but does not specify acceptable risk levels", so the acceptability line in your plan is yours to write and yours to defend.

The join between that file and this plan is clause 7.2. ISO/TR 24971 states that "the risk management plan specifies how the two verification activities required per 7.2 of ISO 14971:2019 are carried out", those two being verification of the implementation of risk control measures and verification of their effectiveness. Interface risk controls tend to be software, so both verifications land in a test suite, and the interoperability plan is where they become visible to a reviewer. ISO/TR 24971 also states the traceability expectation: each identified hazard traces to the risk analysis, the risk evaluation, the implementation and verification of risk control measures, and the evaluation of residual risk. That trace is what the ISO 14971 risk management process asks an auditor to be able to follow.

IEC 82304-1 says the limit of this plan out loud in its own introduction: "Testing of the finished product is not, by itself, adequate to address the SAFETY of HEALTH SOFTWARE." A test plan that carries the whole interface risk argument is doing a job the process evidence is supposed to share.

What can a simulator settle, and what needs the real counterpart?

A simulator settles what your device emits and accepts. It cannot settle what the other side does with it. The MDR names both environments in one breath, listing testing performed "both in-house and in a simulated or actual user environment", so a plan that stops at the bench has to explain the omission.

DICOM assigns the second half explicitly. The template text PS3.2 Annex N.3.3 puts into every vendor's own Conformance Statement says the document "should not replace validation with other DICOM equipment to ensure proper exchange of intended information", and the same annex states that "test procedures should be defined and executed to validate the required level of interoperability with specific DICOM conformant equipment, as established by the healthcare facility". Specific equipment is the operative phrase. Each named peer is a coverage unit.

HL7 concedes the same limit for messaging. Judging the receiving side is "a more difficult task, because it is determined by the consumption of the data and the actions taken on that data", and adequate receiver testing needs acknowledgement and functional requirements written per element, which HL7 notes are "often out-of-scope" for v2 interface specifications.

Interoperability questions a simulator can settle for a medical device, set against those settled only against the real counterpart system.

Settled against a simulator	Settled only against the counterpart
Structure, cardinality, vocabulary and length of what the device emits	Whether a specified function executes correctly on the data, per MDR Article 2(26)(a)
Behaviour on malformed, out-of-order and oversized input	Whether the content of the data survives the far end's own coercion rules
Timeout, retry and reconnect behaviour under controlled loss	Site configuration: which optional elements this deployment made mandatory
Reproducible negative cases for regression	Load and timing produced by the peer's real workload

Pointing at a real counterpart usually means pointing at a system holding records. We do not need production PHI to test. Environments run on synthetic and de-identified data. Which questions a buyer is entitled to ask before that environment exists, and the answers on record, are set out on how we work with protected health information.

For a device that ships into a network the manufacturer never sees, the peer list is a moving target, and what breaks in connected medical devices covers the failure modes that only appear on somebody else's infrastructure.

How does the plan record what was not tested?

In its own section, with a rationale per entry. MDR Annex II Section 6.1(b) ends with the instruction that "where no new testing has been undertaken, the documentation shall incorporate a rationale for that decision". The sentence is usually read as covering the four subject areas a software product skips, and it covers a skipped counterpart just as well.

There is no external pass mark to fall back on. DICOM PS3.1 Section 1.1 lists among the things the Standard does not specify "a testing/validation procedure to assess an implementation's conformance to the Standard", and PS3.2 Section 1 repeats it and adds that no procedure is specified for assessing "whether an implementation matches to its Conformance Statement" either. PS3.1 Section 1.1 also disclaims "the overall set of features and functions to be expected from a system implemented by integrating a group of devices each claiming DICOM conformance". The Notice printed in every Part goes further: NEMA "does not certify, test, or inspect products". So no body issues a certificate that closes this section for you.

Step 5 is what keeps the section from becoming a list of excuses. An entry with a trigger is a scheduled test. An entry without one is a decision nobody will revisit.

What does the finished plan hand over?

The six artefacts a finished medical device interoperability test plan hands over, each with the question it answers.

Artefact	The question it answers
Counterpart register	Which systems, versions, roles and directions the claim covers, one row each
Assumption register	What the device takes on trust about each counterpart, and which test falsifies it
Operating environment statement	Which hardware, network characteristics and security measures the results were obtained under, matched to the instructions for use
Interface hazard entries	Which hazardous situations the second system creates, traced into the risk management file
Coverage statement per counterpart	Which configurations were exercised against which peer, and on which build
Untested case list	What was not tested, why, and the event that reopens it

The coverage statement is the artefact that survives the project. It is what lets a later release argue that a change touched two counterparts and not eleven, and the evidence a change-triggered set rests on is the general problem described in choosing a regression set in regulated software.

What is usually missing from an interoperability test plan?

• The counterpart list names vendors and not versions, so a coverage claim cannot be checked against any deployment.
• Only one direction is written down. The device's own reaction to a malformed or late reply from the peer has no cases at all.
• The plan asserts conformance where the contract expects interoperability, and the two words are used as synonyms throughout.
• Optional elements are tested as optional, although the receiving site made several of them mandatory in its own profile.
• Interface hazards live in the defect tracker and never reach clause 5.4 of the risk management file, so the risk control verification per 7.2 has nothing behind it.
• The operating environment section describes the lab and the instructions for use describe something wider, which leaves GSPR 17.4 and Annex I Section 23.4(ab) disagreeing inside one submission.
• Simulator results are reported without saying they came from a simulator.
• The untested cases were discussed in a meeting and written down nowhere, so Annex II Section 6.1(b) has no rationale to point at.

Clause and article numbers on this page were read from primary documents on 2 September 2026. The documents, their capture dates and the caveats attached to each are listed at the foot of the standard pages linked above.