This document is a guide to the features of PBS XML version 3.0.
The PBS Schedule is published every month. The PBS XML schema defines the structure of the XML that represents the PBS Schedule.
Version 3.0 of the PBS XML schema is composed of a number of modules.
A PBS XML document contains all information that defines the PBS Schedule for a given month. This includes information required for prescribing medicines, as well as information required for dispensing medicines. That is, it includes information on items and listings that are effective but also information that is not effective but still 'active' (i.e. may be claimed).
The figure below shows the toplevel structure of a PBS XML document.
The info element contains metadata about the PBS XML document.
The previous-list element contains history data. It contains previous elements, each of which contains data from earlier versions of the Schedule.
The schedule element contains most of the data for the PBS Schedule. This element contains data for each program of the PBS.
The pharmaceutical-items-list element contains elements that describe "pharmaceutical items". "Pharmaceutical items" pertain to pharmaceutical benefits.
The drugs-list element contains drug concepts. The PBS Schedule uses the Australian Medicines Terminology (AMT) to describe medicines and medicinal concepts.
The prescribing-texts-list element contains textual components of the Schedule. These consist of various types of components, such as restrictions, notes and cautions.
The organisations-list element contains the list of manufacturers of products listed on the PBS.
The rdf:RDF element contains the PBS Ontology.
The PBS XML Schema has major and minor releases, see PBS XML Schema Management Policy. A major release (re-)defines the elements in the PBS Namespace, http://schema.pbs.gov.au/
and is not backward- or forward-compatible with the previous version of the schema.
Over time, new features will be need to be added to the schema. These will be added in a minor release of the schema, starting with version 3.1. Minor releases of the schema are both backward- and forward-compatible.
"Backward-compatible" means that a processor that can accept a certain version of the schema can also accept earlier versions of the schema. For example, a processor that can accept a version 3.2 document can also accept a version 3.1 document.
"Forward-compatible" means that a processor that can accept a certain version of the schema can also accept a future version of the schema. For example, a processor that can accept a version 3.0 document can also accept a version 3.1 document. For the PBS, forward-compatibility is an important feature to support since PBS XML documents are only produced from one source, the Department of Health, and the schema only ever advances its version number.
Forward compatibility is achieved using an extension layer. The extension layer is defined by the XML Namespace http://extension.schema.pbs.gov.au/
. Elements in the PBS Namespace are never removed, their cardinality changed or the meaning of their content changed. Minor versions of the schema always add new elements to the extension namespace. In order to be forward-compatible, a processor MUST ignore elements in the extension namespace that it does not understand.
Schema-validation of a PBS XML document is optional, since the Department of Health ensures that every PBS XML document is schema-valid upon publication. However, some recipients may wish to schema-validate a PBS XML document, for example to augment the document with the PSVI.
There are two modes for schema-validating a PBS XML document: forward-compatible or exact-version.
"forward-compatible" mode only validates elements in the PBS Namespace. All elements in the Extension Namespace are ignored (i.e. they are always accepted as valid). To schema-validate a PBS XML document in forward-compatible mode use rng/pbs.rng
(for Relax-NG validation) or xsd/pbs.xsd
(for XSD validation).
"exact-version" mode validates all elements in both the PBS Namespace and Extension Namespace. This mode is specific to a particular minor version of the PBS XML Schema (i.e. version 3.1, version 3.2, and so on). To schema validate a PBS XML document in exact-version mode use rng/extension.rng
(for Relax-NG validation) or xsd/extension.xsd
(for XSD validation).
General information and conventions used in the PBS XML.
To allow cross-referencing of information, the PBS XML uses codes and identifiers.
Codes are used to identify many different types of concepts, such as a PBS Item (a "prescribing rule"), restriction or a drug concept (such as a TPP). Codes are stable in the PBS Schedule, i.e. a given concept will not normally change its code from month-to-month[1].
A code is represented by the code element. Each different type of concept will have an associated type of code; this is given as the rdf:resource attribute of the code element. Sometimes a concept may be identified by more than one type of code. In this case the concept will have multiple code element children and each code element child will have a different rdf:resource attribute to distinguish the different types of codes.
An identifier is used to identify an individual XML element within the PBS XML document. Identifiers are represented by the xml:id attribute. Identifiers are not stable from month-to-month in PBS XML documents, i.e. they are only relevant to a particular PBS XML document. They are not stable across different versions of the PBS XML document for the same month.
Where a concept may be repeated many times the PBS XML uses a container element, known as a list. A list container is named by taking the plural form of the name of the element being repeated and appending the phrase '-list'. For example, a list of dispensing-rule elements is contained in an element named dispensing-rules-list.
The order of child elements in a list is significant.
The main structure of the PBS XML is contained in the schedule element. This represents the data that is active for the PBS Schedule for a given month. The schedule element contains information that applies to the PBS Schedule as a whole, followed by programs.
Each program is represented by a program element. This element includes metadata, the specification of its dispensing rules and a set of PBS Items, more properly known as 'prescribing rules'.
A dispensing rule is the set of fees, markups and containers that are needed for pricing a product in a particular dispensing setting. A "dispensing setting" is the environment in which a product is dispensed, such as a Community Pharmacy or a Public Hospital Pharmacy.
Every program has a list of dispensing rules. Each dispensing rule has three components:
The fee-definitions-list element contains a list of fee definitions. Each fee that may apply in the dispensing setting is defined by a fee-definition element. The fee-definition element referes to the type of fee using the rdf:resource attribute. The amount payable for the fee in the dispensing setting is given by the amount element.
The markup-bands-list element contains a list of markup bands. Each markup band defines the markup for either the wholesale or handling value or the retail value.
The container-definitions-list element contains a list of container fees. Each container fee is described by a container-definition element. The container-definition element includes the price and size of the container, along with other data such as the unit-of-measure of the container size.
A PBS Item is represented by the prescribing-rule element. The prescribing rule brings together all listing information for an item: benefit type, drug, form-and-strength, maximum quantity, number of repeats, restrictions, and so on. There are different types of prescribing rules, as given by a child element: ready-prepared, solvent-rule, infusible, extemporaneous-preparation, standard-formula-preparation or drug-tariff.
The subsidisation of a drug for a patient is known as a benefit. A benefit may only be paid under certain conditions; these are known as benefit types. The benefit-type element specifies the conditions for subsidy for a prescribing rule. There are different kinds of benefit types, as follows:
The PBS imposes no constraints on the prescribing of the item.
The prescriber is expected to prescribe the item in accordance with the specified restriction(s).
An authority to prescribe the item must be obtained from the Department of Human Services.
The prescriber must include the Streamlined Authority Code on the prescription.
A benefit-type element associates a prescribing rule with prescriber types and (optionally) restrictions. A prescribing rule may be associated with one or more benefit types. A benefit type may be associated with zero or more restrictions. A benefit type may be associated with one or more prescriber types. However, a given prescriber type may only have at most one association with a given prescribing rule.
A prescriber may apply for authorisation for an increased quantity for an item or an increased number of repeats (or both). The increase element provides guidance on whether an increase will be authorised and the rules that apply to the granting of the authorisation. Increases use the same data model as benefit types (though, strictly speaking, they are separate to benefits). An increase always requires authorisation by the Department of Human Services, i.e. they are an authority-required
value. The increase element specifies a threshold value where authorisation may be obtained electronically. Higher values require authorisation by telephone. If an increase is not permitted then the value is given as none
.
An increase element has one value and one "benefit-type". Multiple increase elements may be given for different types of increases, i.e. to maximum quantity or number of repeats, or for different prescriber types. If no increase element is specified for a prescriber type then an increased quantity or number of repeats is not permitted under any circumstances, i.e. this is equivalent to an increase with the value given as none
.
A product listing is an association between a prescribing rule and a TPP. It indicates that that product may be supplied and claimed against the PBS Item. It is represented by the product-listing element.
Product listings are used for both ready-prepared items and infusible items. They are not used for extemporaneously prepared items.
The product-listing element contains information that relates to the product in the context of the prescribing rule, such as pricing and brand substitution. Pricing data is denormalised; each product listing contains all pricing data for the prescribing-rule/TPP relationship, even though that data may be repeated in product listings for the same prescribing rule.
For ready-prepared listings, a product-listing element contains three sets of pricing data:
The reimbursement element contains the amount that the Commonwealth subsidises the medicine.
The lowest element contains the lowest of the manufacturer prices.
If there is a difference between the Commonwealth reimbursement price and the lowest of the manufacturer prices, then a premium is payable by the consumer. This premium will be either a Therapeutic Group Premium or an Other Special Patient Contribution.
The manufacturer element contains the price that the manufacturer charges for their product.
If there is a difference between the lowest of the manufacturer prices and this manufacturer's price, then Brand Premium is payable by the consumer.
Each of these pricing elements contains one or more price elements, one for each dispensing rule defined for the program. The price element contains the price for that dispensing rule in its amount child element, as well as any markups or fees that are included in the price.
Every prescribing rule is subject to a pricing arrangement (except for Extemporaneous Preparations). There are two pricing arrangements:
Payment for the supply of the medicine is made through the supply chain, from Medicare and the consumer to the Pharmacist, a wholesaler and finally the manufacturer.
The normal pricing arrangement is represented by the concept http://pbs.gov.au/pricing-arrangement/normal.
Payment for the supply of the medicine is made from Medicare Australia directly to the manufacturer. The Pharmacist claims any markups and fees associated with dispensing the medicine from Medicare Australia, and pays the wholesaler the wholesale markup, if any.
The invoiced price for the pharmacy may be based on the published price for the medicine. The pharmacy will be eligible for a credit or rebate or adjustment from the wholesaler or compounder based upon the invoiced price less the wholesale markup on the published price.
The fee-only pricing arrangement is represented by the concept http://pbs.gov.au/pricing-arrangement/fee-only.
The pricing arrangement for an item is given by the rdf:resource attribute of pricing elements in product listings for the item. Pricing elements are: ex-manufacturer, to-pharmacist, pharmacist and dpmq. For example:
Example 1. Normal Pricing Arrangement
<product-listing> <code rdf:resource="http://pbs.gov.au/code/manufacturer">GK</code> <tpp-reference xlink:href="#a1484"> <code rdf:resource="http://snomed.info/sct/900062011000036108">11403011000036104</code> </tpp-reference> <reimbursement> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing-arrangement/normal"> <amount>25.10</amount> </ex-manufacturer> <to-pharmacist rdf:resource="http://pbs.gov.au/pricing-arrangement/normal"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>26.99</amount> <markup xlink:href="#a13862"> <amount xml:id="a13863">1.89</amount> </markup> </price> </to-pharmacist> <pharmacist rdf:resource="http://pbs.gov.au/pricing-arrangement/normal"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>31.03</amount> <markup xlink:href="#a13864"> <amount xml:id="a13865">4.04</amount> </markup> </price> </pharmacist> <dpmq rdf:resource="http://pbs.gov.au/pricing-arrangement/normal"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>38.32</amount> <fee xlink:href="#a13866"> <amount xml:id="a13867">7.29</amount> </fee> </price> </dpmq> </reimbursement> <lowest> <!-- Similarly for lowest pricing --> </lowest> <manufacturer> <!-- Similarly for manufacturer pricing --> </manufacturer> </product-listing>
Example 2. Fee-Only Pricing Arrangement
<product-listing> <code rdf:resource="http://pbs.gov.au/code/manufacturer">GK</code> <tpp-reference xlink:href="#a1484"> <code rdf:resource="http://snomed.info/sct/900062011000036108">11403011000036104</code> </tpp-reference> <reimbursement> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing-arrangement/fee-only"> <amount>25.10</amount> </ex-manufacturer> <to-pharmacist rdf:resource="http://pbs.gov.au/pricing-arrangement/fee-only"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>26.99</amount> <markup xlink:href="#a13862"> <amount xml:id="a13863">1.89</amount> </markup> </price> </to-pharmacist> <pharmacist rdf:resource="http://pbs.gov.au/pricing-arrangement/fee-only"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>31.03</amount> <markup xlink:href="#a13864"> <amount xml:id="a13865">4.04</amount> </markup> </price> </pharmacist> <dpmq rdf:resource="http://pbs.gov.au/pricing-arrangement/fee-only"> <price> <dispensing-rule-reference xlink:href="#a13861"> <code rdf:resource="http://pbs.gov.au/code/dispensing-rule">rp-s90-cp</code> </dispensing-rule-reference> <amount>38.32</amount> <fee xlink:href="#a13866"> <amount xml:id="a13867">7.29</amount> </fee> </price> </dpmq> </reimbursement> <lowest> <!-- Similarly for lowest pricing --> </lowest> <manufacturer> <!-- Similarly for manufacturer pricing --> </manufacturer> </product-listing>
When an item with a fee-only pricing arrangement is dispensed, the Pharmacist claims only for the markups and fees for the item (less any patient copayment). The markup amount, per pack, for the wholesaler is given in the to-pharmacist element's markup descendant element. The markup amount, per pack, for the pharmacist is given in the pharmacist element's markup descendant element. Any fees associated with dispensing the product are given in the dpmq element's fee descendant elements.
For example, taking the product listing shown in the previous section, if the dispensed quantity is 2 packs then the amount of $19.15, less patient copayment, would be claimed from Medicare Australia (2 x $1.89 + 2 x $4.04 + $7.29). The wholesaler markup amount of $3.78 would be paid to the wholesaler (2 x $1.89).
An alternative method would be to calculate the Dispensed Price for Dispensed Quantity (DPDQ) in the usual manner, but to then subtract the PrEMP multiplied by the dispensed quantity. For example, taking the product listing shown above, if the dispensed quantity is 2 packs then the DPDQ is $69.35 (2 x $31.03 + $7.29). Multiplying the PuEMP by 2 gives $50.20. Thus the PBS Online claim amount is $19.15 ($69.35 - $50.20).
A Pharmaceutical Item with a normal pricing arrangement has its Approved Ex-Manufacturer Price (AEMP) given in the ex-manufacturer child element of the pharmaceutical-item element. This element has a rdf:resource attribute with the value http://pbs.gov.au/pricing/aemp
to indicate that it is the AEMP value. These items also have a Published Ex-Manufacturer Price (PuEMP). The PuEMP is the published price of the item and is equal to the AEMP. The PuEMP is included in the pharmaceutical-item element as a child ext:ex-manufacturer element with an attribute named rdf:resource with the value http://pbs.gov.au/pricing/puemp
.
Example 3. Pharmaceutical Item with Normal Pricing Arrangement
<pharmaceutical-item> <drug-references-list> <mp-reference xlink:href="#a12875"> <code rdf:resource="http://snomed.info/sct/900062011000036108">21512011000036101</code> </mp-reference> </drug-references-list> <block-container> <dbk:para>Aqueous nasal spray (pump pack) containing ipratropium bromide 21 micrograms (as monohydrate) per dose, 180 doses</dbk:para> </block-container> <quantity>1</quantity> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/aemp"> <amount>14.31</amount> </ex-manufacturer> <ext:ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/puemp"> <amount>14.31</amount> </ext:ex-manufacturer> </pharmaceutical-item>
Pharmaceutical Items with a fee-only pricing arrangement do not include their AEMP. Instead, they have a Published Ex-Manufacturer Price (PuEMP). The PuEMP is given in the ex-manufacturer child element of the pharmaceutical-item element. This element has a rdf:resource attribute with the value http://pbs.gov.au/pricing/puemp
to indicate that it is the PuEMP value.
Example 4. Pharmaceutical Item with Fee-Only Pricing Arrangement
<pharmaceutical-item> <drug-references-list> <mp-reference xlink:href="#a13741"> <code rdf:resource="http://snomed.info/sct/900062011000036108">21820011000036106</code> </mp-reference> </drug-references-list> <block-container> <dbk:para>Capsule 250 mg</dbk:para> </block-container> <quantity>120</quantity> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/puemp"> <amount>732.56</amount> </ex-manufacturer> <ext:ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/puemp"> <amount>732.56</amount> </ext:ex-manufacturer> </pharmaceutical-item>
A TPP with a normal pricing arrangement has its Proportional Ex-Manufacturer Price (PEMP) given in the ex-manufacturer child element of the tpp element. This element has a rdf:resource attribute with the value http://pbs.gov.au/pricing/pemp
to indicate that it is the PEMP value. The claimed price has no rdf:resource attribute. These products also have a Proportional Published Ex-Manufacturer Price (PrEMP). The PrEMP is the published price of the product and is equal to the PEMP. The PrEMP is included in the tpp element as a child ex-manufacturer element with an attribute named rdf:resource with the value http://pbs.gov.au/pricing/premp
.
Example 5. TPP with Normal Pricing Arrangement
<tpp> <code>676141000168108</code> <preferred-term rdf:resource="http://pbs.gov.au/clinical"> Celecoxib (Terry White Chemists) 100 mg hard capsule, 60 </preferred-term> <pack-size>60</pack-size> <brand-name> <value>Terry White Chemists Celecoxib</value> </brand-name> <ex-manufacturer> <!-- Claimed price --> <amount>5.23</amount> </ex-manufacturer> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/pemp"> <amount>5.23</amount> </ex-manufacturer> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/premp"> <amount>5.23</amount> </ex-manufacturer> </tpp>
TPPs with a fee-only pricing arrangement do not include their PEMP. Instead, they have a Proportional Published Ex-Manufacturer Price (PrEMP). The PrEMP is given in the ex-manufacturer child element of the tpp element. This element has a rdf:resource attribute with the value http://pbs.gov.au/pricing/premp
to indicate that it is the PREMP value.
Example 6. TPP with Fee-Only Pricing Arrangement
<tpp> <code>11572011000036108</code> <preferred-term rdf:resource="http://pbs.gov.au/clinical"> Aptivus 250 mg soft capsule, 120 </preferred-term> <pack-size>120</pack-size> <brand-name> <value>Aptivus</value> </brand-name> <ex-manufacturer> <!-- Claimed price --> <amount>732.56</amount> </ex-manufacturer> <ex-manufacturer rdf:resource="http://pbs.gov.au/pricing/premp"> <amount>732.56</amount> </ex-manufacturer> </tpp>
A script may specify that a particular brand of a product has been prescribed. The dispenser may dispense that brand, or may substitute a different brand as long as the following applies:
The statement 'Brand Substitution is not permitted' is not checked
The PBS XML indicates that the two products are substitutable
Brand substitution is represented in the PBS XML as a type of group. Product listings are members of brand substitution groups, which simultaneously gives the products that are substitutable and the context in which they may be substituted.
A given prescribing rule may have no product listings that are substitutable. All product listings in the prescribing rule may be substitutable. Some of the product listings may be substitutable, but not all of them. Also, a product listing in one prescribing rule may be substitutable with a product listing in a different prescribing rule.
Every product listing is a member of exactly one brand substitution group. If the group has only one member, then the product listing is not substitutable with any other product.
The PBS Terminology concept http://pbs.gov.au/brand-substitution
defines the type of group for brand substitution. Instances of a brand substitution group are created using the concept type p:brand-substitution. These concepts are included in the PBS Terminology section of the PBS XML.
Example 7. Brand Substitution Terminology Concepts
<rdf:Description rdf:about="http://pbs.gov.au/brand-substitution"> <db:title>Brand Substitution</db:title> <db:para>Whether a pack may be substituted with another bioequivalent or biosimilar brand.</db:para> </rdf:Description> <p:brand-substitution rdf:about="http://pbs.gov.au/brand-substitution/GRP-12946"> <db:title>Brand Substitution Group</db:title> <p:code>GRP-12946</p:code> </p:brand-substitution>
One, or more, product-listing elements will be members of the group instance. For example:
Example 8. Brand Substitution Group Membership
<product-listing> <tpp-reference xlink:href="#a247829565"> <code rdf:resource="http://snomed.info/sct/900062011000036108">13105011000036107</code> </tpp-reference> <code rdf:resource="http://pbs.gov.au/code/manufacturer">IA</code> <member-of-list> <member-of rdf:resource="http://pbs.gov.au/brand-substitution/GRP-12946"> <code rdf:resource="http://pbs.gov.au/code/group">GRP-12946</code> </member-of> </member-of-list> <reimbursement>...</reimbursement> <lowest>...</lowest> <manufacturer>...</manufacturer> ... </product-listing>
A Pharmaceutical Item (PI) is part of the legal basis for determining a pharmaceutical benefit. A PI includes a drug, form, strength and manner of administration. There may be multiple MPPs associated with a PI, being the different pack sizes that the product is available in. An mpp-reference will include a reference to its PI.
Some pricing information is included in the PI, in particular AEMP and PEMP.
The PBS XML Schema v3 includes support for AMT v3. Seven of the notable concepts in AMT v3 are included in the schema: MP, MPUU, MPP, TP, TPUU, TPP and CTPP. The PBS XML Schema includes an element corresponding to each of the concepts and their relationships are modelled using references.
'Restrictions' are more broadly described as 'prescribing texts'. The term 'prescribing texts' encompasses informational text such as notes and cautions. Prescribing texts are divided into two categories and include the following components:
foreword
administrative advice
caution
definition
prescriber instruction
indication
treatment phase
criteria
parameter
Every restriction has two codes: a restriction code and a treatment-of code. The two code elements in the restriction are distinguished using their rdf:resource attribute. The restriction code has the rdf:resource attribute value http://pbs.gov.au/code/restriction
. The treatment-of code has the rdf:resource attribute value http://pbs.gov.au/code/treatment-of
.
Example 9. Codes for Restrictions
<restriction xml:id="a1234987"> <code rdf:resource="http://pbs.gov.au/code/restriction">1234</code> <code rdf:resource="http://pbs.gov.au/code/treatment-of">5678</code> ... </restriction>
In the example above, the restriction code for the restriction is 1234
, and the treatment-of code for the restriction is 5678
.
Restriction codes are unique across all restrictions. Treatment-of codes may be duplicated; this is because there may be two or more restrictions that have the same legal text, but different informational text.
The treatment-of code only changes when legal components of the restriction are changed, added or removed. Changes to informational prescribing texts do not affect the treatment-of code.
If any part of the restriction is changed, legal or informational, then the restriction will be given a new restriction code.
The treatment-of code of a restriction is used as the Streamlined Authority Code (SAC) for that restriction.
Where a PBS Item's benefit type is authority-required
, the method by which a prescriber applies to the Department of Human Services for an authority to prescribe the medicine depends on how the application will be assessed. There are two types of assessment:
immediate
The application for an authority to prescribe the medicine should be submitted to the Department of Human Services via an electronic interface. If the application is successful, the Authority Approval Number (AAN) will be issued as part of the transaction.
full
The application for an authority to prescribe the medicine must be submitted to the Department of Human Services, along with all required supporting documentation. Currently, this is done by writing to the Department.
The assessment type of a restriction component is determined for each parameter. By default, a parameter requires immediate
assessment. For a given restriction, if any of its parameters require full
assessment then the restriction as a whole requires full
assessment.
Every restriction contains a assessment element that gives the level of assessment required for the restriction as a whole.
Criteria and parameters are used to provide the structured form of the restriction. These may be combined in a flexible manner, using the elements all, any and one-of. These represent the logical operators conjunction, disjunction and exclusive-OR respectively. These logical operators are used to combine components both at the restriction-criteria level as well as criteria-parameter level.
Every criteria or parameter must be satisfied in order for the parent component to be satisfied.
For example, if a restriction has two criteria then both criteria must be satisified for the restriction to be satisfied.
One or more of the criteria or parameters must be satisified in order for the parent component to be satisfied.
For example, if a criteria has three parameters then either one, two or three parameters must be satisified for the criteria to be satisfied.
One and only one of the criteria or parameters must be satisfied for the parent component to be satisfied.
For example, if a criteria has three parameters then one of the parameters must be satisified for the criteria to be satisfied. If two or three parameters are satisfied then the criteria will not be satisfied.
The major restriction components, criteria and parameters, provide a medium-level structure to the restriction. The PBS XML Schema allows a more fine-grained structure by using terminology concepts. Terminology concepts are specified as part of the PBS Ontology. A terminology concept is associated with a restriction component by use of the rdf:resource attribute.
Some parameters are constrained by values. For example, the age of the patient. Constraints on parameter values are specified using facets. There are four facets:
The maximum value allowed, inclusive of the given value.
For example, maxInclusive=70 means any value up to and including 70.
The maximum value allowed, exclusive of the given value.
For example, maxExclusive=70 means any value up to 70 but not including 70.
The minimum value allowed, inclusive of the given value.
For example, minInclusive=70 means any value greater than or equal to 70.
The minimum value allowed, exclusive of the given value.
For example, minExclusive=70 means any value greater than 70 but not including 70.
The PBS Ontology is the collection of terminology concepts for the PBS. A terminology concept is a very fine-grained datum. Every terminology concept is identified by a URI. Some terminology concepts may be associated with a SnoMED-CT concept.
Groups are relationships between elements in the PBS XML that are non-hierarchical. The PBS XML Schema version 3 implements groups using the PBS Ontology.
Groups have three components:
A group type is defined in the PBS Ontology as a concept. The definition will include a description of the group, as well as its default value.
An instance of a group is defined in the PBS Ontology as a subtype of the group type.
An element may deeclare itslf to be a member of a group using the member-of element and referring to the group instance URI with the rdf:resource attribute.
'Temporal Data' refers to data that changes over time. In the PBS XML information is included in each monthly release for all data that is 'active'. 'Active' elements are those that can be prescribed or claimed in that month.
All PBS elements contain an effectivity element to reflect their current status. Effectivity elements are:
The element is currently effective on the PBS Schedule.
The element may be supplied but must not be prescribed.
The element is no longer effective on the PBS Schedule and may not be prescribed nor supplied.
An effectivity element only applies to its immediate parent element. Other child elements of the parent element will have their own effectivity element and their value is not related.
All effectivity elements contain a date, which is the date that the status commenced (or will commence in the future, see 'Advance Notices' below). They may also contain a reason element that provides the reason for the change in status.
Elements in the PBS XML are divided into two categories: complex content and simple content. Complex content elements are those that contain other PBS elements. Simple content elements are those that contain only a data value. The temporal data subsystem treats non-PBS elements, such as DocBook, SVG, and so on, as simple content. Elements that are simple content always include a child element to contain the data value, such as value.
PBS elements may be added, removed or modified. Any element that has changed will have the publication date as its effectivity date. The publication date is contained in the /root/info/dct:valid element.
Example 10. Publication Date
<root version="3.1">
<info>
<dbk:title>Schedule of Pharmaceutical Benefits</dbk:title>
<dct:created>2020-06-18</dct:created>
<dct:available>2020-06-24</dct:available>
<dct:issued>2020-07-01</dct:issued>
<dct:valid>2020-07-01</dct:valid>
</info>
To find all changes in a schedule, search the data for elements that have the value of their effective/date element equal to the publication date. For example, an XPath query to do this would be:
Note that when an element is removed, a moved element is inserted in the position where the element was previously located. The effective date of the moved element is when the removal occurred. This will correspond to the non-effective date of the now removed element (which has been relocated to the previous-list section of the document).
When a PBS element is added to the data it's effective date is equal to the publication date.
For example, a new PBS Item (prescribing rule) is represented as follows:
Example 12. New PBS Item
<prescribing-rule>
<ready-prepared>
...
</ready-prepared>
<preferred-term>aciclovir 3% eye ointment, 4.5 g</preferred-term>
<code rdf:resource="http://pbs.gov.au/code/item">21002R</code>
<effective>
<date>2020-07-01</date>
</effective>
...
</prescribing-rule>
When a PBS element is removed, the position that it was removed from is replaced with the moved element and the previous image of the element is included in a previous element in the previous-list section of the PBS XML document. The previous element includes a hyperlink to the corresponding moved element.
Example 13. Removed PBS Element
<moved xml:id="a73621356" xlink:href="#a92174632"> <effective> <date>2020-07-01</date> </effective> </moved>
Example 14. Previous Image of Removed Element
<previous xlink:href="#a73621356">
<prescribing-rule xml:id="a92174632">
<ready-prepared>
...
</ready-prepared>
<preferred-term>aciclovir 3% eye ointment, 4.5 g</preferred-term>
<code rdf:resource="http://pbs.gov.au/code/item">1002R</code>
<non-effective>
<date>2020-07-01</date>
</non-effective>
<effective>
<date>1991-08-01</date>
</effective>
...
</prescribing-rule>
When a PBS element is modified then the element includes a previous attribute. The value of the previous attrbute is a hyperlink to the previous image of the element in the previous-list section.
Example 15. Modified Element
<price> <amount xml:id="a6324873" previous="a52398432">23.45</amount> ... </price>
Example 16. Previous Image
<previous xlink:href="#a6324873"> <amount xml:id="a52398432">17.62</amount> </previous>
Most elements in the document only have changes from the previous month included. However, restriction-reference elements have their change history retained for 12 months. This includes all elements referenced by the restriction-reference element.
History details are included in the data in exactly the same way as changes. When an element is removed, it is replaced by a moved element and the element is relocated to the previous-list section. These elements are then retained in the data for 12 months. The non-effective date of the data element and the effective date of the moved element show when in the past the removal occurred.
NB. Elements that contain simple content cannot have their history represented in the data.
Where it is not possible to accurately determine the start of effectivity for an element, the "effective" date is determined by the "last known date of effectiveness". This is usually the previous schedule's date.
An effectivity element may include an advance notice of a change in status. This is achieved by including the future effectivity element in the current effectivity element. The date element in the future effectivity element gives the date on which the status will change.
Example 17. Advance Notice
<effective> <date>2010-02-01<date> <supply-only> <date>2019-10-01<date> <non-effective> <date>2020-10-01<date> </non-effective> </supply-only> </effective>
In the example above, an object became effective 1 February 2019. It will become supply-only on 1 October 2019 and then will become non-effective 1 October 2020. In the 1 November 2020 schedule the object will no longer appear in the schedule.
PBS XML documents must be both backward- and forward-compatible as long as they conform to a major version of the PBS XML Schema. "Backward Compatibility" means that an application that is able to process documents that conform to the latest version of the schema can also process documents that conform to an earlier version of the schema. "Forward Compatibility" means that an application that can process documents that conform to an earlier version of the schema are able to process documents that conform to a newer version of the schema.
The PBS XML Schema is managed in such a manner as to always maintain backward compatibility. This is achieved by adhering to the following rules:
Elements are never removed.
Content is never removed from an element's content model. This includes changing the cardinality of elements in a content model.
The meaning of an element is never changed.
The data type of a simple content model is never changed.
The PBS XML Schema includes a forward compatibility mechanism. This allows the schema to be extended with new elements to provide new features. The forward compatibility mechanism works by separating new extension elements from existing elements using an XML Namespace. The XML Namespace URI for extension elements is http://extension.schema.pbs.gov.au/
and uses the prefix ext
.
Every PBS element in the PBS XML Schema may be extended using a new element in the extension XML Namespace. There are no limits on the repeatability of extension elements, how many different extension elements may be included in a PBS element or the content of an extension element.
An important aspect of the forward compatibility mechanism is that an application must ignore extension elements that are not understood by the application. This allows an application to process a document that conforms to a newer version of the PBS XML Schema despite the presence of "foreign" elements.
[1] There are some circumstances where an object may change its code. In this situation a change element will indicate that the code value has changed and give its previous value.