Well, the point isn’t to punish users, it’s just to avoid truly basic design errors, like uncontrolled copying.
But I think the key thing is to work out the ‘real’ real world requirements for ‘simplified demographics’. The requirements you describe do not sound like those @ian.mcnicoll or @heather.leslie describe in this thread.
In that thread, Heather is talking about proper archetyped demographic structures, but using EHR-based archetypes. If anyone is going to that trouble, they don’t want uncontrolled replication in their system (which really is disastrous, and might even be a patient safety issue). But on the other hand, if the project / product doesn’t support openEHR demographics, then the hack I proposed will solve it, and using those EHR archetypes - the main need for referencing rather than copying is still achieved.
I think we need to be pretty clear on whether it is intended that every time Dr Jane Smith is referenced from the (say) 50k EHRs in some health service, that the EHR recorder has to re-enter all the same data every time, or whether they could search previous entries and just select the Jane Smith already there.
If the need is to represent demographics snapshots in imported data, and this is regarded as unreliable, partial etc, then that may be a different problem - I would say this belongs with the original_content within the FEEDER_AUDIT. But if the situation is that the demographic data needs to be relied upon to be in any way correct, then creating the circumstances for uncontrolled replication isn’t going to help that.
Secondly, if there is the need to replicate the sophistication of the openEHR demographic model using EHR archetypes, that is doable, but it implies that there is control over the creation of that data; if so, it should be in a managed cache that supports references rather than copying, and which is very easy to implement.