Frequently Asked Questions

If needed, please view the Project Glossary.

Generalised Questions

How will PRISMS data flow between the PRISMS and provider systems? Will data be entered directly into a provider system and updated in PRISMS, or entered into PRISMS for updating in provider systems?

The data will be entered directly into a provider system and updated in PRISMS. The plan is to have Application Programming Interface (API) functionality implemented in PRISMS so that the data in the admission and student management systems can create Confirmation of Enrolment (CoEs) in PRISMS. We may also introduce the facility to retrieve some CoE updates from PRISMS through the API to feed into your student/admission systems. This may depend upon provider feedback going forward.

Will there be other changes to PRISMS functionality as a result of updating the system to allow for APIs?

The scope of this project is to expose PRISMS functions through the Application Programming Interface (API). We do not intend to change existing behaviour, for example, changing the behaviour of student transfers. Current transfer restriction rules will be maintained; meaning providers cannot bypass National Code Part D, Standard 7 when creating CoEs through the API.

Will manual CoE creation processes continue when the API is released? If so, at what point will this cease?

We are working under the assumption that not all providers will use the new PRISMS API. We expect a gradual transition of providers towards PRISMS API. Therefore, the PRISMS web user interface (UI) will continue into the foreseeable future.

The initial focus of the API is mainly geared towards data entry (CoE creation). Are data extraction functions being considered (for example, reporting purposes)?

The current focus is to have Application Programming Interface (API) functionality implemented in PRISMS so that the data in the admission and student management systems can create Confirmation of Enrolment (CoEs) in PRISMS. We may also introduce the facility to retrieve some CoE updates from PRISMS through the API to feed into your student/admission systems. This may depend upon provider feedback going forward.

Will the API project include Student Course Variations (SCVs), or does it simply focus on the creation of new CoEs?

We are currently targeting implementation of functions that will allow for CoE creation for the second quarter of 2023. We intend to implement some high value simple SCV functions at a later date, however this implementation may depend on provider feedback in terms of which PRISMS functions are viewed as highest priority.

What happens if a provider decides to change software vendor?

A move to a new software vendor would simply require a re-registration process for the provider in that new software system. We are working on a model that would not require new accounts etc. to be established.

As some student management systems record Unique Student Identifiers (USIs), is including the USI a consideration in this project?

As PRISMS does not record USIs currently, there are no plans to use USI as part of this project.

Is project funding available for Software Vendors to support build costs from their side?

No, not through this project. This project is just focusing on the development of APIs.

Can we use API functionality for CoE extensions? Also, if students are ‘transfer restricted' from another provider, will API functionality still prevent issuing a new CoE without a release?

CoE extensions (student course variations) are out of scope for Phase 1. We intend to implement some high value simple SCV functions at a later date, however this implementation may depend upon provider feedback in terms of which PRISMS functions are viewed as highest priority.

Current transfer restriction rules will be maintained; meaning providers cannot bypass National Code Part D, Standard 7 when creating CoEs through the API.

With the introduction of APIs to PRISMS, will there be any other updates to current PRISMS functionalities?

We have no plans to change existing business processes as part of this project.

What level of engagement is required from software vendors and providers to prepare for the APIs release?

Software vendors are critical to the success of this project as they will need to update their student management and admissions systems to consume the new PRISMS APIs. In the coming months, we will begin the formal process of registering or onboarding software vendors as development partners with the department. Once onboarded, we will reach out to understand the development processes and needs of our partners, as well as provide expectations, timeframes and requirements for the new APIs.

Will there be an API 'start-up' kit that makes it easy to connect to APIs?

Yes, we anticipate publishing overview and detailed documentation on the APIs themselves, as well as more general ‘user guide’ documentation, published on a developer portal for registered development partners.

Technical Questions

Will the PRISMS UI be changed to use the same underlying new APIs to perform the same transaction (to avoid having different behaviour between the UI vs the API)?

We do not have any plans to change the PRISMS UI. Where we can, we are going to utilise the new API calls, however this may not be possible in some situations. Where this is not possible, we are going to great lengths to ensure the new API will use the same rules as the UI to help ensure consistency between the API and UI. We are also enhancing a range of automated tests to help pick up any potential discrepancies.

When it comes to data validation (to see if a student exists or not), what type of parameters are you considering? Are you looking at multiple parameters (composite IDs)?

When creating a CoE we are planning to automatically identify the student for whom the CoE is being created. Where a suitable student record cannot be found, PRISMS will create a new student record for the CoE.

To identify the student, we will use information given as part of the CoE Create request. We intend to use a previous CoE of the student (optional input), and passport number and nationality (both mandatory inputs) to determine whether the student exists. We will validate the details to ensure input student details match those of the student in PRISMS (e.g. names, date of birth, country of birth).

As individual user authentication is problematic for SMS software vendors to implement, is the project looking to use machine-to-machine credentials?

At this stage we are looking at individual user authentication for legislated reporting tasks, but note there will be many tasks that can be machine-to-machine. Where it makes sense, we will use machine to machine authentication. We understand individual user authentication can interrupt the user experience, however there are role restrictions, compliance, and audit requirements around the CoE process that requires us to assign tasks to an individual user.

Is dataflow from PRISMS to SMS being considered? For example – can visa status be updated in SMS?

We do foresee some functions being implemented in the future that could allow data such as visa status to be retrieved through the API. However, the features that are developed will depend upon provider feedback. We will use this feedback to help focus our attention on the highest priority features we implement as part of this project.

Where within the project’s key dates will the API specification (assuming in RAML) be released?

We are expecting to release API definitions following OpenAPI rest based standards. We are currently breaking down the APIs required and their definitions. We will be engaging with software vendors to begin onboarding and determine the optimal time to begin releasing these. However, at this stage we do not have a specific time frame in mind. Please refer to the question “what level of engagement is required from software vendors and providers in order to prepare for the APIs release?” for more context.

Will the API validate the user on provider systems as having the required access to PRISMS, or is this up to providers to implement controls?

Identity checking will be part of the APIs. However, we haven't determined yet whether this should be at the user level (attended) or system level (unattended). If at the user level PRISMS will be able to check the user role. However, an attended workflow will require the user to validate their identity with PRISMS at some point in the workflow. In an unattended workflow, PRISMS will not know the identity of the user, so it would be up to the provider's system to enforce roles.

For any thoughts on this, please write to prismsapi@education.gov.au

Are we able to commence the mapping of data elements in anticipation of completing the integration quickly?

In terms of mapping, we’d suggest looking at the gaps in the data collected just for awareness at this stage. We will be engaging with software vendors on the next stages in further detail. For now, please provide us with feedback on any gaps in data elements and send to prismsapi@education.gov.au

What UID (unique identifiers) are you planning to use for the queries? Currently, PRISMS allows you to search CoEs based on the student's provider ID, passport, or CoE number. Are all those included?

We are currently defining these. Right now our focus is the creation of a CoE. When appropriate, we'll be seeking further feedback on our next focus areas.

Universities have data in multiple systems required for creating CoEs. How will the API manage that situation?

The scope of our project is to expose existing PRISMS functions through the API. Data required (e.g. to create CoEs) will remain as is. We will leave the arrangement of which of the provider systems will be creating APIs between education providers and system software vendors. Education providers may wish to elect/register one of their systems to be creating CoEs for them, depending on workflow.

Please send any feedback to prismsapi@education.gov.au

What authentication method will you be implementing?

We are currently working through the authentication system that will be used for API access. It will use open standards – OAuth/OpenID Connect based. We are aware of the requirement to maintain the current authentication system to the PRISMS Web User Interface while we build the authentication mechanism for the APIs. We are currently in the process of running proof-of-concepts to work through the authentication flows and will be providing more feedback once these have been completed.

How and when will PRISMS API credentials be available?

There will be a mix of business process and technical onboarding for API credential access. We are currently working through the identity system and associated security requirements for the APIs. When this is complete, we will liaise with software vendors on both the business and technical aspects for onboarding. Please refer to the question ‘what level of engagement is required from software vendors and providers in order to prepare for the APIs release?’ for more context.

Was there any consideration of PRISMS API's being an extension of the existing DE TCSI framework?

The requirements that govern PRISMS and TCSI and the point they need to engage in the student life cycle are very different. PRISMS engagement is required before TCSI. We therefore cannot use the TCSI APIs for the requirements of this project.