I remember seeing an evaluation (openEHR-EHR-EVALUATION.alert.v1) and composition (openEHR-EHR-COMPOSITION.alerts_list.v0) archetypes for patient alerts on CKM, which I cannot find both anymore, although I have them saved on my computer.
I did some research on them before and decided to use them in the future (now ) in order to keep compliant with the archetypes on CKM.
What is the reason for the removal of these archetypes?
Are there any substitutes? I see there’s an evaluation archetype called “Precaution” but the purpose and description does not really match what I want to do.
I see that Apperta ckm has the alert evaluation archetype, but it does not have the same data points as the one I have - I mean, I can still use it, I believe some data points were deleted because they could be redundant, but I though I was playing in a safe area since the other archetype was a v1 with published state, and the new one in apperta has a team review status since july. Not really sure what’s the best way to proceed on this one.
It was rejected 5 years ago by @heather.leslie , and the Log message is: “Avoiding use of ‘Alert’ at present until clear use case is identified within the Therapeutic Precautions suite of archetypes.”
I must admit that I don’t remember all the discussions leading to the rejecting, to my excuse I must say that it was in my earliest years within the editorial group.
Nevertheless, if you now have a use case, it might be a good time to start the work with the precaution/alert/nota bene type of archetype. Can you describe your requirements?
Seeing this alert data is mostly labelling some info in some other composition as worthy of an alert. We could make a FOLDER.alert and link the data worthy of an alert from there.
But it will be harder to implement in the frontend compared to just an eval that may duplicate/paraphrase some info. E.g. do not resuscitate is clearly stored in the eval.advance intervention decisions and could even be automatically linked to FOLDER.alert. But where to store aggressive behaviour? Probably there’s some place to be found. But it makes sense to start recording this info from clicking the alert. Now the implementer will have the problem of where to store this info. Could do both folder and eval as well?
The scope of ‘Alert’ has always been the issue (and at the heart of why it has been difficult to develop).
I don’t think we will ever find a clean answer but there IMO is a need for a ‘fall-back’ generic alert archetype for simpler use-cases, where there are very significant issues that merit ‘double-alerting’ or where the other alert-warning style archetypes do not fit.
Currently we only link the resuscitation data in alerts to the primary data source (not openEHR data yet). There are three other categories of alerts, aggression, infection and warning, this data is not linked to other data. Each organisation can set up with alert types they want to allow users to record. And they can encode the different alerts:
What do you say about my proposal of modelling alerts as a FOLDER? Where every datapoint can be an alert as well. And an EVALUATION.alert for information that is a warning and not otherwise present in the EHR in a structured way.
Interesting - traditionally we have managed these kind of ‘curated’ lists or groups within a single composition but I think it is worth looking at other approaches - e.g. grouping based on queries, folders or tags -. Apart from anything else it may be easier to handle situations where an original Entry archetype is stored in a different Composition.
What I like about the folder approach is that it prevent data duplication (and all it’s problems like possible inconsistency, duplicated maintenance etc). What I like as wel, is that it makes it easier to get “more info” so in case there’s a do not resuscitate recorded in the COMPOSITION.Advance Care Plan and you link that to the FOLDER.alerts, when viewing the patients alert it’s easy to click through to the original data and get the data in original context. (Needless to say inconsistency in DNR info is one of the worst things to happen).
And when the original data is altered it’s easy to update the alert on that data as well.
And finally it’s probably semantically more faithful, since alerting is more about labelling some info as alert than recording a alert in itself (if that’s what you want to do an EVAL.alert would be best).
Alternatively we could stick to an persistent COMPOSITION.alerts with multiple EVALUATION.alert which has DV_URI for the original info and a optional DV_TEXT for the message to the reader. E.g. uri to a eGFR lab result (CLUSTER.lab analyte) and text “carefull with antiobiotics since slow kidney function”. But I think often just labelling a value in any composition is enough.
Folders can’t be in a composition right?
Hi all,
We’ve implemented an alert template which makes use of a new archetype based on the ZIBS model. The archetype is here and the template is pretty basic because… it’s a fairly rudimentary use case from our perspective. There is a categorisation embedded into the application itself to constrain the SNOMED CT search, but this is not present in the archetype.
We’re going to do another pass on our archetype - I have just completed the review round but do you @vanessap want to be involved in a design session to see if we can make it work for both of us?
At the Swedish National Board of Health and Welfare there has been some interesting work (done by Rikard Lövström and others). The spreadsheet https://www.socialstyrelsen.se/globalassets/sharepoint-dokument/artikelkatalog/klassifikationer-och-koder/2020-12-7122-bilaga-3.xlsx in various tabs contains an intersting mix of things that are useful for alerts. Some of them would be best recorded in specific archetypes like the ones discussed above, but some would likely be better implemented as AQL queries looking for certain diagnosis, lab results, medications etc.
Example: below, the tab of the excel sheet labeled 1.1. lists codes for some patient conditions/diagnosis where “standard clinical care /medications” would likely cause damage
Rikard and I spent a lot of time talking about this at the time. His ideas informed mine significantly, and I was disappointed when it was not taken up by ISO as a standards.
But it also made me more aware that we should not model an alert as a single concept, in fact that we need to identify the types of alerts and model them explicitly and precisely. Hence my advice to ‘run away’ when someone wants to model a generic alert - because everyone uses the term differently and the semantics can only be confused.
Edited to add:
The Medinfo link from Rikard’s site has been hijacked to refer to online gambling and I can’t access the other material but if I remember correctly the concepts of precaution and contraindication specifically came from Rikard’s work and he was involved in the reviews.
As a CKA, I recognise the tension between what is in systems (& working with FHIR) vs the way we should model clinical medicine into the future. If the alert archetype ever gets reactivated in the international CKM, it should only be used for legacy or integration purposes. It is tempting to lump all sorts of ‘stuff’ into an alerts, as we have always done, but really the work needs to be done to understand what is meant by ‘alert’ and model each of these types of alert so that each is fit for use. The blog post was a first step towards that… and the matching Project (already containing 10 archetypes) that I think has already been shared, and somewhat ironically named ‘Warnings and Alerts’ (because no one would likely go looking for 'Therapeutic precautions )
sorry for late reply, i have been quite busy. I will reply to everyone in a single post
@varntzen
Thanks for the information. i totally forgot to check the lifecycle tab.
i was asked to make an alerts template, very similar to the fhir flag/alert encounter in the “most generic way” (which i never know what that means tbh without proper context, i am still waiting for more information for the last weeks). For now this “alerts” case will be feeded by other external system with all the possible patient flags that can come it, but it might be transforming as the underlying DM/template of a core module in the future in the system I am working in. My problem is - how to define what is an alert in the various clinical settings? How this data should be saved - a persistent composition or event one? by event i am affraid of how much duplicated data can be in, since there will be no channel validation at my side.
@heather.leslie thanks for your blog entry, very useful, it replies to the most doubts i had and made me think in a more broader way for this case.
Hence my advice to ‘run away’ when someone wants to model a generic alert - because everyone uses the term differently and the semantics can only be confused.
yes, i fully agree with you on this one, overall expectation from requests is to do it most generic as possible so all type of data can come in…
@johnmeredith it would be nice if i could be present in the design session, is it still on? I would need to make a final decision until final of this week
Please, let me set the record straight: I’m not from ZIBs, aka the Zibcentrum, part of Nictiz, but I work for VZVZ and am asked to advise the Zibcentrum on the product vision. In my role at VZVZ I have also participated in the working group that developed the Zib MedicationContraindication.
Coming from a primary care EHR vendor I have been discussing the Zib Alert and it’s many purposes for the last 7 years now and I fully agree that each Zib/archetype should have just one purpose.
The Dutch primary care has a standardised datamodel that is used by all primary care EHR vendors and this datamodel also has different locations for the various purposes attributed to the Zib Alert, making it even harder to properly convey and store the intended information.
The fact that MedicationContraindication is now separated from the Zib Alert is based on the facts that there is a national list of Contraindications (going beyond just medication) and there are datasets and implementation rules that make it possible to automatically signal adverse medication during prescription or dispense based on the conditions registered for the patient.
) in order to keep compliant with the archetypes on CKM.
)
most generic as possible 