# PARTY data in EHR space

**Category:** [Entity/demographics](https://discourse.openehr.org/c/entity/112)
**Created:** 2020-09-21 10:27 UTC
**Views:** 486
**Replies:** 1
**URL:** https://discourse.openehr.org/t/party-data-in-ehr-space/985

---

## Post #1 by @sebastian.iancu

One of the problem mentioned in the last years is that sometimes is difficult to record/use PARTY data in an optimal and clean way inside a COMPOSITION, inside the EHR space.
Off course, there are dedicated places where PARTY information can be captured, like ENTRY.subject, ENTRY.provider and ENTRY.other_participations (see https://specifications.openehr.org/releases/RM/latest/ehr.html#_entry_class), but it seems that there is a demand for a more 'ad-hoc' solution, see following links:
- https://discourse.openehr.org/t/party-as-regular-datatype/231
- https://discourse.openehr.org/t/integration-information-model-revamp/410/24

Some of the problems and suggestions are:
[quote="ian.mcnicoll, post:21, topic:410"]
1. Demographics entities which need to be carried in the EHR space. I’ll make some suggestions in a separate thread but briefly -

* PARTY_PROXY as a datatype, so that it can be added as an ELEMENT.
* other_details ‘slot’ in PARTY_PROXY allowing item_xx or cluster
* add ‘role’ to PARTY_IDENTIFIED.
[/quote]

[quote="ian.mcnicoll, post:29, topic:410"]
Some examples of where we might have used PARTY datatypes

[https://ckm.apperta.org/ckm/templates/1051.57.212 ](https://ckm.apperta.org/ckm/templates/1051.57.212)

Look at section 7,8,9. Sections 7,9 we could probably handle with participations if we were able to add role to PARTY_IDENTIFIED + other_details.

In the lab archetypes we need a place to handle the lab details, lab contact details - names, places, people - hard to squeeze into participations or other RM attributes.

https://openehr.org/ckm/archetypes/1013.1.2191 - see Receiver and requestor slots.
[/quote]

[quote="thomas.beale, post:24, topic:410"]
I will note that this creeping addition of demographic data to the EHR model is likely to create problems in the long term - because it’s creating uncontrolled copies of data rather than references to anything reliable (and normally available).
[/quote]

[quote="birger.haarbrandt, post:1, topic:231"]
I come across some cases where I think it would be beneficial if we could put an item of type Party into an Archetype. For example, the multimedia resource archetype has a field “author” that allows to capture information about the creator of a resource.
[/quote]
[quote="ian.mcnicoll, post:7, topic:231"]
I think having PARTY_IDENTIFED as a data value would be very helpful, along with adding role and organisation as attributes, and having other_details ITEM_TREE.
[/quote]

This topic/thread is to discuss it further, and get to a final proposal about how specs should be changed (if even want to change them).

---

## Post #2 by @sebastian.iancu

From my perspective, looking to the use-cases above and to my own experience with consumers on this issue, and assuming that ENTRY.* attributes are not always a solution to these problems, I noticed the following:
 - none of the above mentioned class cannot be used right now as ELEMENT value;
 - DV_EHR_URI is not reach enough to give context (role, type, name, timeframe, etc)
 - LOCATABLE.links are better than DV_EHR_URI, but still not reach enough, and neither 'positioned' correctly 
 - what we need to record is very close to what [PARTCIPATION](https://specifications.openehr.org/releases/RM/latest/common.html#_participation_class) is for: PARTY identification + name, function/role, optional time and mode. PARTICIPATION in this sense is more reach than PARTY_PROXY or PARTY_IDENTIFIED, or the other LINK/DV_URI solutions.
 - if we could record PARTICIPATION at any point of an archetyped structure (i.e. under ELEMENT), then this could be easily combined with other CLUSTER structures to record more 'other_details' - therefore we might not need to add 'other_details' to PARTY_PROXY.

Is it than perhaps a solution to introduce a new type - DV_PARTICIPATION? I'm not sure about the choice of the name, perhaps other have better suggestion, but I'm more curios about the functional aspect: will this type be a solution for use-cases mentioned in the topics above? 

What will be the impact to have this new type/class? Obviously, it will have to be implemented by EHR vendors, but what will be the impact on AOM/ADL and on AD/CKM/AQL?

Also, will this be enough to solve/capture all the requirements above? My impression is that with this on, we won't be needed to change any of the other types (PARTY_PROXY, OBJ_REF, etc.), which might be easier to accept by existing implementation.

---


**Canonical:** https://discourse.openehr.org/t/party-data-in-ehr-space/985
**Original content:** https://discourse.openehr.org/t/party-data-in-ehr-space/985