the idea of the “demographic service” is to keep the “current” status of demographic entities managed and up to date.
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.
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”.
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 (Common Information Model), 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?
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
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.
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.
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.
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.
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.
Well in a Generic_entry, 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.
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?
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.
I’m trying to catch up with discussions here - so far the following conclusions/proposals:
we will add role attribute (DV_TEXT ?) to PARTCIPATION
PARTICIPATION.performer is most likely a PARTY_IDENTIFIED, which can refer to a ‘proper’ PARTY instance, via the already existing external_refs attribute (type PARTY_REF).
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).
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.
I mostly agree with what @sebastian.iancu says - my hack proposals are not made with pleasure
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.
