It's acceptable to use the nearest key frame when randomly accessing arbitrary frames.
The real problem is that you'd have to rewrite the entire app stack to use H.264 or AV1 for storing the image stack generated by CT.
CT images are 16-bit monochrome, and the pixel values have real physical meaning (Hounsfield Units). So you'd have to prove that your compression tool can reproduce the original images 1:1. The H.264 encoder would also need to be modified to support 16-bit pixels.
And you'd need to modify the post-processing tools to accept your new file format. Otherwise users will still have to convert it back to DICOM or some other commonly accepted format before they can use their post-processing software.
So unless you're a CT vendor, you'll have a hard time pushing this into a hospital.
The real problem is that you'd have to rewrite the entire app stack to use H.264 or AV1 for storing the image stack generated by CT.
CT images are 16-bit monochrome, and the pixel values have real physical meaning (Hounsfield Units). So you'd have to prove that your compression tool can reproduce the original images 1:1. The H.264 encoder would also need to be modified to support 16-bit pixels.
And you'd need to modify the post-processing tools to accept your new file format. Otherwise users will still have to convert it back to DICOM or some other commonly accepted format before they can use their post-processing software.
So unless you're a CT vendor, you'll have a hard time pushing this into a hospital.