Dealing with medical CDs: Images, reports, or both?

By Herman Oosterwijk, contributing writer

June 20, 2018 -- When I visit my specialist, I always bring my own laptop with my diagnostic studies and reports preloaded and a DICOM viewer to review them. I learned my lesson, as I found that most practitioners don't have access to the images, and if I bring them my CDs, they have no privileges to download a viewer to look at the images or their laptops don't have CD readers anymore.

The standard still seems to be the fax machine for distributing reports and other related information. I even have seen faxes used inside a hospital between the CT room and radiology for any paperwork that might be important.

Herman Oosterwijk
Herman Oosterwijk of OTech.

With regard to CDs, just as I do myself, it appears that exchange is mostly facilitated by patients carrying their own media. Even though it is technically correct (according to the DICOM standard) to use a variety of media (flash drives, cards, DVDs, and CDs), the CD is by far the most common physical medium. Occasionally, one might use a DVD for very large studies such as for cardiology, angiography, or breast tomosynthesis.

It would be more efficient and easier if the report and other information could be incorporated with the images on the CD. This would allow a patient to carry all of the information in one package. As I asked around, this is apparently not that common, mostly because of workflow limitations, i.e., the report is simply not (yet) available at the time the CD is created.

And, as the CD exchange standard was originally defined by the DICOM standardization committee and further refined by the Integrating the Healthcare Enterprise (IHE) committee, its emphasis has been on medical imaging content and not on report exchange. But, in practice, some of the CDs also contain documents in various formats, especially if the intended audience is referring physicians.

Let's look at some of the use cases.

1. Where are these media being created and consumed?

These media can be created at the following:

  1. The acquisition modality -- for example, a CT or MR console or even a quality assurance (QA) station of a computed radiography (CR) device, and it is typically done by the technologist. This is very common if the study is performed at a small, freestanding clinic or imaging center. The media could contain images and potentially scanned-in documents in DICOM format.
  2. A PACS console
  3. An independent, freestanding workstation
  4. A third-party CD burner station

Because of the workflow limitations, the media created at the modality (scenario A) do not typically include reports, while the other locations (scenarios B, C, and D) could include reports and/or other documents.

The media are read/imported by the following people:

  1. File room clerk or assistant
  2. PACS or system administrator
  3. Radiologist at his/her PACS or independent workstation
  4. Physician/specialist looking at the result of a study

Note that images, reports, and/or other documents are all important. However, in practice, only the radiologist and some specialists will look at the images; the referring physicians would typically only be interested in the report. But the primary source for reports would not be these exchange media for those referrals, as they are typically faxed or sent electronically.

2. What does the standard say about nonimages on exchange media?

The formatting of information on exchange media was standardized by DICOM as part of the original 1993 release (parts 10, 11, and 12).1 To address the many issues with incompatibilities, IHE subsequently defined a profile called Portable Data for Imaging, or PDI, that highlights the DICOM requirements for successful exchange.2

The PDI profile specifies the following:

The imaging information placed on the media by the creator can include medical images (CT, MRI, ultrasound, angiography, etc.) and associated DICOM objects such as encapsulated diagnostic reports, measurements, dose records, and clinical application results.

The media must include diagnostic data in DICOM format, which is thus suitable for import for further viewing, processing, and archival.

The media may include optional "web-viewable" copies of the information, suitable for viewing in a browser (e.g., HTML versions of the reports and JPEG versions of the DICOM images).

The media may also include an optional DICOM Viewer program for receivers who do not have access to a PACS where the images can be imported, or to a workstation on which they can load their preferred DICOM viewer.

As stated in the first and second points, the information should be in the DICOM medical imaging format; in case the source data are text or some other standard format such as PDF, the data are expected to be encapsulated as a DICOM object, i.e., the information has a DICOM "wrapper" or "envelope" so that it can be handled by the DICOM infrastructure as provided by a PACS. As stated in the third point, there is also a possibility to store "web-viewable" copies such as HTML or JPEGs for images.

The storage of non-DICOM and/or nonweb-viewable data is also addressed in the IHE PDI profile:3

Additional data (e.g., a diagnostic report in non-DICOM format) also may be included on the media. Since the format of any such data is not specified by this profile, such data shall be placed in a separate directory on the media. If such data is referenced in the INDEX.HTM file, it shall be clearly indicated that this content was not generated in conformance with the IHE Radiology Technical Framework, and its reliable import has not been addressed.

The so-called "additional data" can be in any format, such as Microsoft Word files, PDFs, RTF, .txt files, etc. Note, however, that most reports are being exchanged in a networked environment using the HL7 Version 2 standard formatting. These HL7 messages or transactions don't lend themselves for media exchange and/or permanent storage, even though the actual text is stored in the "body" of the transaction. This was supposed to be addressed by HL7 Version 3, which has culminated in the definition of a document standard called CDA or CCD. One could exchange a CDA/CCD with an imaging CD, but limitations on the receiver side create a slim chance that these can be interpreted.

So, in conclusion, yes, text and other document formats are allowed by the PDI profile.

3. What is used in practice?

Text documents are commonly encountered on CDs. Here is feedback from two heavy-duty CD consumers, which is most likely representative of what happens in the real world.

Mayo Clinic in Rochester, MN:4

As a quick summary, having the outside reports together with the outside images in a natural, easy-to-view way is of great interest to our providers. Today we ingest the images from CDs that we receive, but do not try to find/resolve if there are reports on the CD, and if so which report goes with which set of images.

Looking at a sample of CDs that we received: Around 10% to 20% of CDs within our sample set (just one day, October 25, 2016) had some sort of non-DICOM report-like information on the CD. There was a good mix of document types but the most common was some sort of HTML document.

Rich text, plain text, and PDF (not DICOM-encapsulated) documents were also found. Among the different document types, it seems every CD burner software suite had its own unique way of encoding the report data. There was very little convergence. It seemed that no matter how we refined our search we ended up with some number of false positives mixed in. Most of the false positives were either diagnostic reports of some other nature (e.g., blood work) or keywords and a structure like a report but with boilerplate text still intact. The only potential linking mechanism in the reports themselves was a study date or accession number, and even those were not always reliable.

In another sample, we ran a query for DICOM SR objects that were included with the images on the CDs, and about 12.5% of our sample (of a portion of the CDs received from December 2015 through May 2017) had a DICOM SR object of some kind. We didn't interrogate them to know with certainty whether the SRs contained radiology report information (as opposed to dose information, or perhaps some auto-generated measurements).

In general, most of the hospitals we work with either fax a report or otherwise send the report with the rest of the patient data. In most cases these reports end up in our document management system.

When we create CDs to send, we would like to include the report for each study in two formats: DICOM SR and DICOM Secondary Capture (SC). Both are standards-based, and both tie the study information together, so for DICOM viewers that support SC and/or SR, they will associate the correct report with the correct image set and don't require any special logic or functionality to do so. However, as of now, we are only including SC due to limitations from some of our CD/DVD burners that do not support SR.

Minneapolis Veterans Affairs (VA) Medical Center:5

We encounter CDs with reports (usually .pdf format) on them for about 20% of our CDs. For the other 80%, we either receive a paper copy, or they need to contact the facility and request a faxed copy of the reports. We usually print the reports (from the CD) and scan them into PACS via our paper scanners. They go into PACS as a .dcm file and merge with the actual DICOM images.

We have also had them automatically import into our PACS as .pdf. Our PACS can handle this format, but our enterprise vendor-neutral archive can't. So ... we have been known to print them from the PACS, then delete and reimport as a DICOM image via the paper scanners.

4. What do vendors support?

Most of the third-party CD management vendors state that they support documents based on a sample of their websites (there are five to six major players in this market).

5. Why do we even talk about this?

It appears that CDs can be effectively used not only for images but also for reports. Their use case is somewhat limited as in many cases -- i.e., the typical imaging center scenario -- the patient wants to take the CD right after the exam, before a report is available.

From my own experience, which I believe is typical for a patient/consumer, the images are much more valuable than the report as the reports are pretty much unreadable for any nonclinical person. As soon as my specialist brings up the images on (my) laptop, I can see what they are talking about. However, for physician-to-physician communication, the report seems to be the most common means of communication.

Based on this limited poll, which is anecdotal but I think a pretty good representation of the real world, it appears that managing reports is a real pain point and there is no good "standard" way. There are limitations at the PACS (no PDF support) and at the CD burners (no SR support), and some institutions use a document management system for reports (Mayo) and some use the PACS (VA).

6. What does the future have in store?

Patients will increasingly take control and provide access to their own information, whether it is images and/or reports. The Department of Veterans Affairs hospitals have announced they will make all images available to patients through their portal. This will eliminate the need to carry CDs around. And I assume that the reports will be available as well.

There will be an increase in the use of image-sharing services, either by the use of cloud or broker solutions. Mayo has been able to reduce the number of CDs it receives by 35% so far using this solution.

Health information exchanges (HIEs) might become more popular, either through a private or public exchange. While image exchange seems to be on the bottom of their priority list, at least they could get rid of their fax machines.

Where will documents be managed? I believe that the PACS and/or vendor-neutral archive (VNA) is not the right place; instead, a document management system that has a Fast Healthcare Interoperability Resources (FHIR) "document" resource, which can easily be accessed from the PACS workstation and an electronic medical record (EMR), seems to be the best architectural solution. However, there are still questions and concerns regarding the immature standard based on FHIR, and there will be many years of short-term solutions that might not be ideal but get the job done.


In conclusion, medical CDs are used for exchanging images, and in 20% of cases, they are also used for reports. Reports seem to have become somewhat of a stepchild as they can have several different formats: some are DICOM-encapsulated (SC, SR, and PDF) and some are not, depending on the limitations of the institution.

Both image and report exchange should become more streamlined; however, how this is going to happen is not quite clear. It can be done by point-to-point exchange, using HIEs, having FHIR-based resources available through the web, having the patient take care of it, or all of the above.

In the meantime, I make sure I keep all of my (and my family's) clinical information with me as I know that the world of healthcare is still not as connected as it could and should be.


  1. Current edition. DICOM Standard website. Accessed June 19, 2018.
  2. Portable Data for Imaging. IHE Wiki website. Accessed June 19, 2018.
  3. IHE_RAD_TF_Vol1.pdf Rev. 15.0 -- Final Text 2016-07-29, p. 173.
  4. Mayo Source: Ken Persons (enterprise imaging IT architect), Scott Penick (senior analyst/programmer), Arlen Forsch.
  5. VA Source: Rachel McGuire (PACS administrator).

Herman Oosterwijk is a trainer/consultant on PACS, IHE, DICOM, HL7, and FHIR. He can be reached through his website,, where you can also find information about upcoming training and online education on these topics.

The comments and observations expressed are those of the author and do not necessarily reflect the opinions of

Copyright © 2018

To read this and get access to all of the exclusive content on create a free account or sign-in now.

Member Sign In:
MemberID or Email Address:  
Do you have a password?
No, I want a free membership.
Yes, I have a password:  
Forgot your password?
Sign in using your social networking account:
Sign in using your social networking