We hope you will find the answer to your question here. If not, please Contact Us
- What is an IHE domain? ...a profile? ... a profile option? ...a transaction?
- What is an IHE Integration Statement?
- What is the output of the Connectathon?
- Does IHE report the results of testing individual transactions? ..of profile options?
- What happens at a Connectathon? How does it work?
- What is a test partner? How do I find test partners?
- There is a rule that says you have to test with three test partners. What happens if there are not three partners?
- May I test with my own system or my company as a test partner?
- What happens if I am working on a test and my partner fails?
- What is the Connectathon grading system?
- What is the pass/fail rate at the Connectathon?
- How many staff members should I allocate to the event?
- What is the Connectathon schedule?
- Do I have to stay the entire time?
- Why travel to a Connectathon? Can't I just test over the internet?
- What happens if my engineers don't have their software working on the first day? What happens if they don't have it working on the third day?
- Would you cut off your arm to save the rest of your body? You really do want to know the answer to this in the context of the Connectathon.
- What is the difference between IHE interoperability testing and conformance testing?
- Do I need to test at a Connectathon to sell a product? ...to publish an Integration Statement?
- What is a Connectathon Technical Manager and who are they in Europe & North America?
- What is a domain Technical Project Manager? Who are they?
- What is a Connectathon Monitor?
- What are Thorough and Supportive testing?
- Does IHE supply the computer systems at the Connectathon?
- What kind of hardware do participants bring to the Connectathon?
- May I contact other participants in advance to discuss testing or other items?
- Will a .NET application communicate with a Java application?
- Do you know how to configure my system for printing with your printer? Do you know how to configure my VM software?
- How many plants should my conference organizer order?
IHE is organized by clinical and operational domains. In each domain, users with clinical and operational experience identify integration and information sharing priorities and vendors of relevant information systems develop consensus, standards-based solutions to address them. IHE domains are responsible for developing and maintaining IHE Technical Frameworks containing IHE profile, actor, and transaction requirements.
Profiles describe clinical information managements use cases and specify how to use existing standards (HL7, DICOM, etc,...) to address them. Systems that implement IHE profiles solve interoperability problems. For equipment vendors, profiles are implementation guides. For healthcare providers, IHE profiles are a shorthand for integration requirements in purchasing documents.
Actors are responsible for producing, managing, and/or acting on information in the context of an IHE profile. Each IHE profile assigns specific requirements to specific actors.
Transactions are interactions between actors that communicate the required information through standards-based messages. IHE defines a set of transactions based on ASTM, DICOM, HL7, IETF, ISO, OASIS and W3C standards in Volume 2 of each domain's Technical Framework. As the scope of the IHE initiative expands, transactions based on other standards may be included as required.
An IHE profile may define one or more options that an actor may choose to support. An option typically represents an enhanced capability for the actor within that profile.
IHE Integration Statements tell customers the IHE profiles supported by a specific release of a specific product.
Developers of commercial and open source healthcare IT systems can publish IHE Integration Statements to indicate their products' conformance with specifications in the IHE Technical Frameworks. IHE capabilities are always expressed in terms of a profile/actor pair. An actor within a profile may support an option. IHE Integration Statements do not reference specific transactions. See http://product-registry.ihe.net/PR/pr/introPR.seam
By comparing the IHE Integration Statements from different products, a user familiar with the IHE concepts of actors and integration profiles can determine the level of integration between them.
IHE publishes the IHE profile/actor pairs that each company successfully tests during connectathon week. Connectathon results are not reported on individual products or product versions. IHE maintains this database of the results from past connectathons.
See previous question. IHE reports the profile/actor pairs that each company successfully tests. While we test options and transactions at the connectathon (always within the context of a profile), IHE does not report results of individual transactions or options.
Each participant system is assigned a table that typically seats two people comfortably. Participants bring their equipment to the table and use the Gazelle system to identify tests defined by their choice of actor/profile pairs. A participant will select a test to be run, and Gazelle presents a list of test partners. The participant will walk over to a peer’s table and arrange a time for testing. After a specific test is completed, the participant marks the test complete in Gazelle. A volunteer monitor is observing a worklist. He/she will see an item for grading, will put down their donut (maybe), and walk over to grade the test. The monitor enters the test result in Gazelle, and the cycle continues. During the evenings, Connectathon Managers review the individual test results and enter pass/fail grades in Gazelle for specific profile/actor pairs.
Items to bring to your attention:
- You can run tests in any order. With the exception of a few “Do This First” tests, order is not important.
- After you complete a test, you should start another test. Monitors are limited resources and may not appear immediately.
- The test cases indicate the kind of evidence needed to document the tests, and Gazelle provides a mechanism to store log information and screen captures. This is designed to make it easier for participants and monitors to find test results.
- In many instances, client applications initiate tests because that is a natural workflow. If you have server applications, you should be pro-active and seek out client applications for testing. Do not stand in the corner and wait for someone to ask you to dance.
- If you find a problem while running a test, you are allowed to update your application during the event and re-run the test later.
Gazelle, our connecathon management tool, assigns you a set of connectathon tests based on the the profiles, actors, and options you have registered to test. Your test partners are other vendors' system that have implemented complementary actors, eg they are on the other end of a transaction you support within a profile.
When you start an individual test within gazelle, you will be presented with a list of other vendors' test systems that are valid partners for that test.
In advance of the connectathon, you can determine who your potential test parters are. Gazelle produces a pdf report of Connectathon registration organized by profiles within each domain. See gazelle menu Registration-->Registration Overview.
If there are zero partners, the Connectathon Managers will not allow you to test. There will be no way to receive credit for testing. Connectathon Managers will not administer conformance tests as a substitute for interoperability tests.
If there are one or two test partners, Connectathon Managers will award credit if you successfully test with all available test partners.
No, even if your profile has limited test partners. IHE assumes that a company is able to make their own systems work together in their own labs. We would like to see applications from different vendors working together.
For each individual test, both you and your test partner (from another company) must successfully complete all steps. When a test fails, it is often unclear where the error occurred. Even if it is apparent that the fault lies with your partner, we do not grant you credit for that test. Sometimes, your partner will be able to repair the defect and you can successfully complete the test. Otherwise, you abandon that test instance, find a different test partner, and try the test again.
Based on the profiles, actors, and options you register to test, you are assigned a set of connectathon tests. In most instances, you will be required to perform three instances of each specific test wtih a different test partner to demonstrate interoperability. In no cases are participants from organization/company "A" allowed to test with equipment from the same company "A" in order to satisfy testing requirements.
Throughout the week, Connectathon Monitors evaluate the results of these tests -- by visiting your system to observe results, by observing test logs, or by running test tools with your equipment. Each evening, Connectathon Managers check your progress against the requirements for each profiel/actor pair, and assign a "passing grade" to systems that have completed their work. for that profile/actor.
The pass rate is quite high, but not 100%. The purpose of the question is to communicate to participants that the connectathon sponsors want all participants to complete the tests for each actor/profile that is registered, but the sponsors do not guarantee success. Before the connectathon and during the connectathon, some participants drop registration of actor/profile pairs to focus on the areas where they can succeed. IHE sponsors do not publish any failures; however, IHE sponsors also do not give a participant credit for testing merely for showing up.
Your staff members should be technical people who know how to operate and troubleshoot your equipment. Do not use the connectathon event to train new staff.
The responsibilities of a Connectathon participant include understanding the list of required tests, scheduling tests during the week with different test partners, executing test steps, gathering result logs, troubleshooting problems, demonstrating results for connectathon monitors, and monitoring test progress during the week. These are demanding tasks, and experience has shown us that it is extremely difficult to be successful if you send just one staff member.
If you haven't registered for too many profiles, two staff members should be adequate. If you have questions about staff levels for your test system, contact a Connectathon Manager for some guidance.
Each Connectathon published its own schedule. NA and EU Connectathons typically run for five days, starting on Monday morning and ending on Friday at noon. Some targeted Connectathons are shorter.
NA and EU Connectathons end at noon on Friday. (Other events have published schedules.)
All participants are required to be in attendance until the end of Connectathon.
Participants are not allowed submit test results after the end of the Connectathon
Any finished test that is not evaluated by a connectathon monitor onsite will remain ungraded. We do not evaluate tests after the connectathon closes. You must plan your time to complete all work, both running your tests and ensuring they get graded, before the connectathon ends.
Yes. This is a requirement for participating in the Connectathon. Other participants rely on you to complete their testing. This is a collaborative event.
The IHE Connectathon is designed as a face-to-face, collaborative testing event. Since 2001, organizations participating in the Connectathon have realized the benefits of having engineers in the same room running tests, finding and fixing bugs, and exercising the IHE capabilities in their products with their industry partners. While IHE is planning to offer additional services that allow for virtual testing, the Connectathon requires you to participate and run tests on-site.
It is common for participants to find bugs and fix them early in the week, allowing them to complete tests later that may not have worked on Monday. If you are still struggling on Wednesday, see FAQ question 17.
...or, during Connectathon week, you may find that you have bitten off more than you can chew. If you are registered to test multiple profile/actor pairs, you are responsible for monitoring your testing progress during the week. Connectathon participants are encouraged to manage their time and fully complete testing for a given profile/actor pair rather than perform partial, but incomplete, testing on a number of profile/actor pairs.
During the Connectathon, you may choose to drop one profile/actor in order to concentrate on completing another. Likewise, Connectathon Managers may on a case-by-case basis advise a participant to drop profile/actor pairs if we think you're at risk of not completing your work.
We define conformance testing as testing your system against IHE profiles or existing standards using a test harness (test tool). You plug in your system, execute the conformance tests, wheels turn, bells ring and a conformance result pops out of the test harness.
IHE Interoperability testing is conducted by connecting peer systems on a network (or exchanging media where appropriate) and testing the communication and application behavior of those systems. During a Connectathon, we do perform some conformance tests, but the focus is on testing the behavior of two or more systems together.
The interoperability testing provides better proof that systems will work together in the field. It also helps us test the IHE Integration Profiles themselves. Sometimes problems in profiles or communication standards are difficult to find until different developers write applications and test these together.
You may sell a product wtih IHE capabilities or publish an IHE Integration Statement for your product without testing at a Connectathon.
Connectathon Managers oversee the technical aspects of the Connectathon testing event. The support vendors as they prepare for the Connectathon and communicate the test requirements and schedule. They are responsible for the Connectathon test process and manage that during the event itself. With the growth of IHE, a Connectathon Manager will be aware of each of the domains tested during the event, but is not responsible for the details of each domain (see “Domain Managers for $200").
Eric Poiseau manages connectathons in Europe, and Steve Moore is the technical manager for the January North American connectathons.
Technical Project Managers work with domain Technical Committees to review new profiles during the annual profile development activities. They provide guidance on pre-Connectathon test tool development, write Connectathon tests and oversee testing in each domain during the Connectathon. The Technical Project Managers are listed here.
The Connectathon sponsors recruit a contingent of volunteers to evaluate the results of the tests you run with your partners. Connectathon Monitors are experts in a variety of clinical areas; they are PACS administrators, security whizzes, academics and more. They are not vendors (ie vendors don't evaluate other vendors' work).
We have a full explanation here.
No, you must provide your own equipment.
Years ago, many participants had large computers shipped to the Connectathon. Now, the majority of test systems arrive on the connectathon floor running on laptop computers. Production-level hardware is generally not needed to complete connectathon testing.
This a trick question. IHE relies on network protocols that are independent of implementation technology. If your software properly implements the communication protocol, your application will be able to exchange messages with peer systems. It does not matter if the peer system uses .NET, Java, C++ or python.
No, and no. The staff you send to the connectathon should know the ins and outs of your test system.
None. (We really did get this question once.) This is an engineering event. Leave your decorative plants at home. However, a small bowl of chocolates has been known to be popular with visiting test partners and connectathon monitors.