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)
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.
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.
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.
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.
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.
