The rules for conversion specify that the SOP Instance and Series Instance UIDs of converted images be changed, and that the same UIDs be used each time that a query or retrieval is performed. The strict separation of the two "views" of the same information, coupled with the "determinism" that results in the same identification and organization of each view every time, are required for stability across successive operations.

Were this not to be the case, for example, the results of a query (C-FIND) might be different from the results of a subsequent retrieval (C-MOVE or C-GET), or for that matter, successive queries. Further, references to specific instance UID in either view may be recorded in external systems (e.g., in an EMR), hence it is important that these remain stable and accessible.

This places a burden on the Q/R SCP to either retain a record of the mapping of UIDs from one view to the other, or to use some deterministic process that results in the same UIDs (one could envisage some hashing scheme, for instance). How this is implemented is beyond the scope of the Standard to define. The determinism requirement does not remove the uniqueness requirement; in particular it is not appropriate to attempt to derive new UIDs by adding a suffix to a UID generated by a different application, for example.

There is no time limit placed on the determinism; it is expected to be indefinite, at least within the control of the system. This is a factor that should be taken into account both in the design of federated Q/R SCPs that may integrate subsidiary SCPs that support this mechanism. It should also be considered during migration to a new Q/R SCP, which ideally should support the mechanism, and should support the same mapping from one view to another as was provided by the Q/R SCP being migrated. This may be non-trivial, since the algorithm for conversion may be different between the two systems. It may be necessary to define some persistent, standard, serialized mapping of one set of UIDs to the other.