This post is a follow up to a previous post about the PCEHR review, where I promised to talk about medications coding. The PCEHR review quotes Deloittes on this:
The existing Australian Medications Terminologies (AMT) should be expanded to include a set of over the counter (OTC), medicines and the Systematised Nomenclature of Medicine for Australia (SNOMED-CT -AU) should become universal to promote the use of a nationally consistent language when recording and exchanging health information.
Then it says:
Currently there are multiple sources of medication lists available to the PCEHR with varying levels of clinical utility and functionality. From some sources there is an image of the current medication list, from some sources the current medication list is available as text, from some sources the information is coded and if the functionality existed would allow for import and export into and out of clinical systems as well as transmission by secure messaging from health care provider to health care provider.
Note: I’m really not sure what “there is an image of the current medication list” means. As a separate choice to “list is available as text”, I guess that implies it’s actually made available as a bitmap (or equivalent). I’ve never seen anything like that, so I have no idea what they mean.
The NPDR should be expanded to include a set of over the counter (OTC) medicines to improve its utility.
Over the counter medication is essential to detect such issues as poor compliance with Asthma treatment, to show up significant potential side effects with prescription only medicines and to allow for monitoring and support for drug dependent persons. The two main data sources of data are complementary and neither can do the job of the other. The curated current medications list together with adverse events, could be sourced from the GP, Specialist, Hospital or Aged Care Facility clinical information system, the discharge summary public or private is immediately clinically useful and will save time for the clinician on the receiving end.
It is imperative that further work be done on software systems to make the process of import and export and medication curation as seamless as possible to fit in to and streamline current workflow.
- Extend AMT and NPDR to include over-the-counter medicines
- Work with all the providers to get consistently encoded medicines and medication lists so the medications can be aggregated, either in the PCEHR or in individual systems
Well, I guess this means pharmacists only things (such as ventolin, which they mention) and doesn’t include supermarket type things like aspirin or hay-fever medications. I don’t know how realistic this is from a pharmacist workflow perspective (e.g. getting consent, signing the NPDR submission), but let’s (for the sake of argument) assume that it is realistic. That will mean that each OTC product they sell will need to be coded in AMT (once AMT is extended to cover them). I don’t know how realistic this is – can it be built into the supply chain? Let’s assume that it can be, so that pharmacists can make this work, and that we’ll then be able to add this to NPDR.
However there’s a problem – this recommendation appears to assume that the NPDR is already based on AMT. I’ve got a feeling that it’s not. Unfortunately, good information in public is not really available. By repute, AMT adoption isn’t going well.
Is that true? What would really be helpful in resolving this question would be to fill this table out:
|First Data Bank|
Where each cell contains 3 numbers:
- Number of systems certified for PCEHR connection
- Number of documents uploaded that contain codes as specified
- Number of medications in PCEHR coded accordingly
Some notes about this table:
- Even just gathering data from the PCEHR to fill this table out would be a significant amount of work – it’s not just running a few sql queries. And even then, it wouldn’t cover non-PCEHR exchange – if it did, it would be even more interesting
- Although a system may encode medications in one of these coding systems, some medications might not be coded at all since they don’t appear on the list of codes. And some systems encode immunizations differently from medications and some do it the same (ICPC 2+ is used for immunizations by a few systems)
- Although most medications use codes in production systems, for a variety of reasons many medications in the PCEHR are not coded, they’re just plain text (in fact, other than the NPDR, I think plain text would be the biggest number). I know of several reasons for this:
- There was no financial penalty for not coding medications at all
- The PCEHR system returns warnings and/or errors if the medications are not coded the way it supports
- The PCEHR system is extremely limited in what it does support
- There’s no systematic way to find out what it does support
- Trouble shooting failed documents is extremely hard for a variety of reasons
- There’s lack clarity around safety and where liability falls when aggregating
- note: I don’t claim that this list is complete nor have I assigned priorities here
If we saw the counts for this table, we’d have a pretty good feel for where medication coding is in regard to the PCEHR. And I’m pretty sure that it would show that we have a long way to go before we can get consistent encoding.
Consistently Encoding Medications
Getting consistently encoded medications list is far more difficult that merely getting alignment around which technical coding system to use. Beyond that, different systems take different approaches to tracking medications as they change. For instance, the standard Discharge Summary specification says that there are two medication lists:
- Current Medications On discharge: Medications that the subject of care will continue or commence on discharge
- Ceased Medications: Medications that the subject of care was taking at the start of the healthcare encounter (e.g. on admission), that have been stopped during the encounter or on discharge, and that are not expected to be recommenced
There’s a hole between those two definitions: medications that the patient took during the admission that have residual effect. But many discharge summary systems can’t produce these two lists. Some have 3 lists:
- Medications at admission
- Medications during inpatient stay
- Medications at discharge
Others only track medications prescribed by the hospital, and not those already taken by the patient, or if it tracks those, it does so as text. Some systems don’t know which inpatient medications are continuing after admission or not. Even if the system can track these medications in fully coded detail, there’s no guarantee that the clinical staff will actually code them up if they didn’t prescribe them. Some institutions have medication management systems that track every administration, while others don’t.
Finally, there’s the question of to what degree GP’s and specialists record medications that are not relevant to the problem(s) they are interested in (particularly specialists). Humans (or clinicians – I’m not convinced they’re the same things 😉 ) are good at dealing with degeneracy in these lists, and it saves them a lot of time (mention a medication generically, but no relevant details). Computers are not good at dealing with degeneracy, so in the future, the clinical staff will all have to be unerringly precise in their records.
Note that I’ve moved into pure clinical practice at the end there; in order to meet the PCEHR goal, we need to align:
- Medications coding
- Medication tracking system functionality
- Clinical practice
And while we’re at it, we need to jettison the existing data which will be come legacy and no longer useful to all the existing systems.
I’m not holding my breath. The PCEHR review says:
The PCEHR Value Model suggests that of the total gross annual theoretical benefit potential of eHealth in Australia, medication management is the greatest individual driver of benefits ($3.2 billion or 39% of gross benefits).
I’m not convinced that will be a net profit 🙁
p.s. does anyone know where the PCEHR Value Model is published?