Right - we already handle that routinely with the PARTY_IDENTIFIED and PARTY_RELATED types, which are the types of ENTRY.provider, and (via PARTICIPATION), ENTRY.other_participations and COMPOSITION.context.participations.
Just to agree with Heather and Vebjorn, that for good or bad we are frequently faced with situations where we need to embed small aspects of person information within the EHR. Sometimes this is ‘by design’ as per Vebjorn’s example, sometimes simply because the kind of technical/governance infrastructure that Thomas correctly suggests, is simply not available, at least in the short term.
As an example, we have been using a small set of archetypes based on the FHIR Care Team resource, which works well for various (often ad-hoc_ lists of important contacts - the might be global for a patient or more likely local to specific conditions or care pathways.
An example is on the ResPECT template. Ideally this would be managed by some sort of master list and not in the EHR at all but that simply is not available to us in either of tyje projects where this will be going live. Even if it did exist there may well be circumstances where some of tis information needs to live in-line (as per Vebjorn).
I am starting think that we need to fundamentally rethink this aspect of how we manage ‘demographic data’ . It is not the clean separation originally envisaged and is not well supported by the current PARTY classes.
1 Like
But these do not work, as we are missing role(s), which could be added to PARTY_IDENTIFIED but then we have a long tail of other, variable pieces of information - contact details, other comment, parent organisation details. None of that is supported by PARY_REF (as in-line data).
If we were to add an archetypeable other_details structure to PARTY, that would become much more useful. but I think we need fundamental re-think in this area.
2 Likes
PARTICIPATION has function; if that is not enough, it’s easy to add role as well.
Well as soon as you say that, we are just talking about the contents of the demographic model. So why wouldn’t we just use it and make references to common instances in a demographic cache in the EHR system? If you’re going to include all these details for Dr Jane Smith once, if you just do that inside Entries or Compositions in an uncontrolled way, you’ll do it again and again, and all those details will contain errors, gradually go out of date etc, and there is no way to keep them up to date.
Doing it with a demographic cache means the instances are properly modelled, archetyped, versioned, and maintainable.
I can’t see any argument for making all this ‘inline data’, but there are many reasons why we would not do this.
BTW I am assuming that there are really three kinds of demographic data we want to capture:
- A: informal data of non-professional persons related to the patient, e.g. parent, friend, person who brought them to A&E etc
- B: thumbnail info for clinical professionals - name & identifier(s) - that could be used to look up the professional in an MPI later on
- C: reliable and detailed demographic data for clinical professionals
A & B can be done with inline data (already handled by the model); C can’t safely be done by that method (the problem of errors, no versioning) - it needs proper modelling and representation.
1 Like
Just thinking about this scenario: is the argument to push ‘proper’ demographic data into the EHR simply because most implementers have not implemented the demographic model? And the workaround today is to put all this stuff into archetyped Observations, Evaluations etc, inside the EHR?
I would suggest the options are:
- A: do inlined demographic information in the EHR
- B: build a simple demographic DB within the EHR system, i.e. old-school tables, and refer from EHR Entries to those entities
- C: implement the demographic model as a versioned demographic cache within the EHR system
A is potentially quick but has the problems of data inconsistency - uncontrolled copies, errors, etc.
B would be pretty quick, and solves the inconsistency problem, since you have one instance of each demographic entity. This solution can also be replaced by a later implementation of C.
C will take longer, but all the modelling and many archetypes are done (and the archetypes are easier), and adds versioning as well.
1 Like
A few more thoughts percolating in my mind as I was out walking…
Let’s say an area health service has 1,000 clinicians, and they have average 10 contacts / day, x 300 days in the year. That’s 3million contacts. With no common repository for their details, that’s 3 million replicated data entry events. Normally we want to avoid that.
For solutions/products that have only a CDR and no demographic capability today, there is an easy hack that will solve the problem, which is:
- create a special EHR (possibly with a special UID, e.g. 0000 …)
- use that to store Compositions containing ADMIN_ENTRYs, containing the demographic details of interest, probably one Composition per entity. They will be versioned in the normal way when changes are made.
- use
PARTY_PROXY.external_refto point to these.
I still think this is only marginally quicker to implement than a local demographic cache containing PARTY objects, but one attraction is that it should be completely possible with no software changes to an existing CDR product.
2 Likes
As @heather.leslie mentioned at the start of this thread, several things have been found to be needed both in EHR and DEMOGRAPHIC space.
Here comes a (possibly stupid) question from me, related to this discussion:
Why are CLUSTER archetypes prefixed with EHR or DEMOGRAPHIC?
Now we for example have both:
openEHR-EHR-CLUSTER.death_details
and
openEHR-DEMOGRAPHIC-CLUSTER.person_death_data_iso.v0 (plus
openEHR-DEMOGRAPHIC-CLUSTER.person_other_death_data.v0)
If it for example would be the case that some CLUSTER-archetypes like these could be useful in both EHR and DEMOGRAPHIC use cases, could we not then have more neutral CLUSTER archetypes like
openEHR-CLUSTER.death_details.v0 or openEHR-DATA_STRUCTURES-CLUSTER.death_details.v0 that could be used in both?
Item structure and CLUSTER classes are neither in EHR nor in DEMOGRAPHIC models, they are instead in the sibling level Data Structures Information Model
I can imagine many detail CLUSTER instances that one at certain points would want to copy from some registry/catalog/demographic data and into specific EHR documents, It would be convenient to be able to reuse exacty the same archetyped data structure for both.
@thomas.beale and others, are there historical reasons for the EHR/DEMOGRAPHIC-prefix of CLUSTER ARCHETYPES? Was the data structure package and CLUSTER originally part of the EHR model before being moved to a separate reusable model?
2 Likes
In an archetype id like openEHR-EHR-CLUSTER.death_details , the structure (as I think everyone knows) is
publisher-Model-Class.concept.version
where the Class is reachable by the ‘model’ referred to by ‘Model’. Here EHR means the EHR ‘model’, i.e. the EHR IM part of the RM.
In Task Planning we can therefore have:
openEHR-TASK_PLANNING-COMPOSITION
because the TASK_PLANNING model uses class COMPOSITION.
Back to CLUSTER… the assumption made in the existing CLUSTER archetypes is (AFAIK) that the CLUSTER would only make sense under an EHR model top-level object, or a DEMOGRAPHIC model object (PARTY or whatever).
If they could be used in either place then we could solve this by sticking with the original archetype id, and in the appropriate slot in say OBSERVATION or the using archetype, just make sure that the regex pattern pointed to the correct archetype, i.e. openEHR-EHR-CLUSTER.death_details.
So I am not sure if there is a concrete problem, and indeed, such a slot regex makes it clear that somehow the EHR is reusing a ‘demographic’ concept.
If this were not enough, we’d need to invent some special pseudo model name like GENERAL that would be detected by tools, and that starts to look like work…
I share the idea that cluster can be generic, not EHR specific. And I like the flexibility of getting clusters reused outside the EHR model. Another example is CLUSTER.device. And maybe many others.
But I do worry about the migration work, every archetype and template and stored composition ever that uses a cluster would need to be migrated…
1 Like
What migration do you mean?
Replacement of the regexes and use_archetype reference that now point to e.g. openEHR-EHR-CLUSTER.device.v1 and afterwards should point to e.g. openEHR-GENERIC-CLUSTER.device.v1
I was not really suggesting we do that; as far as I know the current tools have no problem with either openEHR-EHR-CLUSTER.device.v1 or openEHR-DEMOGRAPHIC-CLUSTER.device.v1, and it’s easy to make a regex allowing both:
openEHR-(EHR|DEMOGRAPHIC)-CLUSTER\.device\.v1\..*
2 Likes
They could do it but they don’t do it right now. At least not the Ocean / Better tools @yampeku . I’d be in favour.
If regex are correctly defined, then no problem including any of the archetypes that are allowed in that regex. Demographic clusters are allowed to be created/edited in linkEHR in any case
2 Likes
If we want to add a choice of also picking some more neutral string (in addition to the present EHR or DEMOGRAPHIC) for the model part of publisher-Model-Class.concept.version, then such an ID choice/renaming could in the future be considered…
- …when a new CLUSTER archetype of shared interest is created or…
- …when for some reason a new major (breaking) change is needed anyway for a CLUSTER archetype of shared interest
1 Like
I would assume that other things apart from archetype_id could be used for slot definition, probably things like TYPE or CLASS (e.g. “TYPE=‘CLUSTER’”), BINDING (e.g. BINDING=<<SNOMED-CT::1234567), and maybe even some special keyword to mean “anything valid at this level”
Our practical experience of regex definitions in slots has been to make minimal use and only as ‘suggestions’ as to appropriate / intended archetypes but nothing more. The only place where we mandated a specific archetype (medication dosage) has just had a CR to be relaxed (I agree).
2 Likes
Regexes are not the big problem, agreed.
But ‘every’ (adl2?) template has a (usually many) USE_ARCHETYPE constraints right? Those would have to be updated if the ID of the cluster changes. Doing that with a major version change makes sense I agree with @erik.sundvall. Otherwise every CDR and design tool should know about (EHR|DEMOGRAPHIC) forever. And that’s just technical debt you don’t want right?
‘use_archetype’ is not technically a constraint, it’s a slot-filling statement, and it will be made with ids of archetypes available at the time. So templates are pretty safe from that point of view.
If someone wants to go and change ids of archetypes, that’s a whole other situation. Normally no-one should be doing that, other than in the version id part at the end, other than for v0 archetypes, where anything goes.
Those regexes are ‘allow_archetype’ statements - that’s the slot definer, i.e. 'what can go here. For slots that have any kind of demographic meaning, ‘EHR|DEMOGRAPHIC’ might make sense, but there are better ways to define slots that are more of a semantic constraint, and can be based on other things has @yampeku said above; if we had a subsumption operator on archetype concepts (e.g. roughly << /*.exam.*/) then it would be more powerful.
1 Like
At risk of poking bears again on this topic, I’ve just sent out the 5 demographic EHR archetypes for review again. All 5 candidates can be viewed in the Demographics EHR archetypes project
In anticipation of pushback again from the technical/specs purists, we understand your issues but there are many clinical and/or modelling use cases that require these models. I am certainly getting repeated requests from modellers - ‘We really need these archetypes’! One of the most critical use cases is to consistently record information where the person, organisation or address will never ever be found within any relevant registry/index/service.
All archetypes are a careful, simplified subset of ISO 22220, but avoiding all the attributes that are required for managing identity/addresses etc, so you’ll see no valid dates or types of use etc.
We have gradually refined the metadata, based on misunderstandings/brilliant insights/feedback/pushback to describe the use of these archetypes as:
Use to record details of a person/structure name of a <person/address/electronic communication/ organisation> as they are known or understood in the course of clinical documentation, often ad hoc or when it is not appropriate or possible to use a formal demographic register/index or address lookup service.
Misuse always states context-appropriate statements such as:
Not to be used to represent or replace formal identification management or for the purposes of maintaining an official demographic register or index. Use a formal Health Provider Index for this purpose, or archetypes based on the openEHR Demographic Information Model.
Not to be used to represent the location of care and similar data elements that should be represented formally in the health record using the Reference Model attributes.
These archetypes are out for review until April 8. If you would like to participate and have not received an invitation in your email box today please adopt each archetype and you will be added.
Regards
Heather
5 Likes