Stay away from DICOM RT structure sets. Until very recently, the only option to specify concavities (holes in the intersection) was to use the keyhole technique. Since many faulty, non-DICOM compliant software implementations started to appear in the last few years (which did not use the keyhole technique but used traditional computer graphics method of combining contours with XOR operation), vendors stepped in and added a supplement that allows imaging vendors to explicitly state that they used keyhole technique and a separate contour type for software that cannot generate keyholes. (Note that neither the keyhole, nor the XOR technique relies on polygon winding direction, so you would not need to worry about clockwise direction.) Of course most software developers are still not aware that they were not standard compliant and that they would need to specify a different contour type if they use XOR technique. Another issue is that contours can only be generated reliably for simple shapes (typically hand drawn by clinicians), and not for arbitrarily complex intersections generated by reslicing images. What is even worse, reconstructing of 3D surfaces from parallel contours is not a well defined operation either. Therefore, RTSTRUCTs are really problematic: it is practically impossible to implement an accurate reader and writer that works well with multiple software applications. There is significant difference between even how clinical radiation therapy systems generate and interpret the parallel contours (see this recent paper).
In case you are forced to use RT structure sets (because for example you need to inject segmentation into a radiation treatment planning software) then don’t even think about implementing yet another limited, broken exporter, but choose one of the many existing implementations. We got a big grant about a decade ago to implement RT support in 3D Slicer: we spent 5 years implementing an importer, which has become quite good in the end (tested on tens of thousands of images by many users, which probably brought out most of the limitations and they are all quite reasonable); and integrated the DICOM exporter of Plastimatch library, which we don’t get too many complaints for either. So, one option is to use these algorithms in 3D Slicer/SlicerRT. If you don’t need a solution that works for a wide variety of contours (or you can manually verify all imports and exports and can correct them manually as needed), then you can do a google search and choose one of the many simplified implementations (mostly in Python). Although these implementations often have many serious limitations and not thoroughly validated, but they might work for your specific use case.
If you you just need a way to store segmentations (binary masks) in DICOM then the best information object for that is DICOM Segmentation Object. It allows lossless, unambiguous storage of segmentations. Reading/writing this information object is not trivial either because unfortunately the file format uses a complicated bit packing algorithm. But the difference compared to RT structure set is that there is a consensus among software developers of various packages of how to handle Segmentation Objects and there are a few well-tested implementations (for example in DCMQI library, which is very widely used in the research community).