*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.
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
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.
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.
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.
We are always looking for ways to improve our website
© Commonwealth of Australia | Department of Health and Aged Care