Verify

Verify #

The verify endpoint works with or without a `type’ element.

  1. To reduce the number of verify API calls you can omit the type element from the request (eg “type”: “Verify:Medicare”) and the API will determine from the JSON body what type(s) of verification to do. You can send a full range of information in a single verify request and the API will attempt to verify everything. EG if Medicare +/- Fund +/- DVA details are provided then the API will perform all the possible verifications and return the results in one aggregate response.

  2. Any verify request that has a Medicare component will also return concession eligibility Your code to parse the status.concession node and display the results in the UI.

  3. The verify error codes have worked example. You should adapt your integration to handle return codes in the range 8015 to 8021. See examples below.

Alternatively you can add a specific type to verify if you only want a single type of verification. NOTE that verification requests for single patients will receive a synchronous response if the Medicare gateway is available.

The types of verifications are

  • Medicare - the most common of verification types, most Australians have a Medicare card which entitles them to various rebates for medical activities. This also covers Reciprocal Health Care Arrangements (RHCA) for visitors from certain countries. The verify function may display updated Medicare and DVA details in some cases, see the examples below.

  • Concession entitlement - Concession cards are granted to some Australians to provide a discount for health services. The API will routinely return a concession entitlement status with a Medicare verification. No concession details are returned, only the status.

  • Veterans Affairs (DVA) - is for checking Veterans Card details with the Department of Veterans Affairs. Claims for veterans with this card are handled by Medicare on behalf of DVA, sometimes using different item numbers and claim rules.

  • Fund - is for checking Health Fund details with the relevant fund. Note that a fund sometimes knows a patient by a different name, you should allow for this in your UI. Some funds such as BUPA require an additional patient.fund.ref for their Patient Identifier (UPI).