Development Assessment Forum
electronic Development Assessment – Australia
eDA Interoperability Specification (eDAIS)
Functional Definition
Purpose
This document provides a conceptual overview (functional description) of eDAIS; the
electronic Development Assessment Interoperability Specification (the Specification).
Furthermore, it outlines what the Specification is ...by describing the system-to-system
interaction made possible by the Specification.
The Specification prescribes how organisations are to interact electronically with each
other in the shared endeavour of obtaining or granting permissions related to planning
and development activities.
The Specification is a recipe for defining the business documents, the business
processes and the “software components” that will enable organisations to complete
transactions with each other over the Internet. The Specification does not prescribe
the “system” that any one organisation may need to conduct business. It only
prescribes the “components” needed to enable interaction with other organisations.
This document provides an overview of, or introduction to, what the Specification
prescribes; specifically it describes the types of transactions that will be performed.
A udi enc e
The primary audience of this document is key stakeholders in the Specification. We
define a key stakeholder as: someone who makes decisions in respect to the
Specification; and/or someone who is responsible for an organisational outcome that
the Specification may directly impact; and/or someone who is responsible for an
organisational system that uses the Specification.
An additional audience is the business analyst. We define a business analyst as
someone who interviews key stakeholders and documents their requirements in
respect to the Specification in such a way that business systems and software
solutions may be designed and built to meet the requirements.
An additional audience is the process engineer. We define a process engineer as
someone who designs and implements business processes and business systems to
meet the requirements.
An additional audience is the software developer. We define a software developer as
someone who designs and builds software solutions to meet the requirements.
Prerequisite Reading
It is recommended that the Business Domain Definition document be read prior to
reading this document. The Business Domain Definition provides the contextual
background (raison d'être) to eDAIS.
Filename: 106749669
6-Mar-16 | Page 1 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Table of Contents
Purpose ....................................................................................................................................................1
Audience ...................................................................................................................................................1
Prerequisite Reading ................................................................................................................................1
Table of Contents .....................................................................................................................................2
Functional Overview .................................................................................................................................3
GIEM and UMM Conventions ...................................................................................................................4
Terms and Definitions ......................................................................................................................4
Transaction Patterns ........................................................................................................................5
The Business Transactions of eDAIS .......................................................................................................6
Template for Business Transactions ...............................................................................................7
Create Application............................................................................................................................8
Change Application ..........................................................................................................................9
Remove Application ...................................................................................................................... 10
Declare Referral_ Obligation ........................................................................................................ 11
Create Direction Referred_ Application ........................................................................................ 12
Change Direction Referred_ Application ...................................................................................... 13
Remove Direction Referred_ Application ..................................................................................... 14
Create Advice Referred_ Application............................................................................................ 15
Change Advice Referred_ Application .......................................................................................... 16
Remove Advice Referred_ Application ......................................................................................... 17
Declare Referral_ Compliance ...................................................................................................... 18
Declare Direction Referred_ Determination .................................................................................. 19
Declare Advice Referred_ Determination ..................................................................................... 20
Declare Public Notification_ Obligation......................................................................................... 21
Declare Public Notification_ Compliance ...................................................................................... 22
Record Public Opinion .................................................................................................................. 23
Declare Information Request ........................................................................................................ 24
Create Supplement ....................................................................................................................... 25
Change Supplement ..................................................................................................................... 26
Withdraw Application .................................................................................................................... 27
Amend Application ........................................................................................................................ 28
Defer Assessment......................................................................................................................... 29
Declare Reminder ......................................................................................................................... 30
Declare Status Change_ Application ............................................................................................ 31
Declare Determination .................................................................................................................. 32
Declare Appeal ............................................................................................................................. 33
Request Status_ Application ......................................................................................................... 34
Query Public Status_ Application ................................................................................................. 35
Authoritative Source for the Specification ............................................................................................. 36
Related Documents ............................................................................................................................... 36
Additional Information Resources.......................................................................................................... 36
Filename: 106749669
6-Mar-16 | Page 2 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Functional Overview
The Specification describes the means whereby two parties interact over the Internet
to achieve shared objectives in respect to the electronic processing of planning and
development applications. More explicitly, the Specification describes the means
whereby the business systems and the software systems of two parties interact.
Furthermore, because many parties are potentially involved in any one application, the
Specification supports the concept of an agent or intermediary to manage, on behalf of
any one party, all of the communications, with all the other parties, necessary to
process a single application. Thus many interactions between multiple pairs of parties
are choreographed to produce a single or ‘joined-up’ service to the applicant.
The party may be a government agency, an individual or a commercial organisation.
The interactions include concepts related to obtaining or granting a permission
(statutory right), such as (generically named): investigation, lodgement, referral,
request-for-information, direction, advice, determination.
The nature of the application includes the full range of planning and development
activities such as (generically named): reconfiguration, sub-division, change-of-use,
regulated use and building.
The interaction comprises the exchange of programmatic messages that can be
interpreted by software systems to have a specific business meaning. The shared or
mutual objective is for all systems involved in a given interaction to be synchronised
such that there is no ambiguity in respect to the accuracy, correctness, completeness
and intent of the information provided; i.e. all organisations have the same information
and all organisations agree as to the ‘state’ of the application.
The Specification prescribes the mechanisms whereby the disparate software systems
of different parties are enabled to interoperate. In this way the disparate business
systems of two parties will also be enabled to ‘interoperate’ by the mechanisms
prescribed by the Specification.
The Specification is independent of any technology platform, yet assumes that the
interaction will take place over the Internet using secure, industry standard,
communication protocols (e.g. Web Services, WS-I Profiles, Reliable Secure
Messaging, SSL).
An underlying design principle of the Specification is that the required interactions
between organisations can be achieved using common building blocks, and that each
state or territory can achieve legislative objectives using a combination or
choreography of those building blocks.
The building blocks are known as Business Transaction and Business Document. The
choreography specific to a state or territory is known as a Business Collaboration
Protocol.
The Specification follows the Australian Government Information Exchange
Methodology (GIEM) which is based on the UN/CEFACT Modelling Methodology
(UMM). GIEM and UMM define three foundational business modelling artefacts.
o
Business Transaction: is defined as an activity that leads to a synchronised
business state change between two collaborating organisations.
Filename: 106749669
6-Mar-16 | Page 3 of 36
Development Assessment Forum
electronic Development Assessment – Australia
o
Business Document: is defined as the information exchanged during a
business transaction. Every Business Transaction has a Business Document
representing a request and depending on the type of Business Transaction an
optional Business Document representing the response.
o
Business Collaboration Protocol: defines a set of Business Transactions that
are choreographed (enacted in a defined sequence, and according to defined
rules) to achieve a common goal.
GIEM and UMM Conventions
In the context of GIEM and UMM, a Business Transaction is a unit of work through
which information and signals are exchanged (in an agreed format, sequence, and
time interval) between two business partners. It completes when all constituent
interactions succeed; otherwise, it is rolled back to a state that was defined before it
was initiated. A Business Collaboration is made up of one or more Business
Transactions.
The parts of a Business Transaction used to exchange information are called
Business Actions. Business Actions are performed either by a partner who is
requesting a business service or by a partner in response to such a request. These
business actions are comparable to an illocution act (spoken instruction) for sending
or receiving business information in the form of Business Object.
A Business Action can be described in terms of an intention, an action, and a
transaction. In addition, Business Actions generally relate to a Business Object. By
generating a name for a Business Message that identifies the intention, action,
transaction activities, and associated Business Object, the message can be more
easily classified and semantic information about the business message can be
communicated to a receiving business partner without having to examine the contents
of the message. The name of business information exchanged in a Business Action
can therefore include terms that provide a complete and unambiguous description of
the Business Action. Thus a Business Message can be expressed as:
<Intention> <Action> <Object Qualifier_> <Business Object> <Transaction Activity>
Terms and Definitions
The terms used by GIEM and UMM are defined as follows:
Intention defines the sender's intent with respect to the Business Object. Allowed
values are:
Propose
The Initiator proposes to create, change, or cancel a Business Object.
Accept
The Responder accepts a previous proposal.
Reject
The Responder rejects a previous proposal.
Declare
The Initiator unilaterally creates, changes, or cancels a Business
Object.
Query
The Initiator asks for information about a Business Object.
Filename: 106749669
6-Mar-16 | Page 4 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Reply
The Responder replies to a previous query with the information that
was asked for.
Assert
The Initiator makes a statement about one or several Business
Objects.
Action defines the instructions for processing a transmitted business object. Allowed
values are:
Create
The Recipient is to create the Business Object; it must not already
exist.
Change
The Recipient is to change the Business Object; it must already exist.
Save
The Recipient is to save the Business Object.
Remove
The Recipient is to delete the Business Object so that it no longer
exists.
None
The Recipient is to take no action on the Business Object.
Amend
The Recipient is to amend the Business Object with details that do not
substantially change existing obligations.
Request
The Recipient is to interrogate the Business Object in order to answer
a query.
Withdraw
The Recipient is to withdraw from any and all obligated actions in
respect to the Business Object, which continues to exist.
Defer
The Recipient is to cease any and all obligated actions in respect to
the Business Object.
Business Object defines a discrete set of business information that has a predefined,
agreed format.
Object Qualifier defines a subset of information about the Business Object.
Transaction Activity is determined by the style interaction that is required between
the parties. The type of Transaction Activity required is determined by understanding
the type of Transaction Pattern that is required.
Transaction Patterns
The Transaction Patterns defined by GIEM and UMM are as follows:
Commercial Transaction
The Commercial Transaction pattern is used for interactions that result in an economic
commitment (contract or obligation) between business partners, and thus, nonrepudiation and authentication are essential. The transaction activities from the sender
to the receiver and from the receiver to the sender are each specified as a
"transaction".
Filename: 106749669
6-Mar-16 | Page 5 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Query/Response
The Query/Response pattern is used when an initiating partner requests information
that a responding partner already has. The response comprises zero or more results
each of which meets the constraining criteria in the query. The pattern specifies a
"query" transaction activity from the sender to the receiver and a "response"
transaction activity from the receiver to the sender.
Request/Response
The Request/Response pattern is used when an initiating partner requests information
that requires the responding partner to produce a complex interdependent set of
information. The pattern specifies a "request" transaction activity from the sender to
the receiver and a "response" transaction activity from the receiver to the sender.
Request/Confirm
The Request/Confirm pattern is used where a contract or obligation already exists and
where an initiating partner requests confirmation about status with respect to
previously established contracts or with respect to a responding partner's business
rules. The pattern specifies a "request" transaction activity from the sender to the
receiver and a "confirmation" transaction activity from the receiver to the sender.
Notification
The Notification pattern is used for the exchange of a notifying business document
(and the return of an acknowledgement of receipt signal) that typically has nonrepudiation requirements. The pattern specifies a "notification" transaction activity
from the sender to the receiver.
Information
The Notification pattern is used for the exchange of informal information that therefore
has no non-repudiation requirements. The pattern specifies an "information"
transaction activity from the sender to the receiver.
The Business Transactions of eDAIS
A design goal of the Specification is to support all required interactions between
organisations using a national set of Business Transactions. The following set of
Business Transactions have been developed to support both current and future
practices; and, to achieve the legislative objectives in all states. The underlying
premise is that each state or territory can achieve legislative objectives using a
combination or choreography of these Business Transactions.
Note
The following Business Transactions are those that appear in eDAIS release
candidate version 2.1.
It is expected that this set of transactions will evolve over time, as organisations
validate the Specification through implementation and discover new requirements and
uses. Changes to the specification will be inevitable as legislation, organisational
policies, and business practices change to take advantage of Internet technologies.
Filename: 106749669
6-Mar-16 | Page 6 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Template for Business Transactions
This Template is provided to help the reader interpret the Business Transactions as
they are presented in this document.
Goal:
The goal of the Business Transaction is expressed from the
perspective of the Initiator (the party who starts the transaction).
The goal is expressed in terms of what action the Responder
needs to perform to satisfy the intent of the Initiator.
The goal is expressed in terms of what business document is
being acted on.
Prerequisite:
If there is any prerequisite “state” of the business document
required for the Business Transaction to be valid, then the
prerequisite “state” is named here.
Success State:
The “state” of the business document after the Responder has
successfully performed the required action.
There may be more than one Success State to handle situations
where multiple cycles of a transaction are needed to assemble all
of the required information.
The “Success” message from the Responder to the Initiator may
include additional messages.
Failure State:
The “state” of the business document after the Responder has not
performed the required action.
The “Failure” message from the Responder to the Initiator may
include additional messages.
Business Object:
The business document involved in the transaction
UMM Pattern:
The Transaction Pattern as defined by UMM; i.e. one of:
Commercial Transaction; Query/Response; Request/Response;
Request/Confirm; Notification; Information
Business
Messages:
The initial message sent by the Initiator
The response sent by the Responder (except in the case of one
way transactions namely Notification and Information patterns)
There may be more than one type of response message.
This document provides an introductory overview of the Business Transactions.
Business Analysts, Process Engineers and Software Developers should refer to the
formal model in the online repository at www.govdex.gov.au or www.xml.gov.au
Filename: 106749669
6-Mar-16 | Page 7 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Create Application
Goal:
The Initiator proposes an Application
The Responder creates the Application proposed by Initiator
Prerequisite:
none
Success State:
Created and Complete
Responder informs Initiator that the Application is complete;
Responder undertakes obligation to commence work
Success State:
Created but Incomplete
Responder informs Initiator that the Application is incomplete and why;
Responder keeps the Application pending additional action from the Initiator
Responder does not undertake any obligation to commence work
Failure State:
Rejected
Responder does not create the Application in their system;
No obligation exists
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Create Application Transaction
Accept Create Application Transaction
Reject Create Application Transaction
Filename: 106749669
6-Mar-16 | Page 8 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Change Application
Goal:
The Initiator proposes changes to the Application
The Responder changes the Application according to Initiator's
proposed change
Prerequisite:
Application is ‘Created but Incomplete’
Success State:
Changed
Responder informs Initiator that the Application is Changed as per the Initiator’s
proposed change
Failure State:
Rejected
Responder rejects the proposed change to the Application; i.e. does not change
the Application in their system
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Change Application Transaction
Accept Change Application Transaction
Reject Change Application Transaction
Filename: 106749669
6-Mar-16 | Page 9 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Remove Application
Goal:
The Initiator requests that the Application be removed
The Responder removes the Application according to Initiator's
request
Note: This transaction may also be in response to a system generated request
to remove the Application based on a pre-agreed timeout or lapse in activity
Prerequisite:
Application is ‘Created but Incomplete’
Note: If assessment has commenced, use the Withdraw Application to cancel
Success State:
Removed
Responder informs Initiator that the Application is Removed
Failure State:
Rejected
The consensus of the eDA community was that this transaction would always
succeed; i.e. an incomplete Application would always be removed on request. If
it did fail, then only because of a technical failure.
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Remove Application Transaction
Accept Remove Application Transaction
Filename: 106749669
6-Mar-16 | Page 10 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Referral_ Obligation
Goal:
The Initiator declares any and all of their obligations to refer the
Application
The Responder formally acknowledges the receipt of the
declaration
Note: This transaction may be redundant in some jurisdictions.
Prerequisite:
Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Referral_ Obligation
UMM Pattern:
Notification
Business
Messages:
Declare Save Referral_ Obligation Notification
Filename: 106749669
6-Mar-16 | Page 11 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Create Direction Referred_ Application
Goal:
The Initiator proposes an Application be referred to a Direction
referral authority
The Responder creates the Direction Referred_ Application
proposed by the Initiator.
Note: Direction is used to assert that the Referral Authority’s determination is
binding on the determination made by the Consent Authority
Prerequisite:
Application is ‘Created and Complete’
Success State:
Direction Referred_ Application is ‘Created and Complete’
Success State:
Direction Referred_ Application is ‘Created but Incomplete’
Failure State:
Rejected
Business Object:
Direction Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Create Direction Referred_ Application Transaction
Accept Create Direction Referred_ Application Transaction
Reject Create Direction Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 12 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Change Direction Referred_ Application
Goal:
The Initiator proposes changes to a Direction Referred_
Application
The Responder changes the Direction Referred_ Application
according to Initiator's proposed change
Prerequisite:
Direction Referred_ Application is ‘Created but Incomplete’
Success State:
Changed
Responder informs Initiator that the Direction Referred_ Application is Changed
as per the Initiator’s proposed change
Failure State:
Rejected
Responder rejects the proposed change to the Direction Referred_ Application;
i.e. does not change the Direction Referred_ Application in their system
Business Object:
Direction Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Change Direction Referred_ Application Transaction
Accept Change Direction Referred_ Application Transaction
Reject Change Direction Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 13 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Remove Direction Referred_ Application
Goal:
The Initiator requests that the Direction Referred_ Application be
removed
Responder removes the Direction Referred_ Application according
to Initiator's request
Note: This transaction may also be in response to a system generated request
to remove the Application based on a pre-agreed timeout or lapse in activity
Prerequisite:
Direction Referred_ Application is ‘Created but Incomplete’
Note: If assessment has commenced, use the Withdraw Application to cancel
Success State:
Removed
Responder informs Initiator that the Direction Referred_ Application is Removed
Failure State:
Rejected
The consensus of the eDA community was that this transaction would always
succeed; i.e. an incomplete Application would always be removed on request. If
it did fail, then only because of a technical failure.
Business Object:
Direction Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Remove Direction Referred_ Application Transaction
Accept Remove Direction Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 14 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Create Advice Referred_ Application
Goal:
The Initiator proposes an Application be referred to an Advice
referral authority
The Responder creates the Advice Referred_ Application
proposed by the Initiator.
Note: Advice is used to assert that the Referral Authority’s determination is
advisory in nature (i.e. not binding) on the determination made by the Consent
Authority
Prerequisite:
Application is ‘Created and Complete’
Success State:
Advice Referred_ Application is ‘Created and Complete’
Success State:
Advice Referred_ Application is ‘Created but Incomplete’
Failure State:
Rejected
Business Object:
Advice Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Create Advice Referred_ Application Transaction
Accept Create Advice Referred_ Application Transaction
Reject Create Advice Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 15 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Change Advice Referred_ Application
Goal:
The Initiator proposes changes to an Advice Referred_ Application
The Responder changes the Advice Referred_ Application
according to Initiator's proposed change
Prerequisite:
Advice Referred_ Application is ‘Created but Incomplete’
Success State:
Changed
Responder informs Initiator that the Advice Referred_ Application is Changed
as per the Initiator’s proposed change
Failure State:
Rejected
Responder rejects the proposed change to the Advice Referred_ Application;
i.e. does not change the Advice Referred_ Application in their system
Business Object:
Advice Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Change Advice Referred_ Application Transaction
Accept Change Advice Referred_ Application Transaction
Reject Change Advice Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 16 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Remove Advice Referred_ Application
Goal:
The Initiator requests that an Advice Referred_ Application be
removed
Responder removes the Advice Referred_ Application according
to Initiator's request
Note: This transaction may also be in response to a system generated request
to remove the Application based on a pre-agreed timeout or lapse in activity
Prerequisite:
Advice Referred_ Application is ‘Created but Incomplete’
Note: If assessment has commenced, use the Withdraw Application to cancel
Success State:
Removed
Responder informs Initiator that the Advice Referred_ Application is Removed
Failure State:
Rejected
The consensus of the eDA community was that this transaction would always
succeed; i.e. an incomplete Application would always be removed on request. If
it did fail, then only because of a technical failure.
Business Object:
Advice Referred_ Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Remove Advice Referred_ Application Transaction
Accept Remove Advice Referred_ Application Transaction
Filename: 106749669
6-Mar-16 | Page 17 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Referral_ Compliance
Goal:
The Initiator declares that their obligation to refer the Application to
the appropriate referral authorities has been fulfilled
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Referred_ Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Referred_ Application
UMM Pattern:
Notification
Business
Messages:
Declare Save Referral_ Compliance Notification
Filename: 106749669
6-Mar-16 | Page 18 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Direction Referred_ Determination
Goal:
The Initiator (the Direction Referral Authority or agent thereof)
declares the determination that has been made
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Direction Referred_ Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Direction Referred_ Determination
UMM Pattern:
Notification
Business
Messages:
Declare Save Direction Referred_ Determination Notification
Filename: 106749669
6-Mar-16 | Page 19 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Advice Referred_ Determination
Goal:
The Initiator (the Advice Referral Authority or agent thereof)
declares the determination that has been made
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Advice Referred_ Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Advice Referred_ Determination
UMM Pattern:
Notification
Business
Messages:
Declare Save Advice Referred_ Determination Notification
Filename: 106749669
6-Mar-16 | Page 20 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Public Notification_ Obligation
Goal:
The Initiator declares that there is an obligation to notify the public
of the Application
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Public Notification_ Obligation
UMM Pattern:
Notification
Business
Messages:
Declare Save Public Notification_ Obligation Notification
Note: The planning and development term ‘Public Notification’ and the UMM
term ‘Notification’ have different meanings
Filename: 106749669
6-Mar-16 | Page 21 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Public Notification_ Compliance
Goal:
The Initiator declares that their obligation to notify the public has
been fulfilled
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Public Notification_ Compliance
UMM Pattern:
Notification
Business
Messages:
Declare Save Public Notification_ Compliance Notification
Note: The planning and development term ‘Public Notification’ and the UMM
term ‘Notification’ have different meanings
Filename: 106749669
6-Mar-16 | Page 22 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Record Public Opinion
Goal:
The Initiator provides an opinion in respect to the Application
The Responder records the opinion of the Initiator and formally
acknowledges the receipt of the opinion
Prerequisite:
Application is ‘Created and Complete’
Success State:
Accepted
Failure State:
Null
Business Object:
Public Opinion
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Create Public Opinion Transaction
Accept Create Public Opinion Transaction
Filename: 106749669
6-Mar-16 | Page 23 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Information Request
Goal:
The Initiator declares that they need further and/or better
particulars in order to assess this application
The Responder formally acknowledges the receipt of the
declaration
Note: This transaction only applies after Assessment has commenced.
Subsequent to receiving this Notification, the Responder may or may not
proceed to Create Supplement to address the concerns raised by the Declare
Information Request
Prerequisite:
Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Information Request
UMM Pattern:
Notification
Business
Messages:
Declare Save Information Request Notification
Filename: 106749669
6-Mar-16 | Page 24 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Create Supplement
Goal:
The Initiator proposes a Supplement to the Application
The Responder creates the Supplement proposed by the Initiator
Note: This transaction only applies after Assessment has commenced. This
transaction may be in response to a Declare Information Request sent by a
referral agency or a consent authority. It may, legislation permitting, be used
independent of a Declare Information Request.
Prerequisite:
Application is ‘Created and Complete’
Success State:
Supplement is ‘Created and Complete’
Success State:
Supplement is ‘Created but Incomplete’
Failure State:
Rejected
Business Object:
Supplement
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Create Supplement Transaction
Accept Create Supplement Transaction
Reject Create Supplement Transaction
Filename: 106749669
6-Mar-16 | Page 25 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Change Supplement
Goal:
The Initiator proposes changes to a Supplement
The Responder changes the Supplement according to Initiator's
proposed change
Prerequisite:
Supplement is ‘Created but Incomplete’
Success State:
Changed
Failure State:
Rejected
Business Object:
Supplement
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Change Supplement Transaction
Accept Change Supplement Transaction
Reject Change Supplement Transaction
Filename: 106749669
6-Mar-16 | Page 26 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Withdraw Application
Goal:
The Initiator requests that assessment cease and that the
Application be removed
The Responder removes the Application according to Initiator's
request
Note: This transaction applies only after assessment has commenced. This
transaction may also be in response to a system generated request to remove
the Application based on a pre-agreed timeout or lapse in activity.
Prerequisite:
Application is ‘Created and Complete’
Success State:
Withdrawal Accepted
Failure State:
Withdrawal Rejected
i.e. assessment activities do not stop or the Application is not withdrawn
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Withdraw Application Transaction
Accept Withdraw Application Transaction
Reject Withdraw Application Transaction
Filename: 106749669
6-Mar-16 | Page 27 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Amend Application
Goal:
The Initiator proposes to amend a component of the Application
The Responder accepts the Initiator's proposed amend any
component of the Application
Prerequisite:
Application is ‘Created and Complete’
Success State:
Amendment Accepted
Failure State:
Amendment Rejected
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Amend Application Transaction
Accept Amend Application Transaction
Reject Amend Application Transaction
Filename: 106749669
6-Mar-16 | Page 28 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Defer Assessment
Goal:
The Initiator requests that assessment of the Application be
deferred.
The Responder accepts the Initiator's request to defer assessment
of the Application
Prerequisite:
Application is ‘Created and Complete’
Success State:
Deferral Accepted
Failure State:
Deferral Rejected
Business Object:
Application
UMM Pattern:
Commercial Transaction
Business
Messages:
Propose Defer Application Transaction
Accept Defer Application Transaction
Reject Defer Application Transaction
Filename: 106749669
6-Mar-16 | Page 29 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Reminder
Goal:
The Initiator declares a Reminder to the other party of an
Obligation
The Responder formally acknowledges the receipt of the
declaration
Note: This transaction may be used by any party to remind another party of any
obligation; though typically as a reminder of an assessment obligation and an
impending deadline
Prerequisite:
Application is ‘Created and Complete’ or
Application is ‘Created but Incomplete’
Success State:
Received
Failure State:
Null
Business Object:
Reminder
UMM Pattern:
Notification
Business
Messages:
Declare Save Reminder Notification
Filename: 106749669
6-Mar-16 | Page 30 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Status Change_ Application
Goal:
The Initiator notifies the other party of an Event that has changed
the ‘Status’ of the Application
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Application is ‘Created and Complete’ or
Application is ‘Created but Incomplete’
Success State:
Received
Failure State:
Null
Business Object:
Status Change_ Application
UMM Pattern:
Notification
Business
Messages:
Declare Save Status Change_ Application Notification
Filename: 106749669
6-Mar-16 | Page 31 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Determination
Goal:
The Initiator (the Consent Authority or their agent) declares the
determination.
The Responder formally acknowledges the receipt of the
declaration
Prerequisite:
Application is ‘Created and Complete’
Success State:
Received
Failure State:
Null
Business Object:
Determination
UMM Pattern:
Notification
Business
Messages:
Declare Save Determination Notification
Filename: 106749669
6-Mar-16 | Page 32 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Declare Appeal
Goal:
The Initiator declares that a determination is being appealed.
The Responder formally acknowledges the receipt of the
declaration.
Prerequisite:
Determination Received
Success State:
Received
Failure State:
Null
Business Object:
Appeal
Note: this object is not the Appeal itself but rather information about the Appeal
UMM Pattern:
Notification
Business
Messages:
Declare Save Appeal Notification
Filename: 106749669
6-Mar-16 | Page 33 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Request Status_ Application
Goal:
The Initiator makes an enquiry about the status of the Application
The Responder provides the information about the status of the
Application
The Initiator formally acknowledges the receipt of the information.
Note: Used where the nature of the information requested/provided is typically
restricted to access by trusted parties and may not be readily available, i.e. may
need to be ‘calculated’
Prerequisite:
Application is ‘Created and Complete’ or
Application is ‘Created but Incomplete’
Success State:
Received
i.e. the Status information is Received by the Initiator
Failure State:
Null
Business Object:
Status_ Application
UMM Pattern:
Request/Confirm
Business
Messages:
Query Request Status_ Application Request
Reply Save Status_ Application Confirmation
Filename: 106749669
6-Mar-16 | Page 34 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Query Public Status_ Application
Goal:
The Initiator makes an enquiry about the status of the Application
The Responder provides the information about the status of the
Application
Note: Used where the nature of the information requested/provided is open to
access by the public and readily available, i.e. does not need to be ‘calculated’
Prerequisite:
Application is ‘Created and Complete’ or
Application is ‘Created but Incomplete’
Success State:
Received
Failure State:
Null
Business Object:
Public Status_ Application
UMM Pattern:
Query Response
Business
Messages:
Query Request Public Status_ Application Query
Reply Public Status_ Application Response
Filename: 106749669
6-Mar-16 | Page 35 of 36
Development Assessment Forum
electronic Development Assessment – Australia
Authoritative Source for the Specification
The Specification itself is a ‘formal model’; it is ‘written’ in a formal technical language
(Unified Modelling Language, UML); it adheres to a formal modelling convention
(UN/CEFACT Modelling Methodology, UMM) and, it is stored and maintained in an
authoritative repository as a set of linked, annotated diagrams, text and programmatic
files. Because of the technical nature and complexity of the Specification it is both
inelegant and counterproductive to reproduce it as a static file or printed document.
The repository resides at AGIMO’s www.govdex.gov.au . It is also published as a
read-only model at www.xml.gov.au
Related Documents
Also published at www.govdex.gov.au are:
Business Domain Definition: provides the contextual background (raison d'être) to
eDAIS.
Deployment Plan: defines the plans and controls for the deployment of an endorsed
version of the Specification. It provides an indicative schedule of work that may be
used in a request-for-quotation or similar procurement process.
Support Plan: defines the plans and controls for supporting and maintaining the
Specification on a national basis. It provides an indicative schedule of services that
may be used in a request-for-quotation or similar procurement process.
Additional Information Resources
Supporting documentation on the Specification:
http://www.govdex.gov.au/confluence/display/eDASpec
Australian Government Architecture Reference Models
http://www.agimo.gov.au/publications/2007/june/AGA_Reference_Models
Government Information Exchange Methodology
https://www.govdex.gov.au/confluence/display/GTM/Home
International Alliance for Interoperability [BuildingSmart]
http://buildingsmart.org.au
LandXML
http://www.icsm.gov.au
Filename: 106749669
6-Mar-16 | Page 36 of 36