Previous Next Index Thread

DICOM Directions, was Re: DICOM Image Compression & JPEG

 In article <4r0rsj$k0h@xmission.xmission.com>, haas@xmission.xmission.com (Walter O. Haas) writes:
 >In article <31D2CF71.35C4@care2.uab.es>,
 >Craig D. von Land <craig@care2.uab.es> wrote:
 >>As I have stated in the past, if the DICOM standard had been designed
 >>using object-oriented techniques, this would not have become a problem.
 >>I am working on such a design, but I fear that it is much too late for
 >>DICOM 3. Perhaps these issues could be addressed in a future version
 >>of the standard.
 I don't see that it is necessarily too late ... one of the major strengths
 of DICOM 3.0 is that it defines "Information Objects" (really data
 structures) for certain applications ... these are relatively well defined
 and based on reasonably realistic real world models, even if the translation
 into a linear tag based encoding is a bit archaic. The services on these
 "objects" (data structures) have been defined as needed to handle them.
 I see no reason why it would not be possible to take the existing data
 strucuture definitions and map them into a more object oriented 
 mechanism for handling them, defining methods for the objects that
 subsume existing functionality or extend it in some more pure and
 consistent manner. Furthermore such a definition could be bidirectionally
 interoperable with existing DICOM 3.0 applications through relatively
 simply conceived gateways.
 >I'd like to see an object-oriented version of DICOM ... perhaps built on
 >CORBA, if that's a practical open object platform ... 
 It certainly seems to be the only standardized player in town, though
 how many cheap off the shelf and interoperable implementations of
 object brokers there are I am not sure ... such things would be necessary
 to get a DICOM effort in this direction off the ground.
 > and by an open IETF
 >process ... 
 This is not a pre-requisite for going object-oriented, or in any other
 direction. If WG VI and the ACR/NEMA committee can be convinced that
 this is a worthwhile thing then they may go that way, though who would
 have the expertise and do the work is another question. The people
 on the working groups are pretty swamped with existing work. They
 might be much more ammenable to such suggestions if someone were to
 come along with a formal white paper on the matter and a sample
 experimental application to demonstrate the feasibility and benefits
 and demonstrate their willingness to continue developing it. DICOM
 won't respond to wish lists, only people committed to doing the work.
 On the other hand, as you can see from the white paper on a MIME content
 type I presented to WG VI last meeting before CAR (which is available
 from my web site), I suggested standardizing and allowing conformance
 definition for the use of http and email exchange of DICOM messages,
 something that is already being done by many groups, and to say that
 the reception I got was cold would be an understatement. I don't really
 know how to take that any further, and was waiting for further feedback
 after CAR but I don't seriously expect I will get any. There is serious
 opposition from some sectors of the vendor community to allowing anything
 other than part 8 network and part 10 media to claim conformance. I can
 see from an interoperability guarantee point of view some merit to their
 arguments, and it may serve as a warning to those defining say a CORBA
 based approach, to pay close attention to a conformance mechanism at
 least as tight as the existing one, from the start.
 Personally I feel this issue is so important it warrants a separate
 Working Group on Object Management Directions or something, but I
 don't know that the expertise or commitment exists within the current
 groups to go that way.
 >and ideally, a version that solves the problem of updating
 >information in real time, so that information items such as "Mr. Smith
 >is now on the couch ... now he's not there any more" can go between a scanner