Latest revision as of 12:43, 18 March 2019

Disclaimer

This page only refers to test software that is used in advance of the IHE North America and IHE Europe Connectathons. There are other connectathon events that may use some of this software or have their own software. This page does not address those events (for example, IHE-RO has a distinct testing event and distinct tools).

History of Test Software

This section will help you understand the evolution of IHE pre-connectathon test tools, but you can safely skip it. The most important sections to read are

First MESA Tools

IHE started in the Radiology domain. A contract was awarded to the Mallinckrodt Institute of Radiology (MIR) to manage Connectathons and produce test software to prepare participants for those events. The acronym MESA was coined by MIR staff, but as we have no sales/marketing people, it was not the best acronym.

IHE expanded to IT Infrastructure and Cardiology. MIR's contract was expanded to deliver test tools for those domains. The same software and test structure was used, and all of the software was bundled in one release. The model for the MIR MESA software was that a participant would download a binary copy of the software, install on a local computer, and run tests in the laboratory. No external access was required. Source code was provided to anyone interested. Most participants relied on the binary installation.

NIST Contribution

IT Infrastructure took up the XDS profile (so named before there was XDS.a and XDS.b). Bill Majurski of NIST was a major contributor to the development of the XDS profile and offered to develop test tools for that profile. After about 3 seconds of consideration, MIR was happy to have a partner in developing test tools. Bill/NIST decided they needed a different architecture to support the XDS testing, and also decided on a model that made use of public servers located at NIST. In 2009, Bill's toolkit will be expanded to support the XCA and DSUB profiles. As a US government agency, NIST has different copyright rules than does MIR, so Bill/NIST decided to publish the source code for the XDS tests on Source Forge at IHE Open Source.

Lest you think that only Bill works for NIST, we will tell you that another merry group of NISTers works with Bill and has an interest in CDA documents. This is driven by the NIST involvement with HITSP, NHIN, NPR and SDS. Patient Care Coordination tests were originally written as schematron tests by PCC committee members. The NIST group led by Andrew McCaffery and Gavin O'Brien took those original tests and the PCC documentation and improved the content of the tests and provided a web interface to the tools. These are found here: CDA Guideline Validation.

Yet a third set of tools from NIST covers PIX and PDQ testing. This comes from the group managed by Rob Snelick. We will refer to this as NIST-PIX. The 2009 tools are found here: IHE PIX and PDQ Pre-Connectathon Test Tool. A new release will be made available in October of 2010 at a URL TBA.

NIST also is involved in testing devices through the Patient Care Devices domain. The primary contact there is John Garguilo. I refer you to Manny Furst for information on location of those tools.

In the sections below, we will refer to these different tools/support mechanisms as

NIST-XDS
NIST-CDA
NIST-PCD
NIST-PIX

OFFIS Contribution

The test tools for softcopy/hardcopy consistency were developed under contract with O-Tech, Kuratorium OFFIS e. V., and the Institute for Microtherapy. These are valuable for testing the Radiology CPI profile.

Northwestern Contribution

Northwestern created a standalone Windows application that is used to test disk format and file structure for the Radiology PDI profile.

IHE Canada Contribution

IHE Canada proposed the XDS-I profile, and that was taken up by the Radiology domain and published. Funding in Canada was provided to Rita Noumeir at École de technologie supérieure to produce test tools for XDS-I. These tools are found at École de technologie supérieure. Dr. Noumeir's group built on the tools produced by NIST, but maintained a separate software repository and release system.

With HL7 Version 3 a requirement in Canada, IHE Canada requested that the PIX and PDQ proviles be augmented to support HL7 Version 3. As part of the work, more test tools were developed École de technologie supérieure.

INRIA Contribution

The Laboratory domain has been managed primarily from Europe and Japan. INRIA was given a contract by IHE Europe to write test tools for the Laboratory domain. These tools were developed by Eric Poiseau's group and can be found here.

What Does All of This History Mean to You?

The term MESA when originally coined was meant to apply to the software architecture developed at MIR and the test tools that used that architecture. As other tools were developed, people associated the name MESA with those tools as well. This has been confusing to the community (and the developers). We are not at the point where many people equate the term MESA with pre-connectathon testing, no matter the source of the software.

When we are ready to release the next version of tools, we hope to do a better job of naming the tools and to make a single software release. In the mean time, there is no harm in equating the term MESA with pre-connectathon test software. Read the next two sections for guidance finding the software you need for testing.

Cardinal World Series Wins: 1926, 1931, 1934, 1942, 1944, 1946, 1964, 1967, 1982, 2006

General Guidance

Without repeating the history above, there are general guidelines that will help you find the pre-connectathon test software you need. The 'Specifics by Actor' section will have specific links, but this is an overview.

XDS, XCA, and DSUB test tools are developed/maintained by NIST-XDS.
PIX/PIXv3 and PDQ/PDQv3 test tools are developed/maintained by NIST-PIX.
CPI visualization software tools are developed/maintained by OFFIS
Initiatives sponsored by IHE Canada are maintained by École de technologie supérieure
PDI tests for CD media were developed by Northwestern
IHE Lab test software is from INRIA, with the exception of XD-Lab
CDA Schematron tests (PCC documents, XDS-SD, XD-Lab) are maintained by NIST-CDA.
IHE PCD tests are maintained by NIST-PCD.
Test software for all other profiles is either managed by MIR or has not been written. See the MIR MESA software distribution page.

Test Numbers and Names

Pre-Connectathon tests are assigned a number (an index value) and a name to help describe the test. Each numbered test is designed to test one or more requirements defined in one or more Technical Framework document. At times, requirements for a use case or workflow involve more than one actor, and the test naming convention assigns a number/name pair to that use case for all of the actors involved.

Therefore, a fictional test such as test number 9105 / PDQ Query by Twitter Name is designed to test the query sent by a Patient Demographics Consumer to a Patient Demographics Supplier. Assuming the Technical Framework required both actors to support such a query, that one name is used to describe the use case. A separate test is written for each actor so that your actor is tested for the proper response.

If your system implements two or more actors in a profile or in similar profiles, you are likely to see the same test number/name show up on your test list. That means you need to run that test for both actor, with slightly different instructions.

Continuing the example above, your Patient Demographics Consumer would run a test to make sure it could send a query with the proper format and content. The Patient Demographics Supplier would be given some data to load and would be queried and tested for the proper response. Two different results are generated. These different results are loaded separately into the Kudu or Gazelle tool for evaluation by Project Manager staff.

Specifics by Actor

While pre-connectathon test software is normally developed by one group for a domain or profile, we find it useful to list the documentation and software by actor. Many IHE actors participate in multiple profiles, and the test plans and software will generally be similar across those profiles.

In order to find the proper software for your pre-Connectathon tests, follow these steps

Determine the pre-connectathon (MESA) tests you need to complete for your actor/profile pairs
1. When you read the test plans by actor (linked below), they will contain the set of all possible tests for that actor. You might required run only a subset of those tests. Some tests are defined as extensions or not meant as a pre-Connectathon requirement.
2. For Connectathons managed in the US and Europe, use the Kudu or Gazelle tool to find the list of required tests for your registered system(s). Kudu or Gazelle will give you a list of tests and the appropriate actors to be tested.
3. You might be required to run the same test (number/name) for two different actors. See the section above on test names.
Read the documentation for each test for each actor. We maintain one wiki page which lists each actor and gives references to the documentation and software needed to test that actor.
1. The link to the central wiki page sorted by actor is Pre-Connectathon/MESA_Software.
2. The table on the wiki page might have multiple entries for one actor. That means that more than one group developed test software.
3. The link to the test documentation will give you a number of tests for that actor. You need to find the correct test or tests in that document. Remember, you might not have to run all tests.
4. The wiki page should also provide a reference for installation and other instructions.
There is another path through this maze. If you already understand the differences in the sets of tool and how they are used in testing, there is a centralized resource at http://ihedoc.wustl.edu

Unfortunately, not all actor/integration profile pairs have pre-connectathon test software. This is the reality of time and budget constraints.

Special Mention: MESA Test 1

MESA Test 1 is designed only for systems that need to test with the MIR software. If your system does not need to test with that package (maybe you are only testing PCD), you do not need to run MESA test #1.

The documentation for MESA Test 1 is found in the Installation Manual.

The purpose of this test is to make sure you have installed the software and do not wait until the day before tests are due to begin installation.

Difference between revisions of "Navigating MESA Software"