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\..*
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
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…
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).
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.
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
Hi, Would you label the demographics related achetypes as ‘clinical’ or ‘admin’?
Hi Archana,
These ones in the Demographics EHR archetypes project are developed using the EHR reference model, based on ISO standards, and intended for clinical modelling or documentation purposes only.
They are definitely not intended for use as part of a formal demographic service.
IMO DEMOGRAPHIC model on the CLUSTER archetype ID is wrong, since CLUSTER is defined in the representation package inside EHR.
It would be useful to contemplate these use cases against the current models to find the gaps, since @thomas.beale keeps finding ways of modeling different use cases with the current model. On the other hand, modeling tools are not there yet with the demographic model, maybe if tools allow to use the demographic model in full, we could use that model more. It’s also true that the current demographic model needs some fixes and have been left aside from reviews and improvements in the last 10 years.
The issue is not really that there are gaps inthe spec or models but these are the issues we encounter…
For clinical users it is not uncommon for us to be asked to carry a few more details in the CDR than is allowed for in the RM e.g. in a recent project we have been asked to carry the clinician name, ID, role and speciality in the CDR. THis information is maintained in a staff directory but we do not have access, and the customer has sked us to put these detailsin the CDR for clinical sense-making.
Similarly external reports like lab reports often carry additional information like lab address or lab specialist contact number, and these need to be stored in the CDR, as these details are not otherwise accessible, other than from the lab message.
There are other structures like Emergency personal contacts or professional contacts that are specific to care pathways. In theory, the professional contacts should be maintained in a demographics store but of then this does not exist, or is not accessible/maintainable and even if it , it may not support the additional requirements for Emergency contacts.
Unfortunately the inability to extend PARTY . PARTICIPATIONS in the RM via a cluster slot means that we often have to add these EHR Demographics clusters in odd places - this often means that we have to ignore Participations (see project above) and essentially recreate Participations in a Cluster archetype that does allow some extensibility.
Adding a other_details slot attribute to PARTY_IDENTIFIED would go a long way to making this much more rational and understandable to modellers.
Having said that the basic problem is that in many/most of the projects we have worked with right now it is simply impossible to have a completely clear separation of demographic details into the demographics space, and that is probably never going to go away.
This really has nothing to do with the Demographic RM or models, or indeed tooling.
I think we agreed on this in principle a long time ago, although I can’t put my finger on a CR or PR documenting that so far.
But do you want another Cluster inside PARTICIPATION as well as one on PARTY_IDENTIFIED?
As we’ve discussed before, over the course of accumulated events in thousands of health records, much of this data will be replicated through all those records, since the labs and other imported data come from the same places (for the receiving institution that has the EHRs). Errors and omissions in recording that data can’t be realistically fixed, because there will be no way to track them.
I don’t know whether such replication is currently thought to be the preferred solution, but it sounds pretty bad from a data management perspective.
An easy solution architecturally to address it is to create a special ‘EHR’ within an openEHR CDR EHR service (I have proposed in the past, with a special number ‘0’, i.e. the Guid ‘0’ or some other special Guid) that contains normal Compositions containing ADMIN_ENTRYs containing the relevant provider demographics. These would be archetyped using the EHR flavour of demographic achetyped, but would also be properly versioned, and would be referenced by the PARTY_IDENTIFIED EHRs in that service. This will give the effect of close to having a versioned demographic service without actually doing so, and would require minimal engineering by CDR implementers.
Doesn’t that have more to do with the implementation than IM or archetypes?
I mean, what the user sees is not only information from the CDR, each screen has integrated information from many sources, CDR included. So the requirement of having some data physically stored in the CDR is more a technical decision than a user requirement, isn’t it?
For instance, in Atomik we support storing EHR and DEMOGRAPHIC in the same physical database, based on respective EHR and DEMOGRAPHIC OPTs. Then the end user in the end system will see the same information independently of which repository was used to store the info. The same thing would happen if an architecture has 10 different systems like an MPI, clinician directory, CDR, contracts, consents, admission, etc. all as different services/repositories, the user, at the end, will see all information integrated in one screen. Of course, for this to happen, the platform should be capable of resolving those references between different repositories, so the end user doesn’t really know where is the data physically.
Note this is in the tone of a question, I don’t have strong opinions about what Heather posted initially, just curious about if that is the best solution or if it’s just an interim one while we fix the demographic model and modeling tools.
Same question, are not accessible because of technical implementation constraints of because something that has to do with the IM or archetypes?
That might be actually a gap between requirements and IM/archetypes. It would be worth to specify the requirements, document the gap to the current demographic IM, and use those notes as input for the new entity model.
That’s kind of the question to answer: why is that? is that demographics lack expressiveness? because modeling tools don’t support demographic archetypes and templates in full? because modelers are not familiar with the demographic model? because implementers feel it’s convenient/easier/direct to do it that way instead of pointing to the demographic model via PARTY_PROXY?
Again, I don’t have a strong opinion here, just trying to understand since I’m not 100% convinced that this is the right path or the only path.
The discussions have not been with the leaders of the clinical modelling efforts in CKM.
As I’ve said before, there is a serious disconnect between specs program decision-making and modelling program requirements. Nothing has changed.
If both aren’t operating in sync then the organisation has a problem.
Well we have had numerous technical discussions over the years on purely architectural concepts. As I’m sure you’ll appreciate, the technical part of any organisation needs to have such discussions in order to get its ideas straight.
We have had many subsequent discussions that have included yourself and other clinical modelling experts. No doubt we need more.
Let’s continue to look at the details of what is needed to marry technical good practice (e.g. non-replication, sustainable modelling, representational clarity) with clinical and business needs and realities. That’s what this discussion is for.
Wouldn’t the NL conference be a good place to have a SEC + Clinical discussion on open topics?