Enhanced DICOM Profile - Brief Proposal: Difference between revisions
Jump to navigation
Jump to search
New page: <<Describe proposal for one or more Content Profiles based on the Enhanced IODs for CT, MR, XR and PET>> ==Issues Needing Addressing== ===Downgrading to Old Objects=== How should a PAC... |
|||
| Line 1: | Line 1: | ||
<<Describe proposal for one or more Content Profiles based on the Enhanced IODs for CT, MR, XR and PET>> | <<Describe proposal for one or more Content Profiles based on the Enhanced IODs for CT, MR, XR and PET>> | ||
| Line 9: | Line 7: | ||
SOPs in the association for the C-STORE. The problem is that before the C-STORE there is probably a C-FIND and when you don't know what the client wants, how many series do you tell them there is. One Enhanced, but if they want Old, there are many situations you | SOPs in the association for the C-STORE. The problem is that before the C-STORE there is probably a C-FIND and when you don't know what the client wants, how many series do you tell them there is. One Enhanced, but if they want Old, there are many situations you | ||
would want/need to split into multiple series. Similar when they query for image instances. | would want/need to split into multiple series. Similar when they query for image instances. | ||
: Realistically, I think that this would have to be done on the basis of the requesting AET, keeping a table in the SCP as to which AETs want "old" and which want "new" CT objects (or similarly for MR of course). This could either be configured manually (yuk!), or perhaps better done by "trying" to negotiate the enhanced objects in each outgoing C-STORE operation...that way any upgrade of the client could automatically be updated as soon as t gets upgraded (well ONE query later in fact!) Once the decision has been made, then splitting into series/images is '''probably''' not too difficult......if anyone would like to send me an example enhanced image would would benefit from splitting, then I'd happily give it a try - Dave Harvey | |||
===Upgrading to New Objects=== | ===Upgrading to New Objects=== | ||
Taking old objects and generating enhanced is even harder since there are required fields that would need to be filled and the necessary information is likely not present. | Taking old objects and generating enhanced is even harder since there are required fields that would need to be filled and the necessary information is likely not present. | ||
Revision as of 07:16, 13 June 2007
<<Describe proposal for one or more Content Profiles based on the Enhanced IODs for CT, MR, XR and PET>>
Issues Needing Addressing
Downgrading to Old Objects
How should a PACS handle it if the modality provided Enhanced but a client needed old style. Creation of the old objects is not so bad, and could be triggered based on the SOPs in the association for the C-STORE. The problem is that before the C-STORE there is probably a C-FIND and when you don't know what the client wants, how many series do you tell them there is. One Enhanced, but if they want Old, there are many situations you would want/need to split into multiple series. Similar when they query for image instances.
- Realistically, I think that this would have to be done on the basis of the requesting AET, keeping a table in the SCP as to which AETs want "old" and which want "new" CT objects (or similarly for MR of course). This could either be configured manually (yuk!), or perhaps better done by "trying" to negotiate the enhanced objects in each outgoing C-STORE operation...that way any upgrade of the client could automatically be updated as soon as t gets upgraded (well ONE query later in fact!) Once the decision has been made, then splitting into series/images is probably not too difficult......if anyone would like to send me an example enhanced image would would benefit from splitting, then I'd happily give it a try - Dave Harvey
Upgrading to New Objects
Taking old objects and generating enhanced is even harder since there are required fields that would need to be filled and the necessary information is likely not present.