Burned-In Text in DICOM: Ultrasound and Secondary Captures

A clean header does not help when a reviewer opens a de-identified ultrasound study and finds the patient's name and date of birth printed across the top of every frame. That protected health information (PHI) is burned in, meaning it was written into the pixel values when the image was captured. Header cleaning never touches it, and neither does a check that reads only the header. Burned-in text in DICOM (Digital Imaging and Communications in Medicine) files concentrates in a few kinds of image, and knowing which ones is where finding it starts.

Our guide to DICOM de-identification maps the other places identifiers sit in a study, from header tags to private vendor fields, and the pixels are the one surface a header dump cannot show you.

Where burned-in text appears in DICOM images

Burned-in text shows up wherever an image was captured from a screen or a video signal instead of being produced directly by the scanner, and wherever the image is text to begin with. The standard draws the contrast between computed tomography (CT) and ultrasound itself, noting in PS3.15 that "CT images do not normally contain such burned in annotation, whereas Ultrasound images routinely do."

Every one of these can reach a research or trial release looking like any other image, because nothing in the file forces it to declare the text it carries. A CT series and an ultrasound loop can sit side by side in the same release, and only one of them is likely to show a name.

Why the Burned In Annotation flag cannot be trusted

DICOM does define an attribute for this, Burned In Annotation (0028,0301), which PS3.3 describes as indicating whether the image "contains sufficient burned in annotation to identify the patient and date". In the General Image module it is Type 3, which means optional, and the standard states that "If this Attribute is absent, then the image may or may not contain burned in annotation." A value of NO is only as good as whoever set it, so a de-identification process has to treat every image with pixel data as a possible carrier and look for itself.

Header cleaning misses this text for the reason our guide sets out, since the standard's baseline profile leaves the pixels alone unless a pixel option is chosen. When the Clean Pixel Data Option is applied, the standard expects the de-identifier to add Burned In Annotation with a value of NO. That value then travels with the file as a claim a recipient can read without looking at the pixels. It should only ever be written by a step that actually read and masked every frame.

Read every frame, then decide what is personal

Finding burned-in text starts with reading every frame, because a banner on the first frame of a cine loop sits on the others too and captured screens can differ from frame to frame. Text that changes as the loop plays, such as a running clock, is only caught by reading each frame, since a mask copied forward from the first frame misses whatever appears later. Reading every frame depends on knowing where one frame ends and the next begins, which our article on multi-frame DICOM files explains.

Text on a frame is found the way text on a scanned page is, with optical character recognition (OCR). Labels written along the edge of an image, and captures taken in portrait, showed us that text is not always upright, and a reader that only handles horizontal text passes such labels straight through. The orientation of the text on each frame has to be found before the frame is read, so that a sideways label is read like any other.

Once the text is read it has to be sorted, because most of the text on a medical image is there for the clinician. Orientation markers, laterality labels, exposure settings and measurement annotations make the image interpretable, and blanking them does damage of its own. Dates are where sorting gets hard, since an exam date in the banner is an identifier while the numbers beside it may be depths or velocities. Only the text classified as personal information should be masked, with the rest of the frame left as it was.

A useful test image for any de-identification tool is a chest X-ray with the patient's name burned into one corner, an L or R side marker and a tube voltage (kVp) annotation. After de-identification the name should be gone, while the side marker and the kVp value are still there and readable. On ultrasound the same test should include a measurement, since masking the banner must leave the calibration in the header intact. Our article on DICOM private tags and nested sequences explains where that calibration is stored. How well any tool sorts text depends on the fonts and layouts your devices produce, so the test images tell you most when they come from your own equipment.

Derived copies carry the banner too

Removing the text means changing the stored pixel values rather than covering them, for reasons our article on redacting DICOM pixel data works through along with the choice between solid fill, blur and pixelation. Derived copies need the same treatment, because a thumbnail, a preview or a JPEG export made from an unmasked frame carries the same banner into whatever system receives it. Every rendition that leaves with a study has to be made from the masked frames, and a release checklist should name each one.

Releases to patients, attorneys and payers work differently

Release-of-information teams meet burned-in text from the other side, because a release to a patient, an attorney or a payer is not a de-identification at all. Each receives identified images within its own limits: a patient gets their own record, an attorney usually what the patient's authorization covers, and a payer what HIPAA's minimum necessary standard allows. In all three the patient's name, record number and exam dates stay on the images, and a research profile that stripped them would hand back something the requester cannot use.

What has to go are other people's details, and imaging produces them in predictable places. A worklist screenshot can list the day's other patients, and a dose report or a technologist's screen can be captured with another patient's session still showing. Scanned requisitions and consent forms can end up filed into the wrong study, so a release should never assume that every page belongs to the patient named on the request.

None of those images carries a field that says whose details it holds, so a person has to look at each one before it goes out. Every patient name and record number visible on those images should match the patient named on the request, and another patient's details come off before release. The two kinds of release also need separate settings in whatever tool does the automated pass. A configuration built to remove every name from a research dataset will also remove the one name a patient's request is about.

What still needs a person

Some burned-in text remains hard for any automated approach, and a release plan should say how it handles each case instead of assuming detection took care of it. Text in scripts other than Latin needs recognition built for those scripts, and text that overlaps anatomy is hard to mask without masking the anatomy along with it. Annotations stored as overlay planes or presentation-state graphics usually sit outside the pixel data, so a pixel pass never sees them. Older files can also carry overlays in unused bits of the pixel data itself, a usage PS3.5 has since retired. Faces in clinical photographs saved as DICOM need a different kind of detection altogether.

Human review is the backstop for every one of these cases, and the field's own guidance sets a high bar for it. The Medical Image De-Identification (MIDI) Task Group's report describes the state of the art for checking pixel data as a full check by at least one person who looks at every image on screen. It suggests focusing that effort on the images at greater risk, such as ultrasound and anything the header marks as a secondary capture or screenshot, with the choice backed by a documented risk analysis. Reviewers do that work in the organization's own DICOM viewer, stepping through frames at the several window settings our guide describes.

A reviewer working through a sample has to confirm what left each masked frame as well as what stayed on it. The name, ID and dates should be gone, and burned-in dates and timestamps count among them. Under the Safe Harbor method of the Health Insurance Portability and Accountability Act (HIPAA), a date tied to the patient's care is PHI wherever it is printed. Orientation markers, laterality labels and measurement annotations should still be there and readable.

How Redactor reads and masks each frame

VIDIZMO Redactor reads every frame of a DICOM file for burned-in text, finds the orientation of the text on each frame before reading it, and masks only what its detection classifies as personal information. Each mask is written into the stored pixel values of the output file. The file that comes back is still DICOM, and the banner is gone from the data rather than hidden on screen.

Imaging that travels with scanned charts, trial documents and recordings is covered on Redactor's medical and clinical redaction page.