Exchanging the pixel_array for a DICOM RT Dose file - values change - pydicom

I have a DICOM RT Dose file that I want to change the original pixel_array with a new one. The problem is that when I give a certain pixel its new value, somewhere in the process it changes randomly. The block of code for the exchange is given below. I do the exchange one pixel at a time only to check where the problem is, so I know it can be done much faster:

print pixel_arrayFLK[86][85][78]
print dosem.pixel_array[86][85][78]
for a in range(zBinsTPS):
    for b in range(yBinsTPS):
        for c in range(xBinsTPS):
            dosem.pixel_array[a][b][c] = pixel_arrayFLK[a][b][c]
            if a == 86 and b == 85 and c == 78:
                print dosem.pixel_array[a][b][c]
                print pixel_arrayFLK[a][b][c]

The original pixel_array is the dosem.pixel_array and new one is the pixel_arrayFLK. As an example of what happens:

pixel_arrayFLK[86][85][78] has the value 65813. The original dosem.pixel_array[86][85][78] has the value 62947. After the exchange pixel_arrayFLK[86][85][78] still has the value 65813 whereas dosem.pixel_array[86][85][78] suddenly now has the value 277.

Print functions yield:

However, if I divide all the values of pixel_arrayFLK by 2, the exchange works fine. I really do not understand what's happening. Does it maybe has something to do with the data type in the DICOM file? Some more information contained in the DICOM:

(0028, 0002) Samples per Pixel                   US: 1
(0028, 0004) Photometric Interpretation          CS: 'MONOCHROME2'
(0028, 0100) Bits Allocated                      US: 16
(0028, 0101) Bits Stored                         US: 16
(0028, 0102) High Bit                            US: 15
(0028, 0103) Pixel Representation                US: 0
(7fe0, 0010) Pixel Data                          OW or OB: Array of 6750000 bytes

I have another DICOM file where the Bits Allocated = 32, Bits Stored = 32 and High Bit = 31. The pixel_array exchange in this file works seemingly fine.

Solution

Figured it out. As the bits are 16, the maximum value is 65536, where 65813 overrides this value by 277, and therefore start at 0.