Monday, May 24, 2010

Governance, SDOs, PEOs and NHIN Direct

Next week I head to Vancouver and then to Milwaukee. In Milwaukee I'll be teaching a generalized course on Interoperability standards to Masters students in software engineering, along with one of my collegues. As part of that course, I teach how to work with standards organizations, and the need for consensus based standards in industry.

As I review the course materials today, I'm looking at some potential disconnects between what I teach, and where I participate. Where I spend most of my time now is in IHE, HL7 and NHIN Direct, and last year, you could replace NHIN Direct with ANSI/HITSP. 

Not too long ago, I spent about an hour getting my ear bent about the governance, processes and status of some of the organizations that I particpate with. IHE International was incorporated in 2009 and its Principles of Governance can be found here.  Anyone who wants to participate in IHE can do so without charge, and after becoming a member, can vote on and participate in any activities.  ANSI/HITSP, while no longer under Federal Contract still maintains its web site.  Documentation about HITSP processes can be found on that site.  When it was active, anyone who wanted to could join HITSP and can vote on and participate in any activities.  HL7 is an accredited ANSI Standards Development organization, and publishes their bylaws and Governance and Operations Manual on the web.  Membership is by fee, but anyone who wants to participate can become a member and can vote on and participate in any activities.  Non-members can also participate in committee discussions on standards and in the HL7 Mailing lists.  HL7 standards can also be voted on by non-members for a modest administrative fee.

HL7 is a Standards Development Organization. IHE and HITSP are (or were in the case of HITSP) Profiling and Enforcement Organizations (PEOs -- an acronym I believe to have been invented by Wes Rishel).  But NHIN Direct is the oddest duck of the lot. 

NHIN Direct is an "Open Government" project.  There's some detail about the NHIN Direct project on their FAQ page.  I have not been able to find detailed documentation about governence or process on the NHIN Direct pages.  Some of it is there, but other parts are missing. 

For example, there are three ways to participate:
1.  By being a member of the core group (which I happen to be).
2.  By joining the wiki and e-mail lists and participating there (which I also do).
3.  By passively participating using the resources provided by NHIN Direct.

Someone from a large research organization that does quite a bit of government work asked me last week how you get into the first group (his organization wasn't able to, but had tried).  I didn't and still don't have an answer.  I know it's by invitation, don't know what the qualifying criteria are, and I have yet to find anything other than what is stated on the FAQ.

Recently, NHIN Direct announced a new co-chair to one of the workgroups.  I wasn't aware that A) there was a vacancy, or B) what the process would be to "run" for that vacancy.  Apparently the process for the selection of leadership NHIN Direct is not documented either.  I didn't see any call for a vote either on the new leadership.  BTW:  I'm not against this particular leader, I think he's a pretty good leader, even though we disagree on several issues of substance.

Back to the class that I will be teaching:  I describe six key features of concensus standards bodies.  These features are derived from the HITSP Tier 2 process (word document), US Federal Law, and a circular published by the Office of Management and Budget describing policies on Federal use and development of voluntary consensus standards and on conformity assessment activities.  Here are my six features, accompanied by an analysis of how NHIN Direct stacks up:
  • Open -- Membership should be open to all affected parties.  In NHIN Direct, there are two classes of membership, contributors and decision makers.  Decision making isn't open to all affected parties.
  • Balanced  -- Members should come from providers, suppliers and consumers of affected products.  I see some balance in the membership of NHIN Direct, but no documentation of it.
  • Process Oriented  -- The organization should have a defined process.  A very weak link here, as there is little documentation of any process in NHIN Direct.
  • Appeals -- Decisions should be able to be reviewed and appealed.  I don't see any documentation, nor would I know what those processes would be in NHIN Direct.
  • Consensus Based -- Decision making should be based on a consensus of the organization members.  This is one of NHIN Direct's strong points.  It's very clear that everyone has a chance to be heard, and I've actually learned a number of ways to improve consensus building in other organizations where I participate from the NHIN Direct work.
  • Maintenance -- Specifications produced need to provide for ongoing maintenance.  Because there's very little documentation about NHIN Direct, and because it is a "Project" of ONC rather than an organization, it's not clear what the ongoing maintenance process will be.
I very much support the activities that NHIN Direct is working on, because I think that they will enable smaller healthcare providers to exchange clinical data between themselves and other providers.  However, NHIN Direct has quite a bit of work to do before I would even consider putting them into the category of a consensus based standards body.

Which leads me to my final questions:  What should be done with the NHIN Direct specifications when they are complete and implemented?  Should they be run through a Standards Development Organization ballot or voting process?  Should NHIN Direct try to become an SDO or PEO (Profiling and Enforcement Organization)?  What do you think?

2 comments:

  1. Glen put his finger on it. The project is unabashedly a prototype project. It makes no pretense of being a standards organization or a profiling organization. It is trying to re-use existing standards to solve a problem that the small provider has little time to focus on. We should view it more as a consulting gig to all the very small doctor offices, and less like a design-for-all project.

    As long as the focus stays on helping the very little provider solve this problem, I believe that it will be useful. But as soon as use-cases that are not specific to the very small doctor office creep in, it will have 'jumped the shark'. (like CCHIT and HITSP before it) Scope-creep will eventually kill it as a useful thing.

    ReplyDelete
  2. The spark for how this project is constituted came from some testimony to the Implementation Workgroup of the HIT Standards Committee. During the non-healthcare industry panel, there was some very useful testimony on how real progress in standards in other industries proceeded. One of the clear themes was that the best way to advance standardization is to gather organizations together and write code while you write the specifications. Both the example from the automotive sector and the insurance sector (the latter unfortunately not provided in the above link) followed a similar pattern where breakthroughs happened by bringing organizations together to solve real-world problems doing the minimum necessary to achieve real interoperability in a short amount of time. Aneesh Chopra's write up of the findings provides some of the key lessons from that testimony.
    (see http://blog.nhindirect.org/2010/05/process.html)

    ReplyDelete