Memory Space

PF. vd. Stelt p.vdstelt at ACTA.NL
Thu Sep 20 19:00:54 PDT 2001


Hi Axel,

for the same reason you mention in your message, I will reply through
ORADLIST.

Postprocessing is an important issue. Sometimes two kinds of postprocessing
are distinguished:
1. the processing needed to bring the raw data into a form that represents a
"good" image. This is sometimes also called reprocessing because it is in fact
required to give a useful image. An example of this kind of processing is the
12 to 8 bit conversion used by many dental systems to compensate for over- and
underexposure. The 8 bit image contains the full diagnostic information, but
this is based on 12 bit "raw" data. This is part of the sensor system and
should be left to the responsibility of the sensor manufacturer.
2. the real postprocessing includes procedures such as contrast enhancement,
contour enhancement  -  in general any global or local filter action applied
to the image. In our system (Emago), we store and keep the image always in its
original state. If any kind of image processing is applied, however,
information about the image processing is stored together with the image file.
When the image is retrieved, the same processing is automatically applied
again, and the user is looking at the processed image (obviously, there was a
reason to process the image). When the user wants to see the original image,
the image can be returned into its original state by one mouse click. This
combines, in our opinion, the best of two worlds: have an optimized or
enhanced image available, but always be able to get back to the original. This
all without increasing the required storage space.

I think (that is also the regulation in many countries) that the radiographic
images should be stored in a central database and be considered as medical
information, which requires the usual privacy and security measures. We keep
all images on a central server (of course with the common redundancy, but in
fact it is one server). Image acquisition is possible only in those places
were scanners, sensors or other input equipment is present. The workstations
(near every dental chair) have no import or export functionality. Only on a
few places in the building, supervised by an authorized person, import and
export of digital images is possible. This turns the aspect of security and
privacy from the technical level back to the organizational level, which is
not different from the way analog films are handled and archived.

Finally, removing an image is nearly impossible. It means we end up with a
number of images that are considered as useless (yes, sometimes we make
misalignment errors ...), but it also gives us a change to monitor the ratio
of "effective" exposures and total exposures, which is something we never
could do in a reliable way with conventional radiography (because it is
impossible to check every garbage bin at the end of the day).

I realize this again is a rather long reply, but I hope it contributes to the
exchange of thoughts.

Best regards,
Paul

- - - - - - - - - - - - - - Original Message - - - - - - - - - - - - - -
On Thu Sep 20 16:21:23 2001,
"Axel Ruprecht" <ruprecht at BLUE.WEEG.UIOWA.EDU> wrote:
>Paul
>
>Thank you for your timely response.
>
>I shall respond to your comments on ORAD, inasmuch as this may be of
>interest to others, who may also have comments. Our Digital Imaging
>Task Force did consider your other comments, and felt that some of
>this was like fortunetelling. We wondered about what would happen
>with other digital imaging modalities, and felt that it was too early
>to predict.
>
>We are considering the probability of other memory requirements, for example
>
>for digital still and video clinical images,
>for predictive imaging (cosmetic/esthetic dentistry, orthognathic
>surgery, orthodontics etc.),
>for scanning in older but still "current" radiographs that were required, and
>for histopathology images as part of a histopathology report
>
>Also, we were wondering about post-processed radiographic images. The
>consideration here was that images would be stored as captured, i.e.
>native. OM Radiology might post-process images to optimize them and
>store these as the working images. At first we thought that any other
>post-processing that was carried out anywhere else in the college
>would not be stored on the central server, as this would quickly add
>up to a large volume of space (what with the likelihood that no one
>would ever remove an image). We had thought that these images would
>be stored on the departments own computers (to discourage excessive
>storage of every nuance of change). However, the new HIPAA (Health
>Insurance Portability and Accountability Act) mandates electronic
>security, and this would, probably be a violation of HIPAA. How are
>you dealing with post-proceesed images versus native images.
>
>Rgds
>Axel
>
>
>
>>Axel,
>>
>>As a rule of thumb:
>>- intra-oral images are 300 - 400 KB (depending on the make of the sensor)
>>- extra-oral images are 4 - 6 MB (same).
>>
>>Mulptiply the anticipated yearly "production" with the file size for each
>>image type and you get the storage space you need. These numbers do not take
>>file compression into account, but a lossless file compression will buy you
>>only 30% extra at the most.
>>We installed storage space for what we think is required over a period of
>3-4
>>years, although x-rays have to be kept available longer. The reason is that
>>the costs of disk space is dropping every year. That makes it probably more
>>cost effective to buy additional dik space after a few years, than buying a
>>system that is large enough for many years straight from the beginning.
>>Other things to consider are:
>>- were is the patient management database located (requires storage space as
>>well, but preferably not on the same disk as the images)?
>>- do you want to include intra-oral video images as well?
>>- how is the optimum performance of the database engine (sometimes the
>>performance drops when the disk is full over a critical threshold)? This is
>>something you IT(database) people can tell you.
>>
>>I hope this helps.
>>
>>Best regards,
>>Paul
>>- - - - - - - - - - - - - - Original Message - - - - - - - - - - - - - -
>>On Thu Sep 20 14:11:43 2001,
>>"Axel Ruprecht" <ruprecht at BLUE.WEEG.UIOWA.EDU> wrote:
>> >Hello
>> >
>> >For those of you out there who are using digital radiography systems
>> >for general clinical purposes, could you please tell me how much
>> >memory, on average, you have allocated per patient, per year for
>> >storage of the digital radiographs that are made?
>> >
>> >I ask, on average, because , of course, this will vary from year to
>> >year, but for any given time frame there must be some plan as to how
>> >much memory is needed. we are looking at what we would need, were we
>> >to proceed.
>> >
>> >Thank you.
>> >
>> >Rgds
>> >Axel
>> >*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>> >
>> >Axel Ruprecht D.D.S., M.Sc.D., F.R.C.D.(C)
>> >Professor and Director of Oral and Maxillofacial Radiology
>> >Professor of Radiology
>> >Professor of Anatomy and Cell Biology
>> >
>> >  (O) 319-335-7341
>> >  (FAX) 319-335-7351
>> >
>> >  e-mail:axel-ruprecht at uiowa.edu
>> >
>> >  mail: University of Iowa - DSB
>> >           Iowa City  IA 52242-1001
>> >
>> >Web: http://ruprecht.radiology.uiowa.edu
>> >
>> >The only man who ever got all his work
>> >done by Friday was Robinson Crusoe.
>> >
>> >*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>> >
>>
>>- - - - - - - - - - - - End of Original Message - - - - - - - - - - - -
>
>*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>
>Axel Ruprecht D.D.S., M.Sc.D., F.R.C.D.(C)
>Professor and Director of Oral and Maxillofacial Radiology
>Professor of Radiology
>Professor of Anatomy and Cell Biology
>
>  (O) 319-335-7341
>  (FAX) 319-335-7351
>
>  e-mail:axel-ruprecht at uiowa.edu
>
>  mail: University of Iowa - DSB
>           Iowa City  IA 52242-1001
>
>Web: http://ruprecht.radiology.uiowa.edu
>
>The only man who ever got all his work
>done by Friday was Robinson Crusoe.
>
>*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>

- - - - - - - - - - - - End of Original Message - - - - - - - - - - - -



More information about the Oradlist mailing list