ROLE inherits from PARTY, PARTY has identities and contacts, which seem reasonable for a PERSON, ORGANIZATION or AGENT, which inherit from ACTION which inherits from PARTY, but I can’t see what’s the use of those fields for ROLE. Those fields seem to be more suitable for ACTOR than for PARTY IMO.
Does anybody have a use case for ROLE that uses identities or contacts?
The usual reason is that a person having a ‘Role’ (= available to act in a certain capacity) has contact info and sometimes even identifying info specific to the role. E.g.
A different identity for a ROLE is not that common, but it happens - writers and rock stars for example, with performance names and so on.
I’ve been reviewing the demographic model, and working on a new version known as an ‘entity’ model, which for the moment may serve only to indicate how to improve the current one. Other parts of that new model should address some long-standing requirements about modelling resources as well (see the sibling packages in the UML).
It’s not complete, and anyone who is interested should comment - initially on this thread, but we can talk about it in SEC if there is interest.
Thanks @thomas.beale I get the idea. I wasn’t considering the ROLE has exactly one performer. That way each nurse will have an instance of role, then for that it doesn’t have any issues to have contacts or identity. I was thinking of defining each role with one instance of ROLE (the “nurse” being one instance of role, the “doctor” being one instance, and so on, in that context it doesn’t make sense to have identities or contacts).
Thanks!
If I understand correctly, you mean something like ROLE = role type, i.e. the class ‘nurse’ (in the ontological sense), rather than some specific individual nurse (a ‘particular’ in the ontological sense)?
This is a different concept, and also a useful one, which we need in places like Task Planning where you want to state within a plan what kind of performer is needed on a task.
Exactly, I realized that after I send the message and continued working with the model, then I found the performer [1..1] then what you mentioned on your first answer was totally clear 
@thomas.beale what do you think about identities being 1…*?
Do we need an identity for each role?
Generally not, and it should be 0…*, which I will fix in the Entity model. The way it should work is that most of the type, the Agent (i.e. real Person, Org etc) will have identity/ies, and occastionally a Role of the Agent (what is called ‘persona’ in the new model) will have an identity, which for that role, overrides the Agent’s ‘real’ identity. E.g. a stage name, nickname etc.
EDIT: indeed, it might be argued that there should only be 1 identity for an Agent, and maximum one per Persona, but it’s always risky to over-constrain…
Yep, I thought requiring an identity for Role was kind of too much, since it might have that in some contexts, but not in general. So it’s messy to add just a dummy object there to comply with the specs. Also that makes identities required in the JSON/XML schemas based on the RM. I do prefer less constraints there in the RM, specially because those could be constrained more in archetypes and templates (I’m working right now with demographic archetypes and templates for the conformance verification).
Coming back to this issue, we’ll need to make our JSON schemas more flexible since our roles won’t have identities and the openEHR JSON schemas requires at least one element there, and creating dummy data is not the path we want to follow if we know the issue is on the spec, for instance because the dummy data will also be queried.
Just raised an issue about this Jira
I agree with your change proposal @pablo
I don’t see why identities should be mandatory, not only for ROLE but for any other PARTY. We can read this in the specs:
Instances of
PARTY_IDENTITY, linked toPARTYby the attributeidentitiesare intended to express the names of people, organisations, and other actors - that is names which are “owned” by the party, e.g. self-declared (in the case of institutions and companies) or by virtue of social relations (names given by parents, tribes etc). Identifiers of Parties given by other organisations, or the state are not represented in this way, and should be recorded in thePARTY.detailsstructure instead.
So, what if an organisation, a person or a group does not have other name than the assigned one? We can see it in this example, the name can be enough in many cases.
Hi @damoca I think in the case of the group, if “cardiac surgery team” is actually the GROUP.name value, then the corresponding archetype/template node is set to that value, though I guess when you model GROUPs you want something more generic, so the name might not be that, but maybe “surgery team” then on different groups you might actually want an identity with the specific name for that group. Though I get your point and it depends on how it’s modeled.
The case I feel stronger against the mandatory nature of the identity is for the ROLE.
Please follow the ticket on JIRA, and maybe we can talk about it in the next SEC meeting.
