Mission Creep

I was on a call this morning discussing the evaluation and selection of material that could be used in a new standard.  I did something uncommonly done, which was reject the idea on the basis that the SDO was not the right SDO to develop the work.  This is a common problem with healthcare standards development organizations.  Many of us (members of the SDO) obviously have the general IT skills necessary to create standards which can be used in IT (and have already done so in SDOs if the morning meme is any indication).

However, the question that needed to be raised was whether it was appropriate for THIS SDO to do so.  My main concern is that any such standard needs to be something generally available in off-the-shelf general IT software, not just in "healthcare IT" specific applications.  While THIS SDO could develop something, it wouldn't actually meet the needs of the organization if it did so.  At that point that THIS SDO developed it, it would become a standard in the wrong home.  That would NOT result in the deployment of the standard in off-the-shelf software, which is part of what the SDO really needs.

This isn't the first time this has occured.  I've seen it happen before in IHE, HL7, and ASTM E31.  It's a case of not just scope creep, but mission creep.