PARTY as 'regular' datatype

Specifications RM
#1

Hi everybody,

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. Just using a URI instead of a DV_TEXT might be insufficient. Of course we might build an internal cluster and put a string and an URI together to build our own PARTY subtitute. Though, this does not seem to be an elegant approach. Any thoughts on this? (I apologize if this has been discussed before, Slack did not provide any hints on this kind of discussion)

Best,

Birger

#2

Normally you should use PARY_REF of PARTY_IDENTIFIED. Problem is that is not (easily) available while creating the archetype, you might want to consider attributes like composer, provider, other_participant, etc for that. You could also use DV_IDENTIFIER, and use type=PARTY.
On the other hand if you would like to go for URI, the problem is that we don’t have yet a standard way of referring to a PARTY in URI format (as we have for EHR content, via DV_EHR_URI). There is an ongoing discussion-topic inside SEC about this, hopefully we’ll have soon more info about this.

#3

Thanks Sebastian. The issue is that composer, provider etc. don’t seem to be feasible as they are related to the composition and not the pdf document, CDA whatever that can be stored inside the composition. I assume that Heather and Ian considered these option when creating the Archetype.

The issue with URI is that I cannot “hard-code” additional information. From a medico-legal perspective, onyl relying on an URI is not feasible.

#4

What kind of additional information you would like to record?

#5

At least a person’s name would be good.

#6

Still thinking on this subject …
Would something useful to have something like DV_PARTYxxx, having PARTY_IDENTIFIED or PARTY_PROXY as value ?

#7

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. I know we should be trying to manage all of this as references but it is practically impossible in many/most projects I am working on for now.

#8

Indeed you/we mentioned it in last SEC meetings (or we touched briefly this subject) - just that the use case wasn’t clear for everybody at that time. Perhaps we should elaborate a bit more, get an idea about the proposition and its impact. Introducing a new DV_x is not trivial, but can it be done if we have sufficient good reasons.