# PARTY as 'regular' datatype **Category:** [Entity/demographics](https://discourse.openehr.org/c/entity/112) **Created:** 2019-12-11 09:55 UTC **Views:** 2025 **Replies:** 33 **URL:** https://discourse.openehr.org/t/party-as-regular-datatype/231 --- ## Post #1 by @birger.haarbrandt 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 --- ## Post #2 by @sebastian.iancu 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. --- ## Post #3 by @birger.haarbrandt 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. --- ## Post #4 by @sebastian.iancu What kind of additional information you would like to record? --- ## Post #5 by @birger.haarbrandt At least a person's name would be good. --- ## Post #6 by @sebastian.iancu Still thinking on this subject ... Would something useful to have something like DV_PARTYxxx, having PARTY_IDENTIFIED or PARTY_PROXY as value ? --- ## Post #7 by @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. 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. --- ## Post #8 by @sebastian.iancu 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. --- ## Post #9 by @sebastian.iancu there is a follow up topic: https://discourse.openehr.org/t/party-data-in-ehr-space/985 --- ## Post #10 by @yampeku I'm fine with it as long as we don't end with an empty class... --- ## Post #11 by @ian.mcnicoll Taking this thread in a slightly different direction, part of the original problem is that we are often asked to refer to external parties in various parts of the data model without any gurantee that we can resolve these to an actual demographic service entity. This often involved slotting in cluster pseudo-demographic slots and associated clusters which is ugly and confusing for newbies. However, I have re-visiting the existing palaces that PARTY_PROXY appears in an ENTRY and I think a couple of adjustments might solve a lot of the issues. A major gap in PARTY_IDENTIFIED is the lack of an attribute for role/relationship, alongside name and identifier, as 'minimal clinically useful info' where a full hookup to a demographics service is not possible or needed. However PARTY_RELATIONSHIP does support that, albeit that it requires a coded_text. Should PARTY_IDENTIFIED by extended with a new relationship/role attribute (DV_TEXT) or should we make use of PARTY_RELTIONSHIP to include professional relationships as well as personal. The other addition would be to add an other_details structure to PARTY_IDENTIFIED. In particular it opens up the use of other_participants to carry those snippets of contact number, address, org details that integration often forces upon us. So add relationship 0..* to PARTY_IDENTIFIED (or widen scope of PARTY_RELATIONSHIP) add other_details to PARTY_IDENTIFIED. --- ## Post #12 by @thomas.beale [quote="ian.mcnicoll, post:11, topic:231"] A major gap in PARTY_IDENTIFIED is the lack of an attribute for role/relationship, alongside name and identifier, as ‘minimal clinically useful info’ where a full hookup to a demographics service is not possible or needed. However PARTY_RELATIONSHIP does support that, albeit that it requires a coded_text. [/quote] I seem to remember we discussed this, although I could not find a PR for it. But it would be easy to do. [quote="ian.mcnicoll, post:11, topic:231"] Should PARTY_IDENTIFIED by extended with a new relationship/role attribute (DV_TEXT) or should we make use of PARTY_RELTIONSHIP to include professional relationships as well as personal. [/quote] I would suggest not - this is a class that will only work in the demographic model to represent relationships between PARTY instances. [quote="ian.mcnicoll, post:11, topic:231"] The other addition would be to add an other_details structure to PARTY_IDENTIFIED. In particular it opens up the use of other_participants to carry those snippets of contact number, address, org details that integration often forces upon us. [/quote] Technically easy to do. But it risks creating a disaster in the data, due to undisciplined copies of same / almost the same demographic data representing the same provider entities. A better solution really would just be to add a place in an EHR for demographic objects to go (versioned), and provide a way for PARTY_PROXY instances to point to those. Then at least you will have only one Dr Jones, one Nurse DuPont etc, rather than hundreds of copies. --- ## Post #13 by @ian.mcnicoll [quote="thomas.beale, post:12, topic:231"] A better solution really would just be to add a place in an EHR for demographic objects to go (versioned), and provide a way for PARTY_PROXY instances to point to those. Then at least you will have only one Dr Jones, one Nurse DuPont etc, rather than hundreds of copies. [/quote] It would absolutely be a better option but we very frequently have no choice - typical example is a lab message that contains name of lab scientist an contact details. We need to have a simple way of handling this. --- ## Post #14 by @ian.mcnicoll @Thomas - I was a bit confused about what you were suggesting re adding 'role' somewhere. Sorry it is me being dense. Did you mean that you favoured adding a role 0..* [dv_text] attribute to PARTY_IDENTIFIED? --- ## Post #15 by @thomas.beale [quote="ian.mcnicoll, post:14, topic:231"] Did you mean that you favoured adding a role 0…* [dv_text] attribute to PARTY_IDENTIFIED? [/quote] Yes. This seems reasonable to me - in fact I thought we had had a discussion that was close to agreeing this... If we did this, and it wipes out say 70% of the current 'difficulties' then I think this would be a good start. --- ## Post #16 by @thomas.beale [quote="ian.mcnicoll, post:13, topic:231"] It would absolutely be a better option but we very frequently have no choice - typical example is a lab message that contains name of lab scientist an contact details. We need to have a simple way of handling this. [/quote] Good point - I presume this is a/the case where you also have 'role' in the incoming message and nowhere to put it in the openEHR target? --- ## Post #17 by @ian.mcnicoll It is a very common 'minimum' bit of this kind of demographic info. That would be a great start but we still need to find a way to handle other tel. contact details, organisation names etc where we need to capture the incoming information without having access to a proper external reference. Not having this flexibility is forcing us to work around the limitations by adding hacky cluster archetypes, when we should be able to make a lot more appropriate use of the provider, other_participants. We would still need some clusters but we can embed them within the context of proper Demographic models and archetypes or mirrored DEMOGRAPHIC/EHR cluster archetypes. --- ## Post #18 by @ian.mcnicoll Typical current example - Cancer MDT referral. Job is to import into a CDR from a traditional database. We might have some sort of provider demographics service but not clear yet. Even if we do, it is still very helpful to be able to show in the template that we can 'meet the requirements' even if in practice the GP email details are not eventually modelled in-line. ![image|414x500](upload://5rqBumoRpLyEPi7Bd0VYepTz4KH.png) --- ## Post #19 by @thomas.beale [quote="ian.mcnicoll, post:17, topic:231"] That would be a great start but we still need to find a way to handle other tel. contact details, organisation names etc where we need to capture the incoming information without having access to a proper external reference. [/quote] Note that my solution above is a new one: to add PARTY objects to individual EHRs, not to rely on a separate Demographic service (which we should have but don't). Putting them at the root of the EHR is a kind of hybrid - it creates a mini-Demographic DB inside each EHR, which at least means: * only one copy of each distinct identity for that EHR, i.e. only one instance of a particular Dr Jane Smith rather than say 50, corresponding to all the visits done with Dr Smith during 3 pregnancies; * ability to use real PARTY classes * ability to compare PARTY objects stored in EHRs across EHRs, and potentially detect errors, commonalities, and maybe extract out a proper demographic DB image later on; * at runtime, you could use the EHR's private demographics as a picklist for demographic entity when creating a new PARTY_IDENTIFIED attached to an Entry. This is an 'idea', not an advanced design, at this stage. If we actually did it, we could either abandon PARTY_IDENTIFIED, or keep using it, and just treat it as a short summary copy of the most useful bits of data from the PARTY it points to (within the same containing EHR). --- ## Post #20 by @ian.mcnicoll That's worth considering further but in most of the integration projects I have been asked to get involved with , it would still be beyond the scope of what we are asked/funded to do. It requires a whole other layer of governance when all that is really required (for good or bad) is to add some snippets of practical and orienting provider details embedded in the messages. --- ## Post #21 by @pablo [quote="ian.mcnicoll, post:11, topic:231"] A major gap in PARTY_IDENTIFIED is the lack of an attribute for role/relationship, alongside name and identifier, as ‘minimal clinically useful info’ where a full hookup to a demographics service is not possible or needed. However PARTY_RELATIONSHIP does support that, albeit that it requires a coded_text. Should PARTY_IDENTIFIED by extended with a new relationship/role attribute (DV_TEXT) or should we make use of PARTY_RELTIONSHIP to include professional relationships as well as personal. [/quote] I see a couple of things here: 1. the idea of the "demographic service" is to keep the "current" status of demographic entities managed and up to date. 2. recording PARTY_XXX in a COMPOSITION won't create a managed demographic entity, just a snapshot of that entity at the moment of recording the COMPOSITION. 3. if having the snapshot is enough to comply with the requirement, then instead of a 'role', which is related with the 'current' status of the entity, PARTICIPATION.function and PARTICIPATION.mode can be used, which are more related with the snapshot of the 'role' at the moment of the recording, because the stable 'role' would be part of the managed entity in the "demographic service". 4. I think is something (clinical or demographic) is needed to be in the COMPOSITION, then it is a snapshot. On the other hand, by looking at the common.generic model (https://specifications.openehr.org/releases/RM/latest/common.html#_overview_3), we have a bunch of stuff there that could be reorganized. For instance the whole PARTY_PROXY hierarchy, seems to be something different than the rest of the classes, it could be perfectly a DATA_VALUE. That might lead to another discussion: why aren't OBJECT_REF and OBJECT_ID also DATA_VALUE? https://specifications.openehr.org/releases/BASE/latest/base_types.html#_overview_4 --- ## Post #22 by @ian.mcnicoll [quote="pablo, post:21, topic:231"] ecording PARTY_XXX in a COMPOSITION won’t create a managed demographic entity, just a snapshot of that entity at the moment of recording the COMPOSITION. [/quote] Yup -exactly - it is just a snapshot - either because that is genuinely sufficient for the user requirement or the user is to mean to pay to do it properly as per (1)!! The role is sometimes context-specific i.e I might be a GP in one role and a diabetes associate specialist in another. The participation is a good example for a current use-case we need to record a set of people who have signed-off on an end of life care decision.. Name Professional identifier Role -> GP, Consultant surgeon, Consultant palliative care specialist but also a second role 'normal signatory' or 'senior responsible clinician'. We have worked around this in a different way but allowing multiple functions in other_particpants would work, but does not work for e.g. ENTRY.provider or composer. I think I would rather add role to PARTY_IDENTIFIED - that would then allow, e.g. in participations to have Name: Dr Smith Role: Consultant surgeon function: Senior responsible clinician signatory time: 2020-12-12 --- ## Post #23 by @thomas.beale Just to clarify the semantics of Participation and Party_proxy... * when a party occurs in the model as a specific kind of participation, e.g. ENTRY.subject, you just use PARTY_PROXY (any descendant), since the 'subject' tells you the participation * for generic participatons, like ENTRY.other_participations, then the model uses PARTICIPATION, since each kind of function, etc needs to be stated, e.g. 'renal nurse' etc Neither Participations nor Party_proxies are data values in the sense of being possible value types of observable things. Ontologically, they are what they say: participation of Party(s) in the situation being documented, and Party_proxy is just a smart ref to a Party. Therefore, rather than trying to include such participations as data items (e.g. ELEMENTs), the model enables them to be recorded so as to represent what is really going on - i.e. via ENTRY.other_participations, COMPOSITION.participations. If the need is just to record meaningless data trees coming in on some integration channel we should use the approach @yampeku has been looking at with the revised Generic_entry; also @birger.haarbrandt's posts on having an integration front-end 'bucket' to receive whatever incoming data before processing it into proper opeenEHR form. We should not try to make the core openEHR RM an integration model - that will destroy its utility is a proper EHR, i.e. the kind you want to have sitting behind openEHR applications. --- ## Post #24 by @thomas.beale [quote="ian.mcnicoll, post:22, topic:231"] but also a second role ‘normal signatory’ or ‘senior responsible clinician’. We have worked around this in a different way but allowing multiple functions in other_particpants would work, but does not work for e.g. ENTRY.provider or composer. [/quote] Well the participations of 'provider' or 'composer' are already defined to be what they are, i.e. provider of the information, composer of the Composition. To record 'normal signatory' or 'senior responsible clinician', you need to create the appropriate Participations in Composition.participations. --- ## Post #25 by @ian.mcnicoll That is pretty well what we are doing though using other_participations in an ACTION is the sign-off is for a specific part of the overall document, not the whole thing. The problem remains though, that we cannot carry both the role and the function inside PARTICIPATION. An you can guarantee that the next customer will ask for a simple contact number for the signatory and we will have to resort to fudging that somewhere else in the composition. In my experience there is not a clear line between an integration exercise and doing the semantics properly. I always look to use proper ENTRY archetypes and semantics as the target but there are always edge-cases and I think we are putting unnecessary blocks in the way of maximising the ability to do it right, as per my example above. If I can't add a contact number to PARTICIPATION, then I can't use it at all. Better to use it with some slightly imperfect extensions that the client does not want to have properly handled as pure demographics entities. THis should be an implementation choice, IMO with some wiggle room. Otherwise people work round it in even more variant ways. --- ## Post #26 by @ian.mcnicoll and I don't see how the Generic archetype approach helps here. You still get to an end point of 'where do I put that contact number' if the client does not have a properly integrated demographic service, or indeed there may be examples of private carer contact numbers which are not allowed to go into s proper demographics service. --- ## Post #27 by @thomas.beale [quote="ian.mcnicoll, post:25, topic:231"] The problem remains though, that we cannot carry both the role and the function inside PARTICIPATION [/quote] Well we can add role to PARTICIPATION if needed - that's dead easy. From a technical point of view, we can recreate the whole demographic model inside PARTY_IDENTIFIED. But doing so will create a mess in at least some systems, as people use this for what is essentially an integration function - capturing variable demographic data. I'm not saying it will always happen but I guess it will get used a lot. All of that data buried inside PARTY_IDENTIFIED will be effectively not reliably queryable (i.e. will generate duplicates, misses etc), and will provide no means of perusing the demographic data buried in the EHR. In an integration environment, that's fine - it's what you expect, but in an EHR, it just reduces the quality of the data, more or less recreating the mess of the exterior environment right inside the EHR. So I would strongly suggest using an integration-oriented front end based on Generic_entry or similar, and then converting from that data (where needed) to proper openEHR data, which will then be reliable under querying. --- ## Post #28 by @thomas.beale [quote="ian.mcnicoll, post:26, topic:231"] and I don’t see how the Generic archetype approach helps here. You still get to an end point of ‘where do I put that contact number’ [/quote] Well in a [Generic_entry](https://specifications.openehr.org/releases/RM/latest/integration.html#_overview), it can go anywhere. Generic_entry is just a tree. We would still need to modify it a bit to add Participations on any node, plus Parties hanging off the Entry or maybe a specialised Composition but that's easy to do. Then you've got a simple basis for an integration staging cache, from which proper openEHR data can be constructed. This is pretty much the architecture used in real integration environments anyway - there is usually a staging DB containing a fairly literal transformation of the data for further processing. --- ## Post #29 by @ian.mcnicoll Sorry, I must be getting old and confused (don't answer that!!). In my scenario I can and already create 'proper' openEHR data using standard lab archetypes etc . THe only 'gap' is that the integration requires me to add some snippets of demographic stuff ' tel number' etc that cannot be done 'properly' because either their is nor formal demographic service for me to hook up to or that the data quality in the message makes that impossible, or the client does not want to pay for may be quite a complex process. You are making the assumption that at the end of this process there is a 'prefect' demographics target that can be hit - that's not always the case. Using Generic entries just takes me backwards. I still have this issue of how/where to carry 'lab scientist's phone number' . The clinicians want it (for obvious reasons), The' system' does not allow me to hook up to a proper provider registry. Right now I add a CLUSTER archetype to protocol, when it would make much more sense to add it as part of a PARTY structure or PARTICIPATION - that would let me use the RM as-designed to the very maximum, accepting that it is not perfect. Right now the lack of extensibility of PARTY/PARTICIPATION is forcing me to do some serious hacky workarounds where with a little more flexibility, I would be able to make much more use of the correct attributes. Practically - I think if we extended PARTY_IDENTIFIED to add role(s) that would be available in PARTICIPATION? --- ## Post #30 by @thomas.beale [quote="ian.mcnicoll, post:29, topic:231"] You are making the assumption that at the end of this process there is a ‘prefect’ demographics target that can be hit - that’s not always the case. [/quote] Well not a perfect demographics - but one sufficiently standardised that querying will work, since the 'work telephone number' etc will always be in an expected place whose path is knowable. Anyway, let's solve this in steps. Let's say we add role to PARTICIPATION. That is easy and reasonable. I t could also be added to PARTY_PROXY (doesn't even need to be PARTY_IDENTIFIED). THere is a reasonable theoretical for putting it in both places: for PARTY_PROXY (e.g. OBSERVATION.subject, ACTION.provider etc) you still don't have the role, only the 'function' (which is the name of the attribute, i.e. subject, provider etc). I am in favour of doing this sooner rather than later - our current model of Participation is a bit too light. To start adding in demographic data beyond ids, like contact phone numbers etc, I think we need to be careful. Initially, it will seem fine to just add a phone number. Then someone will want multiple phone numbers, each with a purpose, plus similar for email addresses and so on. Pretty soon, you are recreating what is already in the Demographic model. To avoid doing that, we need to make those PARTY_IDENTIFIED references point to real PARTY objects. If we don't have them in a separated service (as indeed, we usually don't) I propose to put them in the individual EHR. This is a bit hacky, but it's a controlled hack and we could do useful things with it. A worse (but maybe still palatable) hack would be to add PARTYs to COMPOSITIONs, and make all interior refs point to them. The former will break much less software as well as enable more useful extra functionality we don't have today, and I would argue is the best compromise here. --- ## Post #31 by @sebastian.iancu I'm trying to catch up with discussions here - so far the following conclusions/proposals: 1. we will add `role` attribute (DV_TEXT ?) to [PARTCIPATION](https://specifications.openehr.org/releases/RM/latest/common.html#_participation_class) 2. `PARTICIPATION.performer` is most likely a [PARTY_IDENTIFIED](https://specifications.openehr.org/releases/RM/latest/common.html#_party_identified_class), which can refer to a 'proper' `PARTY` instance, via the already existing `external_refs` attribute (type [PARTY_REF](https://specifications.openehr.org/releases/BASE/latest/base_types.html#_party_ref_class)). 3. we'll explore the (hacky) concept of adding `PARTY` under `EHR`. 3.1. alternatively we could add new attribute PARTY_IDENTIFIED.other_details (type ITEM_TREE) to capture 'snapshot' details 3.2. alternatively we could add support for a whole PARTY inside COMPOSITION In my opinion 3.2) is not at all an option that should be considered. The 3.1) option is something that might work. But indeed, it will create a mess of different 'snapshots' living in parallel inside CDR - if that's an acceptable trade-off for CDR users/managers, then why not?... The option 3.) I see it with less enthusiasm: it might be doable to make specifications, and manageable to implement by vendors, but speaking from my own experience implementing RM-Demographics, not much easier implement and use than the proper RM-Demographic package. The AQL and REST and other ITS should be also amended. On the application level, the PARTY_REFs will still have to be resolved to the right EHR-PARTY instance. ...It doesn't look simpler (to me), yet it will introduce confusion and create doubts about the scope and purpose of EHR-PARTY vs Demographics-PARTY. I'm more in favor then to provide betters specs, guidance and tooling to embrace and promote the current 'proper' solution (RM-Demographics). --- ## Post #32 by @ian.mcnicoll [quote="sebastian.iancu, post:31, topic:231"] we will add `role` attribute (DV_TEXT ?) to [PARTCIPATION](https://specifications.openehr.org/releases/RM/latest/common.html#_participation_class) [/quote] I think ti makes more sense to add role to PARTY_PROXY or PARTY_IDENTIFIED - as name, ID and role )in the context of the composition composer, participant or provider etc is often a key minimal part of 'orienting' the reader as to the author's credentials w.g Dr John Smith, GMC ID, 'diabetes associate specialist'. Of course that would then also be available inside PARTICIPATION. I'm not keen on handling PARTY inside ehr or composition - that still just makes the assumption that I have the ability/budget to properly normalise/reconcile bits of 'snapshot' demographic data carried e.g in a lab report. I'm deliberately accepting the compromise that I am not attempting to maintain a source of truth. As you say, these are snapshots- the lab specialists contact number is only relevant for a few days in the context of having to confirm or query a result. Of course, this is a sub-=optimal and if possibly can I would do this 'properly' but is it impossible - I agree it should be up to those designing the semantics around the CDR to make those decisions, not imposed by the RM. --- ## Post #33 by @thomas.beale I mostly agree with what @sebastian.iancu says - my hack proposals are not made with pleasure ;) [quote="ian.mcnicoll, post:32, topic:231"] I think ti makes more sense to add role to PARTY_PROXY or PARTY_IDENTIFIED - as name, ID and role )in the context of the composition composer, participant or provider etc is often a key minimal part of ‘orienting’ the reader as to the author’s credentials w.g Dr John Smith, GMC ID, ‘diabetes associate specialist’. Of course that would then also be available inside PARTICIPATION. [/quote] So I would go with `PARTY_IDENTIFIED` (I can think of edge cases where `PARTY_SELF` might want a role, but that's a bit obscure - and if we understand 'role' as a professional standing, then we can forget it). This is ok, if we do nothing else. If we want more, it's better to roll 'role' into the rest... For extra demographic snapshot data we may want under PARTY_IDENTIFIED - what is it exactly? One phone number? multiple phone numbers, email addresses, IM contacts, and purposes & time intervals for all those? This is where we start recreating the PARTY model. I'm coming around to the idea that an attribute like `PARTY_IDENTIFIED.thumbnail: XXX` could be added. I.e. we consider the extra meta-data attached to the `PART_IDENTIFIED` as an uncontrolled 'thumbnail' partial copy of some definitive data elsewhere. Now, the XXX could be `ITEM_TREE` (or `CLUSTER`, same thing) or `PARTY`. Solution A -------------- As noted earlier, it's technically easy to put `thumbnail: ITEM_TREE` in `PARTY_IDENTIFIED`, but if we do so, and implementers build that, that will be the solution for the next 5-10 years. This means we need to keep doing these fake demographic CLUSTER archetypes, and everyone will probably use there own, which means querying over data in a federating situation e.g. HighMed, will fail. Solution B -------------- Or else we put the PARTY model in there (i.e. `PARTY_IDENTIFIED.thumbnail: PARTY`) (but no `PARTY_RELATIONSHIPs`). This gives us a thumbnail of the same structural form (for some systems at least) of the primary demographic data, and it is also queryable. It also gets rid of these fake CLUSTER demographic archetypes. It still creates unmaintainable copy-paste data - but that is the nature of thumbnails. Discussion -------------- We need to consider to what extent we may compromise the quality of EHRs if we go this path; I'm not saying it is a forgone conclusion, just that we need to have the discussion fairly widely, because whatever we decide here will create significant work for implementers and will have a significant effect downstream on openEHR EHR data. We just need to be prudent and think ahead on this. --- ## Post #34 by @sebastian.iancu [quote="thomas.beale, post:33, topic:231"] we need to have the discussion fairly widely, because whatever we decide here will create significant work for implementers and will have a significant effect downstream on openEHR EHR data. [/quote] Yes, completely agree, we need feedback on above concepts/solutions. [quote="ian.mcnicoll, post:32, topic:231"] I think ti makes more sense to add role to PARTY_PROXY or PARTY_IDENTIFIED - as name, ID and role [/quote] indeed, it makes more sense --- **Canonical:** https://discourse.openehr.org/t/party-as-regular-datatype/231 **Original content:** https://discourse.openehr.org/t/party-as-regular-datatype/231