By Tim Kaschinske

This is the third blog in a series focusing on how healthcare organizations are dealing with unprecedented volumes of unstructured data and how this impacts the holistic view of the patient’s data. My first blog addressed the challenges this new data phenomena presents; the second discussed how one organization, the IHE (Integrating the Healthcare Enterprise), is working to resolve these issues.

In this blog, I will examine additional problems with unstructured data that exist where integration is relatively well defined in clinical environments such as radiology and oncology.

Radiology Scheduled Work Flow

Let’s start with one of the more successful IHE integration profiles, the radiology scheduled work flow (SWF).   The SWF integration profile defines how information is exchanged between different systems in the process of ordering, acquiring, reading and reporting on a radiology imaging procedure.  Many radiology departments are successfully using the transactions defined by SWF to exchange data for radiology procedures.

Even in this well-defined environment, problems still exist for data exchange.  Three examples that I’ve encountered at hospitals are:

  • Scanned Documents during Admission
  • Scanned Patient Histories
  • Radiology Reports

Scanned Documents during Admission

When a patient presents at the hospital for a radiology procedure, they go through the admitting process.  This process often involves the patient providing a photo ID to ensure proper patient identification, and/or an insurance card for proper billing.  These are scanned to digital images and are stored in the Hospital Information System (HIS).  While the HIS does broadcast the patient information to other systems with an HL7 ADT message, the scanned images themselves are not available to other systems.  Could the photo ID of the patient help ensure that the correct patient data is selected at the imaging modality, or within the PACS?  For example, the patient for a radiology procedure is usually selected from a work list, but what if there are two patients with a common name?  The photo ID could help to ensure that the correct patient is selected from the work list.

Scanned Patient Histories

Prior to the radiology procedure, a document will be filled out to capture the patient history.  It is important to know details such as whether the patient is pregnant before performing a radiology procedure.  At many sites, this information is initially captured on paper.  In order to make the patient history available to the radiologist when reading the images, sites will often scan the document as a JPEG image, and then use software associated with the scanner to “wrap” the JPEG image with a DICOM header so that it is associated with the imaging study in DICOM.  This process is known as “DICOM-wrapping” and is widely used to make data available to the radiologist as part of the radiology study in PACS.

While this process works for its intended purpose, some questions arise with regard to the access of this patient data. If, for example, you wanted to compare the different histories from multiple radiology procedures, how would you do that?  How could you search the history for individual values?  Since the history is a scanned image, you could not search the histories for the different medications that a patient has taken.  Also, this process works today for the radiologist who knows how to access the radiology procedure in PACS, but how does the referring physician access this data? Or another department?

The good news is that Electronic Medical Record systems are solving this problem, making the patient history available to all that need it.  But what about all the legacy patient history data stored as images in PACS?  How would that be imported into the EMR?

Radiology Reports

As we’ve mentioned, much of the work flow surrounding the radiology procedure is defined by IHE and works well.  There are some problem areas, however, specifically related to the radiology report.  In almost all environments the reports are stored in the Radiology Information System, RIS, and the images are stored in the PACS.  Most sites use an identifier called the “accession number” to link the report to the images.  The accession number is communicated using an HL7 order message (ORM) to all systems that need it, including PACS.

The problem occurs when you want to view both the report and the images together.  How does PACS get a copy of the report?  IHE defines this transaction using a DICOM Structured Report.  The problem with this is that very few Radiology Information Systems support DICOM Structured Reports.  Almost all Radiology Information Systems distribute the report using an HL7 ORU message.  If the PACS does not support the HL7 ORU message, how can it display the report to the radiologist?

Other solutions have included the use of desktop integration, where two applications are coordinated to display data for the same patient.  When the radiologist brings up the study for the patient in PACS, the accession number is used to display the report in the RIS.  Also, many EMR systems provide ways of viewing both the images and the report by having a link to the radiology report in the RIS, and a link to the images in PACS.  The physicians click on these links to view both the images and the report.  Because there is no standard way to integrate the viewing of the radiology report along with the images, different applications provide different methods to solve the problem.  As long as all of the applications support the chosen solution, everything works fine.  What happens when a new or replacement application is introduced that does not support the chosen solution?  A new solution to viewing reports and images must be implemented, often resulting in the disruption of the clinical work flow.


Another example environment is Oncology where there are many different applications, some that support DICOM for images and some that don’t support DICOM.  Even among those that support DICOM, there are issues.

Oncology clinics will often have multiple treatment planning stations, used by different personnel to plan the treatment of different types of cancer.  These treatment planning stations are from multiple vendors.  They all support DICOM, but they often have different methods of archiving data, making it difficult to have a central archive.  Patients will sometimes have different treatment plans on different treatment planning stations.  In this environment, how do you answer the following questions?

  • What treatment plans have been created for a patient?
  • When were these plans created?
  • What treatment stations generated these plans?
  • What happens when a treatment station is retired?  Where does its data go?
  • How does the treatment team obtain a complete view of the patients’ plan and history?

There are also applications in Oncology that do not support DICOM images.  For example, a skin cancer treatment planning station may use photographs stored in JPEG.  The patient data is not stored as part of the JPEG image, as it is in DICOM.  Often these JPEG images are contained within a folder that has the patient ID as the folder name.  The patient ID folders also contain the treatment plans and any reports in addition to the photographs in JPEG.  There are similar difficulties answering the same questions we saw for the DICOM treatment planning stations, but it is complicated further by the different data format, applications, and ways of identifying a patient.

You might ask: Why not store the JPEG images in DICOM?  The application that generates this data often does not support DICOM, resulting in another application being added to the environment to perform DICOM wrapping and to store and retrieve the data in DICOM.  This adds overhead, slows down the process, and as a result does not provide sufficient benefit to support the costs and overhead.

These examples illustrate the problems accessing patient data in only two departments, radiology and oncology.  There are many other departments, such as pathology, laboratory, dermatology and surgery, each of which are managing patient data that is often inaccessible outside of its primary use.  Healthcare is clearly in need of a solution that provides a standard method to consolidate and make patient data accessible wherever it is needed.

As difficult as all these problems are, so far we have assumed that we have correctly identified the patient.  In my next blog I will examine problems related to patient identification.

Read the first two blogs in the series:

Much Ado About Unstructured Data;

IHE, Hard at Work Solving Healthcare’s Big Data Dilemma

Download the BridgeHead whitepaper: VNA Does Not Equal Image Availability: What You Need to Know