Friday, March 26, 2010


God, grant me the serenity
To accept the things I cannot change;
The courage to change the things that I can;
And the wisdom to know the difference.
As an editor of standards, I often wish that more people had the wisdom to know the difference.  Over many years, I have run across situations where I will read comments on a standard that:
  1. Reject the scope of the effort out of hand, or attempt to broaden or replace it with a different scope, usually to address some percieved need of the writer
  2. Reject a particular definition or conformance requirement, or attempt to rewrite it according to a scope that is different from what is stated in the standard.
I've also seen others, and been accused myself of being against a particular activity when I've pointed out that that activity isn't within the agreed to scope of the work being discussed.  Discussions of scope are usually out of scope by the time you are commenting on a particular work.  That means that these are things that cannot be changed.

I've learned that dealing with these sorts of issues is simply part and parcel of the effort.  I wish it were easier, but I don't have the wisdom to know whether this is something I can change or not.  Lacking that, I will try through education.

Recently I've been developing a short class on Standards for software engineers.  Not just healthcare standards, but IT standards in general.  In it, I make the point that the time to address questions of scope are when discussions of scope are going on, and the time to comment on the standard is when it is being voted on, and not visa versa.  The point is that often what you can change is what is presently under discussion, not the preconditions already agreed to previously as a waypoint to getting to this stage.

I've seen the same thing in comments on regulation.  Effective comments understand what can be changed, inneffective ones rail against the law or process that require it.  These are again questions of scope and/or process, and the time to raise and get those addressed is not when the regulation is being proposed, but when the law that requires it is.

Not too long ago someone on the HISTalk pages  commented that "NIST is disregarding usability" in its testing programs (see comment from All Hat No Cattle).  Does the writer understand that this testing program has specific certification criteria already identified in regulation (see 45 CFR Part 170), and that NIST cannot pick and choose what it wants to do?  Do they also understand that NIST is working separately on usability?

I don't want to pick on this particular example too hard.  The point I want to make is that these sorts of comments aren't effective.  You do have to understand the scope of the work being done (and what is being done elsewhere).  Failing that, you run into the danger of having the bozo bit flipped on you.

On the other hand, as a commentor on standards activities, regulation and law, I also wish that the writers and editors of these were willing to compromise on those parts that could be changed, and were unstinting only on those parts that couldn't be, and had a clue about which was which.

So, in closing, I offer the writers of standards, profiles, regulation and policy this little prayer:

Grant me the serenity to accept the changes that can be made,
the courage to retain that which should not be changed,
and the wisdom to know the difference.

As one of those authors, I intend to meditate on it myself.


Post a Comment