The following announcement appeared a day or so ago.
NEHTA announces the availability of Australian Medicines Terminology (AMT) Release 2.11
28 May 2010
RELEASE NOTE
AMT Statement of Purpose
The Australian Medicines Terminology (AMT) has been developed to be fit for the purpose of unambiguously identifying for clinicians and computer systems, all Therapeutic Goods Administration (TGA) identified 'Registrable' medicines marketed in Australia, and is therefore available to be represented in acute sector clinical information systems for the following activities:
• Prescribing
• Recording
• Review
• Supply
• Administration
• Communication of the above in a Discharge Summary
While systems developers and end users might choose to deploy AMT or information generated from AMT enabled systems for purposes other than those described, no assessment with regards to fitness for purpose has been made by NEHTA.
NEHTA Announces the Availability of Australian Medicines Terminology Release 2.11
The latest update, Release 2.11 of Australian Medicines Terminology (AMT) has been published, and is available for download from NEHTA’s Secure Website. AMT is freely available for e-health software developers to use in their Australian products, under NEHTA’s licensing arrangements with the International Health Terminology Standards Development Organisation (IHTSDO®1).
AMT does not provide total coverage of all products used in the Australian health sector. As a result, it is continuously updated and releases are issued on a monthly basis. Updates include additional data items, and refinements as identified by stakeholders.
The 28 May 2010 release of AMT contains all the Australian marketed products that are included on the Schedule of Pharmaceutical Benefits, including the Repatriation Pharmaceutical Benefits Schedule (RPBS). This release includes products that become available as PBS products on 1 June 2010.
The full release notification can be found here:
This has all been going on for quite a long time.
AUSTRALIAN MEDICINES TERMINOLOGY RELEASE 1.0.0
Release Notes
19 December 2007
NEHTA publishes the Australian Medicines Terminology Release 1.0.0
Australian Medicines Terminology (AMT) Release 1.0.0 has been published. This comes after an extensive development phase incorporating feedback from our stakeholders. The scope of this release is limited as described below, and information on upcoming releases and their contents will be published as they become available.
Australian Medicines Terminology (AMT) Release 1.0.0 is an extension to SNOMED CT and access is limited to those holding license agreements managed by NEHTA.
The development of Australian Medicines Terminology has involved analysis and review by NEHTA, and has incorporated feedback from stakeholders.
The Australian Medicines Handbook (AMH) reviewed AMT and provided a report of recommendations. This is available on NEHTA’s website1. Key recommendations, as identified by NEHTA, have been incorporated into this release. A meeting held by NEHTA with stakeholders in December considered the remaining recommendations from the AMH report; the outcomes from this meeting will be posted on the NEHTA website and incorporated into subsequent AMT releases.
This release contains medicines from the Australian Register of Therapeutic Goods (ARTG) that are included in the Schedule of Pharmaceutical Benefits as published on the 1st December 2007, and includes over 3,500 products. More Pharmaceutical Benefits Scheme (PBS) items will routinely be added to the AMT through monthly updates to the Schedule of Pharmaceutical Benefits.
Inclusion of non-PBS items listed on the Australian Register of Therapeutic Goods will also be added to future releases of AMT. NEHTA will work closely with TGA and PBS to identify issues and ensure AMT is updated as new products become available.
----- End Extract.
Indeed it goes back much further:
In a NEHTA document dated 14 August, 2006 we have the following:
Document Title:
FACT SHEET - NATIONAL MEDICINES TERMINOLOGY
NEHTA’s Task
There are numerous systems that document drug information in Australia, all of which require slightly different information and perform slightly different functions. These include: TGA (ARTG) Register, PBS Schedule, state-wide and local hospital drug formularies and proprietary drug files such as those used by the medical software and knowledge resource industry.
NEHTA aims to ensure that terminology used for the naming and identification of all medicines registered and listed with the TGA is standardised across all e-health systems used in Australia. This will be done by developing a standard medicines terminology which is accessible to all.
NEHTA’s medicines terminology will deliver:
• A standard means of identifying branded and generically equivalent medicines; and
• Standard naming conventions and terminology, to accurately describe medications.
NEHTA will work with industry and international experts to develop the standards, specifications and infrastructure necessary for this task.
The Australian Catalogue of Medicines (ACOM) is an important contributor to this project and will be the central source of up-to-date trade product information to the medicines terminology. ACOM is available to the pharmaceutical industry to populate with current and standardised product data.
Additional Requirements
The Australian medicines terminology is also designed to:
• Be an extension to the nationally agreed terminology for all clinical terms used in Australian healthcare, SNOMED CT;
• Be used by e-health systems in both hospital and community settings;
• Be extended to include the identification of extemporaneous formulations as well as clinical trial drugs; and
• Have the ability to be extended to include medical devices.
----- End Extract.
The purposes for having a medicines terminology (among others) include:
- Facilitating e-Prescribing and Medication Management.
- Reduction of Medication Errors
- Enabling Improved Accuracy of Medication Recording.
- Improving Clinical Trials and Medication Research.
- Assisting in Providing Quality Clinical Decision Support
For this to work properly and practically ALL prescribeable medications must be covered and covered in all their presentations (packaging etc). That is why this incomplete coverage is a major barrier to effective use.
They say:
“AMT does not provide total coverage of all products used in the Australian health sector. As a result, it is continuously updated and releases are issued on a monthly basis. Updates include additional data items, and refinements as identified by stakeholders.
The 28 May 2010 release of AMT contains all the Australian marketed products that are included on the Schedule of Pharmaceutical Benefits, including the Repatriation Pharmaceutical Benefits Schedule (RPBS). This release includes products that become available as PBS products on 1 June 2010.”
You simply can’t make effective use of a terminology that only covers a proportion of what is prescribed and used.
I am also told the present data formats in which the terminology is provided are less than ideal.
Just why is it – after so long - this is just not done and dusted so the only updates are for new and deleted medications - as it has been promised and should have been.
Some good questions on this in Senate Estimates would not hurt! It is just hopeless.
David.
41 comments:
I think you are way off base here David.
Firstly I will put a standard disclaimer that I am on one of the NEHTA 'support' groups for the AMT (on a voluntary basis) because I think medicines terminology is a building block that Australia must have. So I think a national terminology is a good idea, but I also think there is money to be made by helping software developers adopt and use the AMT - so there are my biases out in the open.
Now onto the main thrust of your argument which seems to be that because the language of the AMT README file indicates that not everything is covered, you seem to think that they are not doing anything, and that the AMT can't be used.
I would have thought a quick actual read of the README files would have shown you that it is not like the AMT has stood still - from AMT 1.0 which covered 3,500 products, AMT 2.11 now has 11,192 products.
And in fact, if you used some journalistic devices like 'email' - you might have bothered to email the AMT group at NEHTA and find out what exactly isn't covered, rather than basing your 'commentary' on README files and anonymous tips.
Certainly every product listed on the PBS/RPBS and the VAST majority of current TGA listed drugs are in the AMT. I can't put it as a percentage, but would imagine it is a pretty rare GP who would ever want to prescribe a drug not in the AMT.
There are also continual discussions/work surrounding scope, and filling in any gaps
(these have all been considered and discussed in
meeting I have been to - I don't know what their current work status is)
a) historical TGA listing
b) special access scheme drugs for hospitals (registered through the TGA, but these are drugs not for general sale in Australia)
c) herbal products
d) early access drugs such as drug trials etc
e) devices
Now these all require stakeholder involvement and work on how exactly the modelling and editorial rules should work (i.e. the answers are not self-evident and doing it is hard). But I can assure vendors that the gaps are so small that they could either be ignored, or filled with local terminologies if required.
> Some good questions on this in
> Senate Estimates would not hurt!
> It is just hopeless.
I have some questions that perhaps you might answer. How exactly do you think anyone else would do things better? Do you think people just aren't trying hard enough? That the wrong people are doing the work?
You realise that we could disband the AMT group tomorrow and we would go from having an 'imperfect' Australian medicines terminology to having NO Australian medicines terminology. Or perhaps you could get all your favourite Australian health IT anonymous sideline snipers, lock them in a room with Senator Boyce and an all-star management team, and do you know what - it would take them a couple of years and they would roll out an Australian medicines terminology that is almost exactly the same as the current NEHTA one. And it would have the exact same results as the current AMT in terms of not having 100% coverage. That's because the easy issues were dealt with at the start to get to 99% coverage. And 99% coverage covers the vast majority of use cases for 99% of the people. All that's left are hard issues, which NEHTA seem to be working through methodically. I'm not sure what more you want them to do?
Sometimes NEHTA and government deserves a kick up the bum, and sometimes the building blocks are actually progressing exactly as knowledgeable people would expect. Unfortunately, we seem to be devoid of a media/blogging community who have the skills to tell the difference.
Andrew
Andrew, what you are saying sound like good news however it has been a very long time. Can't anything actually get finished. The test in my mind is which products, which are in active clinical use, have deployed the AMT? This project has been underway for over 4 years.
I am sure you have a list. I note BP is actively promoting how they are using MIMS.
I am sure stuff it happening and that is good but why so slow?
Get it done, fully and properly and move to routine care and maintenance. Can it be that hard?
David.
David, I think people have a unrealistic expectation on timeframes when it comes to anything that involves computer software development. In terms of actual development/rollout - adopting the AMT could easily take a year or more before appearing in a real product on someones desktop. That's just the reality of the timeframes of a plan/develop/test/deploy cycle in software. And that doesn't include tender/budget process. If I was a big hospital, I can imagine the process before development would also take a year or more.
And as you quite rightly pointed out, an incomplete set is not useful. So way back in early 2008 when there were only 3,500 drugs - I wouldn't expect vendors were even looking at the AMT. Perhaps the reality is that the AMT wasn't a viable terminology set till 2009..
Now?? I hope vendors do take a look. I believe there are some vendors who are in planning/development - but perhaps they are just sticking their toes in the water and having a paddle. I have no idea if they plan a roll-out with real users.
Vendors I think have the quite realistic attitude that 'enabling' e-health for the rest of the country at great expense and time to themselves is not a good value proposition. So I have no illusions that vendors will adopt AMT without carrots and sticks. But that's health IT politics - I'm just a technical guy so I leave that to others.
But I also know that without AMT we'll get to some point were everyone has discharge summaries and referrals whizzing around electronically, and the best a computer will be able to do is display them onscreen as a blob of text (because the Cerner hospital system says aspirin is 34322 and BP say aspirin is 656477). And quite frankly that's just depressing.
Andrew
I hope so too. But they won't until 'victory is declared' and NEHTA says this is ready for 'prime time'!
Thanks very much for your input!
David.
Hi David,
I am less than impressed with AMT because it is very close to a flat list of drugs and is NOT an extension to SNOMED-CT but is standalone.
I appreciated what Andrew Patterson says in terms of coverage, my beef is the lack of semantics and the inability to use AMT for allergy checking. This makes it useless for Clinical decision support and inadequate for use in a Personal Health record. Yes it does function as a common code for drugs, which is useful - but it should not be called a SNOMED-CT extension as while it may have codes that are valid the semantics are missing.
I don't expect it to provide extensive drug information in the way that MIMS does, but I do expect it to be able to tell me that Amoxil is a type of penicillin and be able to record penicillin allergy in a PHR record.
Its the lack of a cohesive plan that allows this to happen. If Nehta could grasp the way the pieces fit together this type of omission would not happen.
"I appreciated what Andrew Patterson says in terms of coverage, my beef is the lack of semantics and the inability to use AMT for allergy checking. This makes it useless for Clinical decision support and inadequate for use in a Personal Health record. Yes it does function as a common code for drugs, which is useful - but it should not be called a SNOMED-CT extension as while it may have codes that are valid the semantics are missing. "
So what we have is agreed to be incomplete - as yet - and not useful for its most important purposes (decision support, allergy checking).
Just what then justifies taking 4 years to get to something that is pretty much useless for what it was intended?
David.
What justifies taking 4 years to get to something that is pretty much useless?
That is the essence of the issue. Andrew McIntyre as a clinician, a developer and head of a successful health software organisation in health informatics makes more sense than most.
Andrew Patterson too makes some good observations and is reputed to be technically highly competent. Unfortunately he lacks the clinical depth and experience of the health domains to validate some of his views. This is unfortunate, but commonly the case in health informatics. This is the very reason why a combination of the skills and knowledge of the likes of Andrew Patterson and Andrew McIntyre need to be married closely together with the objective of overcoming these deficiencies in communication and avail 'architects and develpers' of the deep knowledge and insight required to address such 'clinical informatics' issues as these two experts gentlemen are currently discussing.
Hopefully they will both agree with that view. If so, extend the thought process a little further and I submit you have the answer as to why it has "taken 4 years to get to something that is pretty much useless?"
From the moment NEHTA was formed this position was put and rejected. It has been put time and time again to NEHTA and some of its Directors over the ensuing years and by the looks of things continues to be rejected. Perhaps it might have been possible to cut that 4 years to 2 had NEHTA been a little less arrogant and prepared to listen a tad more.
Andrew and David (and anonymous),
What frustrates me about this debate is that despite you clinicians having 'depth of clinical knowledge' and 'experience in of the health domains' (apparently an anonymous person on the internet knows that I don't have any experience of the health domains - which leaves me wondering what I've been doing for 5 years) - you continually want to have a debate in the shallowest of terms, and make glib points without acknowledging other points of view. That may help score points with people who don't know the area, but to those of us who are familiar with the issues I find it annoying.
As I posted on Andrew M's blog - I make the effort to 100% understand his point of view regarding the lack of links into the substance hierarchy. Now I personally may not fully agree, but I can understand for his 'use' cases it may be frustrating that AMT doesn't work this way out of the box. And as I said on his blog, it was done this way both for historical reasons, and because there is a genuine debate around the correct boundary between assertional knowledge, and terminology definitions. But to continually present this as if NEHTA didn't know anything about the domain, or as if they wanted to have a 'piss off Andrew M day' is just not correct.
So I would once again make the point that AMT is perfectly capable of allergy checking and recording at the substance/ingredient level. It does not have the 'classification' of drugs (such as ACE inhibitor, penicillin class etc) and links into SNOMED at this point because the entire SNOMED substance hierarchy is being redesigned (at an international level - not NEHTA). Furthermore, this is bread and butter for knowledge sources such as MIMS which have these tables putting substances into 'classes'. So I think the general consensus is that this may be better enabled by knowledge vendors (but I am not wedded to this idea - I am open for convincing).
But if this is the only issue that is stopping Andrew M from using AMT then perhaps we can make an effort to solve this problem. Perhaps the AMT group can produce a list of substance mappings into SNOMED? Perhaps MIMS can publish a specific AMT substance classification table?
All I know is that perhaps unlike the rest of the NEHTA work program, the AMT is 2-3 years further along the path than doing nothing (they needed to establish relationships with the TGA, work on TGA data cleansing/accuracy, set up a publishing pipeline, quality assurance, agree on medicine data modeling etc). This is not as trivial as people seem to be making out.
So we can disband it now, and have these arguments again in 2-3 years time, or work on the process of continually improving what we have.
Andrew
Hi Andrew (P),
I guess it comes down to expectations and mine are a lot higher than yours!!
I do not believe that the SNOMED-CT debate that is going on is about making SNOMED-CT a flat list of codes, as that would destroy its value. The debate is about classifying drugs into use based groups as well as families.
The structural hierarchy which makes penicillin a parent of amoxycillin is not up for removal in SNOMED-CT. If it was then SNOMED-CT would bemove useless for its usual roles.
The fact is that the SNOMED-CT hierarchy, without using the contentious areas remains very useful for allergy checking and decision support and if AMT was an extension of SNOMED-CT, as was proposed, then it would also be useful for these things.
I do not think you should have to pay for MIMS to check that amoxicillin is a type of penicillin!!
I think you are casting the restructure in a way to broad a way and its not an excuse for not linking AMT to the SNOMED-CT core. My impression has been that its safer to have no semantics because with semantics there is some risk and governments are risk averse. This annoys me as I and every other doctor are faces with the allergy checking risk every time I prescribe. I would have thought that 50 pharmacists and 4 years would result in better allergy checking via AMT than I could do using wetware. Its their job to provide reliable allergy checking. I would be happy to deliver that given the same resources put to bear on the AMT so far!
> I guess it comes down to expectations
> and mine are a lot higher than yours!!
I'm meant to be the naive one! My expectations of government are generally low enough that I am rarely disappointed. But I do like to recognise when I think people are moving in the right directions. And I can't find anyone who disagrees that we should have a national medicines terminology. And the AMT has both funding, and is 2-3 years into the process. So that puts it way ahead of anything else I can imagine would replace it.
> The structural hierarchy which
> makes penicillin a parent of
> amoxycillin is not up for removal
> in SNOMED-CT. If it was then
> SNOMED-CT would bemove useless
> for its usual roles.
Agreed - but the current substance hierarchy is a mix of structural classification, functional classification and usage classification all curated by hand into a large and complex ISA tree. The redesign (I believe) aims to retain an ISA hierarchy on chemical structure, and move other assertions into different relationships. And eventually, of course, AMT should link into this hierarchy. But I think you are being unfair in saying that just because it doesn't, it makes the AMT a flat list of codes. The AMT clearly has a fair bit of modelling structure inside it (albeit not as far as you would like it to go).
Your point about risk aversion is well taken, though I have never heard anyone use that as the justification for why knowledge assertions shouldn't be in terminology (I think the reasons are broader than that).
But I also think it is unfair to place any blame for the nature of risk aversion at NEHTA's feet. There are much more complex issues regarding our litigious society, and the completely unfair expectation the public and the legal system has on doctors to be perfect. But I think you would understand why the software industry and government may not be going out of their way to join in that particular fray.
Can someone explain what is in AMT that is not in MIMS? Has AMT be build from scratch, or has it reused existing knowledge resources?
I would categorise MIMS as a "printable" knowledge source with computable components, but I'm not sure it would have been usable as a national terminology. In fact, not being critical of MIMS, it probably has too much in it. So it has information like PBS prices, drug schedules, but also lots of data that is suitable for "printing", but perhaps not suitable for "definitional" knowledge that
would be expected in a terminology.
But I could be wrong - perhaps it would have been possible to make a stripped down version of MIMS as a terminology. But I presume there would have been commercial considerations that ruled it out as well.
The resource that the AMT used was the source data stored by the TGA (who after all, are the ones who get it direct from the drug manufacturers). But my understanding was that it took a bit of too and fro and processing to get the TGA data with enough rigour to be used for terminology purposes.
I would hope knowledge vendors like MIMS would embrace AMT as well. I mean whether we call "aspirin 100 mg table" 54, or 345345345, is not really a way of differentiating your product. But if knowledge sources at least have AMT codes in their data, then doctors and software vendors can have a choice of First Databank, or AMH, or MIMS for their knowledge sources - i.e. competition based on the quality of the product rather than having to use MIMS because your software only has MIMS codes.
I understand that it is always easier to be on the sidelines or in the back-seat driving but could we come back to a point raised earlier what exactly would you do differently given the opportunity and how would you ensure clinical safety and more importantly ensure that there are people out there able to understand these products in order to support them in a maintenance MAC environment. I think you will find that there is more than meets the eye generating digital reference sets and clinical information, and expecting a machine to mimic a brain that has taken thousands 3-4 decades of education and discipline to be able to comprehend is placing lives at risk ahead of your own simple need within the collection of data
It appears that the commercial drug information sources can provide the mechanisms to test for drug allergies and SNOMED-CT certainly can. The fact the some of the information is under review should not mean that AMT misses its goals or sits on its hands. SNOMED has an allergy hierarchy in substance and it appears to work quite well. If AMT was integrated into SNOMED-CT which was a stated aim we would have this capability now. If it changes in the future then AMT will also need to change. If the existing hierarchy has errors then they are in a position to identify and correct them.
I have seen the arguments against the functional drug categories such as “Anti-hypertensive” but never against substance hierarchies, which is what this discussion is about. The point is this is all discussion for the future of SNOMED. AMT is for use now.
I am afraid that I am unable to just say “It’s the government, what else do you expect” and it’s our money that’s being spent and if they don’t feel capable of doing it then the job should not be done internally. I don’t think its rocket science creating these hierarchies, but it is responsible work that is critical for safety. It will, like the rest of Snomed never be perfect, just as clinicians are never prefect but that’s not a good reason to do nothing. As a result of the lack of this capability every developer when asked to check if the patient is on any drug they are allergic to in the Personal Health Record with have to create their own list of AMT codes that imply “Penicillin” to do the test. That’s surely a huge danger, that process should be quality checked by 50 pharmacists working for Nehta... but it has not happened.
The whole point of a clinical terminology like SNOMED-CT is to provide a knowledge base to allow this type of reasoning to be automated by software. It will never be perfect and should never be relied upon totally without a human check, but that is what eHealth is: “An imperfect Science” just as medicine is part science and part art. To not provide these capabilities means the goals are not being met. Everyone wants an AMT, but we want one that is useful. It needs to integrate into the current SNOMED-CT to be useful beyond a simple mapping device. I see evaluations of interaction checking in existing software and that’s way more complex than allergy checking in AMT. Failure to deliver the ability to check allergies using AMT is failure in my books. It does fail this test unless you want to add every current variant of penicillin to the list of allergies when documenting the patient is allergic to all forms of penicillin.
The test is "Has a software vendor put AMT into their product and has there been an increase in the probability of positive outcomes (ie. improved health outcome) for the patient and/or the decrease in the probability of a negative outcomes (ie. adverse medication event) over what is already in existence." Unless you can prove one and/or the other there has been no benefit. We expect this of everything else in health why not with AMT?
Geoff, that's a pretty tough standard - I'm not sure many building blocks can actually demonstrate how they've improved patient outcomes (how many
patients lives has XML saved?). But seriously, it's a laudable goal. We _should_ judge AMT by that criteria. I'm not sure now is the time to do the judging though - 4 years may seem like an eternity to some, but I actually don't think that is an extraordinary length of time. Obviously some have different opinions.
On your first criteria, I don't know of any vendor that has currently implemented AMT (but then again, vendors don't run their decisions by me - for all I know everyone is about to launch AMT products at HIC). I totally understand vendors asking 'why should I?'. Given not many of them are actually exchanging medicines information in coded form at the moment I might suggest that they haven't probably haven't run into some of the harder issues.
Now I may be young and naive, but it doesn't take much imagination to see a world in the (not to?) distant future where systems are exchanging clinical information. Discharge summaries, GP to GP transfer, PHR's, IEHRS, aged care med charts, whatever you can imagine. And as an pragmatic person, I can see an easy route of implementing these with a common medicines terminology, or a really hard route of doing this with everyone using their own medicines terminology.
I'd prefer to plan for the easy future. I don't know what will make vendors join onto the vision? Surely the overwhelming horribleness of not being able to understand different hospital discharge summaries because they all use different code sets would cause some vendors to think that at least mapping to the AMT might be a good idea (even if they don't use AMT internally). Perhaps vendors should be angling for money to help fund this - I think they could make a really good case as to how this would benefit national e-health.
Can anyone make the case that doing N x (N-1) mappings from every vendors medicine set to every other vendors medicine set is somehow _safer_ than doing one mapping for each vendor to the AMT?
Geoffrey Sayer - HealthLink said... "Has a software vendor put AMT into their product"
- the bottom line to all this is that until AMT is available in a vendor's product (at least one vendor) and in routine use the whole exercise remains one of Research & Development. That's fine, R&D is the first step. The proof will be in the routine implementation and widespread use of AMT. We look forward to that day. Does anyone have any idea when that will be? This year, next year or 4 years hence?
Hi Andrew (P),
I think the problem is that you regard the AMT as a means of mapping the codes in PMS systems to each other. It certainly enables people to use common codes, but SNOMED-CT is much much more than common codes and we have to take the issue to a level beyond that or you are selling it short. SNOMED is about semantics and it is the lack of semantics that is the issue.
Its the lack of Semantics that makes its use in any personal health record problematic. There is a trend to try and dumb down SNOMED and reduce it to a picklist. This trend is very short sighted and this is why we need some vision to take us beyond the next step. This is why the very concept on Nehta implementing personal health records in 2-3 years is simply pre-election spin. Yes we need common codes, but beyond that we need common codes that have some semantic value. We need to be able to ask a question such as does this patient have a diagnosis of Asthma and are they taking a B-Blocker orally.
I think you should look at the Snomed-CT core. If you are happy to prescribe generically it could be used in Australia now and it works for this type of query and for allergy checking. All it needs are the Australian extensions to give us brand names to localize it and any missing drugs. Thats what AMT could have offerred...
Hmmmmm - so why don't they use the AMT for electronic transmission of prescriptions? Isn't that a good first application for it? If they aren't using AMT, then what are they using to describe the medications that the patient is going to take? Wot? Surely they are not just transmitting lumps of text to be printed in the pharmacy? Wot use is that? I guess it saves a stamp!
Lets go back to basics.
1. Software vendors (prescribing and dispensing) tend to be happy using other's people content when it comes to drug lists and drug interactions. The many vendors that I have dealt with over the years would be happy to replace it with a better or same source of content for same price or less price respectively.
Vendors’ desire in this area is supported by the fact many of those vendors' people were involved with AMTS before NEHTA even existed.
2. Drug interaction (drug-drug, drug-allergy, drug disease) functionality is mostly required at the time of prescribing because a lot of the patient history is already present and you want to nip the issue off before the drug has the chance of being given. Therefore any new system being developed must match at least what is currently available in GP land as they seem to be responsible for the lion's share of prescribing (order of 100 million prescriptions generated). The developers of the new medication system then needs to consider how will vendors integrate it into the vendor's systems. There will be an over head in doing so but a business can do the sums quite quickly and it may be possible to get their ROI over a number of releases. This will depend how they have incorporated the previous medication list, drug interactions, need to migrate data etc. However, fundamentally while there are concerns (real or perceived) that the AMT is considered not fit for purpose why would a vendor look seriously at that path beyond keeping an eye on it. Now a hospital vendor might because their system is a lower benchmark of drug interactions or the procurer is prepared to pay for the integration. I don't think I could find a GP who is prepared to pay additionally for the integration of a system which is no better than what they have got. However, if it made the GP vendor's life easier to maintain, cheaper etc the vendor may make the business decision and wear the cost with the aim of efficiency.
3. While sending messages using the same set of drugs in terms of codes is important it is not as important as ensuring that a system at the other end has what is considered an acceptable level of drug interaction checking.
Furthermore you need to make sure that the message format being used is structured in a way that the data can be used by the receiving system. You need “interoperability”. I know I will be told by someone - "foundation building blocks" - "NEHTA separate stream" - being handled by SMD "interconnecting" - which is not focused on "interoperability" - which is what you will need to get the benefits that Andrew P talks about.
4. However, on a positive note, in contrast to Andrew P's lament "I'm not sure many building blocks can actually demonstrate how they've improved patient outcomes", I believe that any incremental benefits can be realised if you actually take into consideration what are the drivers to make sure the building blocks are actually being taken up by those who are in the strongest position to "increase the probability of positive outcomes (ie. improved health outcome) for the patient and/or the decrease in the probability of a negative outcomes (ie. adverse medication event) over what is already in existence."
In the case of AMT, terminology, UHI and interoperability through standards around message payload, each one on their own can make a difference - when combined of course will get a multiplier effect.
5. I know I will be told that they have done this already but I strongly urge NEHTA and those helping NEHTA to really consider in their work plans how building blocks can be structure, incentivised, deployed and supported from the outset (or at least going forward) so that maximum uptake can be achieved as quickly as possible. You also get a timeline of the delivery of the benefits. Otherwise they are not foundation pieces if only a small percentage of the healthcare software vendor system actually implement.
Andrew, I'm totally familiar with SNOMED-CT core and the possibilities of SNOMED. I'm particular interesting in post-coordination and canonical forms, and also the boundaries between SNOMED and information models. I don't want to dumb things down at all. I'd suggest that you need to recognise that people can both understand your position, and yet still disagree with you.
What I was saying in my other posts was that if I was a vendor with an existing product who wanted to do the minimum amount possible, at least mapping my codeset to the AMT would enable the rest of the e-health ecosystem to do the exciting interesting things that you and I want. If the edge systems can at least generate AMT/SNOMED, then we can build interesting bits in the middle.
So that was what I was suggesting as a first step implementation for existing vendors. But hey, if they want to run with AMT they can do all sorts of other interesting things.
I find it interesting that you are saying the AMT is setting the bar too low in terms of ambition, and Geoff and others seem to be saying that the bar is too high for AMT (hence noone implementing it).
This is a very valuable conversation as it gives us an excellent insight into the differences of opinions that exists in when pursuing the 'common gol".
As Andrew Mc said Monday, May 31, 2010 8:49:00 PM "SNOMED is about semantics and it is the lack of semantics that is the issue."
Clinical depth comes with practical hands on clinical experience and it is important that we find a way to truly marry deep, insightful, technical skills and clinical expertise together as effectively as we can so these differences in 'viewpoint' can be better understood by all in the research team.
Hi Andrew,
I appreciate that you understand the power of the semantics in the Snomed model. I just want those powers preserved, as thats ultimately where the eHealth pay off comes from. A common codeset has value, but limited value.
Unless AMT has those semantics the value of implementing it is gone. I was waiting for AMT but in the end decided to map generic third party codes to the Snomed core as there was no value in using AMT. There is value in the semantics of the core however. Its not perfect but allows a lot of valuable computer checking of patients information to try and reduce human error.
Its this sort of thing that delivers value so its catch 22 if you accept the argument that semantics won't be introduced until people implement AMT, but they are not implementing it as the semantics are not there!
The personal health record is the very place that the semantics become important and its the disconnected from a PMS system.
Anonymous at 9:28
We would all know what eRx/Medisecure use for drug coding in electronic scripts if they made the specifications public. Alas they haven't.
My understanding is they use PBS codes for PBS drugs, and free text for everything else.
I can't help but feel a little ganged up on here. Doesn't anyone at least agree with the goal of enabling a common medicines terminology?
I mean, if you could go back 20 years, noone would actually suggest the current ecosystem is a good idea. Noone would say to vendors, "you call aspirin number 25, and he'll call aspirin 673, and then in twenty years time you won't be able to exchange information with each other".
I mean people do realise how absurd that is as a premise. Don't we all want to work towards fixing this historical anomaly?
Geoff, I agree with most of what you say.
I'd just point out that I'm not sure vendors need to replace their existing interaction systems/databases with AMT. As you noted, GP system have quite advanced point of prescribing interaction checkers. Surely they could just get the ball rolling by putting AMT codes in their database (alongside the PBS codes, and MIMS codes and whatever other codes they currently have for all their drugs).
Sure, its a block of work, and I don't know what incentive structure their is for them to do it. But at least they could then export e-prescriptions, or GP2GP records etc with a common terminology. At least one day when they get random discharge summaries from hospitals they can look up the AMT codes alongside their own codes and work out the 'differences' between the drugs lists in a computable way, not just by displaying blobs of text.
In a non AMT world, what exactly are GP vendors going to do about medicines terminologies for discharge summaries/e-prescriptions etc? Are we really suggesting they do a mapping from Cerner, and iSoft and whatever else is out there generating discharge summaries? Then do a mapping to each dispensing software code set for e-prescribing? Or do like eRx and send PBS codes and blobs of text? Is this really the future we are planning for?
Hi Andrew P
Just to clarify re settin the bar too high. I am saying that unless AMT is exceeding the current bar that is already in the market place in terms of functionality and at lower cost of acquisition it won't be implemented nationally across all sectors.
It is supposed to be a national building block so should be developed with "national use" in mind. I am not convinced so far that the current strategy will work in a timely fashion given the effort expended to date.
"I can't help but feel a little ganged up on here. Doesn't anyone at least agree with the goal of enabling a common medicines terminology"
Of course I agree with that. Its just that that is only one benefit that should come. A common code is much more useful if it comes with the ability to check allergies and know what group of drugs it belongs to.
Ideally all communication outside a practice should use a common code but unless you can use that code for things like allergy checking the value of it is minimal. If you have to map it back to eg MIMS to do anything with it then you loose the advantages of the snomed has to offer.
If all we ever use Snomed for are pick lists then the value proposition of Snomed is lost. The reason Snomed was selected was its reasoning ability. AMT has virtually none of that reasoning ability.
There is a huge danger of Nehta dumbing down Snomed to a set of flat refsets, which is mostly what AMT currently is. The semantics in AMT are very limited. Basically "Generic"-"Trade name"-"Pack" navigation and a lack of any substance hierarchy.
Its been a fascinating discussion and thanks to all so far. Can I perhaps summarise the question that is left hanging in all this? i.e. Why is AMT not NEHTA standards compliant?
Since Snomed-CT is the national terminological system standard, with medicines are a part of that system, why is the AMT localised list of medicines not designed to interoperate with Snomed?
If NEHTA does not understand or is unwilling to see that its own standards need to interoperate with each other, what the hell is going on?
Apologies to all the hard working AMT types, as this is not directed to you, who are hard at work developing the lists, but to the folks who guide strategy and implementation.
The thing about building blocks is that they need to fit together, no?
> is already in the market place in terms of
> functionality and at lower cost of
> acquisition it won't be implemented
> nationally across all sectors.
Geoff, I think there is a disconnect here between your expectations and what the scope of the AMT is. I don't think AMT will EVER be able to replace the functionality already existing in GP systems. I would contend that it has never been its intention.
Sure, Andrew M rightly points out that you could do allergy checking with SNOMED. And but for some historical reasons, that would be possible now out of the box with AMT, and the intention is definitely in the future to reintegrate AMT with the rest of SNOMED to enable this.
But for instance, drug class to drug class interactions are not within the scope of AMT. They are not within the scope of SNOMED. You won't find concepts like "MAOIs interact with SSRI's causing a severe, possibly fatal reaction" in any terminology on the planet. That is the role of assertional knowledge products like MIMS, AMH etc. And this type of feature is obviously vital in GP packages. So out of the box the AMT will never do this, and if vendors are waiting for this they will be disappointed (but as I said earlier, I don't think replacing their entire decision support engine is necessary for existing vendors - just starting with the codes would at least help the rest of the e-health ecosystem out with regards exchanging information).
However, the AMT does allow knowledge vendors, and GP vendors, and dispensing vendors to share a common frame of reference for medicine codes. Thereby reducing the amount of work required to get these systems talking to each other (i.e. do 1 mapping to AMT, rather than N mapping to every other vendor and knowledge source vendor). I think that makes sense.
And Andrew M, I realise that that is setting the bar low, but surely if we start with some existing dominant vendors at least using AMT codes, other vendors like Medical-Objects can really show them how to make their systems sing..
Anonymous @ 9:25 AM
People may find this hard to believe, but the reason AMT isn't integrated with SNOMED is because NEHTA were so far ahead of the curve that they were actually driving the process of improvements to the international core SNOMED medicines model. As in, the international SNOMED community has just recently agreed to rejig the SNOMED medicines in an AMT-like way (historically, both the modelling and the boundary between generic and trade medicines was not perhaps well defined in SNOMED - given it came from a US focus, and sometimes people in the US forget that the rest of us exist).
So sure, they could have held off releasing AMT until international consensus was reached but would that have really make us happier? And sure, perhaps they should have been pragmatic and linked in at least at the substance level to enable what Andrew M wants. But they didn't. I'm not sure how much more we can beat up on them for that. Can't we build a bridge and start using AMT for the things it can do now, and then set out to improve it as we go?
Wow - that's fabulous. Thanks to everyone in this discussion! It's a real lesson in terminologies, what role they play, and how we can get on practically while letting them evolve. You would never find this sort of discussion in a textbook or a lecture theatre. And thanks to David for his blog!
Thanks Andrew, for your explanation of the state of play of SNOMED-CT Vs AMT, and SNOMED's immaturity with respect to medications.
Its quite a surprise to hear that the 'core' national standard, first off the rank because it was ready to go, is actually not sufficiently mature to guide a most foundational application to medicines identification. I'm quite shocked to hear that, and if it is true, well ....
I guess the question I asked about why AMT and SNOMED-CT dont 'fit' has not really been answered. It is OK to say that the two currently dont fit today, but it would then be absolutely crucial to make it clear what the path to convergence was, and what was being done to ensure convergence.
As standards are public documents, used to shape future industry development plans, such a disclosure of intent and method and timeline would be useful. They probably exist, no? Please say they do!
Pat Gallagher said
There be dragons here
There is another take on this subject matter that no one has raised
Refer A Patterson's mention (May 31) of 'common medical terminology'
For three years 32 Australian experts sat at committee and produced the 'Medicine Coding Council of Australia" report
Which said that the only single, global, product identifier that can be used from end to end, womb to tomb, is the GS1 number
And went on to say, in part, that while the GS1 discipline is the only and safest methodology to avoid keying and mapping errors (be certain of that otherwise occurring), for clinical and research purposes, i.e. AMT, the high order GS1 can be mapped to this subset and other number regimes.
Why?
This is a national catalogue imperative
PRICAT cataloguing rule 101 - use the number owned by the product owners as they can be the only reliable source of core data
Manufacturers use GS1 and are extremely conscious of their responsibility to maintain data quality control.
Manufacturers are not responsible for the AMT codes, or Snomed or any other numbering system
Some other party has to intervene to ensure core product ID accuracy and statistics say that will introduce up to 6% error rates
Think of it this way
If we do not seamlessly integrate the supply chain into the clinical chain we will introduce these wetwear errors
A fact beyond dispute
A good way to describe this challenge is to say "every clinical decision is a procurement decision"
Think of bedside barcode scanning; where pray will the AMT or Snomed number come from to be printed and used from the product scan to the patient wrist's scan?
Hmmm?
Please, map your hearts away with AMT, Snomed and any other subset number that can be justified.
Just DO NOT give these numbers a higher status than the core numberplate that is owned and used by the manufacturer.
Use the GS1 numberplate and link/map that back to clinical or other user needs in whatever database they have built.
Do to other wise will end in tears; patient tears
Does anyone really believe doctors have a deep and abiding interest 'in codes', 'in coding and all the manifestations thereof?
Doctors want to treat their patients as quickly as possible and move on to the next one. The business of coding (in whatever form it must take)is not something doctors want or will allow themselves to get distracted by. Face it, accept it as a fact of life.
So whatever approach you deploy to using and applying 'codes' as per the above discussion make sure it is a seamless process and does lead to distracting or delaying the doctor as part of the patient consultation.
I appreciate that is 'difficult' yet pragmatically essential.
Dear Anonymous @ 4:27,
The "code" is never seen by the user but it is vital it means something to the computer.
If it is a proper code it can allow the computer to warn you that the patient had a previous anaphylactic reaction to penicillin if you try and prescribe Ampicillin when you are in a rush.
If it is an AMT code it currently cannot perform this function and getting the internal details correct is very critical. Otherwise its like a patient judging the quality of the whipples procedure by the scar.
So the discussion about getting it right has to go more than skin deep, even though users might just look at the end result.
> Does anyone really believe doctors have
> a deep and abiding interest 'in codes', 'in
> coding and all the manifestations thereof?
Absolutely not - doctors are interested in the features of the applications and their ease of use, not the internal code systems.
And in part, therein lies a problem for NEHTA and the government. Vendors quite rightly say, "well our customers the doctors aren't asking for SNOMED or AMT". And of course they aren't - for the reasons above. And whilst ever the doctors aren't exchanging 'coded' clinical information with other systems they aren't even running into any of the issues that a lack of unified terminology brings about. So for both doctors and vendors, a new terminology is all downside.
But I also know at some point hospitals, and specialists and GP's are going to get their shit together and start exchanging coded information - and I'd prefer not to have to explain why they have to retype in lists of drugs just because their computer has no idea what the other computer is talking about.
Pat,
I must say that I'm still not sure of what capabilities supply chain numbering systems like GS1 offer and whether their usage can be extended all the way throughout clinical systems (I know at some point you sent me some docs but I'm still not sure I 'get' it),
AMT is a definitional terminology. That means that it is both a code, but also a set of relationships and modelling that enable things like working out how much fexofenadine there is in mg in 180 mg of Allerfexo (suprisingly not 180!).
That is to say that the 'concept' 'Allerfexo 180mg' is defined by the relationships that make it up, included its form, substances by weight etc. And this modelling works across both trade and generic drugs, and allows movements between any concept to the related concepts in other areas (i.e. move from a generic drug, to all the concepts of containers of trade products that are the same as that drug). And as discussed above, one day (hopefully soon for Andrew M) linked into the SNOMED substances to provide drug classification.
I don't have any proof of this, but my understanding is that the AMT undergoes a fair bit of data cleansing to get the TGA data (provided by the manufacturers) into a state that it is usable by a definitional terminology.
I realise manufacturers 'own' the responsibility for their GS1 codes and that surely is a good thing - but how good is the quality of that data when it comes to using it for complex medicines data modelling? Can GS1 express the level of complexity needed for modelling across the whole health sector?
Well, it takes two (systems) to tango. Vendors won't want to invest in changing their internal database structures or their interfaces to use AMT coding, until there is a good reason to do it. Good reasons include:
Having regular drug data sources in AMT (e.g. the PBS and MIMs datasets); and
Needing to share medication data with other systems (e.g. medication orders with a pharmacy, or discharge medications to an electronic health record). Is the Commonwealth intending to provide the PBS dataset in AMT flavour? Would that be a good start....?
I am afraid that I don't think the current progress is adequate for our needs. The “remodelling” of the Snomed medications is mostly just discussion at the moment and is likely to be years away from resolution and implementation. It is unproven and abstract at this point.
What we need is a realistic and pragmatic solution to deliver value now. Extending the existing Snomed-CT distribution with localised drug names and doses without adding the contentious atomic dose attributes etc and not including pack information would give us a 95% solution to the problem. The existing drug information resources have that information anyway.
This would allow allergy checking, unique codes for PMS systems to use and allow clinical decision support. The “Full remodel” can then continue in the background and in a few years when it’s proven and decided a new version, also fully integrated with the new Snomed-CT can be released.
The codes for the Australian drugs could remain the same, it would just require the relationships to integrate it with the existing Snomed-CT medications hierarchy. Then existing Snomed-CT tools and servers would be able to deliver value now and be modified when a new stable plan was developed.
To sit on our hands when the realistic timetable for delivery is years away does not seem reasonable to me. Maintaining existing functionality while working on the new and improved version is common practice in the software world and would be manageable. We also have the mechanisms to provide a Snomed X-Map to Pat’s “GS1” codes with the current Snomed-CT implementations. Pragmatic solutions are required, and this solution would deliver real value, far more quickly than the glacial pace of progress we are currently seeing.
David More said Sunday, May 30, 2010 5:17:00 PM "Get it done, fully and properly and move to routine care and maintenance. Can it be that hard?"
Reinforced by Andrew McIntyre Tuesday, June 01, 2010 9:39:00 PM, "To sit on our hands when the realistic timetable for delivery is years away does not seem reasonable to me."
He also said "Maintaining existing functionality while working on the new and improved version is common practice in the software world and would be manageable. We also have the mechanisms to provide a Snomed X-Map to Pat’s “GS1” codes with the current Snomed-CT implementations.
Further he said "Pragmatic solutions are required, and this solution would deliver real value, far more quickly than the glacial pace of progress we are currently seeing."
__________________________________________________
Here is the real world view.
All too often we see the technology developer working to finalise their perfect system before releasing it to the world at large. Sometimes that last few percent of work takes years of effort and in the meantime no practical real life experience of the rest of the work, already completed, can be gained.
Commercial pragmatism says get it out into a Beta test site now. Get it out now.
Do not be scared. If you are confident you have done the job well then let us put it to the test. Accept the fact there will be problems. When they are identified they can be fixed.
Implement the processes and procedures to enable that to happen. Keep moving forward with real world experience behind you.
The 'perfecto techo' more often than not doesn't have the skills and experience to implement the system. Their skills lie in perfecting the system as they see it. They see the world differently from the implementers and those who package and implement the product. The perfecto techo finds it hard to let go of their special project for all sorts of valid reasons. But let go they must or else no-one will benefit and the world will stay still.
Post a Comment