Make sure you have a clear understanding of the specification
When you are developing an implementation, make sure that you have a clear understanding of the specification of the protocol and the artefact. The specification is meant to be precise enough to ensure that your implementation is interoperable with others or is at least very close to be. In case of questions or unclarities, do not consciously make assumptions but contact the author of the specification. Interoperability is primarily a matter of correct and consensual interpretation of this specification. Assumptions made that are not shared amongst the community of implementers difficult the implementation and will require (costly) software adaptations.
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.
Document the used version of the specification
Always choose the latest version of the specification that will be used for the implementation. Document the version number 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.
Be aware that it is a very unlikely event that all applications migrate their implementations at the same time to a newer version of the specification.
Compatibility
When migrating your implementation to a newer version of the specification, make sure that you have identified and implemented the non-backward compatible features of the specification. This is needed to be able to correctly consume artefacts produced by other applications/implementations using the older version(s) of the specifications.
Processing of optional features
The optional character of a specified feature, when concerning an artifact that may be produced and consumed, is a common source of confusion and interoperability failure. An artifact MAY implement a feature. This clearly means that a compliant device producing such an artifact MAY omit this feature. However, any compliant device consuming such an artifact MUST be able to process this feature, should it be present (unless specified otherwise).
Composition of two specifications
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.