In April of this year, HITSP diverged from its assigned tasks to work on an important issue for ONC, which was the restructuring of its prior work to support pending regulation for ARRA/HITECH. As a result of these efforts, we modularized many of the HITSP specifications to simplify tasks for implementors. This resulted in the creation of two new types of HITSP specification (they call them constructs, but I won't delve too deeply into HITSP-geek-speak here).
The first of these is a Capability, and the HITSP capabilities are what the HIT Standards Committee looked at when they identified standards for meaningful use. The second is something called a Service Collaboration, and it is a specification for how to make several different pieces of an implementation work together. Because this work was done quickly, we set up a few rules (which we may need to break in the future) about Capabilities and Service Collaborations. Capabilities may not call on other Capabilities, but Service Collaborations can. Capabilities include content, but service collaborations don't. These rules seem to be more like generalizations of an ideal world. The HITSP Internal Review Board is currently discussing all the pieces parts as we develop new Capabilities and Service Collaborations to complete our slate of work for 2009.
Here are my own, unapproved definitions of these HITSP specification types:
Capability: A collection of service collaborations, standards and implementation guides working together to serve a business purpose.
Service Collaboration: A collection of service collaborations, standards and implementation guides working together to serve a technical function.
Capability is an integration concept, and Service Collaboration is an implementation concept. What I mean is that developers will "implement" the Service Collaborations in software, and the Systems Integrators will put together Capabilities from Service Collaborations. Ideally, Service Collaborations should be generalized to support a variety of use cases, whereas Capabilities would be more fine tuned to meet business requirements. The rules about structuring these specifications are emergent properties resulting from common design patterns used in the integration and implementation layers.
However, the dividing line between implementation and integration is fuzzy and blurred. The HITSP Capability 119 Exchange Structured Document sits right on that line. Is this a business function or a technical one? You could argue it either way. Another issue to address is that capabilities over time become commoditized, and that pushes them across the line.
For now, I still consider Exchange of Structured Document to be a capability, but I'll be very happy to see the exchange of structured documents become a service collaboration in the future.