The battles of Relevant and Pertinent

In the year+ since we started the Relevant and Pertinent project, I've relearned many lessons that would have been readily apparent had I come from a military background. Two of these stand out in my mind:

No battle plan survives past first contact with the enemy.  

What we planed, and what I expected we would execute has gone through many iterations.  So far though, our general strategy has remained: Provide tools to enable developers to ensure that providers aren't overwhelmed by data that is neither relevant nor pertinent to what they are doing.

Never give an order that you know won't be obeyed.

One of the biggest debates we've had in this project is what to do when we've decided that something isn't relevant. The main concern was related to unintended consequences. What if ... we don't send it and it was important ... what if ...

So, we've decided not to decide what to do.  Instead, what we will do is provide rules for assessing he relevance and pertinence on a very coarse grained scale:

• More Relevant
• Somewhat Relevant
• Less Relevant

The data bears out fairly well that there are three clusters of relevance, and that clustering is somewhat insensitive to the provider experience with CCDA documents.  It's hard to argue with that.

In this, we follow the advice of Sun Tzu: 

The supreme art of war is to subdue the enemy without fighting.  -- The Art of War

We will provide some suggestions of different ways to use these assessments to avoid overwhelming providers with too much information, but these won't be requirements of the informative document, merely some things to consider.  Thus, we avoid the battle.

I'm fairly hopefully that we can shortly get to the point of Mission Accomplished.

   Keith