National Medical Warning System and patient alerts - is there any work in progress on this under Te Whatu Ora or HIRA?

Discussions
, ,
21

This certainly is seeming promising for med reconciliation . . .perhaps a ‘virtual place’ for that reconciliation, that then automatically updates medical lists in all the EHRs a single patient has medication lists (e.g., pharmacy, outpatient, hospital, GP practice - patient portal)?? It does seem things are moving in the right direction!

No doubt, AI will also help with this process and with a bot to pick up a past intolerance or failed treatment, that is inadvertently being trialed again . . .but the patient doesn’t recall the intolerance/failure, and the prescriber is a new prescriber . .

The interface of how the medical lists are presented to users, to visually highlight changes + be functional for searches + contain some unstructured data to explain changes will also be important.

The future is looking more promising :wink:

22

Kia ora team,

2 years gone since this discussion and … nothing changed?

I am wondering how different places manage MWS. We have our local alerts as well as MWS and sometimes they do not match, sometimes MWS does not make sence and there are not guidelines or any advice what to do with those.

how do you manage them locally? How do you ensure they are up to date?

Thank you.

23

Well, the big fat financial axe falling on Data & Digital 1.5 years ago kind of destroyed virtually all forwards momentum on that (and most other) front(s), sadly.

The good news is that a core piece of work in this area has survived and remains alive:

@MValentine - are you able to share anything about Alerts / Allergies and how it is likely to work?

24

Why yes, thank you for asking @NathanK .

The Shared Digital Health Record (SDHR) will get allergy/intolerance information from GP PMSs and make them available in its data service, initially available through SEHRs like HealthOne and Your Health Summary. Unfortunately much of this data is poorly coded and structured. It will definitely add value and safety as free text, but it’s not really in a state that we can reliably reconcile it with other systems or use it for any kind of decision support.

The National Medical Warning System (NMWS) used in secondary care is also entirely free text. It has some structure for categories of alerts, such as allergies, but not really within categories. As part of the Hira programme we were working on cleaning up and structuring the allergy/adverse reaction information but didn’t have time to complete it. It lives on to small degree in the Allergy/intolerance standard for NZCDI.

We would love to improve both systems and hope that with new opportunities that grow out of SDHR as well as the Centre for the Digital Modernisation of Health that we’ll have the opportunity to do so. One thing that will be necessary though, and that the clinical informatics community can help with, is to support clinical leaders and services to be the clinical owners of such systems, i.e. take the responsibility and accountability for the systems. Digital can build and operate them, but ultimately they are clinical tools and need clinical leadership and governance.

Let me float a question to this audience - this is just me talking and not any sort of Health NZ plan at the moment - what do people think of the idea of a single national repository for allergies/alerts that’s shared across health in NZ? One repository that our PMS and portals and specialist systems can all integrate with, with a robust structure to ensure good quality data? No more having to copy new allergies from one system to another? The MedChart rollouts around the country have shown that effective structure for allergy/alerts can be done, so should we do it on a larger scale?

4 Likes
25

We already have a medical warning system that to some extent contains warnings about verified allergies, e.g., to medications. So, are you talking about a system that contains information about unverified allergies, e.g., self-identified allergies? Is there a reason why the existing system can’t be expanded?

26

Unfortunately, “to some extent” is doing a lot of heavy lifting in that sentence. The current system does not capture any structured information about allergies/intolerances or reactions. There are multiple spellings of words like “penicillin”. It’s just a 70-character free text field. It can be displayed in-line in secondary systems but is not suitable for direct ingestion into prescribing system. It is also on a pretty old platform. Replacing it with a modern FHIR service and structure would be the way forward. Whether that is “replacement” or “expansion” is a semantic discussion - technically it needs to be replaced in order to expand its clinical function.

It’s also not true that our systems only have verified allergies. Yes, some are entered via CARM, but I’ve had plenty of patients who have an allergy to penicillin listed in the NMWS and asked them about it, and they say something like “oh yeah I think my sister had a reaction to it when we were kids and so my mum told me never to take it”. That kind of provenance (or lack thereof) is not captured currently. Putting better structure around allergy records would help with this.

2 Likes
27

Thanks Matt. I’ve always wondered how well the CARM system works, e.g., do docs have time to verify an adverse reaction and do the documentation? It’s a pity that it’s not well-used as it supports safe care. I agree re ‘my cousin is allergic to x medication and I’m not prepared to have a go with it’ kind of allergy must be recorded but can’t be verified. It’s a pity we can’t have a system that enables that (and is fully compliant with interoperability and can be analysed for research and is transferrable and shareable. Surely we’re approaching an age where this kind of data sharing should be mandatory.

Thanks for all the hard work that you and Te Whatu Ora staff are doing towards making clinical content more shareable.

3 Likes
28

Thanks Matt. 100% we need to be looking at a single repository, rather than tinkering with existing processes and solutions that are simply not fit for purpose. While we have MWS, it hasn’t met the mark for many years (despite various localised attempts to manually enforce some standardisation around entries). In reality, document templates hold a lot of this critical information in large part because that’s where clinicians capture it, and silos of digital paper is still largely how we enter and view information sadly. Peter Jordan’s comments about definition are critical. We need to think more broadly about a repository for patient-level structured information, with appropriate categorisation, provenance, severity and guidance. Adverse reactions are one use case, but there are others. SDHR will help aggregate the silos, but to your point, this still enables those silos to exist.

2 Likes
29

Hi @MValentine, just chiming in with a comment from the sidelines here…

The MWS is currently integrated with all PASes around the country, regional clinical portals, and probably PMSes (don’t quote me on the latter). Inadequate as it is, any improvements to it would need to be backwards compatible with the crude plain text version we have now, else it would break those integrations.

Retaining backwards compatibility would of course encourage the same garbage in, garbage out problem we have today.

So mine is a vote for a replacement system, or perhaps to add this dataset to something like the HDP and then publish it as a well defined API supplemented by a NEMS event.

1 Like
30

Totally agree, Hamish. All the old info will need to be migrated or maintained, or preferably reviewed at least. I have seen two patients in my years who had NMWS entries for “large ears”, and I don’t think those need to be maintained.

The PMSs do NOT have access to NMWS, and one would certainly expect a modern system to be available to primary as well.

2 Likes
31

One big fat “Yes”. Whatever now is in NMWS is in the terrible state, with a lot misspelling or none-confirmed/nonexistent allergies like: “Vegetables, soups, gravy.” this is a worse example I seen. Due to the fact, that we cannot trust this information we are not paying much attention to it. This is bad practice. Ideally, one database with appropriate coding, maintenance and governance should be across whole country to ensure patient safety regardless to the type of care patient receives.

Regards

1 Like
32

Medicines / ADRs are my thing and I stumbled accross this thread in a forum I neglect. A big credit to Nathan and others for conversations, communication underpins health - communication is sharing information. Right information, right place, right time for health care is a daily clinical challenge. I spend most of my clinical life creating, changing, sharing, managing information in a world overwhelmed with information sources and types. My eyes and ears when I meet a patient being primary and clinical records being secondary. The marvels of bespoke individual information that can be generated from a drop of blood or a brief dose of radiation are extraordinary. The volume of misinformation generated in well meaning efforts are tragic.

Re GIGO, when Canterbury changed PAS from HOMER to SIPICs and rolled out MedChart we had to decide w legacy data. It was both low validity information and not cost effective to migrate. It was kept accessable as ‘history’ to inform entry of ADRs into MedChart (source of truth for ADRs), as each patient admitted to hosptial. It was seledom even used. Of the alert types, ADRs are a big one. Sadly most is crap, but some is critical to care. The critical information is not able to be extracted from the NMWS or other secodary sources, it is in critical places such as resuscitation records, anaesthetic letters, discharge summaries, clinic letters, GP notes, If you are going to drill for oil, pick your drill site carefully.

ADRs are a diagnosis & aetiology that informs future care. The diagnosis is what happened to the patient, the aetiology is often more than one factor. Diagnoses are hierachical in detail at level sufficient for given decisions, e.g. shortness of breath < heart failure < left ventricular failure with reduced ejection fraction < mixed mitral and aortic valve disease < pergolide. Aetologies need to be suspected and ascertained. When I am deciding whether or not to treat your loved one with a medicine I need more than an alert of a possible ADR, I need access to the detail of what happened to weigh up alternatives. The alert is my link to the record of the original event.
At the time I record an ADR I can’t decide future care, I don’t know what future circumstance will arise. I can record accurately what happened this time in a way that is useful for future decisions. Alerting systems can deliver that information at the time and place it is needed.

Diagnoses must be editable - and the history of editing viewable. Aetiologies must be editable. They may be subsequently refuted or subsequently emerge.
An event has happened to a person at a time in their lives - it is one event and the information linkage is needed. Wrong diagnoses or aetiologies need to be corrected and findable. It’s complex information dynamics usuing a few simple information elements. A person, a date, a problem = diagnosis, suspected aetiology(ies). Where the suspected aetiology is a mediicne there is a batch specific record of administration or dispensing. Suspected = linking this to the diagnosis event/record. Fundamentally simple but…

For example rash caused by amoxicillin. Firstly rash is not a diagnosis, their mother can tell me they have a rash, a more detailed disgnosis is expected when you see the health system. Secondly causal attribution is unreliable, most patients (>98%) with a label penicillin allergy can safely have penicillin. We spend a lot of time and effort ‘delabelling’ misdiagnoses of ADRs only for them to be added back as the new information hasn’t stuck.

Design to the future not the past. If someone has an ADR today, what information is needed where and how is this subseuqently managed?
The first information is something has happened (diagnosis), that this may have been caused by a medicine is the second information. The exposure to the medicine is sitting in an administration or dispensing record i.e. link the second information to the first, don’t create a new information entity that is unlinked and probably wrong.

Kapai, thank you for being interested colleagues who care. Multi-D is more than clinical skills, informatics is at the heart of care. thank you.

5 Likes
33

Thanks @Matt_Doogue for your interesting unpacking of the problems associated with wanting more information (processed data) to feed knowledge (capacity to act) to provide better health care. The more I learn about knowledge and knowledge management, the more I see it as a process where we build one decision on another decision and then on many decisions. It’s the process we need to get right so that we can preserve and build the knowledge to make it relevant and useful every time we need it. Information technologies are good at collecting, storing and retrieving data for us - as you say, we need more than that. Perhaps AI (well designed, carefully curated) can help. It can’t create the future (that’s what humans do), but it can give us a good picture of the past and help us with the knowledge process we need for making good decisions. Your thoughts?