How Open and Broad Should an Interoperability Project, like the Direct Project, Be?

Arien and I have discussed the topic that was presented at the HIT Standards Committee on October 27th:  NHIN Direct: Current State and Lessons Learned (1).  Dr. Doug Fridsma said in his Standards and Interoperability Framework presentation that the Direct Project is an example for how other ONC-sponsored interoperability projects may be run. Lots of people are watching and learning from the Direct Project!

 

One of the points in Arien's presentation was:  "Implementation group grew too large, too fast.   In future, set the commitment bar even higher and have firm limits on number of participants".  This blog post is to express some initial thoughts, and urge others to weigh in, on a question stimulated by the presentation:

 

How should The Direct Project (and future ones like it) establish their group of participants? 

 

In reflecting, you could ask yourself other questions. What is "right-sized" for such a project? Should there be a public call for participation open to everyone? If not, how should participants be selected or qualified? How should the tradeoff between "broad/open/large" vs. "committed/fast/efficient" be made?

There's a tradeoff between an open, broad, and formalized, but slow process (e.g., SDOs), vs. a selective, smaller, less formal, but quicker/agile process such as The Direct Project has used. In any group, the number of "committed and contributing" members may be fewer than the full number of participants, so I understand the reasons that the presentation recommended a high commitment bar.

 

On the other hand, if an arbitrary limit is set (e.g., no more than 20 organizations) then a project might face credibility problems down the road due to lack of openness, and lower probability of people "buying into" and adopting specifications in which they could not participate.

 

In the Direct Project, we have over 20 EHR vendors represented individually or through the Clinical Groupware Collaborative, covering a significant share of the EHR market; about 10 state or regional HIEs; several medical and professional associations; several HIE/infrastructure vendors; government agencies, and more. IMHO this has brought sufficient critical mass so adoption can spread "virally" in a good way.  However, if the group were restricted, cutting those numbers by 50% or more, then the critical mass and buy-in necessary for broad/quick adoption might not be there. What would "consensus" really mean among too small a group? I think the industry would not put too much credence in something that was supported, say, by only 3-5 vendors and 3-5 HISPs/HIEs through a closed process, even if it were developed quickly and worked well in pilots.

 

IMHO, our group is reasonably sized. Deloitte and the leaders have done yeomen's work in moving the project forward. Still there's room for improvement. We have technology (LiveMeeting, wiki, google groups, blog) to facilitate collaboration, even with a fairly large group. Some streamlining of administrative processes (e.g., shortening and partially automating capture of attendance, eliminating exhaustive "roll-call rounds" while still giving everyone the opportunity to speak) could help use our time more efficiently.

 

My thoughts: I totally agree with continually improving the process for the Direct Project and for other S&I Framework projects modeled after it. But I think that great care must be given to avoid sacrificing the openness and critical mass necessary to adopt, while trying to making things easier, rapid, and efficient.

 

But that's just my opinion, and I think Arien and the Direct Project leadership would welcome feedback from all of you, who are "living" this project. What do you think about How The Direct Project (and future ones like it) should establish their group of participants? It would be helpful if you could reply to this post, so that the discussion will be transparent and all views can be seen together. 

 

Thanks,

 

David Tao

Comments

[John Williams]

Great topic. My input is to encourage broad participation. You never know which organizations will end up making important contributions, so inclusive participation is a must.

Case in point is my organization Health-ISP, a service of Garden State Health Systems Inc. The Direct project was not on our radar until until it was well under way. We came in late but are contributing with a pilot project (Catawba County, NC, see Potential Implementation Geographies) and connectathon participation (HISP interconnectivity)

When this topic was first identified, I assumed the discussion would be "membership" going forward. For direct messaging to have the market impact we hope it will, there is need for coordination akin to the CONNECT project coordinating committee. Thoughts on future membership:

- Does the Direct Project plan to provide this industry coordination going forward?

- Self regulation by a HISP association or Direct Project leadership is reasonable approach.

- Planning for future industry coordination should begin as early as possible.

Thanks,

John Williams

[Fred Trotter]

I think the Direct Project has been an perfect example of how a small focused group of participants, following the general principles of Openness and Open Source, can collaborate at a much higher level. It has been wonderful to see Cerner, Microsoft and Epic at the last meeting, operating like Open Source pros!

This true open-ness comes at a cost. There are deep differences between the priorities and agenda of the different participants. It is a hard balance to know when a debate (open source vs proprietary or protocol A vs protocol B or CCR vs CCD) is productive and useful or counter-productive. These arguments are traumatic and difficult for a project, but if those issues are not brought out into the open, then long term a project will self-implode. The secret, which Arien and Brian have done a fine job of, is to know just how much tension is productive.

Moving forward, it will be critical to continue to reward participation with special consideration regarding decisions. Its not just being on the phone calls that matters, its actually doing stuff. Writing code, testing code, writing documents and the like. The Direct project has done a fine job of this so far, but this ultimately needs to be formally embedded into the governance of the project.

Just my two cents.

-FT

[Keith W. Boone]

Thanks for bringing up this point David. My comments can be found here:

http://motorcycleguy.blogspot.com/2010/11/how-open-should-standards-project-be.html

[John Moehrke]

Thanks for bringing up this point... When reinventing the wheel: hint it is circular in shape...

For more details on what I mean by this, see my blog expansion on your original question:
http://healthcaresecprivacy.blogspot.com/2010/11/re-how-open-and-broad-should.html

[Karen Witting]

The Direct Project Governance process is vague and confusing. There is very little content to it and leaves a lot to the imagination. As a participant I have found the lack of clear governance the most distressing and frustrating part of this project.

In fact the process has been continually evolving based, seemingly, on the desires of the leadership. Only very recently, in particular AFTER this blog was released, has the leadership actually documented the process. An undocumented, unexplained process is the exact opposite of open and transparent. Anything the leadership documents now cannot be considered the Direct Project process since only the leadership was aware of their beliefs about how things worked. Little was explained to the participants and almost nothing was documented.

Much better to consider starting with a governance model that actually works, has been in practice for many years, is well documented and is less prone to undue influence of the leadership. I recommend the IHE process which is documented in the IHE Governance document http://www.ihe.net/governance/index.cfm.

In particular I recommend IHE's model for membership. Any organization can join but to have the right to vote the organization must acquire and maintain voting privileges by attending meetings on a regular basis - never missing more than three consecutive meetings. It is natural that those who contribute the most have the most impact on the direction of the work. There is no need to legislate this. But sometimes the best idea comes from a minor contributor who just has that needed insight to help the project make good progress. Allow broad participating and do not legislate contributions. The most recent Direct approach gives membership to those who "contribute significantly" but this is much too vague a term to be applied without the possibility of leadership favoritism.

[Arien Malec]

Just a quick reply to Karen's comments here.

We are trying to get things written down, and Karen has raised, both in private and in public, valid comments on how consistent we've been on issues such as base time that a deliverable is posted for consensus, and how an organization that believes it should be part of the Implementation Group can challenge a judgement of the "contribute significantly" test.

However, the basic rule for the Direct Project is, and has been from the beginning, that any organization in the Implementation Group had the right to object to a deliverable, on any grounds, so long as they propose the fix. That right has been used to object both to substance and to process, and provides a very strong redress mechanism for organizations who have concerns about process.

[china product]

Ah-ha!!!
A perfect diversion for when I want to procrastinate doing anything useful. Thanks!!!