Support Expectations

This document contains information regarding:

  1. Communication mechanisms.
  2. What Software vendors are supposed to do as first level support.
  3. Scenarios to assist understand yours and our role.
  4. Triage actions expected of the software vendor before contacting ACC.
  5. Examples of error messaging and what to do.
  6. ACC support expectations.

 

Communication Mechanisms

You are to contact us using the ACC Developer Resource Centre:

  1. Private or commercial-in-confidence matters:

    Use Contact Us

  2. Other matters: Use Authenticated Forums

We will notify you regards:

  1. Private or commercial-in-confidence matters: Email; or
  2. Forums: Responses, FAQs or Announcements

The Software Vendor is the First Level of Support for the User

We ask that you convey to your users that you:

  1. Are the initial point of contact regards user service desk requests;
  2. Will escalate to ACC, if appropriate; and
  3. Will keep the user regularly informed.

For a major incident ACC may elect to also update users through other mechanisms such as its website or an email list. This would be an additional, but equivalent, supporting message to what the software vendor will have been provided.

Who does what for these scenarios

Scenario

Who

Action

Receive a problem from a user

Identify an ACC-related issue ACC triage

You

You

ACC

Undertake triage

Advise ACC using “Contact Us”

Advise & update using email &/or Forum

Standard maintenance window Advise your users

ACC

You

Announce through “Forum”

Your standard mechanism

Non-standard outage Advise your users

ACC

You

As Above

Deprecation

Move to updated version

ACC

You

As Above

Feedback

You

Advise using Portal “Contact Us”

Try the below before contacting ACC

The following is recommended to provide a quicker resolution for your users:

  1. Identify and review error message and attempt to resolve issue
  2. Has the user been set up to use API services with ACC?
  3. Has the authentication for this particular API product been set up correctly? (Digital Certificate / RealMe etc)
  4. Check local user environment – not an internet issue or network issue
  5. User has been configured correctly to use API products? (Switched on with ACC and IDs/numbers provided?)
  6. Is this a user training issue rather that technical problem? - Has the user been trained to use their system, the API, and knows what they are doing?

Please provide as much details as to your resolution steps when you contact us

Error Messaging

We recommend that software vendors set up their APIs to pass on the ACC generated error messages through to their user.

The following is a summary of response codes that a user may see, with suggested resulting action:

Code

Indicates

Interpretation

Action Required of Software Vendor

201

created

Content created but not received by ACC

Advise user to send content to ACC if still required

202

accepted

Submission received by ACC

No action required

400

invalid data

Content being submitted is incorrect

Confirm this is a genuine user error and not a coding issue

401

authentication error

Senders Digital

Certificate is not valid so transaction can’t take place

Software vendor needs to check Digital Certificate is installed correctly via https://secure.healthlink.net/certinfo If no issue then, contact ACC Digital

Operations on 0800 222 994 option 1.

403

authorisation error

Sender is not authorised by ACC to make the submission

User is to contact ACC Digital Operations on

0800 222 994 option 1 to arrange permission.

500

internal server error

ACC system issue

Advise ACC Digital Operations on 0800 222 994 option 1. User needs to resubmit content to ACC later. 

673
30