Differentiating Policy Requirements from Interoperability Requirements

Several times over the past several days I've had to deal with issues of policy which were raised as problems preventing interoperability.

In one case, the discussion was around the failure of two big organizations to be able to interoperably exchange information with each other using the HITSP C32.  The challenge wasn't really in the ability of the two organizations to do the exchange, or even understand the information being exchanged.  The problem was in the fact that the business policies and procedures of those organizations were different enough that the data both organization considered essential was captured either using different vocabularies, or that they had different definitions of essential data.  The data could be transmitted in the C32, but what was sent by one organization either wasn't used, or couldn't be used as effectively by the other because of the allowed variations in coding.

Another example of this is in how CCDA focuses on the US Realm vocabularies and identity domains, thus failing to be internationally supportable.  For example, CCDA says to use the providers National Provider ID (NPI), and specifies an OID that is required to be used.  Yes, in the US, the policy being applied here is that the identifier of the provider is communicated using NPI, and so when you put that policy together with CDA (producing CCDA), you get a requirement that the OID has to be the NPI OID.

But the interoperability requirement is much simpler.  There must be an identifier for the provider in the document that is from the identity domain established by policy.  And the policy requirement is also very simple: The (in this case national) policy is that providers in the US are identified by their NPI.

Unfortunately for implementers, separating policy requirements from interoperability requirements creates a level of indirection that quite honestly, most of them don't, and shouldn't have to care about.  It's just like vocabulary binding.  There are probably two dozen people in the world who are real experts about all the nuances of vocabulary binding.  The rest of us just want to know how to create the content needed, and care very little about all this nuance.  So putting that level of indirection in the implementation guide isn't really what many implementers want.

So we put policy requirements in implementation guides (especially realm specific guides) in ways that support what implementers need.  Somehow, we need to make this easier for people.  There needs to be a way to express policy constraints just as there is a way to express interoperability constraints, and we need to be able to separate those concerns, and build tools that will enable them to be managed, and to produce the result of combining both.  In that way, we can readily create implementation guides that can be more easily customized based on policy decisions.

     Keith