The Australian PBS codes are used to describe the medications for which the Australian government offers rebates under the Australian Pharmaceutical Benefits Scheme. The codes are published as part of the rules definitions tables, and can be found here. In living memory, the codes have consisted of 4 digit codes followed by a alphabetical check letter. For instance, the code for a particular packaging of Simvastatin (used to be a clinical interest of mine) is “2011W”, and you can get the full details for this code at http://www.pbs.gov.au/medicine/item/2011W (note that this is not case sensitive, and http://www.pbs.gov.au/medicine/item/2011w also works).
However, the 4 digit codes are starting to run out. As I previously discussed, the PBS team won’t be reusing old codes for new meanings, so that means that they’re going to start using longer codes. That’s forecasted to happen in May/June this year.
That’s where the fun starts. From my post from before, the proper representation for a PBS code in a CDA document is this:
<code code=”1471K” codeSystem=”1.2.36.1.2001.1005.22″/>
and in a v2 message, it would be something like this:
|1471K^^PBS|
(Though there’s no v2 registered code system for PBS – I’d like to think that means that no one is exchanging PBS codes in v2, but I think people are. We talked about defining PBS on an Australian basis, but we never formalised that)
The problem
However there’s a problem: when Medicare were updating their systems to handle longer PBS codes (something that was done last year after it was decided that PBS would use longer codes), they changed their interfaces so that the PBS code would be represented like this (quoted from one of several rules published as amendments to the National Health Act):
PBS/RPBS Item Code: Six bytes, right justified, zero filled, five bytes numeric followed by one byte alphabetic check character, being the code for the pharmaceutical benefit which appears in the Schedule of Pharmaceutical Benefits for Approved Pharmacists published by the Department of Health and Ageing. A zero code is to be used in the case of Repatriation items which are not included in the Schedule but have been prior approved by the Department of Veterans’ Affairs.
Valid values include: 0-9, A – Z. Alpha character must be in upper case.
So all the DHS/Medicare interfaces prefix the PBS code with a 0, like this: 01471K. Note that many of the medicare interfaces are fixed width file interfaces, and they don’t really have a lot of choice but to fix the width of the field, and it’s going to be either prefixed with spaces or zeroes. Whatever, the PBS Authority (DOHA) that publishes the codes doesn’t prefix with 0.
I discussed this with the team that defines the PBS codes. From their point of view, the code is an integer value, with an accompanying check character, and whether or not the integer value has any ’0′ digits prefixed to it is not significant, doesn’t affect the check digit calculation, and doesn’t affect the interpretation of the code. Whether 0 is prefixed in any given context is an implementation detail, and they are comfortable with people using either form.
Note that they don’t use prefixed codes – the ascii and xml formats that they distribute don’t include a leading 0, and http://www.pbs.gov.au/medicine/item/02011W is not found (based on the links above). That’d be the implementation aspect of it showing up.
As a side note, the PBS codes already include 2 and 3 digit codes for some special items. For instance, 183P is Chlorhexidine Acetate (use as additive only). Note that no variation of http://www.pbs.gov.au/medicine/item/183P that I could think of trying worked, so I presume that these special codes are not published through the PBS web site. Btw, they PBS team also informed me that they reserve the right to use codes longer than 5 digits in the future, but I think we can safely assume that this won’t happen since DHS can’t support it without changing their interfaces again, which isn’t going to happen any time soon.
Because one of the first document types to be uploaded to the pcEHR was the medicare records, and because they use the 0-prefixed form internally, naturally, the medicare documents contained this form:
<code code=”01471K” codeSystem=”1.2.36.1.2001.1005.22″/
And because of the way this is implemented internally in the pcEHR, the pcEHR is therefore configured to only accept the 0-prefixed form. And now vendors that are testing to their documents with the pcEHR are running into this as a problem, since they do not prefix the existing codes with 0s.
Solution
There are various possible solutions:
- Get DHS/Medicare to change to not prefix the codes with 0
- Insist that PBS codes are always prefixed with 0 values to 5 digits when they are exchanged between systems (but not displayed to users?)
- Leave it that all systems should accept codes prefixed with 0s or not and know that the code itself is the same either way
- Say that the medicare interfaces and the pcEHR documents always (and must) prefix with 0, but in other contexts, it doesn’t matter (see rule #3)
I think we can safely say that the first isn’t a good idea. The second sounds like a good idea unless one day we start using 6 digit codes, but what happens to existing interfaces? #3 sounds like a good idea, but is really tough for systems, since the codes are suffixed with an alpha character – this violates normal rules for handling code systems, and special cases are always bad. The 4th is a variation of the 3rd that spreads the pain around differently (still involves special cases).
It doesn’t seem obvious to me what is the right solution here. This blog post is to solicit opinions from the various vendors etc that are affected by this problem. You can either comment on the post here, or if that is counter to your policy, you can comment to me directly. (Note that if you have a relationship with NEHTA, and it’s necessary, you can comment to me under NDA if you wish).
At some stage I’ll have to update the registration for the code system to clarify this, but I’ll wait for now. Also, I think it’s probably necessary for us to get a v2 code system for PBS codes. Let me know if you exchange PBS codes in v2 messages.
Update (13-Feb 2013): DHS advises that: “PBS Online will accept either a zero-filled or non zero-filled PBS item code. In practice some Software Vendors zero-fill and some do not.”
I’m not a vendor. And I’m not affected. However, from a methodology perspective, if you drop support for all codes that were previously accepted and add a completely new set of codes that represent the same sort of comments, that’s a strong indicator you have a completely new code system and should be using a distinct OID. Any systems that were dealing with the old style codes can’t deal with the new ones and vice versa.
Also from a methodology perspective, codes are strings, no matter *what* they look like. Stripping off or adding leading characters to a code is not ok. It’s going to break all sorts of generic terminology handling services, such as CTS.
I would recommend the following:
- Keep all of the old codes (no leading zeros)
- Add new codes with leading zeros and declare them as synonyms of the old codes
- You can then create value sets that use only new codes, only old codes or mix of new and old
That lets you keep the same OID and lets different systems choose what codes they’re willing to deal with.
Note: If you actually display codes to the user, you should display what came over the wire – no messing around with leading characters. It’d be nice if their web service handled both the version with the leading zero and no leading zero.
Well, those are the methodological words that describe the options. But I should’ve made that last point – having a different wire format from the UI format will be a lasting source of confusion to everyone
As described here, it seems pretty clear that PBS considers this thing as ‘integer code plus alpha suffix’, so it would behoove any implementer to note this and treat the leading zeros as optional padding, stop the parse at the 1st non-numeric and that’s your check character.
If, you’re defining a fixed-width interchange format, (presumably to speed up parsing to you can pick out parts of a message without having to parse all the preceding bits), then you need to require zero (or something) padding but that is a “wire format” and independent of the code system itself. (And you’ve been warned, the code size will change; maybe you should fix the width at something >> 6)
IMO
michael
Doesn’t affect me either
but why bother with the leading 0???
If no leading 0 is used then
1 All existing codes are still valid, no need for synonyms
2 You are free to expand the system to long a string as you like.
Lloyd is right external systems should treat them as strings regardless of shape. Whether or not Medicare interprets them internally or not.
I must say it is very poor that they do no conform to their own leading 0 standard, you have my sympathies.
A code should be opaque and should not really be interpreted as an integer, but just like Medicare provider numbers it means that the system has to have specific handling of this code type to allow equality testing (for example) internally.
Having a codeset that requires specific handling is less than ideal, but there is no choice. Every system that uses these codes has to have custom routines to massage them consistently internally (And when sent externally it seems). That just increases the cost to users of the codeset and increases the cost to customise software written elsewhere. At least the behaviour of government is consistent in their eHealth policies.
If the numbering schema is just incremental then there is no need to add a zero. Simply extend the codes beyond 4 digits. Example: After code 9999Z we could have 10000A. Similarly, after 99999Z which could go on to 100000A. The advantages would be:
1. No changes in the original codes
2. No limit to the number of codes (future proofing)
3. Coding changes could be as simple as a 2 line divert (if-then) for the new codes
3. The end-user(clinician) does not see this (back-stage change) and (frankly) couldn’t care less.
On the other hand if the coding schema has some logic behind it (e.g. Codes for cardiovascular drugs are in a group within the numbers, say 5000 to 6000) we will need to apply a different logic. That logic could be applying a 2 or 3 letter prefix/suffix thereby keeping the grouping (and logic) intact.
Whatever the solution, we MUST remember that every change in code/logic requires tons of money, time and effort for software/Db changes and user trainings. So do choose wisely.
with warm regards,
Dr D Lavanian
MBBS,MD(AM)
CEO and MD
HCIT Consultant
http://www.hcitconsultant.com
http://www.telemedconsultant.com
Certified HL7 Specialist
Joint Secretary – Indian Association for Medical Informatics
Co-Chair, Memberships – HL7 India
Senior Consultant and Domain Expert – Healthcare Informatics and TeleHealth
Former Vice President – Healthcare Products, Bilcare Ltd
Former Vice President – Software Division, AxSys Healthtech Ltd
Former Co-convener Sub committee on Standards , Government of India, Task force for Telemedicine
Former Vice President – Telemedicine (Technical), Apollo Hospitals Group
Former Deputy Director Medical Services, Indian Air Force
Why is (1) not an option? I mean, it’s a DHS interface definition (not even the definition of the entity that generates the codes) – DHS seem to have got it wrong – can’t we stop the mistake from expanding out into the rest of the known universe (especially into worlds that don’t have fixed length fields and so would never ever consider zero padding a code)?
They can keep the interface backwards compatible and accept leading zeros – but change the formal definition to be padding with leading spaces for where PBS items are represented in fixed width fields. So sure, that means some confusion at the boundary to DHS systems, maybe even some costs. But it keeps the problem where it belongs i.e them.
How many vendors currently interface to the DHS/Medicare systems? What stage of the transition are they in from 4 -5 character codes? How locked down are their interface definitions?
I guess I’m a little in Lloyd’s camp – why can’t the stuff up be restricted to just the DHS interfaces and vendors (i.e. put leading zeros on the codes when sending, take leading zeros off codes when getting just when talking on the wire). That at least ring fences the stuffup. If DHS then wants to fix the definition down the line to perhaps accept space prefixed codes – that is something that can be done with suitable change management. But the rest of us don’t have to deal with the crap.
I agree with Andrew Patterson and most other commentators on this. But I’d go even further with the ring fencing. DHS/Medicare should admit they got it wrong and fix their interfaces. These shortsighted fixed-length, zero-padded codes often become an integration nightmare on steroids! Why didn’t NEHTA kick back before the PCEHR was loaded? [ perhaps they did? Who did the testing? What did the clinical safety review say? ] The DoHA produce the PBS codes. They define the rules. Their specifications say “five or six characters in format (n)nnnna”. They do not publish zero-padded codes. So we have most if not all users of the PBS codes obtaining their codes from the PBS website, with regular updates. They contain no zero padded codes. Yet, we have another hand of DOHA (PCEHR System Operator) and DHS/Medicare expecting every user system to have to (under certain circumstances) append zero or more leading zeros, when sending to certain (a changing number of) sites and to strip leading zero(s) from incoming data from certain sites. And when the DoHA again needs to increase the number of digits for PBS codes, we’ll need every system to embed new rules to cater for some Medicare bureaucrat’s new whim whilst trying to remain backward compatible with other systems that have yet (if ever) to adjust to DHS/Medicare’s new rules.
What a recipe for disaster! It should be fixed pronto.
And as you rightly point out Grahame, it is not just vendors affected. I would suggest that the majority of those affected might lie in your “etc” camp. Thanks for soliciting feedback. ‘Tis a pity DHS/Medicare seems to have neither your insight nor your initiative!