6.4.3 Interoperability measures

What this heading covers

The measure is tied to an interface and a message set, and both have versions. An exchange that succeeds against a mock and fails against the live system is not a successful exchange, so the test environment belongs in the definition. Interoperability covers sending, receiving and using the information, and a product can do the first two and fail the third. The measure should include the error handling for malformed or partial messages, because that is where interoperability usually breaks.

Record position: family 8 of 40 in clause 6, under 6.4 Compatibility, which carries 2 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.4.3 in the public contents; the text behind it is not public.

How a measure for this family is built

Take the number of message exchanges completed and used correctly as the numerator over the number of exchanges specified in the interface test as the denominator. Name the interface version and the message set version. If the exchange is asynchronous, define the timeout and how a late message is counted.

What to put in place before publication

1. Version the interface and the message set in the measure definition.
2. Include negative cases: malformed, partial and late messages.

Evidence to keep

Two questions to ask

• Which interface and message-set version was tested?
• Were malformed, partial and late messages part of the test?

Where teams usually fall short

• An interoperability pass against a mock that was built from the same assumptions as the product.

What the number cannot tell you

It cannot tell you whether the other system behaved correctly. An exchange failure can belong to either side, and the measure does not allocate blame.

What happens next

Security measures are the next concern for an interface that carries data between organisations.