Table 3 Functional concerns

Functional model conflict

Two applications have incompatible factorings of the process activity space: there may be a task that each expects the other to do ("nobody's job"), or a task that both expect to do themselves ("overlapping roles").

Roles and responsibilities are specified in the IHE integration profile. When testing a system, our software tests a specific role and therefore tests all responsibilities associated with that role as required by the profile.

Functional scope conflict

One party's behavioral model for a function contains more activities than the other party's model: 1- when the requester's model is larger than the performer's model, the performing application executes a subset of the expected behavior, leaving some expected tasks not done; 2- when the requester's model is smaller than the performer's model, the performing application executes unexpected activities as well as those requested. One example of functional scope from the IHE radiology technical framework relates to the Modality Performed Procedure Step (MPPS) transaction where the expected behavior of the receiving system is not specified in details; therefore this transaction is usually successfully received but does not trigger actions or state change as implicitly expected.

In the profile of interest here, functional scope conflict is avoided as far as the applications implement the required responsibilities of the specific role they play; these responsibilities are verified by the testing software as stated above.

Embedding conflict

The behavior of an application is affected by the integration with other peers. This happens when the application is capable of some adaptability in behavior which might be configured.

This kind of conflict is supposed to be detected and fixed by the testing engineers while using the testing software. The testing software does not detect en embedding conflict per se; but performing the testing with the help of our testing software simulates the integrated environment in which the application is supposed to operate in a real situation; therefore, an eventual embedding conflict would be fixed before deployment.

Intention conflict

The application is being used in a way its design did not anticipate, resulting in unexpected behaviors. This relates to differences in the details of the application specification versus the specification as needed for the role of that application in the larger system. This kind of conflict is hard to grasp. One example of such conflict is encountered in the way x-ray images are organized into series: one acquisition equipment may group multiple x-ray images into one series, while another one may put each image in a different series. Although both equipments have the right to do so, the receiving system may not be able to function with one or the other type of image grouping.

Even though the testing software helps in detecting some intention conflicts, such conflicts may arise anytime during the operation of the integrated larger system.