Item 2

Introduce a distinction between prototypes and products during the connectathon test.

Section 1. Introduce a distinction between prototypes and products during the connectathon test.

The connect-a-thon aim at testing the implementation of IHE actors and integration profiles withing company products. When new actors and integration profiles are defined by the IHE committees it is not realistic to test their implementation in products during the connect-a-thon that follows the release of the new supplements.

Section 2. Objective.

We need to distinguish products from prototypes in the connect-a-thon testing process.

Better characterization of the systems tested during the connect-a-thon. Are we testing a real product or a prototype. Improve inter vendor communication : Vendors need to know the status of their peers systems. Did they test with a product or with a prototype ? Reduce the risks for user when integrating systems in their institutions. User shall be informed of the quality of the system tested during the connectathon. Prevent usage of systems customized for the connectathon and that will not

Section 3. Analysis.

During the connect-a-thon, there is no distinction between products and prototypes. Therefore when the users consult the Connectathon results, the only way to find if the company has tested a real product is to look for an Integration Statement with the same actor/profile capabilities. In a number of cases an Integration Statement is not published, leaving the user uncertain of the nature of this Connectathon Success. Some company may appear to use a prototype just for having a star in the Connectathon results ! The integration statement must normally solves this problem because this document describes more deeply the conformance of a specific version of the product with the actors/profiles. Unfortunaltely this document is generally not easy to locate and use by an end-user (not all companies take advantage of the IHE web site page pointing to vendors’ IHE Integration Statement. There are reasonable needs from the vendors for various levels of testing:

• Having the possibility to test their new/fulture products (prototypes) with their own products or with others prototypes or products from another company.
• Have the possibility to test existing products against other vendors existing products.
• Have the possibility to to bring a prototype for testing (product not yet commercially announced) and a few weeks or months after the Connectathon wish to switch the implementation status to a product.

If only commercially available products were allowed in the connectathon, or if prototypes were allowed, but the results not listed in the results, the company would have more difficulty to explain to their customers the status of the product given the fact that the Connectathon quite popular for users. The introduction of new profiles (in trail Implementation status) is greatly enhanced by prototype implementations which not only help the vendors assess the maturity of their implementation, but provide critical quality feedback on the IHE specification and underlying standards. It would not be reasonable to expect product implementation of new profiles in a Trial Implementation, especially as critical corrections may have to be introduced in the final text, final text to which commercial product shall only comply with.

This proposal is to improve the connectathon process and better balance between the implementors’ constraints and the users needs for transparency and quality.

This item includes the review and definition of proposed enhancements fro the IHE Connectathon:

1. Improve the quality/coverage of the pre-connectathon testing tools (see item 6)
2. Define how to proceed for prototypes or products in the Connectathon : Should the process be different in the two cases
3. How to publish the Connectathon results depending on the nature of the implementation (product vs prototype) depth of succesfull tests, IS,…
4. Relationship, and widespread availability integration statements by adding/linking them in the connectathon results
5. Education and awareness for the Connectathon results and Integration Statements. for both users and vendors.

Section 5. Roadblocks.

No significant roadblock are foreseen. This proposal need to account for the fact that this process will likely take IHE in the context of what is broadly called certification. It is not the intent of this proposal to turn IHE into a “formal certification authority”, however if such certification authorities want to leverage this enhanced IHE process this should be possible.

This analysis need to be performed in conjunction with the other IHE regions. It is indeed critical that the meaning and interpretation of Connectathon results be consitent between the US, European and Asian connectathons.

Section 6. Work breakdown: Actions and organization and timing

Resource needs : To write documents and to report when meeting as a WG : 2 Man x Month

Timing : 4 months

Working group : user and vendor representatives (6 members)

Dependency :

• With MARCOM committee for the description of the evaluation process. This description can also be used for education and testing committee for tools.
• Coordination with other IHE regions (USA, Asia).