As I 've said above my work does not normally include anything for which I feel a great need for a GENERIC_ENTRY class as I rarely work on ‘pure’ integrations but within that there are 2 areas that cause me grief when trying to integrate external data (or fit with a national ‘schema’ as per in Finland, which I suspect are pretty universal.
Demographics entities which need to be carried in the EHR space. I’ll make some suggestions in a separate thread but briefly -
PARTY_PROXY as a datatype, so that it can be added as an ELEMENT.
other_details ‘slot’ in PARTY_PROXY allowing item_xx or cluster
add ‘role’ to PARTY_IDENTIFIED.
These changes would go a long way to making it easier to integrate with messages and systems and where there it is not possible or practical to properly normalise/reconcile these entities into a demographics server.
'Observable elements. ’
There is a big push to move Observation the information around vital signs, patient wearables etc. I am seeing a lot of this being done at Element level (not exclusively via FHIR Observations) but with a similar single-element value - basically a name (often loinc-coded) , a value and a unit. We can argue that our approach of chunking these things up into Observation classes is a better long-term approach but finding a scalable solution to importing these values is difficult. We generally have no control over which data are sent. This is the exact use-case in Finland (not using FHIR but similar loinc-coded name-value pairs and UK GP systems will do something very simialr.
My immediate solution was to create physical measurements observation archetype, which is not dissimilar to the lab approach where the individual observable is expected to be coded (LOINC or SNOMED) and therefore queried that way.
This works fine for the pure integration phase but there will be a point where some systems are providing e.g properly modelled 'pule rates (using the Pulse observation archetype) whilst others are still populating the generic structure. I want to be able to query both directly via the associated code on the ‘observable’.
What needs to happen next is that we can do a CONTAINS OBSERVATION CONTAINS ELEMENT el … WHERE el/code MATCHES loinc xyz.
I appreciate that this may be tricky to make preformant but it might be possible to tag certain elements being observables, and therefore carrying codes and a target for better indexing.
I think this second use case is very much aligned with the “generic registry” proposal. Organize data points the way you want and give them meaning. I would say that querying by the meaning would be the minimum support to these generic classes EHR systems should provide.
Also related to your post, I’m actually not sure about changing the RM itself to try to fit these non-openEHR things (possibly creating several ways for modellers to model the same thing). Making it a completely different part of the RM should be enough to let modellers know the final purposes of each class, arguably easing openEHR overall understandability.
sure but in my world this is very much a mixed economy - not aspearate registry and as as we go along, archetypes will cover what for now is only supported in the generic format … or customers want to bulk import stuff into the generic format but use ‘proper’ archetypes for new/internal data.
I don’t understand [A] - why would a PARTY_PROXY need to be added as an ELEMENT anywhere in an openEHR RM structure (other than something like GENERIC_ENTITY, or whatever @yampeku comes up with)?
[B] - probably OK, and easy enough to do.
[C] - also easy.
I will note that this creeping addition of demographic data to the EHR model is likely to create problems in the long term - because it’s creating uncontrolled copies of data rather than references to anything reliable (and normally available).
Really we should just implement openEHR demographics as a versioning demographics cache…
Right, but that’s some other model, it’s not openEHR. openEHR RM is a model of coherent committed data, not ad hoc retrieved data.
If we want to persist ad hoc retrieve results (which is what FHIR structures are), they need to go into a different place and have their own model. Even openEHR query results should not be stored back in the openEHR EHR.
These are qualitatively different things.
Having a technology-neutral query service sitting over cached queries and EHR data… I’m not sure if that makes sense. The primary danger is that you have no idea what copies of things are in the FHIR or other retrieve results. Queries that include previous query results will in general return multiple instances of the same thing.
I don’t understand [A] - why would a PARTY_PROXY need to be added as an ELEMENT anywhere in an openEHR RM structure
What I remember was mentioned a few times in the last year is a DV_ kind of a type which can hold reference to a party together with some extras, like those provided by PARTY_IDENTIFIED and perhaps also PARTICIPATION … but all these are not extending DATA_VALUE, so cannot be added to an ELEMENT.
These kind of information can currently only appear as ENTRY.subject, ENTRY.provider, .other_participation etc, and I think was mentioned in the past the need to be able to use on ‘other places’, archetyped.
Right - that’s what I’m asking - what are those other places? Currently, all the places that a PARTY could make sense in the main RM already have a specific attribute for that, as you mentioned.
The author information is not about the EHR entry but about the author of the resource. In this example, it might be desired to use a PARTY_PROXY I guess?
Look at section 7,8,9. Sections 7,9 we could probably handle with participations if we were able to add role to PARTY_IDENTIFIED + other_details.
In the lab archetypes we need a place to handle the lab details, lab contact details - names, places, people - hard to squeeze into participations or other RM attributes.
Again possibly feeder_audit or participations might work but we need yo be able to extend PARTY_PROXY with other_details and find a better way of making these visible and locally meaningful in the template. It is just really hard to explain these things to devs and clinicians alike.
If I understand what I am seeing on that template…
Section 7:
if this is the actual clinician signing the current form, then it should be an ENTRY.other_participation - that’s exactly what that’s for; only problem is that it doesn’t give you ‘role’. We could add this easily enough to PARTY_IDENTIFIED, which is where I think it should go, if ‘role’ here means ‘HCP’s employment category / post type’ etc i.e. ‘role’ isn’t an artefact of this involvement, it’s a property of the kind of person who did the signing, e.g. presumably things like ‘family practitioner’. Note that you already have ‘function’ in PARTICIPATION, which in this case would be set to ‘signing clinician’.
Section 9 participant is called ‘review of plan’. I’m not clear on whether this means someone who has reviewed this current plan, i.e. participated in the act currently being documented, or if it’s trying to stipulate an HCP who should review later. Seems like the former to me. In which case, it should also be ENTRY.other_participation. Same situation for adding role.
Section 8 appears to be listing any number of emergency contacts, which can be anyone, to be contacted presumably in the situation where the patient is found in extremis by the health system. These are not participants, this is just contact specification information. I would be using a plug-in CLUSTER archetype which I think you already have, that ideally follows the Demographic model’s PERSON structure.
I think for sect 7 and 9, the fact that actual other participants are not represented as ENTRY.other_participations is an error, since a query on the data looking for other participants will fail to find these ones, which presumably are in fact centrally important to this kind of form. In the very short term, I would remodel that and add an extra ‘role’ data point in protocol (admittedly not clean), but we can add PARTY_IDENTIFIED.role quickly, and add it to the BMM instantly, which means it will instantly be visible in the AD tool (well, as soon as the updated BMM is loaded by an admin). The change would take a bit longer to flow through Archie native RM, if anything (e.g. CKM) is relying on that.
Section 7 and 9 I agree - we had already been discussing that, although as you say we do need role as in employment role (in the context of this participation - some people have multiple contracted roles). The Review date is a bit confusing but we are now clear that it is a set of past reviews not scheduled future reviews.
However we were lucky in this case that there was not other requested info e.g contact number - that is where we also need to have an other_details ‘slot’ to allow for CLUSTER archetypes to be plugged in.
Well that’s true technically if people are searching for other participants, but that is very unlikely - they will actually be searching (if anything) for ‘signing clinicians’ and that is one of the weaknesses of current approach - we are not able to frame the use of generic structures like other_participations in local ‘business terms’ - and probably a big reason why many modellers just go for demographics clusters and ignore other_participations. I’m not defending that but I know that it makes documentation/explanation much easier, and the lack of role and other_details really hampers alignment with external feeds.
I’d be delighted if we could extend PARTY_PROXY (other_details) and PERTY_IENTIED with role but we need to get CDRs to support that as well, so need quick buy-in there.
Section 8 is a IMO a good example of where PARTY as a datatype would be helpful. In the short-term the Emergency contacts are likely to be hard-wired into this composition but the direction of travel is that the list itself is local but the parties are references to external resources - most likely to be FHIR resources around a proprietary demographics- that’s why we have replicated the FHIR Careteam resource and related resources. But the key thing here is the junction point into the actual local clusters or external references which really should be a PARTY_PROXY -esp if extended as above with other_details.
I’d have to say, putting cut & paste contact info for HCPs directly in the patient record isn’t a great idea in the long run. That info is usually maintained elsewhere. The copies made of it (probably with errors that will no doubt be made) will degrade in the long run and could get in the way of safe care.
Right, but to do that, you query for other_participants where function = 'signing clinician'. The local business meaning of the involvement of the participant is the ‘function’ attribute, unless I’m missing something.
Well, in openEHR a ‘data type’ is a logically atomic leaf value item, while PARTY objects are large structures containing many such leaf items… if implementers are going to support PARTY objects, why put them in the EHR data? It’s a small step to put them in a demographic cache.
Then the contacts list for a patient can be constructed as a set of refs in the EHR to the relevant PARTY objects. These would be expressed with the new DV_OPENEHR_URI (today, just DV_URI). So the contact list would then just be a CLUSTER of ELEMENT containing DV_OPENEHR_URIs.
We could in theory also make a DV_ form of OBJECT_REF from which PARTY_REF inherits, to express the references.
