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.
Your new definitions of Capability and Service Collaboration are flawed. I do not understand why you want to bring in 'technical function' to an 'interoperability' discussion. A Service Collaboration is an infrastructural composition that carries out an exchange of some type of content. A Capability is a binding of some specific content to a Service Collaboration 'exchange'
ReplyDeleteThe ability to exchange structured documents (and unstructured) is already available as a Service Collaboration (SC112). What more do you want? What CAP119 brings to the table is an ability to bind a specified content to the SC112 transport.
The discussion in HITSP is more around if we use a CAP119 model where we have lots of content, each with a named option; or if we create new Capabilities for each content. Specifically the discussion is around HL7 V2 messages binding to SC115 which is a service collaboration that delivers HL7 v2 messages.