The issue with the ProtocolSliceNumber is described here.
  https://crnl.readthedocs.io/stc/index.html

The scans were specified on the console with reversed slice numbering. This only impacts how slices are ordered in the 2D mosaic, not how images are acquired. I would urge you to heed Siemens warnings on acquiring data this way. While I assume dcm2niix works correctly, I have not tested all the possible edge cases. You will want to rigorously evaluate the data to ensure it is correct. The big fear is that the slice timing numbers might be reversed or the diffusion gradients reversed.

For MRI image processing, we are only concerned with 3D scans, in general the 2D scans are localizers that are used to plan subsequent scans. I always use the dcm2niix -i y to ignore these scans.