APIs available to Providers

 ACC processes are packaged as a series of online “interactions”. In most cases, the complete set of “interactions” needs to be available to the Provider, & their support team, for them to most effectively assist the patient.

ACCs move to APIs initially does not alter those “interactions”, it replicates them. This provides parties the opportunity of an initial reasonable impact step change.

Given time, ACC will change its processes; such change will be solely built using these APIs. Other solutions will be phased out for reasons such as the technology-base has reached end-of-life.

A view from your user’s perspective

The series of standard “interactions” ACC uses to manage information between Providers (& their Practices / DHBs) & itself, are:

1. Claim – Initial interaction regards a patient injury the Provider believes ACC will cover1. This interaction also empowers:

1. The Provider to refer the patient to other Providers (e.g. x-rays & / or physio’s) to undertake work that will assist with diagnosis & / or recovery2.
2. A subset of Providers (Medical Practitioners3) to advise a level of fitness for work of less than 100% which then results in authorisation of weekly compensation for the first week by the employer & the second week by ACC4.

2. Medical certificate – Secondary interaction (linked to Claim) if:

1. A patient:
   1. Needs time off work beyond the first two weeks;
   2. Needs additional support to operate in life or getting to / from work;
   3. Presents additional complications that need to be considered;
2. The Provider: Needs extra support services to assist with diagnosis.

Important Note: The Claim & Medical Certificate are also crucial standard “interactions” for the Patient; providing a document for their record &, as appropriate, a document for their employer (or other third party) advising of their circumstances. 

3. Request for extension – Secondary interaction (linked to Claim) if the patient needs extra treatment(s) beyond standard maximums. To ensure that ACC will fund them, the Provider needs to gain prior approval of these.

Important Note: This interaction is still not offered via API. 

4. Change of Diagnosis – Secondary interaction (linked to Claim) for Providers to submit an update in diagnosis thinking.

5. Invoicing – Mechanism to receive invoices from Providers for ACC funded diagnosis & / or treatment (linked to Claim).

6. Claim query status – Ability for the Provider to see whether the claim has been accepted & what are the latest diagnoses if other Providers have been referred to.

7. Invoice / Payment query status - Ability for the Provider / Practice to see whether invoices for the claim, or secondary interactions, have been paid.

8. Document In - Ability for the Provider / Practice to submit various document types:

• Extension of treatment requests – ACC32
• Discharge and Operation reports
• Surgery requests and documentation
• Radiology reports
• High Tech Imaging
• Guided Injection requests
• Specialist / GP / Other treatment provider notes

Managing expectations

Some standard questions & answers:

1. What APIs are offered for Providers?

All the above “interactions” except Request for extension.

2. What is the immediate impact of change for the Provider?

ACC is deliberately not changing the basic “interactions” as described above; this is to keep the initial change experience for all parties at a reasonable level. However, adoption can still result in considerable benefits for the Provider; see the following section titled “ACC intent – with a focus on Provider benefits”.

3. What is the impact of change for the software vendor?

Prior to each API being published for your use, ACC will have it in use in some practices. Some indicators of impact follow:

1. Development & Testing: Duration subject to your experience with APIs.
2. Acceptance to go to Production: ACC put you through some standard tests. These are designed to try & pick up quirks that current “interactions” may provide.
3. Once APIs are in Production & have been consumed by Providers:
   1. Software vendor is the initial point of contact regards user service desk requests & is to keep the user base informed.
   2. Software vendor escalates to ACC if appropriate & is then kept informed.
4. Change Management:
   1. Industry good practice with APIs is to work with current version (N) or the version immediately preceding it (N-1).
   2. ACC intends to not release such a version upgrade any more frequently than every six months with legal & compliance issues always a possible exception. This frequency may well occur initially but will ease off.
   3. Software vendor needs to commit to such versioning.

 4. Further improvements?

Given time, there will be improvements to the “interactions” supported by these APIs. Timing for such change has yet to be confirmed, but will be signalled well in advance.

5. Future of legacy solutions?

Service improvement will be channelled through these APIs; legacy solutions will be closed down.

ACC intent - with a focus on Provider benefits

Software vendor adoption of these APIs will result in Providers receiving the following benefits:

1. Simpler user set up – There will only be one:

1. User registration process for all “interactions” listed above;
2. Place to go within your application for all ACC related activity; &
3. User look-&-feel experience within a vendor system.

2. Simpler / Better user experience - To make it easier for Providers to do things right first time ACC is being a bit creative with those standard “interactions”. For example:

1. Mandate vendor ID with the claim to more easily link it to a resulting invoice.
2. Ensure that any patient cellphone number is sent to ACC.
3. Using cache to speed up the claim status experience after the first search.

 3. Software vendor can provide value add – Vendors can now:

1. Provide these “interactions” in a way that makes sense in their application;
2. Consider adding further value for the Provider from their experience; feel free to share thinking “in confidence” with ACC early on to ensure value.
3. Extract & automatically populate an API request from their stored database rather than the Provider retyping information.

4. Optimised change management - ACC is working to adopt central Government / sector initiatives & signalling that change to its processes / “interactions” is coming:

1. These APIs are the platform to support all such changes; for example:
   1. API standards: https://www.ict.govt.nz/guidance-and-resources/standards-compliance/api-standard-and-guidelines/
   2. SNOMED codes: http://www.health.govt.nz/nz-health-statistics/classification-and-terminology/new-zealand-snomed-ct-national-release-centre
   3. New improved ACC approach to services.
2. By moving to these APIs now, software vendors assist their Providers by stepping through a part of the overall change process.

A key driver

SNOMED codes are being adopted nationwide & will eventually be the only medical codes accepted across New Zealand. SNOMED codes can only be submitted to ACC using APIs & any future widening of SNOMED acceptance by ACC will also only be through APIs. Other ACC solutions will be phased out because they cannot be adjusted to support SNOMED code submission.

1. Claim is accepted after a registration step within ACC; 92% of claims are accepted within 24 hours of submission.
2. Upon acceptance of the claim ACC will also cover the costs of these Providers as well as the initial Provider.
3. Medical Practitioner = General Practitioner & Nurse Practitioner. Note: Nurse Practitioner differs from Practice Nurse
4. Claim can only be used for this purpose to a maximum of two weeks; subsequently a medical certificate is required.