Following is a list from applications making use of the definition management in DVTK.
Whenever a new requirement is encountered in an application, it is only noted down at
that place.



DCM Editor
==========
- Option in the UI whether or not to change VR UN with known VR's from a definition file when a file is loaded.
Current implementation is that the mechanism of changing UN Vr's to known VR's is always used during reading of a file.

R1a:
Have an option available during loading of a file wheter or not to change VR UN with known VR's from a definition file or

R1b:
Have the possibility to populate a DataSet in memory in such a way that VR UN are replaced with known VR's from a definition file. Next to that, automatic changing of VR's is never enabled.


- Propose a VR in the UI when adding a new attribute.

R2:
For a specific tag, get the VR.
(already implemented)


- Show the attribute name in the UI.

R3:
For a specific tag, get the name.
(already implemented)


Compare tool
============
- Show the type of an attribute, taking into account the SOP class and DimseCommand of each of the two datasets.

R4:
For a specific SOP class UID and DimseCommand, have functionality to get the type.



DVT
===
- When specifying the definition files loaded for a session in the SOP class Tab, only these definition files may be used for validation. Definition files loaded in another session may not be used.

R5:
For a session, only use the definition files loaded for that session.



Software interface
==================
- The logic how validation is performed within DVTK is not completely transparant (first a SOPClass DimseCommand
combination is searched in combination with e.g. a system specific name-version, if this doesn't exist a
Dicom 3.0 name-version is used).

R6:
Make determining which SOPClass DimseCommand combination is used more transparent.

- When a lot of definition files are loaded, multiple calls of some methods may take more time then needed.
E.g. DefinitionManagement.GetAttributeNameFromDefinition(DvtkData.Dimse.Tag tag). When this method is called
for each attribute in a large dataset, each time the correct SOPClass DimseCommand combination needs to be
looked up.

R7:
- Make some definition management method calls more efficient.




Remarks
=======
Even the Dvtk.DvtkDataHelper.ReadDataSetFromFile method (which is not connected to any session!) will
use the definition management singleton for converting unknown VR's to known VR's from loaded definition files.

Depending if changing the definition management is a possibility (if the risk of problems introduced during changes is acceptable), possible design for R6 and R7.

- Implement a new SopClassDimseCommand and SopClassDimseCommands class.

- A SopClassDimseCommand instance represents the information of part of a definition file for exactly one Dimse Command.

- Typical methods/properties available on the SopClassDimseCommand class are:
. AEName
. AEVersion
. SopClassUID
. SopClassName
. DimseCommand
. IODName
. GetName(Tag tag)
. GetVR(Tag tag)
. GetType(...). Supplying a Tag only is not sufficient because also attributes within sequence attributes must be addressed.
. Iteration through all attributes present (also within sequence attributes at any nested level)?
. Validate(...)
. FullFileName (definition file it is part of)

- On the Session class a property:
. SopClassDimseCommands, the SopClassDimseCommand instances for all loaded definition files for this session
(e.g. for one Dicom 3.0 storage definition file this results in two SopClassDimseCommand instances).

- On the SopClassDimseCommands class:
. GetForSopClass(String SopClassUID)
. GetForIOD(String iodName)
. GetForDimseCommand(DimseCommand dimseCommand)
. GetForAEName(String AEName)
. GetForAEVersion(String AEVersion)
. GetForDefaultAENameVersion()


When these methods are available, following is a possible scenario to validate:

SopClassDimseCommands sopClassDimseCommands = dvtkSession.SopClassDimseCommands.GetForSopClassUID("1.2.840.10008.5.1.4.1.1.7").GetForDimseCommand(C-STORE-RQ);

SopClassDimseCommands systemSpecific = sopClassDimseCommands.GetForAEName("bla").GetForAEVersion("1.1")

if (systemSpecific.Count == 0)
{
if (sopClassDimseCommands.GetForDefaultAENameVersion().Count == 1)
{
dvtkSession.Validate(dicomMessage, sopClassDimseCommands.GetForDefaultAENameVersion()[0]);
}
}
else if (systemSpecific.Count == 1)
{
dvtkSession.Validate(dicomMessage, systemSpecific[0]);
}
else
{
WriteError("Unable to determine which definition file to use");
}


Another scenario to get the type of an attribute:


SopClassDimseCommands dicom30s =
dvtkSession.SopClassDimseCommands.GetForSopClassUID("1.2.840.10008.5.1.4.1.1.7").GetForDimseCommand(C-STORE-RQ).GetForDefaultAENameVersion();

if (dicom30s.Count == 1)
{
TypeEnum theType = dicom30s[0].GetType("0x00080020")
}


At what layers this new functionality should be available (manager C++, DVTK C#, HLI) should be determined.

The current DvtkData.Dimse.Attribute.Type property will not always return a correct value. The value returned will depend on the order in which the definitions files are loaded.

I propose to remove this property, also from the tools that are now using this (only the compare tool I think).
Does anybody disagree?

Hi Marco,
Excellent analysis of Definition Management!
I'll check in detail and post my comments.
Also we can remove Attribute Type property,
it is used only in Compare tool.

Regards,
Piyush

Hi all,

I think it should be possible to get access to the attribute type property. This because this will be usefull in new DVTk applications.

If the current function is not working correctly we must remove it. But note that this will be a requirement for future releases.

Gerard

Removed the Type property both in the DvtkData layer and HLI layer. Committed the changes in cvs.

Following is a response from Rick:

I have added a Boolean flag to the decoding of an attribute to check if a VR
of UN should be changed via a definition look-up or just simply used as UN.
I added a session property called UN-VR-DEF-LOOKUP. You can add this to your
session file and give it a value true to allow look up and false to use VR
of UN.
I have not saved this session property when a session is saved as this will
make our session files incompatible with older versions of DVTK. I will add
this to the save operation if want.

I have also added an extra argument to the dvtk helper methods so that you
can indicate how this UN lookup should be done there. I have kept the old
methods that took just one argument for now as you are using them in various
applications - but I have indicated in the code that they are deprecated in
favour of the new ones.

Please try this new property and let me know how you get on.

I will adjust the HLI to take this mechanism into account.
I will also improve the read/write robuustness when reading and writing files in HLI at the same time.
I will let you know when this is finished.

don't forget the "access to the attribute type property" requirement which is needed for new tooling.

LS,

the problem I discussed during TelCon, after compiling the code again, the new UnVrDefinitionLookUp is working as specified. I didn't update the code, so it must have been a local compile problem.

I also solved a problem when dealing with VR's UN containig 0 bytes, so please update your code again.


Marco