Gazelle Architecture

Gazelle Architectural Components

The figure below shows the major components of the Gazelle software. This section will provide high level definitions of the components.

Gazelle Control System: This is analogous to the control functions that are implemented by the existing Kudu software. The Gazelle Control system provides these major functions:

1. User identity/management (login/logout)
2. System entry/management (lists of actors/profiles)
3. Test entry/management
4. Configuration management
5. Test selection and activation

The Gazelle Control System is not responsible for actually conducting the tests. It will get the tests configured and started, but the actual execution of any test is the responsibility of the Gazelle Test Engine.

Database: SQL based relational database that contains all configuration and other data required to manage Gazelle. This database may also store data used by Gazelle Actor Simulators. The database includes

1. The model of Gazelle embodied as schema definitions
2. Initial data
3. Data collected at run time
4. One or two layers of software interface to provide a common access mechanism

Gazelle Test Engine: This is similar to the perl scripts that drive the existing MIR/MESA software tools. The Gazelle Test Engine drives specific instances of Gazelle tests involving one or more Systems Under Test and using Gazelle Simulator Actors where necessary. The test engine is driven by a scripting language (e.g., one that lists IHE Actors and transactions and the test data needed to drive a test).

Demographics Services: Not shown in this version of the diagram. Demographic services allow the test control module and test engine to request demographics for use in a test scenario. This will allow Gazelle to support different demographic types with proper language encodings (Japanese, French, German, English).

External Validation Services: The Gazelle design moves the validation of messages outside of the Gazelle test engine. The External Validation Services are designed to have a common interface that is relatively independent of the data type (DICOM, HL7, CDA) and will have instances of validation systems that are aware of the data type. For example, we might have two DICOM validation services, one HL7 V2 service and two-three CDA services. The validation services provide two major functions:

1. Validate the message and determine if it is a legal message/object in the context of an existing standard or IHE profile (is this a legal V2 ORM message for laboratory data).
2. Validate the message in the context of a Gazelle test instance. In this case, you are looking for specific data values (the Patient Name that was changed from a prior test step).

Test Scenario: A Test Scenario is a collection of text information and test steps that defines one use case for testing. This information is used by the Gazelle Test Engine to drive the test process for a test and to inform the test users of their responsibilities.

Gazelle Actor: Gazelle Actors are simulators that implement parts of IHE actors in the context of IHE Integration Profiles. Depending on the actor and profile, a simulator may be a simple piece of software or something quite complex. The simulators are typically lacking the management and advanced GUI functions that are found in commercial implementations. Gazelle Actors provide an area for collaboration as there are many actors to implement. Gazelle Actors are needed as communication peers when a System Under Test wants to run a test.

Test Proxy: The Test Proxy is a TCP/UDP engine that acts as a message router. Systems Under Test and Gazelle Simulators are configured to send messages to the Test Proxy. The Test Proxy forwards the messages to the appropriate destination while maintaining a local copy. This local copy can then be retrieved by the Test Engine and passed on to other components for control or validation.

Interface Definitions

The Gazelle architecture will rely on these interfaces defined between modules:

1. Database abstraction (assuming a Java/JBoss environment)
2. External validation services
3. Demographics services
4. Gazelle Control Module / Gazelle Test Engine
5. Gazelle Test Engine / Gazelle Actor/Simulator
6. Gazelle Test Engine / Test Proxy

These file formats will be designed and used as part of the project. The working assumption is that these are XML based.

1. Test scenario format
2. Results reporting for individual tests
3. Results reporting for groups of tests
4. Results reporting for an event (e.g., Connectathon)
5. Configuration information (DICOM, HL7, web services)

Tool Development

As part of the development and implementation process, we know we will need a number of tools so we are not building many of our files by hand:

1. Authoring tool for test scenarios
2. Authoring tool for CDA documents

Component Technology

These are key components that will be used in Gazelle

1. Java (1.5.x)
2. JBoss
3. PostgreSQL (8.x)

These are domain specific toolkits that are being used for evaluation services

1. DVTK software from Agfa/Philips
2. DICOM3Tools from David Clunie
3. NIST HL7 V2 validation tools

These are domain specific toolkits that are candidates for use

1. DCM4CHE: DICOM communication
2. NIST HL7 V2 software
3. INRIA HL7 V2 software
4. Mirth: HL7 communication
5. NIST XDS toolkit

These are existing components in use today in MESA that could be brought forward (but we would like to phase out). At a minimum, we can use the concepts in these tools as we replace them with Gazelle components.

1. DICOM CTN "C" library
2. MESA C++ client and server implementations
3. Perl scripts that serve as test engines.