What kind of additional information you would like to record?
At least a person’s name would be good.
Still thinking on this subject …
Would something useful to have something like DV_PARTYxxx, having PARTY_IDENTIFIED or PARTY_PROXY as value ?
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.
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.
I’m fine with it as long as we don’t end with an empty class…
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.
I seem to remember we discussed this, although I could not find a PR for it. But it would be easy to do.
I would suggest not - this is a class that will only work in the demographic model to represent relationships between PARTY instances.
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.
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.
@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?
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.
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?
1 Like
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.
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.
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).
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.
I see a couple of things here:
-
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.
1 Like