Table 1 Technical concerns

Connection conflict

There is a disagreement at the communication level including the lower layers.

Since we do not execute conformance testing, we only require that the communication successfully takes place while verifying additional communication requirements when necessary. Such additional communication requirements include for example the presence of web addressing at the SOAP level as required by the integration profile.

Syntactic conflict

Different data structures or representations are used between peers.

In addition to verifying the structure of a message, we verify the presence of all required data, and the correct structure of any published document: published documents are constrained to be of specific types such as CDA or DICOM manifest.

Control conflict

The communication peers do not agree on their roles (e.g. which peer is the server) or in the flow of control of a communication interaction (e.g. immediate or deferred acknowledgment).

We do not perform any specific verification of this conflict, as we only require that the communication be successful.

Quality-of-service conflict

The behavior of a communication peer does not satisfy technical requirements derived from "policy" concerns, such as a timely response to a communication response.

Using a timeout, our system will consider the communication as failed, if not timely achieved.

Data consistency conflict

Peers do not consistently use information that is not directly communicated in the interaction (e.g. configuration data). In our case, such data include information about peers' addresses, procedure codes, document types and other codes that would generally be shared in a healthcare enterprise.

Our system requires that the tested system uses shared configuration information with the testing software.