This structural comment applies to the whole document.
The traditional IHE technical framework is based on an old and respectable methodology, but it's completely wrong to consider it as compliant with service orientation design principles. 

In effect, as an example, section 1:10.4 SDPi-P Overview stated that: "From a conceptual perspective, SDC implements an SOA architecture for..." showing a traditional (but very partial General SOA model) and indicates that "A detailed overview of SOA concepts is beyond the scope of this specification. See Appendix 1:B for additional background materials." However, the appendix does not reference any Standards or pointers to the vast canonical literature on Service Orientation concepts and design principles. 

Nor in the specification is there any concrete mapping to Technical Framework concepts and elements to a service-oriented environment.

To be clear, with an example from a different IT domain, we can correctly develop a system with a traditional waterfall development process; conversely, it is meaningless to name it an example of Agile methodology.

So, if the IHE methodology is well established in IHE, Service Orientation is a well-established set of principles and concepts worldwide; however, they have different conceptual grounds. Consequently, Naming a specification based on IHE methodology as service-oriented is wrong and is bad service for the specification and its practical use in real-world architecture.
The document must remove the reference to service-oriented architecture or concretely and meaningfully map the specification in terms of service orientation (indeed this is not a trivial task due to the different design principles).