PBS Software Developers Workshop - 25 August 2015


  • University of Technology, 702-730 Harris Street, Broadway, NSW
  • Date & Time: 25 August 2015, 10am to 4.30pm


  • Arrival: 10am for 10:30 start (morning coffee)
  • Morning Session: 10.30-12.30
    • Welcome
    • Results of PBS Outputs Survey
    • Summary of updates to the PBS Monthly Publishing System
    • Overview of services available through the Publishing API Version 3
  • Lunch: 12:30–1:30 (hot lunch provided - please notify us in advance of any special dietary requirements)
  • Formal Workshop* 1:30–3:00
    • Using alternate formats – API, Publishing XML, JSON (Javascript), SQL (SQLite)
    • How to process only the updates instead of the full data set
  • Informal Session 3.00- 4:30
    • Open discussion; including;
      • Possible collaborative approaches to reducing the risk and cost of processing monthly updates
      • Processing of Chemotherapy compounding
      • PBS Text Extracts
      • Issues, suggestions, requests

*The formal workshop will include live code samples for anyone bringing a laptop. A virtual machine will be provided beforehand so that attendees will have the necessary infrastructure to edit and run code locally.

Final details of how the code will be distributed are still being finalised but anyone that has registered will be notified in advance.  Please let us know if any environment other than Macintosh or Windows is required (we can't promise, but we'll try).

Non-developers are welcome to attend, as are developers that don't bring a laptop, however please understand that the pace of the formal session will be oriented to working with the code.

Presentation Documents

Workshop Notes

Processing Updates vs full data set

Nick Carr raised the question of whether it would be more useful for vendors to process just the changes each month rather than the full data set. Vendors responded that there would be little value in this because the majority of their time is used in checking the data is correct, rather than processing.

Multiple comments were made that using just a delta file was too risky as they cannot be guaranteed this would capture all changes and anything that was missed would stay incorrect in their software indefinitely. Consensus was that vendors would prefer to continue processing the full data set.  The proposal of capturing historical data in the XML was raised but it was felt that the XML would become too large and unmanageable. Therefore there is no need to capture history

Schedule PDFs

A high number of attendees indicated they use the PDF Summary of Changes and Schedule each month as the “true reflection” of the Schedule for QA purposes.

XML data

Nick Carr asked if anyone else was finding it problematic that some monthly alterations look like an addition and a deletion. This was affirmed by many attendees.  It was agreed that more information is needed in the data to be able to distinguish these changes. It was requested that deletion data be kept in the PBS data for a 12 month period.


Vendor feedback was that the current draft version of the SQLite files are useful and easy to work with but it would be preferable if it contained all the data, including AMT and historical data for a 12 month period – Health and Allette will continue to consult and improve the SQLite. 


Some vendors are processing the AMT data from NEHTA alongside Health data for a more comprehensive view of what is happening each month.  It was pointed out that whilst this is okay, there are differences and the Health data is the definitive source for the PBS. Non AMT concepts need to be identifiable in the data. This is being considered for Health XML v3.

Text files

It was agreed that the PBS Text files are largely un-mappable to the current PBS data. However, they are still widely used by vendors and are incredibly useful.  Vendors were open to discussion about improving and updating the Text files, including relaxing the constraints and adding header rows.

Health agreed there would be further consultation, assessment and eventual improvement of the Text/CSV files or other options for future replacements.  However, any changes will be complicated by DHS who require the text files in their current format for their systems. Excel was rejected as an alternative as it was too vulnerable to errors.


Each month the PBS Monthly Publishing System (MPS) processes the PBS XML into the PBS API. The PBS API then drives all PBS outputs/ artefacts.  The API is an example of how there are many different ways to look at and process the PBS data to make it more accessible for different users. Whilst processing the PBS data each month the API runs verification reports, including a general count of drugs, forms and brands.

Vendors expressed that it would be very helpful to receive the API data at the same time as the XML. It was agreed that a working version of the API would be made available to vendors via the embargo page from 1 October 2015.


  1. It would be useful to have end dates in the data. For processing this allows out of date items/drugs to be ignored which reduces processing work.
  2. There are some instances where item codes have been re-used.  There is currently no way of telling that something is a pre-used code which causes some confusion.
  3. It would be ideal to have a snapshot in the data of 12 months of changes – at the moment there is only the changes applying to the current month.  Vendors present indicated that they use the PDF Summary of changes rather than the changes list currently included in the PBS data.
  4. The process for versioning the data needs to include the version within the PBS data. At the moment if there are multiple runs of the data they are all called v1 which is difficult when processing to know which version is current.
  5. Schema versions – incremental bug fixes are not included within the current XML – this requires that some validation must be turned off.  For example for the incremental version 2.11.2 - the 2.11 validation should be used.
  6. Unstable restriction codes and unstable AMT ID’s seem to be a problem for everyone including DHS and vendors expressed that it would be ideal if these could be stabilised. Is there a way that these could be less changeable? Will version 3 of the PBS XML help this situation? Fivium suggested that there are internal IDs which are stable in PharmCIS and there is a possibility of exposing these.
  7. It was agreed that the release notes are not effective and generally do not give enough information about changes to the data.  A vendor noted it is difficult to give clear advice to their users about why they are getting re-issues of software.
  8. It was noted that the volume of changes is increasing and the multiple releases and lateness of data is continuing to cause issues for vendors. It was agreed by Health that advance notice of new data and information about the changes would be communicated as soon as practical.
  9. A pricing Summary of Changes spreadsheet was discussed and vendors thought this could be useful.
  10. Therapeutic Group Premium page has been removed from the PDF Schedule and there was information there regarding based priced drugs which cannot be found anywhere else.  Can this be put back in the Schedule?  Response – this information will be added to the Therapeutic Group Premium page on the PBS website from 1 October.
  11. Add max quantity unit of use into the PDF schedule to match the web content. Response – this is currently being considered by Health.
  12. Supply a list of deletions for the previous 12 month period. This should include item number, program, and brand. Response – this may be possible to do through the API but Health are looking into how best to supply this information.
  13. Include a CAR drug identifier in the PBS data and/or supply a list of CAR drugs including the HSD/non HSD distinction.