Just some quick notes on this,
DCM, the file format itself, is structured so that the leading header data contains this kind of information (segmentation, gantry position of the modality and patient relevance, demographic data, etc). In a multi-image exam, each image header contains a copy of this, along with series information and the position of each image in the overall case. In order to "create" new data inside of that header information, you will need a DICOM UID to indicate that the image of diagnostic reference has changed, and that your software is the new owner.
Here is a link to a quick explanation about DICOM UIDs.
If you don't want to actually change the raw image file, an easier solution is probably to store a secondary file with overlays and edits in it, which references the original file (these are always unique like : '1.2.156.14702.1.3.1.1.20102111224490.dcm'). Yes, overlays are ok as long as your image quality is provably not degraded (DCMTK has modules for image validation, as does the
DVTk project), and as long as you have a way to turn them on and off. Print preview shouldn't be a problem if you already have a way to get the raw bitmap correctly from each DCM, but to print to an actual DICOM Printer will require the actual header data in each file to change (to reflect your software's edits). I suppose you could dummy one up, or use the DCMTK one as noted
here .
You never, ever, want to disturb the actual bitmap (pixeldata) itself. Even in
reconstruction a new series is created for composites. Only the header, and only using globally Unique UIDs if you want to avoid collisions.
Last note is that if you haven't stumbled onto
The medical image format FAQ yet, I highly recommend it.
Hope that helps