PARTY data in EHR space

[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 EHR Information Model), but it seems that there is a demand for a more ‘ad-hoc’ solution, see following links:

• PARTY as 'regular' datatype
• Integration Information Model revamp - #24 by thomas.beale

Some of the problems and suggestions are:

@ian.mcnicoll

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.

@ian.mcnicoll

Some examples of where we might have used PARTY datatypes

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.

@thomas.beale

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).

@birger.haarbrandt

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.

@ian.mcnicoll

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.

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).

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