Taking this thread in a slightly different direction, part of the original problem is that we are often asked to refer to external parties in various parts of the data model without any gurantee that we can resolve these to an actual demographic service entity.
This often involved slotting in cluster pseudo-demographic slots and associated clusters which is ugly and confusing for newbies.
However, I have re-visiting the existing palaces that PARTY_PROXY appears in an ENTRY and I think a couple of adjustments might solve a lot of the issues.
A major gap in PARTY_IDENTIFIED is the lack of an attribute for role/relationship, alongside name and identifier, as ‘minimal clinically useful info’ where a full hookup to a demographics service is not possible or needed. However PARTY_RELATIONSHIP does support that, albeit that it requires a coded_text.
Should PARTY_IDENTIFIED by extended with a new relationship/role attribute (DV_TEXT) or should we make use of PARTY_RELTIONSHIP to include professional relationships as well as personal.
The other addition would be to add an other_details structure to PARTY_IDENTIFIED. In particular it opens up the use of other_participants to carry those snippets of contact number, address, org details that integration often forces upon us.
add relationship 0…* to PARTY_IDENTIFIED (or widen scope of PARTY_RELATIONSHIP)
add other_details to PARTY_IDENTIFIED.