...
- If the specification is about a communication protocol (e.g. a transfer protocol, an interface like the eHealth Hub webservices) and about the behavior of processors of this protocol, then interoperability is understood as the ability of two implementations of this specification – i.e. processors of this protocol - to communicate properly. In the case of an interface, ability of a user entity to communicate with an implementation (or processor) of the interface.
- If the specification is of an artifact (e.g. a business document, a process definition, a policy contract, a Vitalink medication scheme), then interoperability is understood as the ability to process this artifact with consistent results, using different platforms or processors. In such a case, interoperability is often described as portability from the artifact perspective (the artifact is portable across platforms), while the platforms or processors are qualified as interoperable.
...
Responsibility
Be aware that it is not always clear which aspects of interoperability fall under the specification writers responsibility, and which fall under the implementation developers responsibility. Too often interoperability problems arise when each party is over-reliant on the other party to ensure interoperability.
...
Take into account the the intended audience of the specification is wide. Knowing that product managers, end-users, test developers or product developers not always fully share the author’s background and expertise, be aware that interpretation mistakes or liberties will abound.
Defined behavior after errors
Define the behavior of your implementation in case of errors.
The next type of errors should be taken into consideration:
- the errors from "Errors" section of the specification. This mainly concerns the protocol specification.
- errors after reception of faulty artefacts from another implementation.
- errors when processing correct artefacts by your implementation
- errors during generation of faulty artefacts by your implementation
Used version of the specification
Choose the version of the specification that will be used for the implementation, document the choice and make this information accessible for the end-users. Not doing so will cause misunderstandings and interoperability issues over time. Providing the user with clear information about the version and revision numbers of both the implementation and the implemented specification will help to avoid this.
...
When migrating your implementation to a newer version of the specification, make sure that you identified the non backward compatible features of the specification. This is needed to be able to correctly consume artefacts produced by implementations using the older version of the specification.
Defined behavior after errors
Define the behavior of your implementation in case of errors.
The next type of errors should be taken into consideration:
- the errors from "Errors" section of the specification. This mainly concerns the protocol specification.
- errors after reception of faulty artefacts from another implementation.
- errors when processing correct artefacts by your implementation
- errors during generation of faulty artefacts by your implementation
Processing of optional features
...
Specifications refer to each other, and compose with each other. For example, a Vitalink layer will operate above the eHealth Kmehr artefact specification and Hub webservices protocol specification, that are defined outside of Vitalink. On some aspects, the specification writer sometimes assumes a “black-box” or perfectly modular composition. This implies that some “corner cases” (error escalation, mismatched features) are not explicitly documented. This way the details are left to the implementers. The degree of variability introduced by such compositions is then underestimated. As a result, implementers may interpret differently how the composition is supposed to operate. This can be avoided by not making any assumptions in case of doubt, and contact the writer of the specification.
Interoperability Testing
The goal of interoperability testing is to prove that end-to-end functionality between two implementations is as required by the specification that is implemented. It ensures end-to-end service provision across two or more products from different vendors.
It is advised to get a thorough understanding of the interoperability testing facilities offered by the writer of the specification. Once this is identified, an own test plan should be defined.
Interoperability & servicedesk
The servicedesk of the implementer should be able to help the end-user beyond the boundaries of the own implementation. If the root cause of the incident is found or can only be serviced in a third party's implementation, then one of the servicedesk of that third party or the writer of the specification should be informed. Otherwise the end-user reporting the interoperability incident will not be serviced and a possibly underlying problem will not be solved.
...
Requirements
This paragraph should be moved to the requirements documentation.
...