In that case, the RM already does what is needed, by the use of PARTY_IDENTIFIED (and PARTY_RELATED if you want it) in other_participants on any ENTRY, or as subject of other ENTRYs, and anywhere else PARTY_PROXY is allowed.
That can be true. In pursuing a ‘proper’ solution, I am not advocating creating an MPI. But it’s certainly possible to create a EHR demographic cache within the EHR system, for use by all the EHRs there. With that, everytime you want to record a reference to some ‘Dr Sue Jones’, you create the appropriate PERSON object in the demographic cache (first time) or else just a reference to that object (every subsequent time some EHR needs to mention Dr Sue Jones). The EHR demographic cache is versioned, same as the EHRs, so references point to the version of each demographic entity extant at the time. Later modifications create later versions, and later references will correctly point to those later versions.
With this solution, you get proper archetyped PARTYs, proper versioning, and an already existing model of contracts, addresses, capabilities etc. There’s no difficult engineering here, especially if the cache ignores PARTY_RELATIONSHIPs, and just records PARTYs.
Well we already have the solution: the demographic model - I think it already does everything needed (we can certainly add things if needed, but it mostly relies on archetyping anyway).
We already have quite a few archetypes based on the demographic model as well - so we might be in danger of a proliferation here. I wonder if the best way forward is to compare these newer archetypes, and update the demographic model archetypes (based on PARTY, PERSON etc) with any new details needed.
I certainly see where you are coming from w.r.t. current needs, but looking at it from a systems perspective (i.e. what do installed solutions and data look like), I would say the EHR demographic cache is the simplest and cleanest solution.