"Unmaking" a decision that was made in the first place can be extremely disruptive, which is why is usually takes a super-majority, or approval of a supra-governing body or leadership, in order to be done. The amount of disruption that unmaking can cause is usually proportional to the amount of effort required to unmake the decision.
There are a number of reasons why what has been recorded decision needs to be altered:
- To Clarify: The statement recorded is an accurate representation of the decision that was made, but it needs to be expanded up in order to to be understood by others.
- Typographic or editorial error: The statement recorded is an inaccurate representation of the decision that was made.
- Technical Correction: The statement recorded may be an accurate representation of the decision that was made, but it violates other decisions that the body does not have the authority to change.
Any of these can be addressed in HL7 by publishing Errata (as HL7 Structured Documents has done for CDA and other specifications), or by submitting a change proposal in IHE which then goes through approval and implementation process.
Other kinds of changes are more challenging:
- Addressing an implementation challenge: Something specified may wind up being unimplementable or extremely difficult or costly (under certain circumstances), necessitating a change.
- "Harmonizing" similar processes/behaviors/content: Sometimes the same thing (or nearly the same thing) is handled in different ways, especially in a large (or complex) specification. Ideally, you'd address these in the same way, but sometimes we fail. This could apply within the same specification, or across multiple specifications.
- Old vs. New: The specification adopts the way "we" used to do things, but now "we" do that differently, and we want to adopt the new way.
If the profile is still in trial implementation stage in IHE, we can still use the change proposal (CP) process. In HL7, if the specification is a DSTU or non-normative specification, the committee can choose to publish a new version of it (without balloting it), although HL7 governance is not clear specifically what can change in that case. For specifications in IHE at the Final Text stage, or in HL7 at the Normative stage, these sorts of changes require that new editions of specifications be written. In IHE, we generally do not introduce "incompatible" changes to an existing Final Text specification. We do sometimes introduce profile options that allow previously defined behaviors to be "improved upon". There is the concept of deprecation (e.g., as was done for XDS via XDS.b), which is essentially what HL7 when it proposes a new version of a standard.
There is are other ways to "unmake" a decision. One of these is to pretend it never existed, i.e., simply ignore it. This isn't something that HL7 or IHE can do realistically with their own specifications, but it is something that implementers of their specifications can do. Another is to appeal the decision through the organization's appeals process. Appeals are defined in section 14.12 of HL7 Governance and Operation Manual, but the process is rarely used. IHE's appeals process is less well defined in its governance documentation. Most things are usually worked out within the Domain committees, but sometimes are escalated to the Domain Coordination Committee.
There is also a pretty ineffective way to attempt to unmake a decision, which just to loudly disagree with it after it has been made. Just because you disagree with a decision doesn't change it. If you want to change it, you need to follow one of the processes described above. It is a pretty effective way to disrupt a discussion.
No comments:
Post a Comment