...

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.

Be aware that it is a very unlikely event that everyone migrates his implementation at the same time to a new version of the specification. 

Compatibility

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.

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 in another specificationoutside 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.

...

Requirements

This paragraph should be moved to the requirements documentation.

...