With the current architecture this is not possible. The internal class, that does the actual sending, is
DicomServiceUser. The class DicomClient encapsulates this.
There are some difficulties when I read your approach. For example when an association is requested then DICOM defines that the store SCU has to list all AbstractSyntaxes (SOP Class UIDs) that the client will send and the store SCP returns as AssociationAccept wich of these the SCP will accept and wich it will reject.
In your scenario when observing the folder you would have to know in advance which types of images will arrive in your folder. Do you really know this?
I would anyway not recommend to keep an association open without knowing then to send next images. You might block the server.
If the file happen to appear fast (several files per second) you can avoid the overhead of creating a new association per file by collectiont the files into a internal List of filenames and start a timer that every x seconds (or minutes) sends all the files collected in that list within one association and then clears the list. If the files appear slow (a file every several seconds or even minutes) then don't mind to create separate associations. Would that work for your scenario?