# PARTICIPATION needs to be a LOCATABLE **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2008-05-09 10:14 UTC **Views:** 4 **Replies:** 13 **URL:** https://discourse.openehr.org/t/participation-needs-to-be-a-locatable/14749 --- ## Post #1 by @thomas.beale Dear all, the group at Ocean have found that the PARTICIPATION class probably should be LOCATABLE, or act like it is LOCATABLE, because a\) it needs to be archetyped and b\) it occurs as children of 2 container attributes, namely ENTRY\.other\_particpants and EVENT\_CONTEXT\.participations\. The latter fact means that PARTICIPATION objects in archetypes need archetype\_node\_ids to be distinguishable from siblings in these attributes\. Currently, PARTICIPATION is not LOCATABLE or even PATHABLE, but I think it should be\. Making this change will of course have some effect on existing software and schemas\. I am interested in reactions to this idea, and to the impact it would have\. Remember, all changes to the openEHR specifications go into specified releases, so making such a change doesn't 'break' things today \- it is a managed exercise\. \- thomas beale --- ## Post #2 by @system Hi Tom, I agree on the change. Just out of curiosity, do you have any concrete example for archeytped PARTICIPATION? Cheers, Rong --- ## Post #3 by @Tim_Cook2 I fully support PARTICIPATION being LOCATABLE\. \-\-Tim --- ## Post #4 by @system Tim Cook schreef: > I fully support PARTICIPATION being LOCATABLE\. >   Let wisemen decide for me, it does not seem a big problem to implement\. Bert --- ## Post #5 by @system Hi All There is one consequence that is worth considering - I do not think it negative but it must be considered. That is, we must have a participation with an entry in the ontology in order that we can have any PARTICIPATION. So we will, like any-event - need a generic participation to be added to the archetype for all archetypes that we want to have a participation of some kind. My feeling is that we should do this by default and remove it if it is not deemed appropriate (just as any event is removed from APGAR). This will not make current data or archetypes invalid - to do that they would have to make participation existence = 0. Cheers, Sam Tim Cook wrote: --- ## Post #6 by @Tim_Cook2 Hi All, In the context of COMPOSITION\.composer I'd like to continue this discussion a bit\. I still think that PARTICIPATION should be locatable but I am also thinking that every descendant of PARTY\_PROXY should be as well\. How will this affect archetype creation? It just seems to me that there may be use cases for locating all instances of a certain PARTY\.\.\. being responsible for COMPOSITIONS\. Thoughts? Tim --- ## Post #7 by @system Hi Tim Locatable purely means that you can use a path to point to it. Attributes can be contained in a query, so there is no issue with the question you have - and in fact, as composer is a unitary attribute it is pathable. Locatable adds something to the ontology which describes it in some manner - and then there is the possibility of using the path with the name as the differentiator of multiple occurrences of the same node (ie same ontology entry - e.g. at0002 ). The difference between locatable and returned in queries is important and we will need to do some more education about this. It might be good for a Wiki page I guess. I hope this is clear. We are currently able to query all participations - but we cannot point to a specific one using EHR_URI. That is the difference (and due to the fact that these can be multiple) Cheers, Sam Tim Cook wrote: [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #8 by @Tim_Cook2 Hi Sam, > Hi Tim > > Locatable purely means that you can use a path to point to it\. Of course\. > Attributes can be contained in a query, so there is no issue with the > question you have \- and in fact, as composer is a unitary attribute it > is pathable\. COMPOSITION\.composer is unitary but\.\.\.\. it is not a specific class\. It is listed as one of several subclasses of PARTY\_PROXY\. This means that you must be able to first determine which class then introspect that class \(instance\) in implementation\. Since multiple subclasses of PARTY\_PROXY can have lists of identifiers \(PARTY\_IDENTIFIED, PARTY\_RELATED and even the performer attribute of PARTICIPATION\) my thought is that PARTY\_PROXY should be locatable since these instances can occur in so many places and are somewhat unknown between systems\. > Locatable adds something to the ontology which describes it in some > manner \- and then there is the possibility of using the path with the > name as the differentiator of multiple occurrences of the same node > \(ie same ontology entry \- e\.g\. at0002 \)\. Locatable adds the ability to find an instance that contains a specific identifier; correct? Which could be in a list of one of the subclasses of PARTY\_PROXY\. > The difference between locatable and returned in queries is important > and we will need to do some more education about this\. It might be > good for a Wiki page I guess\. Sounds like this may be helpful\. > I hope this is clear\. We are currently able to query all > participations \- but we cannot point to a specific one using EHR\_URI\. > That is the difference \(and due to the fact that these can be > multiple\) I think that this just made my case\. :\-\) PARTY\_SELF is pretty obvious but PARTY\_RELATED is not\. Going to the root of the issue is more future proof than other solutions and it is \(as far as I can see\) without any other costs\. Cheers, Tim [details="(attachments)"] ![Displayemail.gif|1942x29](upload://wvJHHsMMgLmwpg4iINQYKqUoHG8.gif) [/details] --- ## Post #9 by @Heath_Frankel3 Tim, Performer and all other attributes that are of type PARTY\_PROXY are single attributes, not collections\. Therefore there is no need to find a particular occurrence using a node\_id and name\. The whole point of PARTY\_PROXY is that it is a proxy for a real object of type PARTY which is in the demographics repository, this object is a locatable\. The data recorded as part of the PARTY\_IDENTIFED is really just to support legacy environments and is not intended to be used for structured data, hence a name of plain string\. None of this could be consider reliable enough to be used as an identifier of the object\. So if anything, you are looking for a means to resolve the reference of the party proxy and search for the particular PARTY, not the PARTY\_PROXY\. Regards Heath > From: openehr\-implementers\-bounces@openehr\.org \[mailto:openehr-implementers- > bounces@openehr\.org\] On Behalf Of Tim Cook > Sent: Tuesday, 20 May 2008 5:55 AM > To: Sam Heard > Cc: For openEHR implementation discussions > Subject: Re: PARTICIPATION needs to be a LOCATABLE > > Hi Sam, > > > Hi Tim > > > > Locatable purely means that you can use a path to point to it\. > > Of course\. > > > Attributes can be contained in a query, so there is no issue with the > > question you have \- and in fact, as composer is a unitary attribute it > > is pathable\. > > COMPOSITION\.composer is unitary but\.\.\.\. > > it is not a specific class\. It is listed as one of several subclasses of > PARTY\_PROXY\. > > This means that you must be able to first determine which class then > introspect that class \(instance\) in implementation\. > > Since multiple subclasses of PARTY\_PROXY can have lists of identifiers > \(PARTY\_IDENTIFIED, PARTY\_RELATED and even the performer attribute of > PARTICIPATION\) my thought is that PARTY\_PROXY should be locatable since these > instances can occur in so many places and are somewhat unknown between > systems\. > > > Locatable adds something to the ontology which describes it in some > > manner \- and then there is the possibility of using the path with the > > name as the differentiator of multiple occurrences of the same node > > \(ie same ontology entry \- e\.g\. at0002 \)\. > > Locatable adds the ability to find an instance that contains a specific > identifier; correct? Which could be in a list of one of the subclasses of > PARTY\_PROXY\. > > > > > The difference between locatable and returned in queries is important > > and we will need to do some more education about this\. It might be > > good for a Wiki page I guess\. > > Sounds like this may be helpful\. > > > > > I hope this is clear\. We are currently able to query all > > participations \- but we cannot point to a specific one using EHR\_URI\. > > That is the difference \(and due to the fact that these can be > > multiple\) > > I think that this just made my case\. :\-\) PARTY\_SELF is pretty obvious but > PARTY\_RELATED is not\. Going to the root of the issue is more future proof > than other solutions and it is \(as far as I can see\) without any other costs\. --- ## Post #10 by @thomas.beale Tim Cook wrote: > > Locatable adds the ability to find an instance that contains a specific > identifier; correct? Which could be in a list of one of the subclasses > of PARTY\_PROXY\. >   this is correct \- it just happens that there are no 'lists' of PARTY\_PROXY anywhere in the openEHR reference model, so there is never any ambiguity about sibling PARTY\_PROXYs in a list \- any PARTY\_PROXY can only be the sole value of some attribute\. > I think that this just made my case\. :\-\) PARTY\_SELF is pretty obvious > but PARTY\_RELATED is not\. Going to the root of the issue is more future > proof than other solutions and it is \(as far as I can see\) without any > other costs\. >   I don't think being LOCATABLE is the issue that is confusing but I do agree that PARTY\_RELATED is not the most obvious class to use \- it allows some demographic identifiers to be put into the EHR because we know that the demographics / MPI situation outside any given instance of the EHR server could be a real mess; on the other hand it doesn't allow anything in the way of structure \- i\.e\. it doesn't substitute for the openEHR demographic model, if we want to properly model demographics\. Tim is you main reason for wanting PARTY\_RELATED to be LOCATABLE to enable there to be an at\-code and description of it in the ontology, rather than to make it 'locatable' per se? \- thomas --- ## Post #11 by @system A proviso on this Heath - the PARTY_RELATED is strong as there will often not be a link to the Demographics (Mother, Father may be dead for instance or not in a position to give consent to a formal link) Cheers, Sam Heath Frankel wrote: [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #12 by @thomas.beale Sam Heard wrote: > A proviso on this Heath - the PARTY_RELATED is strong as there will often not be a link to the Demographics (Mother, Father may be dead for instance or not in a position to give consent to a formal link) > Cheers, Sam if you remember, this was in fact the main reason we created this class in the first place - to hold a minimum of identifyinng information about related parties when there was no other service to do so - which is most cases today I would say - given that the related parties (non-immediate family for example) could easily be in other health care jurisdictions. - t --- ## Post #13 by @Heath_Frankel3 Yes, but it can’t be guaranteed, in particular mothers of foetus/babies would commonly reference a demographic service entity. Heath --- ## Post #14 by @Tim_Cook2 Hi Heath, I apologize but I just can't understand your point \(one way or another\) about the guarantee here\. Can you please expand on this? \-\-Tim --- **Canonical:** https://discourse.openehr.org/t/participation-needs-to-be-a-locatable/14749 **Original content:** https://discourse.openehr.org/t/participation-needs-to-be-a-locatable/14749