On-Demand could be implemented simply by leveraging the relaxed cardionality, or by using the values that IHE defines for on-demand. The important part is that the URL given in the DocumentReference when a GET is done would cause the document to be created. This is the non-REST part. Once it is created 'on-demand' then that set of bits could be saved to a REST server, with a new DocumentReference that has a relatesTo that points at the original on-demand with the same metadata but the new URL, hash, and size.
Most clients won't notice any difference between a static or on-demand. They would tend to process all the other metadata elements for either query-parameters, or to filter results. They would tend to just pull the URL. And they tend to never check the size or hash. The checking of size and hash is there as a method to protect against integrity failures that result from the distributed architecture XDS provides. When there is not N repositories that are distributed broadly, there is little reason for size/hash.
I didn't include on-demand nor deferred-creation in MHD as we need first experience with static document entries. Please inform IHE of your interest in on-demand. Experience will be helpful to improvements.
Clearly relatesTo needs new relationships (snapshot), and there might need other indicators of on-demand vs deferred-creation. Future improvements that I am happy to do based on experience and use (80%).