DICOM TCP-Services and DICOM implementation details in Ensemble

Hi everyone,

before contacting WRC i thought to ask dev com about some questions related to Ensemble DICOM related implementation. These are more practical things and I hope to have someone around with experience in the field. We´ve created a DICOM Worklist application and are now in the process of roll-out.

1) One of our customers came up with a question to bundle modalities of certain locations to use a single Ensemble Service (EnsLib.DICOM.TCPService). That way instead of creating 10 DICOM TCP Services and assign ports and so on, he would like to use onle four services and assign the allowed RemoteAET(s) to them. The question now is how to configure the service (should jobs per connection be used? - I guess so) itself and how much modalities should be assigned to one DICOM TCP Service in total to guarantee a save processing of incomming requests (are there field experiences around?)

2) The DICOM Worklist Sample provided in ENSDEMO create the DICOM Association with the full set of available SOP-Classes from the dictionary. Specifying only the WORKLIST C-FIND Model SOP-Class (1.2.840.10008.5.1.4.31) when invoking the utilty method to create the dicom association within ensemble

Do ##class(EnsLib.DICOM.Util.AssociationContext).CreateAssociation("JD-SCU","ENS-SCP",$ListBuild("1.2.840.10008.5.1.4.31"))

gives an error telling that this SOP-Class is unknown. What would be the correct way to specify the desired sop-class and do we need to have further SOP-Classes assigned for a worklist application?

3) How to set a value in an object of type EnsLib.DICOM.Document when the field is specified as DICOM VR ´SQ´ (Sequence)  for example to transport the Patients primary language (DICOM-Dictionary, PatientPrimaryLanguageCodeSequence). Setting it like

Set tSC = pDocOut.SetValueAt("English", "DataSet.PatientPrimaryLanguageCodeSequence[1]")

won´t work. So the question here is how to find the expected subfield from the dictionary implemented in ensemble. Maybe someone have further ideas on the points mentioned above and can give me a little hint? In anyway thank you for the support.

best regards,

Sebastian

  • 0
  • 0
  • 353
  • 5
  • 0

Comments

1) Use Job per connection. A DICOM service can handle multiple remote AETs including wildcard definitions.

2) That method takes a list of TRANSFER SYNTAXES not SOP classes. Use the UI to create a specific association definition.

3) You don't need to create the SQ explicitly , it will come into being when you set the first member, e.g. Something in the example below

Set tSC = pDocOut.SetValueAt("English", "DataSet.PatientPrimaryLanguageCodeSequence[1].Something")

Hi Jamie,

thank you for the given hints.

1) Use Job per Connection was one of my first ideas as seen from local testing with some emulators. It is realy a question if there are points to consider when reconfiguring the service. Anyway we might see this in testing against real devices.

2) Uhm, yes missed that. Sry for this. We work on a solution to do this programmaticaly using a temporary file and the method ImportFromFile given by the framework. Endusers may get confused with doing this on the ensemble configuration pages and in our application so we´ve provided them with a single commandline statement to add everything required. Having just the transfer syntaxes and sop classes defined which are required for our application might get us a little performance boost when receiving dicom documents via the service.

3) Yes this is the point. But in my example, what is the correct member for the PatientPrimaryLanguageCodeSequence? I wasn´t able to figure that out from the dicom dictionary in ensemble. In other words, how to find SQ related fields from the dicom dictionary?

best regards,

Sebastian

As regards point 3) T

 

The dictionary does contain the individual elements, for example in our work list demo we do this :-

 

Set tSC=pDocOut.SetValueAt("StationAET","DataSet.ScheduledProcedureStepSequence[1].ScheduledStationAETitle") If $$$ISERR(tSC) Quit

 

ScheduledStationAETitle appears in the dictionary with tag (0040,0001).

 

You will need to consult the NEMA DICOM online documentation to determine which sub-tags are valid for a particular structure, in the particular document you are sending. We (ISC) don't maintain that information ourselves.

 

Hope this helps

Hi Jamie,

thank you for the hint given. Unfortunately I was not able to find any sub tags for the given field PatientPrimaryLanguageCodeSequence. The NEMA DICOM docs only state this field as SQ (a structured type) which sub-tags are need to be used is not clear. Anyway as from my tests. Ensemble try to evaluate the path set when constructing an entry for the dicom document - and in my case for that specific field fails with

<EnsDICOM>InvalidPropertyReference: The property reference 'PatientPrimaryLanguageCodeSequence[1].someTag'
is invalid: Tag name not found in dictionary: 1 at offset 40 - parsing property reference

best regards,

Sebastian

I think you misunderstand. You cannot just add an arbitrary name as a tag! the reference above of course is invalid because someTag does not appear in the dictionary. Each part of the property reference must appear in the dictionary for this to be valid so 'PatientPrimaryLanguageCodeSequence' and 'someTag' both must appear. For your reference :-

(0010,0101) VR=SQ VM=1 Patient's Primary Language Code Sequence