One of the biggest unrecognized challenges to balance in consensus standards development processes is lack of balance in Governance. What do I mean by that?
Governance is about who decides. Who decides what the priorities are? Who decides where scarce resources are deployed. Who decides not just what gets done, but who does it?
Let's look at several examples of lack of balance in government in standards development over the last decade:
CCR: The CCR steering team was made up of medical professional societies. The team decided overall direction for CCR development. Vendors and other participants in the development of the standard were not permitted to be part of the steering team. This resulted in a great deal of unnecessary conflict in the development process, and in the end, the ultimate death of CCR as an XML standard (the core data elements of CCR live on today though, in CCDA and elsewhere).
ONC/AHIC/HITSP: While HITSP had a generally balanced process for development and approval of specifications, it was ONC and AHIC who determined what specifications would be worked upon. ONC set the general direction, and AHIC filled in the specifics. And whether or not the project was viable based on the consensus of the HITSP membership, HITSP still had to deliver specifications to meet the use cases handed down by AHIC. This resulted in specifications such as Biosurveillance which consumed a great deal of effort, and resulted in previous little change (recall that this Use Case came out not long after the anthrax scares of 2011).
ONC/The Direct Project: ONC decided what it wanted and initiated a project to make it happen. It was widely touted as a great success, unfortunately, the specifications are still "government created" as they have not yet been taken up by any SDO, so no non-governmental body exists for maintenance, and there are still challenges in deployment. The decision about what project to work on (a governance decision) was made by ONC.
ONC/S&I Framework: This has been better, but with a lot of variation in how these projects are executed. The best example of governance challenges are with the HQMF and Health eDecisions. The projects were separately initiated and staffed, with little overlap. Fortunately, both projects were also done through HL7 governance. When challenges arose about incompatibilities between models in the two specifications, HL7 initiated a review and rework process that has resulted in much greater harmonization across these specifications. This is a perfect example why consensus in governance is critical.
Argonauts and HL7 FHIR: This one is fun. It's greatly touted collaboration of a number of Health IT juggernauts with HL7 on accelerating the development of FHIR. The project management and decision making about what projects are to be focused on is restricted to a closed group (the original Argonaut members). Others can participate so long as they do so according to the structures created by the original decision making body. The end result may well benefit the whole industry, but the decision making about what to do is closed. For example, how are OAuth2 specifications to be evaluated, and if there are changes necessary to existing specifications, where will those be done? There isn't a consensus group making that decision.
ONC has asked some key questions in their recent publication of the Interoperability Roadmap. Many of these impact governance issues similar to those I've raised above.
Governance is about who decides. Who decides what the priorities are? Who decides where scarce resources are deployed. Who decides not just what gets done, but who does it?
Let's look at several examples of lack of balance in government in standards development over the last decade:
CCR: The CCR steering team was made up of medical professional societies. The team decided overall direction for CCR development. Vendors and other participants in the development of the standard were not permitted to be part of the steering team. This resulted in a great deal of unnecessary conflict in the development process, and in the end, the ultimate death of CCR as an XML standard (the core data elements of CCR live on today though, in CCDA and elsewhere).
ONC/AHIC/HITSP: While HITSP had a generally balanced process for development and approval of specifications, it was ONC and AHIC who determined what specifications would be worked upon. ONC set the general direction, and AHIC filled in the specifics. And whether or not the project was viable based on the consensus of the HITSP membership, HITSP still had to deliver specifications to meet the use cases handed down by AHIC. This resulted in specifications such as Biosurveillance which consumed a great deal of effort, and resulted in previous little change (recall that this Use Case came out not long after the anthrax scares of 2011).
ONC/The Direct Project: ONC decided what it wanted and initiated a project to make it happen. It was widely touted as a great success, unfortunately, the specifications are still "government created" as they have not yet been taken up by any SDO, so no non-governmental body exists for maintenance, and there are still challenges in deployment. The decision about what project to work on (a governance decision) was made by ONC.
ONC/S&I Framework: This has been better, but with a lot of variation in how these projects are executed. The best example of governance challenges are with the HQMF and Health eDecisions. The projects were separately initiated and staffed, with little overlap. Fortunately, both projects were also done through HL7 governance. When challenges arose about incompatibilities between models in the two specifications, HL7 initiated a review and rework process that has resulted in much greater harmonization across these specifications. This is a perfect example why consensus in governance is critical.
Argonauts and HL7 FHIR: This one is fun. It's greatly touted collaboration of a number of Health IT juggernauts with HL7 on accelerating the development of FHIR. The project management and decision making about what projects are to be focused on is restricted to a closed group (the original Argonaut members). Others can participate so long as they do so according to the structures created by the original decision making body. The end result may well benefit the whole industry, but the decision making about what to do is closed. For example, how are OAuth2 specifications to be evaluated, and if there are changes necessary to existing specifications, where will those be done? There isn't a consensus group making that decision.
ONC has asked some key questions in their recent publication of the Interoperability Roadmap. Many of these impact governance issues similar to those I've raised above.
0 comments:
Post a Comment