Additional 'Participations' metadata item

[mar.perezcolman (Marlene Pérez Colman)]

Good morning,

I was hoping we could discuss the possibility of having additional attributes to complement the ‘role’ for the participations in the RM. In Wales, we would like to store both the Role of the participant (ie: Consultant) and the Specialty (ie: General surgery) because there are clinicians who have more than one specialty and there is a requirement to store under which specialty they were reviewing the patient.

To be able to cope with that we have, for the time being, created a specific CLUSTER archetype called ‘Participations’ that has the possibility to record multiple participants:

New CLUSTER archetype:

To be used with ‘Practitioner role’ CLUSTER from the Apperta (UK) CKM:

Example of a Participant with a role and specialty

Would it be feasible to include “Specialty” as part of the Rm attributes for Participants? Or a configurable attribute that can be customised depending on the clinical scenario?

@johnmeredith @rach123

[johnmeredith]

@ian.mcnicoll is this something that could be suggested at the upcoming sec meeting?

[heather.leslie]

Hi Marlene,

Another (interim/‘hack’) option would be to specialise the already published CLUSTER.person into CLUSTER.person-participation, or similar, and add your data elements to that new archetype rather than creating more archetypes outside the international CKM scope.

Regards

Heather

[ian.mcnicoll]

Can we perhaps use this thread to work up a ‘consensus’ clinical view on the changes we would like to see in the RM to try to make this kind of issue easier to handle?

My attempt at a wee summary of the problem…

The core issue is not really with Participations, it is that by design, the RM tries to keep any kind of detailed demographic details outside the CDR.

The key attribute in Participations which handles the ‘demographic details’ is performer which is a PARTY_PROXY, normally sub-classed to a PARTY_IDENTIFIED.

PARTY_IDENTIFIED, which is also used for e.g Composer allows us to carry a name, multiple external identifiers, and an internal identifier but nothing else.

The argument has been that the CDR should never be the source of truth for more detailed professional demographics, which does make a lot of sense. PARTY_IDENTIFIED relaxes this rule a little to allow the professional’s name and ids to be copied into the CDR, to allow a little local sense-making i.e you can see the person’s name and identifier without having to track back into the formal demographics record via some kind of internal identifier.

The problem we see repeatedly is that local practice often requires more information to be immediately available in the CDR, typically at least a role or contact number, even if these are actually originally maintained in a separate demographics store.

This was the case in the Welsh example above. Local Welsh NHS rules say that the practitioner’s role and speciality MUST be stored in the CDR for each participations or composer record, as these may be specific to each encounter, where a practitioner has multiple roles. even though this information is actually primarily maintained in a Welsh practitioner database,

A different use case is where we are often asked to carry some more detailed information associated e.g with a lab report - the name of the lab scientist and tel. contact details.

In this kind of integration scenario, we have no ability to reference back to the Lab information system list of practitioners, if that even exists.

This is why, while I certainly don’t disagree with the principle that practitioner demographics should be handled outside the CDR, in reality we are forced to compromise for many good reasons which is why we see these CDR demographics archetypes being used.

This has a particular impact on Participations because the structure becomes completely unusable since we cannot extend it to carry these extra fields, so we end up in some fashion recreating it in a different part of the data tree.

I think there are 2 potential solutions

1. Extend PARTY_IDENTIFIED to add at least role and ‘speciality’ attributes. This alone would fix quite a few of the gaps in Participations and other places that PARTY_IDENTIFIED is used e.g. composer.

2. In addition, strongly consider adding an’ other_details’ slot to PARTY_IDENTIFIED to allow CLUSTER demographics archetypes to be plugged in. This would allow modellers to add any need demographic details to the correct part of the data tree, rather, as we are right now, having to add cluster archetypes to context or Extensions.

I would argue for both - the reality is that we cannot prevent aspects ‘practitioner demographics’ sometimes leaking into the CDR. Right now we are all approaching this in a slightly inconsistent way, Some small changes to the RM would let us regularise to some degree, and actually promote good practice.

[mar.perezcolman (Marlene Pérez Colman)]

Thanks Ian for clarifying this.
In the UK a practitioner can have multiple roles (nurses who are also midwives) and clinicians with more than one specialty, and the ID stays the same (for example the GMC number for doctors in the UK), so the differences can be told apart by the ID.

Out of curiosity, can I ask how this could be done in a Template:

@ian.mcnicoll

In addition, strongly consider adding an’ other_details’ slot to PARTY_IDENTIFIED to allow CLUSTER demographics archetypes to be plugged in. This would allow modellers to add any need demographic details to the correct part of the data tree, rather, as we are right now, having to add cluster archetypes to context or Extensions.

I haven’t been able to expose the Rm attributes through the AD in a template, so if we did have a slot to add more details, how could this be accessed to fit in any specific CLUSTERs ?

[ian.mcnicoll]

@mar.perezcolman

I haven’t been able to expose the Rm attributes through the AD in a template, so if we did have a slot to add more details, how could this be accessed to fit in any specific CLUSTERs ?

Yes - we would need to get some updates to AD to make this work. There is also a related JIRA PR suggesting a technical change to Participations to make it easier to handle in archetypes but that is a breaking RM change, so I’d like to keep that as a separate discussion.

[damoca (David Moner)]

I don’t fully agree with some of your premises. We have to have very clear the difference between the party and the role. HL7 RIM is very clarifying about this:

An entity (our PARTY_PROXY) participates (our other_participations attribute) in an act (our Entries) using a specific role (our PARTICIPATION.function, this is what could be a bit confusing).

So, everything you mentioned about the management of the Parties outside the CDR is correct. But when they participate in the Entry, the role or specialty are part of the PARTICIPATION class, not attributes of the PARTY.

If the solution to represent this additional information is to create those CLUSTER archetypes, I’m not against it, it’s a decision of the modelers.

But, pushing the RM to its limits, this can also be represented with the current attributes. Remember that the PARTICIPATION.function is a DV_TEXT and that the same person can have multiple participations.

Option 1. Represent each of the participation attributes as one different PARTICIPATION class instance (pseudo code below):

"ENTRY" : {
	"other_participations" : [
		{
			"performer" : "abc123",
			"function" : {"value":"Consultant" }
		},
		{
			"performer" : "abc123",
			"function" : {"value":"General surgery"}
		}
	]
}

Option 2. Represent all the details of the participation inside the same function and use the DV_TEXT mappings to add o more formal specification by using some kind of codes (pseudo code below)

"ENTRY" : {
	"other_participations" : [
		{
			"performer" : "abc123",
			"function" : {
				"value":"Consultant in General surgery" 
				"mappings" : [ 
					{
						"purpose" : "Role",
						"target" : "Consultant"
					},
					{
						"purpose" : "Specialty",
						"target" : "General surgery"
					}
				]
			}
		}
	]
}

Probably this is not the most optimal solution, but it could work without modifying the RM.

[ian.mcnicoll]

Firstly - clever idea about creating multiple participations for a single person!! It is certainly a short-term approach but it feels like a workaround, no something that is easy to defend/explain to others.

@damoca

So, everything you mentioned about the management of the Parties outside the CDR is correct. But when they participate in the Entry, the role or specialty are part of the PARTICIPATION class, not attributes of the PARTY.

I don’t totally agree here.

Firstly we use PARTY_PROXY/ IDENTIFIED in COMPOSITION.composer and ENTRY.provider, and in both cases we are often required to supplement the simple name/id with additional role/speciality informaiton (sometimes more).

So this is not just about Participations.

In the context of composer, I would expect the role and speciality to be one of the official rolea and official speciality, originally recorded in the practitioner datastore.

So I might have 2 jobs …

Ian McNicoll: GMC 1234567
Role/Speciality: Senior GP : General Practice
Role/Speciality : Emergency doctor: Emergency Medicine

In the context of an Emergency medicine encounter, I might be

composer/name: Ian McNicoll
composer/identifier: GMC::1234567
composer/role:   Emergency doctor:
composer/speciality: Emergency Medicine

Participant function potentially takes us deeper into what I was actually doing in the team, in the very specific context of e.g a Procedure

So I was an assistant at a minor procedure performed at that encounter

other_participations
performer
  name: Ian McNicoll
  identifier: GMC::1234567
  role:   Emergency doctor:
  speciality: Emergency Medicine
function
 operating assistant

IOW I would expect role and speciality to be local copies/clones of formal role and speciality managed in the practitioner demographic service, whilst function may well be used to apply a very specific, highly contextual role.

The same might apply at composition level for something like an MDT meeting where

participations
 performer
   name: Ian McNicoll
   identifier: GMC::1234567
   role:   General practitioner:
  speciality: General practice
function
 MDT lead

Although this would mean RM change, it would not be a breaking change. I know we can work around in many different ways but it feels increasingly messy especially when trying to explain to new entrants.

I’d still like to add the ability to slot in a cluster archetype as this allows more complex requirements to be added (telcom details, organisation details) using standardised archetypes as Heather has suggested.

[damoca (David Moner)]

@ian.mcnicoll

Firstly we use PARTY_PROXY/ IDENTIFIED in COMPOSITION.composer and ENTRY.provider, and in both cases we are often required to supplement the simple name/id with additional role/speciality informaiton (sometimes more).

I see the problem here, that is that composer and provider are somehow a pre coordinated participation, where the attribute name itself tells us the type of participation. On the other hand, the other_participations navigates through the PARTICIPATION class, building a data structure closer to the RIM approach. So that’s a problem for adding additional info in those cases.

That said, a different problem is what you have perfectly explained about storing in the CDR an extract of some PARTY_IDENTIFIED information. In that case, I agree that the most generic approach (accepting a change to the RM) would be to add a PARTY_IDENTIFIED.other_details::List< ITEM >, so you can add any structure (even an archetyped one) to the PARTY. That would be better than adding specific role, specialty, etc. attributes.

[ian.mcnicoll]

@damoca

composer and provider are somehow a pre coordinated participation, where the attribute name itself tells us the type of participation

Exactly. I also would prefer the other_details approach as it is ultimately more flexible, and will allow us to work with the RM, rather than against it, as we have to do now. It solves the problem both in composer and in participations.

[damoca (David Moner)]

FYI. In EN 13606-1:2008 the FUNTIONAL_ROLE had other additional attributes : healthcare_facility and service_setting.

[thomas.beale]

@ian.mcnicoll

The core issue is not really with Participations, it is that by design, the RM tries to keep any kind of detailed demographic details outside the CDR.

This is right - it’s an RM question.

@ian.mcnicoll

The argument has been that the CDR should never be the source of truth for more detailed professional demographics, which does make a lot of sense. PARTY_IDENTIFIED relaxes this rule a little to allow the professional’s name and ids to be copied into the CDR, to allow a little local sense-making i.e you can see the person’s name and identifier without having to track back into the formal demographics record via some kind of internal identifier.

The problem we see repeatedly is that local practice often requires more information to be immediately available in the CDR, typically at least a role or contact number, even if these are actually originally maintained in a separate demographics store.

This is the general problem. Even if there is a ref to a target in some EMPI or similar, name + phone (and apparently role) need to be instantly available, and some of these details would only.

At the moment, the main problem is usually that Entry.provider (the reporter of the information) isn’t a PARTICIPATION, but a PARTY_IDENTIFIED. If it were a PARTICIPATION, then we get the function attribute, and (when it is added) a role attribute.

For now, the best short term approach to representing ‘role’ information would be to:

• use ENTRY.provider to just indicate who the info provider is, in the usual way
• use ENTRY.other_participations to include a PARTICIPATION representing specifics about the provider participation - right now, ‘function’ is available.

The reason to do it like this is that current openEHR software expects to find participations in the RM-defined places. If they are additionally represented in some archetyped CLUSTER, most software won’t find that. Plus, in the long term, when improvements do come to the RM, then data in those CLUSTERs is doubly confusing - it will overlap even more with newer RM attributes (at least PARTICIPATION.role).

@ian.mcnicoll

I think there are 2 potential solutions

1. Extend PARTY_IDENTIFIED to add at least role and ‘speciality’ attributes. This alone would fix quite a few of the gaps in Participations and other places that PARTY_IDENTIFIED is used e.g. composer.
2. In addition, strongly consider adding an’ other_details’ slot to PARTY_IDENTIFIED to allow CLUSTER demographics archetypes to be plugged in. This would allow modellers to add any need demographic details to the correct part of the data tree, rather, as we are right now, having to add cluster archetypes to context or Extensions.

I would argue for both - the reality is that we cannot prevent aspects ‘practitioner demographics’ sometimes leaking into the CDR. Right now we are all approaching this in a slightly inconsistent way, Some small changes to the RM would let us regularise to some degree, and actually promote good practice.

Ideally role would be on PARTICIPATION, but since it would be a breaking change to change the type of ENTRY.reporter to PARTICIPATION, point 1. above may be the best non-breaking compromise. And since we assume that this won’t be the last such additional need that occurs, the second proposal above probably makes sense.

If this approach is followed, existing software can be modified to find extra participation meta-data in the RM expected place (PARTICIPATION and PARTY_IDENTIFIED) rather than in unknown places in specific clinical models.

[thomas.beale]

@damoca

But, pushing the RM to its limits, this can also be represented with the current attributes. Remember that the PARTICIPATION.function is a DV_TEXT and that the same person can have multiple participations.

I think @damoca 's solutions should be considered as well (one is the same as I propose - use other_participations). While we are trying to accommodate newer needs within the existing v1 RM, some ‘stretching’ is likely to be required. As long as everyone agrees on such flexible use of certain RM fields (and they are documented), systems can be extended to accommodate these new requirements.

[ian.mcnicoll]

but neither of these solves the problem of us needing to plug in more complex data structures, and into other places where PARTY_IDENTIFIED is used like composer/provider.

I’ll propose a change in JIRA re adding other_details to PARTY_IDENTIFIED. I think that is the cleanest approach. At least it gives us the opportunity to connect those structures to the optimal parts of the RM, rather than adding it ad-hoc to other_context or Entry level extensions.

What do others on the clinical side think?

[damoca (David Moner)]

The good part of doing that is that we will have a place to keep the record any of the historic attributes of the participant in the CDR, to know for instance what was the role of a person at that moment, something that can change in the future.
In the openEHR demographic model we have support of versioned Parties, so you can point to a specific version (i.e. role, specialty…) of the person. I’m not sure if this is so well supported in other demographic systems that might be used together with an openEHR CDR.

[sebastian.iancu]

Good discussions, I also support the idea of adding other_details as well as role and speciality or something similar - please make a the PR or CR ticket.

[mar.perezcolman (Marlene Pérez Colman)]

Apologies for the late reply. I’ll go over this with @johnmeredith to understand the process, or are you @ian.mcnicoll leading it?