Overall Process

Luis Maas is coordinating this project. The specific outcomes of the project, and the lessons learned, will be made available for incorporation into the continuing evolution of the nationwide health information infrastructure to support the widest array of users and uses.

Overall Intent

This project follows the recommendations of the Implementation Group of the HIT Standards Committee and the lessons learned in specification development as presented in the first panel session on such activity in non-healthcare industries.

The goal is to solve a focused problem (enabling nationwide directed secure health transport between known participants in support of meaningful use), document the solution with a well-defined specification, implement the specification in a reference implementation, and test the solution in focused implementation pilots.

Assuming the pilots demonstrate the fitness of the proposed solution to the problem, the solution, as documented in specifications, will then be proposed as a draft standard to a standards development organization. The intent is prior to pilot to meet the IETF definition of a Proposed Standard, and after pilot to meet the IETF definition of Draft Standard. (See RFC 2026, sections 4.1.1, and 4.1.2 for these definitions).

The intent of this process is to enable the following cultural values:

1. Openness and transparency
2. Rapid problem solving focused on a particular well-defined problem
3. A "do-ocracy" where people feel they can solve problems by implementing solutions, and where concrete action is valued over discussion
4. Inclusion of multiple points of view, including those who, for structural reasons of time and cost, are often not able to participate in standards activities
5. Respect for the opinions and objections of all the participants (formal and informal) with the belief that a minority objection is often a signal to an important voice that must be heard and addressed

Openness

All work-products (deliberative, interim and final) of the project will be publicly available, either on this wiki or on public mailing lists. This includes, the the extent reasonably available, notes of teleconferences.

Paths To Participation

The project is led by the coordinator, who is selected by the Direct Project community.

The specifications will be developed by an Implementation Group of public-private stakeholders with an open process allowing for a wide set of participants to volunteer to provide input, feedback, code development, documentation, pilot implementations, etc.

There is also an "Expanded Group" which consists of

• The Implementation Group, who make and act on the commitments defined below
• Active Observers (participants who regularly attend meetings but do not make the formal commitments defined below
• Anyone else who provides content or feedback to the project, via the wiki, blogs, mailing lists, and the like

Members of the Implementation Group are organizations who have made a formal commitment to:

• Participate via formal meetings
• Provide active involvement to the workgroups and discussion of the project
• Develop or deploy the resulting standards and specifications in real world implementations later in 2010 or provide significant assistance of such deployment through documentation or support to implementers, providers, or patients.

Individuals or organizations who want to participate in the implementation group and believe they can meet these requirements should issue their commitment in our commitment tracker and email [[1]]. Implementation Group members are eligible to vote in our Call for Consensus Process. Each member of the Implementation Group should participate in one or more workgroups.

Observers are a subset of the Expanded Group who wish to participate by attending workgroup and implementation group meetings, but can not make an active commitment. Observers may not vote in the consensus process, but are welcome to participate in teleconferences and may participate in the face to face meetings as space is available on a first-come, first-served basis. Observers can also participate by providing comments and suggestions through a variety of channels, including the Direct Project blog, Google discussion groups, and this wiki. They are invited to deploy the resulting standards and specifications but don’t need to make a commitment to do so.

In addition, the project is open to public comment since its work products, minutes, and the above-mentioned participation channels are available on the Web. Anyone from the public can participate via these public forums.

Workgroups

The Direct Project divides work into Workgroups for convenience. Membership in workgroups is self-selecting, and the informal role of workgroup lead is assigned by workgroup consensus. The workgroups have no formal role in this process, but do have a strong informal role to develop, vet and promote deliverables to the Implementation Group. The normal expectation is for deliverables to be sent through the formal Consensus Process only after consensus has been achieved at the workgroup level, following the Call for Consensus Process. That is, only deliverables that have the active support of a focused membership of the Implementation Group will normally be considered by the Implementation Group. (In some cases, it may be desirable to promote a deliverable out of workgroup to get broader input, despite the lack of workgroup consensus. In those cases, it is expected that the objecting workgroup member will vote No in the Implementation Group Consensus Process round).

Pragmatic Consensus Process

All approved output of the Direct Project must be approved through the Direct Project Pragmatic Consensus Process. The belief inherent in the Consensus Process is that organizations who have a common motivation to solve a problem in an interoperable way have an obligation to understand and address the concerns of all the members, and that those organizations have a common interest in moving forward and will not unreasonably block progress.

Voting members of the Direct Project are Implementation Group members in good standing by the judgement of the coordinator (that is, currently meet the defined commitments of Implementation Group membership) and the coordinator. All deliverables sent through the Consensus Process will be submitted to consensus by all members of the Implementation Group, where each Implementation Group organization receives one consensus vote. Each consensus vote will be accompanied by a timeline (with a suggested minimum one week lead time) by which votes are expected by all Implementation Group Members; Implementation Group Members are expected to either meet this timeline, or propose a reasonable alternative timeline that they can meet.

A consensus vote will be one of:

• Yes
• Yes with comments
• No with comments indicating a path to address the objection in a way that meets the stated concerns of other Implementation Group members. No votes without such comment will be considered Abstain votes.
• Abstain (explicit decline to vote)

A Yes vote does not necessarily mean that the deliverable is the ideal one from the perspective of the member, but that it is better to move forward than to block the deliverable. A No vote means that the objector can not proceed with the project unless the objections are met. It is acceptable and expected to use a No vote in an first consensus round to communicate a point of view or process issue that has not been addressed in the drafting of the initial deliverable.

Abstain votes at the deadline set out in the Consensus Process timeline will be considered to be unqualified Yes votes. Failure to register any vote at all (Yes, No, Abstain) by the deadline will also be considered to be an unqualified Yes vote.

If a Consensus Process attracts significant comments (through Yes with comment votes), it is expected that the comments be addressed in a future revision of the deliverable. Should a Consensus Process attract even one No vote, it is mandatory to revise the deliverable to address the No vote (unless an exceptional process is declared).

Expanded Group members may also supply comments and objections through the Consensus Process, and such comments and objections should be addressed by the Implementation Group.

The Consensus Process will continue until all votes are Yes or Yes with comments.

Consensus approved material will be clearly marked as such.

Exceptional Process

The expected process is for all consensus approved output of the Direct Project to be approved without any No vote.

There are exceptional cases where this may not be able to be attained. Generally, such occurrences are examples of significant breakdowns in the core assumption that Implementation Group participants have a shared desire to solve the problem in the real world, or a major disagreement about the scope of the project. The general pattern for these exceptional cases would be for a No vote to be not addressable, despite significant attempts to do so, without attracting a significant number of counter No votes for the proposed solution.

If this happens with a single or very small number of objectors, it is evidence that the objector either does not share the goals of solving the problem, or has a set of operational constraints that do not hold for the vast majority of participants. In that case, it will be permissible, with the permission of the initiative coordinator, to move the deliverable forward with an overwhelming majority despite the objections. This will only be performed with significant good faith efforts to meet the needs of the objector (including at least three consensus rounds). In such situations, it is expected that the objector will drop from the project.

If this happens with a significant split, it is evidence of a significant process breakdown or philosophical split, and it is not expected that the project move forward with a simple majority. To do so would violate the goal of solving the problem at a nationwide level. Instead, it is expected that the problem be reframed, an alternative consensus be attempted, a smaller project to collect more data be initiated, or that the project disband.

Rule Changes

These rules are subject to change through the Pragmatic Consensus Process.

Why Two Paths?

One of the major design goals of the Direct Project is to enable simple, direct interoperability (information exchange) among a wide set of participants, and to do so in a timeframe that allows for standards-based health information exchange meeting the goals for Stage 1 meaningful use. Accordingly, there will be a number of design and implementation tradeoffs between items that would be desirable to support and items that are essential to support. The acid tests for an item under consideration are:

1. Would I feel comfortable going live for the providers I support without this item?
   and
2. Do I have the resources to deliver this item in the timeframe to which I've committed?

We believe the best participants to make those design and implementation decisions are those who are on the hook for delivery, i.e., the Implementation Group.

We also believe that the wider community of interest, e.g., the public, has much to add, by suggesting new items, discovering issues, contributing expertise, etc. We do not wish to limit those contributions in any way.