PARTICIPATION needs to be a LOCATABLE

[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

[system]

Hi Tom,

I agree on the change.

Just out of curiosity, do you have any concrete example for archeytped PARTICIPATION?

Cheers,
Rong

[Tim_Cook2 (Tim Cook)]

I fully support PARTICIPATION being LOCATABLE.

--Tim

[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

[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:

[Tim_Cook2 (Tim Cook)]

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

[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:

(attachments)

[Tim_Cook2 (Tim Cook)]

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

(attachments)

[Heath_Frankel3 (Heath Frankel)]

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.

[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

[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:

(attachments)

[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

[Heath_Frankel3 (Heath Frankel)]

Yes, but it can’t be guaranteed, in particular mothers of foetus/babies would commonly reference a demographic service entity.

Heath

[Tim_Cook2 (Tim Cook)]

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