PARTY.reverse_relationships should better be a Set<PARTY_REF> ?


Would that be better if PARTY.reverse_relationships would be a Set<PARTY_REF> instead of Set<LOCATABLE_REF> ?
Relationships as defined in specifications are always going to be between PARTY objects; furthermore 'path' property of LOCATABLE_REF will never be used in this context.
In the reverse_relationship case the actual kind of reference should be via the use of OBJECT_VERSION_IDs to denote the exact Version of the source PARTY, rather than HIER_OBJECT_IDs.




Sebastian Iancu
August 31, 2017, 2:37 PM

Any new comment or impression about this?
Should this be removed?

Sebastian Iancu
April 25, 2018, 7:45 PM

To review what is suggested to be done:

  • transform this 'reverse_relationships' attribute into a function, as it is rather a 'derived' information

  • keep the 'relationships' as attribute, but should be fixed in 1.0.3/latest to LIST<PARTY_RELATIONSHIP>

  • description of these two attributes/functions should be corrected by changing 'role' to 'party' (see "Relationships in which this role takes part as source.")

  • description of 'reverse_relationship' should be changed to be clear that the refs are of the PARTY_RELATIONSHIP and not of the involved PARTYs (see comments above)

  • LOCATABLE_REF.as_uri() should be relaxed to accommodate non-ehr uri schema

Bjørn Næss
April 26, 2018, 6:24 AM

I have no strong opinions on this. The suggested changs seems reasonable. I will accept them.

Thomas Beale
November 6, 2018, 12:38 PM

Can you check in your implementations if PARTY.reverse_relationships is in fact a List<LOCATABLE_REF> and in there are any problems with it?

(Create new CR for fixing LOCATABLE_REF.as_uri())

Sebastian Iancu
November 6, 2018, 12:57 PM

and were created, things that should be still addressed in a new CR is :

  • transform this 'reverse_relationships' attribute into a function, as it is rather a 'derived' information


Sebastian Iancu




Affects versions