Alerts - it’s a big issue and I’m sure most would agree there is room for improvement.
I’m interested to hear of clinical examples that illustrate where our current alerts systems are not delivering what we need - that is to say not getting the right information to the right person at the right time as well as we could. Examples of what is working well would be good too!
Background
Alerts are typically stored in a variety of systems including:
National Medical Warning System
DHB Patient Adminstration Systems
Primary Care Patient Administration Systems
Orion Clinical Portal (“Concerto” or “Health Connect South”)
Electronic Prescribing systems (Medchart)
Other local besoke electronic clinical applications
Paper based systems, or unstructured “pdf” electronic documents
All these vary in terms of:
The amount of communication of alerts between each system above
Who has access to
Create an alert
View an alert
Modify or delete an existing alert
In the South Island region, we are looking at how to improve the functioning of alerts. It’s potentially a big topic and easy to let it expand to be something too big to solve. To help keep focused on what the problem is, I’m interested in hearing clinical examples (suitably anonymised or generalised) of how the current system is or is not working around the country.
Herein lies a nice Masters thesis for anyone who wants to do it as part of their postgraduate studies. A good challenge to investigate
would be evidence-based alerting in the context of the complexity of multiple software applications (dealing with a landscape of alerts in a broad context vs good alert design and practice in single systems).
Hey Damon,
Yeah, have spent a bit of time banging our heads against a wall about these issues here too.
There are a couple of separate factors which I think warrant consideration.
agree on a single “source of truth” for alerts. We chose the PAS, but the important thing is to have one place where alerts live, and all other “sources” simply replicate all or a subset of the alerts in the single source. Be careful around upload to a national system, and then double display of a single alert. The challenge for HCS is that is spans primary care to a greater degree than other instances of concerto.
Work out what alert types you need and how many, and ensure you have a couple of spares in your source of truth. In our PAS, we’re up against the system limit of 9 types, which is annoying. Consider who see’s what alerts. For example does everybody need to see that there is a dangerous dog on the property? What about who needs to see that there is a risk to staff from a violent patient?
Have some form of clinical governance around alert upload. This is hard, and I can find no way around having a clinical person do it. We have struggled to get the manpower to curate these locally
The goal is to make alert upload easy or accessible enough such that it will be done when appropriate, while avoiding clutter with things like “Morphine - constipation”.
My personal preferred solution (which I haven’t implemented yet) is a link in context from concerto/HCS which allows a user to submit an alert - that alert is then sent to the relevant clinical watchdog for upload or clarification.
If you want me to hunt down our alerts categories and share, I’m more than happy to do so.
Cheers
Mat
Thanks @damon sounds like you’re referring to alerts that can be constructed by at least a subset of users (e.g. adverse drug reaction alerts), as opposed to alerts that fire based on predicates set by the system (e.g. drug X prescribed with drug Y in prescribing software, which might be locally configured e.g. local informatics team, or determined elsewhere e.g. vendor).
Agree with Mat re need for clinical governance around alert upload. Prospective would be ideal if appropriately resourced i.e. a step between submission of alert and publication of alert, but even timely governance would be a massive advance over the current situation e.g. within a week of publication there is formal assessment and curation. These alerts are potentially more visible than diagnoses, and yet anecdotally seem to have lower validity e.g. “Penicillin - Rash and Almonds”.
I think that we need to define what we mean by alerts as well. With the ability of upcoming technology to create “alerts” regarding sepsis, AKI or raised EWS we should be including these as well. An example would be what type of alert requires a notification and what type of alerts requires a push notification. Human factors and alert fatigue would be important players in this area as well.
I totally agree with Damon and have been raising concerns about this for years!
2 other major clinical databases where alerts are captured but do not interface back to the core Patient Management System or link
automatically to the NMWS (just for the record… – pardon the pun) are Titanium and Mosaiq
My keto service (which covers only paeds at the moment) has recently been extended to the rest of the South Island and the type of alerts i generate includes, Emergency Keto plans with go with a “blue card” which summaries a child’s emergency medical plan, alert in Medchart for sugar containing medications (i.e. tablets instead of syrups), emergency letter for ED just in case they come in acutely (illness or accident) etc. These alerts are important because it helps to prevent breakthrough seizures from wrong treatment being used, which can land a patient in ICU.
The current system was functionally all right (in Canterbury for the last 3 years) even though all the information were in different places on HCS… but more recently with Cortex coming onboard, its open another big issue. We are now told that we have to change how we view our documentation on the CVD tree on HCS (thats a huge safety issue) as our Alert folder which clearly displayed at the top disappears when the documents are rearranged to view by service instead of category. I have highlighted this issue and am yet to hear of a suitable solution.
The alert that we input on SIPICS does not appear clear enough on HCS either.
I know it sounds naive but I dont understand why can’t one system coordinate all the alerts with other applications get “plugged in” to get their feed, so that you only need to change it at one source. Surely in the age where technology is at… organising documentation shouldn’t be that hard.
If you have any suggestions, i am all ears. i am hoping all this will be solved before it extends to the adult population.
Thanks for the great comments and feedback on this so far. I would be really interested to hear some clinical examples of what is and isn’t working as well. To get the ball rolling I have some from my experience at SDHB:
Good point
MEDCHART displays alerts from the National Alert Service and our Patient Administration System (IPM)
When a new Medchart session is started for a patient, these alerts are displayed to the prescriber and the prescriber is invited to enter them into MEDCHART if relevant.
This allows medication alerts to be seen by the prescriber at the time of prescribing. It would be better if the alert was in a more structured data form and could be uploaded to MEDCHART with a click, instead of being retyped.
Improvement needed
Alerts from the GP system do not display automatically on MEDCHART
GP alerts can be viewed via the “HealthOne” tab on our Health Connect South (HCS is the South Island’s version of Concerto). However it takes a few clicks to get to the GP alerts section, and you don’t know if there is going to be anything there until you look. Potentially alerts from the GP system could be missed when the patient is in hospital. (The right information may not get to the right person at the right time)
Below is a schematic outline of how alerts data flows at SDHB (credits to @lance.elder)
An example of alerts working well at CDHB is adverse drug reaction alerts that are inputted into a patient’s MedChart and a) autopopulate the discharge summary and b) the patient’s next admission’s MedChart. This is an improvement over the previous flow of data where the discharge summary ADR was autopopulated from the last discharge summary.
A double-edged sword with room for improvement is the display of at least 3 sources of ADR data on the patient summary screen in Health Connect South - I’m looking at a patient now where one source states rash to penicillin, another that there’s some unspecified problem with trienefloprim (a word so unique Google has 0 hits) and a third that says there’re no ADRs recorded.
Thanks for raising this topic @damon. It’s certainly been a difficult issue to land a clear direction on, and as has been stated in this thread, one of the main issues relates to governance and curation. This, in part, has led to silos of alerts across numerous applications, an array of ‘administrative’ and clinically related alerts (most often free text), and subsequently an erosion in information quality and confidence.
In the South Island, we undertook a review of the current ‘alerts’ landscape late last year. Perhaps unsurprisingly, the outcome of this indicated a less-than-tidy current state (illustrated in the attached diagram SI Alert Landscape.pdf (782.6 KB)) when looking at application level sources of local alerts data, and the view of these between systems (spoiler - there’s very little of that occurring!), or within a combined view, such as HCS/Portal. Even in the case of the latter, all five DHBs have different views of alerts within the patient summary screens within the regional instance, and in some cases, local alerts from PAS are not viewable in this context.
We identified some opportunities for improvement, which I’ll copy below, but ultimately what appears to be a key gap is a patient-level repository of structured data relating to identified conditions or concerns that may adversely impact on the care provided to a person, or on those providing it. While there are things we can do now to align policies and processes, as well as views of disparate sources of alerts, these aspects are really seeking to tidy up the current state in lieu of a robust national patient-level solution. The National Medical Warnings System, while aiming to fulfill this requirement, is subject to many of the issues outlined above - further complicated by the fact that very few applications in the current landscape are integrated with it (historically exclusively, and currently predominantly DHB PAS). The most recent version of the MWS data dictionary is dated October 2003.
As mentioned, identified opportunities from local alerts review (these are summarised, but happy to provide more detail if anyone is interested):
Opportunity 1 - Regional governance around alerts and adverse reactions
Opportunity 2 - Review and standardise the alert types in use across the region
Opportunity 3 - Standardise the view of patient alert data in HCS
Opportunity 4 - Combine available views of Primary and Secondary alert data across the Region
Opportunity 5 - Consider a standardised alert request mechanism(s) within HCS
Opportunity 6 - Align specific alerts with the electronic documentation or other electronic information they reference
Opportunity 7 - Address workflow issues within and between systems
Opportunity 8 - Join up the link between alerts and incident reporting
Opportunity 9 - Establish a business-led working group to define requirements and advocate for a fit-for-purpose national alerts and adverse reaction solution
GP MedTech user feedback: There are 3 main ‘alerts’ I experience-
‘Medical warnings’ field- I believe this is where most GPs look routinely, though there is variation, with some GPs preferring information in these fields to also be in classifications! This particular field in MedTech allows free-text and structured-entry, with the structured-entry being way too tedious (e.g., must select ‘drug class’ or ‘generic group’ and I’ve never understood the difference so have to try both, generally, to find the drug code I want) so most GPs free-text.
‘Patient Alerts’ field that is first pop-up when you open a medical file, and most GPs (including myself), click through without focusing on (alert-fatigue). At my main practice we currently have 37 unique-to-our-practice codes, that require manual culling and management that no one has time to do. Maybe 2 or 3 are occasionally used as part of query builds.
‘Interactions/warnings’ pop up when generating a prescription, that I never read as mostly irrelevant. If I’m worried about a particular interaction, I look up more detail in NZformularly or (becuase it’s integrated with MedTech) MIMS. Fairly confident that automatic ‘interactions/warnings’ are notoriously not used world-wide. Even though I never look at these warnings, I don’t have the psychological strength to permanently ‘suppress’ these warnings. Sigh.
Given the manual tediousness of classification and medication reconciliation when I receive discharge and outpatient information, I’ve never contemplated routinely reconciling incoming ‘alert’ information with my MedTech alerts. If it’s a new and significant problem, I expect this to be mentioned as part of the free-text narrative in the discharge ‘impression’. This is because I trust my alerts more than the hospital alerts that are automatically per-populated and I don’t trust the house surgeons, who generally write the discharge summaries, have actually taken a full alert history (nor do I expect them to, as the focus should be on the acute presentation history). Patient cannot recall the names of medications they’ve had problems with, so the GP record is the best longitudinal ‘source of truth’ for ‘alerts’, as it’s the most regular place a patient discloses problems, over their life-time. Ideally, alerts should be in a key part of patient portal, with the patient arbitrating what is, or is not, an active alert (e.g., vicious dog on property, etc). The patient can work with GP to confirm/review historical records of past medicine reactions.
Thus, I never/rarely would login to the hospital system to see what alerts are recorded there, as the return-rate for this being a useful and meaningful activity is very low.
PS- Definitely agree ‘alerts’ need more definition. For example, medicine allergy vs intolerance; significant medical classification (e.g., end-stage renal failure); resuc status; sensitive/confidential- need to be careful on who has access (e.g., domestic violence); behavior (e.g., drug seeking)- ideally this should be an alert for ‘patient contract plan’ or something, that patient has agreed to. All of these ‘alerts’ are patient-unique and, for me, more clinically relevant than the CDS, automatically generated, generic alerts (e.g., medicine interactions) . . . though, I hope in the future, we can have helpful, AI-driven targeted ‘warnings’ for things like triple-whammy prescribing (e.g., diuretic, NSAID, ACE) and/or concerning trends (e.g., drop in weight, rising HabA1c%), etc.
This is an important issue and there is possibly too much for an email discussion to cover all the relevant issues.
My background in this area goes back to my time at the NZF when I led the creation of a draft set of groupings for allergy and ADR checking and alerting. The objective was to create a customised open source data set that would replace commercial systems and importantly make clinical alerts more consistent and clinically meaningful.
I am unsure of the current status and operation of this work but my understanding is that the NZF groups are in operation within several systems in New Zealand.
I have continued to work with other clients on areas relevant to your questions and rather than give you a list of clinical examples I can offer a few possible solutions that may resolve some of the issues that will be identified.
There needs to be a central electronic health record such that medical warnings are available to all health practitioners. Currently information on the NMWS is not available to all practitioners.
There needs to be education and a process to triage and review alerts that are entered into systems - many current alerts are false positives because the observation is not an allergy or significant ADR
Transferring legacy alerts (e.g. in older systems to be replaced) is an opportunity for practitioners to review the veracity of the alert - e.g penicillin allergy
Systems and software developed (e.g. the knowledge base) needs to be flexible to allow adjustment of sensitivity and specificity which can occur on clinical review and confirmation of the clinical problem.
Systems need to have the facility for clinical details to be entered to give a subsequent reviewer the opportunity to confirm, question or remove an alert from the system
An interruptive alert needs to provide options and if possible an indication of the significance of risk of an adverse event. For example, angioedema with an ACE could provide guidance on the use of an ARB and the risk (very low) of similar event occurring with an alternative
7.Systems, including drug groupings and other grouped data need to constructed to allow interrogative alerting as well as interruptive alerting. Many adverse events may not surface at point of prescribing and being able to query patient data sets and combine with boolean logic will allow patients at risk to be identified.
That’s just a quick list and there is lot more. As I did not get the opportunity to continue this work within a national project framework, I have continued this with groups overseas, including the SNOMED clinical review group on allergy groupings.
I would be very happy to contribute to any national objectives that may be underway and can share additional thoughts and findings as appropriate.
Hi Paul I suspect that “trienefloprim” is ‘trimethoprim’ but who can tell? We have an issue that many antibiotic allergies entered in infancy are not in fact drug reactions but rash due to the viral illness for which antibiotics were never required. Sorting that our years later is a challenge so improving data quality is important. The data entry quality may influenced by clerical admin people being asked to enter information by clinical staff who are less familiar with the PAS systems than their clinical interfaces.
To some extent that will be mitigated by having writable clinical interfaces that feed back to PAS systems via the clinician’s preferred clinical information system but that doesn’t necessarily mitigate data quality issues.
Flagging ACPs and Child Protection Alerts are specific functions that should have their own categories. We need finer grained categories for HL7 data alerts, warnings and practice information.
I’d be interested to understand a bit more about the background of the “Alerts” entry in the CDV tree and how documents end up there. There have always been issues with this kind of method of surfacing alerts as some users elect to use a different CDV grouping and therefore wouldn’t see the “Alert” category near the top of the CDV. While Cortex documents also have significant metadata issues in the CDV their presence shouldn’t have made anything worse for the moment.
Recently work was done to ensure that (non-national) alerts entered into SIPICS are visible in HCS in the right hand side of the patient view along with National Medical Warnings. If the text that appears there isn’t sufficient then that’s something that can be addressed.
The core issue here is that an alert is quite distinct to a document in the CDV, the general intention would be for an alert to be short, visible upon initial viewing of the patient and provide info pointing to the presence of more complete information elsewhere.
Obviously these alerts being overlooked/missed has the potential for a massive impact on the patient and therefore I’m keen to see what we can do to ensure things are visible to everyone. The “Alerts” entry in the CDV has been discussed previously by the HCS Steering Group and I’m happy to bring it up there again so we can be sure what was proposed as the alternative will work in your case.
@damon wanted clinical examples. Woman in Gynae clinic examined appropriately BUT had severe reaction to the Latex she is violently allergic to. NOT noted on National Warnings. NOTED in the GP ADR record. Several points:
The GP Allergy list (and they tend to be Rx allergy / ADR and substance only, not vicious dog issues) is NOT visible to the many clinicians using HCS / Concerto as their daily view.
There are significant actual and perceptual reasons for access to the GP list not happening.
Question: Would the Gynae clinician automatically review HCS in the first place for each patient while running a paper-based clinic?
Comment. The least we can do is co-present ADR / Allergy info in each clinician’s ‘home’ working environment.
