In healthcare today many people might view that IHE invented the concept of Connectathon, this is not true. It was invented back in 1986 by those that had written the Internet specification and those struggling to implement it. In 1986 there was also "Interop" which focused more on the infrastructure standards of TCP/IP, and DNS, while "Connectathon" focused more on the application standards such as NFS, FTP, Telnet, and e-Mail. This quote is pulled from the Internet Archive WaybackMachine describing Connectathon as first introduced by Sun Microsystems in 1986:
“Connectathon is an excellent opportunity for vendors to verify that their distributed computing software interoperates with a wide range of client/server implementations on different operating systems. Everything from laptops to supercomputers can be linked together under one roof, encouraging interaction among vendors, engineers and developers in a confidential atmosphere. Implementations are tested and debugged at Connectathon. There are panel discussions as well as open sessions on the latest developments in technologies and solutions by Connectathon participants. Connectathon is a place where engineers can gather without marketing hype and can exchange ideas and information.”You can see in this quote the purpose and principle that make a Connectathon successful.
Up to this point most networking protocols were proprietary. This meant that they were designed, specified, and implemented within the confines of the vendor that invented the protocol. Thus that vendor knew exactly what they intended the specification to say. That vendor knew exactly what other implementations (none) they needed to work against. That vendor could fully test their implementation in simulated deployment all safely within that vendors walls. Any bugs found during this pre-release testing were only the concern of that vendor. Actually any bugs found at a customer site were also only truly known by that vendor.
So it was considered critical to the success of the Internet that we know and love today that with open consensus ‘standards’ for connectivity have a similar but clearly different mechanism. Thus the Connectathon.
This situation is not good for the customers, they must each push their vendors hard to solve problems that simply shouldn't be. This causes delays in deployments. These deployments are also very fragile to changes. This is very expensive.
This situation is not good for the vendors, unless you have an alternative proprietary solution that you want to succeed. Vendors are pitted against each other in a very hostile environment under the watchful eye of the customer. Time is short, tools to debug are few. It is very hard to reproduce that specific environment. The software was written months ago, possibly years ago. The software developer has likely been working on something else in the last few months, so is not thinking about their implementation.
A Connectathon is a purely testing environment, so no worry about exposing real patient data or creating real patient safety risks.
Connectathon provides a RefereeAt Connectathon there are others besides the vendor peers, including those that wrote the specification itself. There is often a set of people who have taken the specification and written test tools. Test tools are a form of implementation as well. As a test tool, it is not expected to be used at a customer production environment. Those that wrote the test tool are not a vendor and are thus not bias in a debugging dispute. Thus the test tool tends to be a non-biased implementation. Those that wrote the test tool are seen as the referee. Those that wrote the specification are also often consulted when a dispute comes up.
The whole purpose for a ‘standard’ is to have a single specification that is highly reusable. The fact that an implementation can be re-used at many deployments drives down the time and costs and drives up quality.
Connectathon is about Cooperation not CompetitionAs a “Safe Place” a Connectathon is an environment where those that are close to the implementation can come and be blunt. The participants of a Connectathon agree that they will not speak negative of their peers. One is allowed to speak of their successes, and they are encouraged at Showcases. But everyone must agree that the most important Principle of a Connectathon is that it is safe to fail, and one aspect of this is that one can fail without their competition blabbing about it. This principle is typically part of the agreement to participate, but most of the time is just socially encouraged. It is in the best interest of all parties.
The main reason why failure must be allowed, is that it must be encouraged. Everyone wants to get through Connectathon having cross-tested with all possible peers. This because by testing in a Connectathon means that they will likely not have problems at a customer site. Thus the more testing that can be considered ‘successful’ the better for yourself. The best case is that you can walk away from Connectathon with a huge list of your peers that you have successfully tested with. These successes can be spoken of, and are often included in a press release by your marketing department after the event.
The fact that Connectathon is a safe place to fail, means that vendors are more likely to send the developer that implemented the specification in their code. In fact it is useless for a vendor to send marketing or sales, there are no customers to speak to. Developers really want their code to succeed too. Thus the developer is much more likely to work with their peer to get the systems working. Often times the developers from competing vendors will be sitting right next to each other at Connectathon, often times reviewing source code. Yes, they are sharing their source code so that another can help them debug it. This concept is totally foreign to most vendor-to-vendor interactions, but it happens often on the Connectathon floor.
This does not mean that a Connectathon eliminates Competition, far be it. There is plenty of aspects of the software that are kept very well hidden during Connectathon. Some social networking is built, but the vendor organizations are clearly direct competitors.
Connectathon is not a Showcase
Connectathon might fix the SpecificationA less visible but just as important aspect of a Connectathon is that the Interoperabilty Specification is also open for discussion. Specifications that are early in their maturity are more open for debate. When two vendors find that they had to fix something in their code, one must ask the question of the specification. Was the specification at fault? Presumably both vendors wrote their implementations from the same specification, and came to different solutions. This could be because one of them simply didn't read the specification correctly, but it could also mean that the specification was not complete enough. Thus the specification is often improved during Connectathon too.
This is so fundamental that IHE requires that their Profiles go through a ‘Trial Implementation’ state. A Profile can’t move to “Final Text” state until three independently implemented systems prove that they can interoperate at a Connectathon event. This governance is there to show that at least three different development groups were able to read the same specification and end up with the same interoperability implementation. There are other governance measures for IHE “Final Text”, but that is a different topic.
Connectathon principles and purpose are criticalA Connectathon is not the only event where developers gather, some other concepts that are related but are different:
- Hackathon – More focused on the development of code to implement some goal. A Hackathon, or Hackfest, or Codeathon, has a targeted solution as the goal. Those that come to the hackathon are cooperating to achieve a goal. There might be more than one independent solution, but generally the goal is the writing of code. A Hackathon might not be focused on an Interoperability Specification, it might be a functional need. A Hackathon is a cooperative environment, again where it is safe to fail. A Hackathon succeeds when it builds buzz, educates the developers, and proves out alternative designs
- Plugfest – This is similar to a Connectathon, but typically focuses on a physical ‘plug’. That is that it is a Connectathon plus it tests physical and electrical interoperability too.
- Bake-off -- This is an event where different technical solutions to a problem are brought together to be compared to the goal. This is used to evaluate each potential solution so that the best solution can be picked. This is a form of implementation first consensus system. In healthcare this is how the "Direct Project" selected secure e-mail as the solution to the problem of 'replacing the FAX'.
- Showcase – To build awareness, educate, and display success. A showcase has been a follow-on event going back to the original Connectathons that were followed by a Telecommunications tradeshow. For much of the IHE profiles the showcase is part of HIMSS Interoperability Showcase, or RSNA Demonstration
- Certification – Organized testing to prove a system conforms to a specification. Needed when the customer is incapable or unable to prove conformance to the specification. Automobile example. Crash safety is based on certification. Engine oil ratings are based on certification. Style, interior, features, handling, etc. are not subject to certification. An automobile buyer is genuinely unable to evaluate engine oil or crash capabilities of their purchases. They are able to decide what kind of car they want. There is no such thing as a complete automobile certification. Certification is limited to those items that the purchaser is unable to evaluate.