Participants reside in different time zones and most will have very busy schedules. As much as people may try to participate on all the phone calls, participation on the phone calls should not be the primary issue resolution mechanism, but a mechanism to resolve issues that cannot be effectively addressed via e-mail or the web site.
Addressing issues via e-mail is the preferred mechanism. The e-mails allow for the issues to be addressed in writing, with the possibility of including attachments with additional documents for all to see, pieces of X12 transactions, references to URLs and other useful information that is hard to convey otherwise.
In addition email allows access by the participants as their time permits and bridges the time zone differences. And, email can be archived and used for reference later.
Some information needs a non-email archive, of the sort best built through a web site, especially a Wiki collaboration site. One of the great advantages of the Wiki is that it can become a permanent archive for issues that have been resolved, so these issues do not have to be re-opened every time a new participant joins the group. The Wiki can also hold the attachments and all the discussion that led to the resolution, and can be easily edited if necessary.
Some Wiki sites have a threaded discussion facility, like a bulletin board, that can become the primary discussion forum for the different topics. With a threaded built-in board type of discussion it becomes much easier to have several parallel discussions on different topics without cluttering the participants’ mailboxes. And the participants can get a single email daily with the entire discussion thread. This is by far the simplest and most effective discussion mechanism to address issues, especially if they are technical issues.
But some issues are not strictly black and white technical issues, and the may require passionate discussion on the phone. In those cases there should be time limits for the discussion, with strict adherence to the times, and at the end of the discussion there should be a decision or a resolution to the issue. Remember this is not a debate forum, but a mechanism to address and resolve issues.
The goal is to come up with a solution that is workable. Not necessarily the best solution. Not necessarily a solution acceptable to all participants. Even if there are one or more dissenting voices during the process, as long as the solution is taken as a consensus solution that all agree to accept as a valid compromise, we are making progress. However, if there is not a valid compromise, we still need to work on it rather than close discussion, so we achieve something that is workable by all.
The issues should be entered into a conference call discussion only if they have been presented either via the threaded discussion list, Wiki or email, at least the day before the conference call, so people have time to review the issue and discuss it over the threaded lists or email. If a new issue is introduced during the call and needs discussion, it should be tabled until the next call, to have an opportunity to discuss it via email or threaded list among people that did not participate on that call.
Whether we use the threaded discussions, the email lists, or the conference calls to address the issues, whenever somebody is raising an issue, they should also propose one or more solutions, or, if other people have addressed the issue in the past and have a solution, they should propose it early in the process, so the proposed solutions can be considered for a consensus solution.
As a solution is identified as a possible consensus solution, the chair(s) should bring it up to a vote by the workgroup. Typically this is done by requesting dissenting votes, as we expect to have fewer dissenting votes. All dissenting votes must articulate the reason for their dissention. Once the dissenting votes have been resolved, or the solution is adopted in spite of some dissenting votes, the solution should be posted to the Wiki, along with enough description and history, so two years from now we don’t have to start from scratch on the same topic. In some cases it is important to also reflect the number and nature of the dissenting votes.
As a couple of examples, taken from the very first meeting of the Technology and Implementation workgroup:
- The issue of whether to use an implementation guide with the designation of 004010X098A1 or 004010X098WC was presented by one of the chairs, discussed briefly, and in about 5 minutes it was clear that everybody on the call agreed that the standard should be 004010X098A1 because the requirements now are practically all aligned with the HIPAA requirements. But, if a pair of trading partners agree to use 004010X098WC instead, they could, as mutual agreement, use that version. A vote was taken, there were no dissentions, and the issue closed.
- The issue of how to send an 835 when there is no payment because the eBill was denied, and therefore there is no check or EFT number to send on the 835 was brought up. After some very limited discussion, it was determined that this was an issue that required technical analysis and it was decided to have subsequent phone call to address it, and invite one of the 835 experts to the call. One of the participants contact the expert and presented the topic via email. The expert was able to point to a couple of X12 HIR resolutions on this very topic because the topic has been addressed by X12 in the past. The expert’s response, and the HIR resolutions were posted to the Wiki. The original requester of this issue read the expert’s response, and considered it responsive to the original request. The issue can now be closed without the need for a conference call, and it is posted on the Wiki site for future reference.
As we follow these suggestions, we will have a better process to address and resolve issues, and we will use our time more productively.
Comments (0)
You don't have permission to comment on this page.