The reason many popular tools (dcm2nii, dcm2niix, Osirix, etc) can not view or convert this image is that it is in fact in violation of the DICOM standard. Specifically, it stores an image icon as uncompressed data but reports a compressed image transfer syntax.
 http://forum.dcmtk.org/viewtopic.php?p=7162&sid=3b516cc751aae51fbb5e73184abe37c2
I suspect these images were originally handled by a PACS system with the GE GEIIS software that contained this bug. However, the images were later anonymized by Offis DCMTK which removed the GEIIS tag (0029, 0010) that I use to detect these buggy images. Another possible reason for this is that the images were compressed using dcmcjpeg and that tool did not properly handle the icon image.

If you go to the dcm2niix github page you can find a new build of my software (25Nov2016) that can handle your images. Hopefully my kludge for fixing your broken images does not have any unintended consequences for handling correct DICOM images. 

In general, I would discourage including icons in your images - the resulting files require more disk space. I would also generally discourage saving your images using the 1.2.840.10008.1.2.4.70 lossless compression transfer syntax. This is an old, inefficient compression algorithm that is unique to DICOM. Some vendors also misinterpreted the format and generated incorrect Huffman tables. Long story short, this format will be inferior to saving your images uncompressed and then using a conventional file compression format (gz, zip) and may well hurt your ability to handle these images with many tools. More details here: 
https://www.nitrc.org/plugins/mwiki/inde...