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

David Tao asks on the Direct Project Blog:  How Open and Broad Should an Interoperability Project, like the Direct Project, Be?


Keith responds with a very measured standards based response that I very much agree with. Leave it up to Standards to have standards on being a standard... Leave it up to an uber-standards-geek to know about it. I am sure the non-standard google helped him out.

The Direct Project (I can't stop reminding everyone that this is the project formerly known as NHIN Direct) is being held up as a Best Practice. I think there have been some really good things that have come out of it, but I really can't say that the 'practice', that is the process used, is an improved or impressive process.


Too many participants, Really?

I would like to understand why some people feel that the Direct Project had too many participants. What evidence leads to this assertion? I was involved from the very beginning and participated in almost all meetings. I never saw a time when shear numbers got in the way.

Well there is one factor where shear numbers did cause trouble, that is the method choosen to run the Direct Project meetings.  It is not uncommon to take attendance at the beginning of a meeting. But the Direct Project experimented with a Process that had good intentions. When an issue was raised by the chair, the process was to poll everyone in order of their company (my sympathy to those with company names beginning with 'A'). This seems like a good idea as it forces people to listen and speak. But it didn't result in discussion, it resulted in disjointed comments. If this is the factor that people are using to assert that the Direct Project had too many participants, then I would far prefer to have a different process than less participation.


A way to deal with too many participants that are not contributing is to leverage the attendance list. There was far too few people in attendance at the meetings. We spent lots of time asking if there was anyone in attendance from XYZ company. The IHE process requires that you must attend in order to have voting privileges. This at least keeps everyone on the same page because they MUST join the calls. I don't know if this is the best solution, but it does work elsewhere.


Normal group behavior
While participating in this group, I didn't notice anything different than any other group. It was very clear to me how this group followed very nicely the four-stage model called Tuckman's Stages for a group. The Forming stage is always painful, the more often one creates totally new groups under new rules the more often the Forming stage wastes peoples time. Bringing in a mature Governance, like Keith mentions, can quicken this phase. I am sure everyone vividly remembers the meeting where we did the Storming, does Redmond come to mind?

Reinvention sometimes happens
My overall observation is that all of the arguments about RESTful vs e-Mail vs XDR... and today we have an open source Reference Model, in two different programming languages, that have successfully implemented ALL THREE!!!!  I am very excited and happy that we have an open-source reference implementation.

Seems to me this is proof positive that we have a clear and chronic case of Not-Invented-Here. Lets please stop the reinvention, and look to the governance established standards and profiling organizations. When reinventing the wheel, my guidance is that it should be circular in shape.