Emergency Notification Software Solution (ENSS)

Trade Agreement: WTO-AGP/NAFTA/Canada-Peru FTA/Canada-Colombia
FTA
Tendering Procedures: 
Attachment: None
Non-Competitive Procurement Strategy: Exclusive Rights
Comprehensive Land Claim Agreement: No
Vendor Name and Address: 
ERMS Solutions Limited
2916 South Sheridan Way
Suite 200
Oakville Ontario
Canada
L6J7J8
Nature of Requirements: 
Transport Canada - ERMS Advantage Platform ACAN


An ACAN is a public notice indicating to the supplier community
that a department or agency intends to award a contract for
goods, services or construction to a pre-identified supplier,
thereby allowing other suppliers to signal their interest in
bidding, by submitting a statement of capabilities. If no
supplier submits a statement of capabilities that meets the
requirements set out in the ACAN, on or before the closing date
stated in the ACAN, the contracting officer may then proceed
with the award to the pre-identified supplier. 



Definition of requirement


Pursuant to the Marine Transportation Security Act (MTSA) and
the Marine Transportation Security Regulations (MTSRs),
Transport Canada (TC), Marine Security Operations (MarSec Ops),
is responsible to immediately inform the marine industry of a
threat or event that may affect the security of the Canadian
marine transportation system which includes marine facilities,
ports and vessels and ferries.  MarSec Ops, a branch of the
Marine Security Directorate within TC has the requirement to use
an Emergency Notification Software Solution (ENSS) in order to
broadcast notifications of such threats or events.

The ENSS provided by the Service Provider must be able to send
out a mass notification to at least 5000 different stakeholders
that include government departments (federal and provincial),
private associations, companies, individuals.  The ENSS will be
used in the TC Regions throughout Canada and also by other modes
within TC as a notification instrument for their own industry
stakeholders and for business continuity purposes.

TC intends to enter into a sole source contract with ERMS
Corporation for the purpose of procuring the ERMS Advantage
Platform suite including associating maintenance and support
service, training and professional services.

 
Criteria for assessment of the Statement of Capabilities

Any interested supplier must demonstrate by way of a statement
of capabilities that it meets the following requirements:

1. Experience

1.1. Experience: The Contractor must have delivered an ENSS as a
Contractor's hosted application for at least three years.			


2. Service Architecture

2.1. Service Design: The ENSS must be designed specifically for
emergency notifications with the capability of broadcasting mass
notifications via multiple methods either simultaneously or in a
cascading sequence to multiple contacts within 5 minutes.			

2.2. Service Design: The ENSS should also include the ability to
send routine messages that are clearly distinct from any
emergency messages.

2.3. Call Throttling: The ENSS must have the ability to control
the number of calls into an organization to avoid flooding the
lines during a mass notification.

2.4. Proprietorship: All hardware, software and data (apart from
Client's owned systems) must be hosted at facilities owned or
leased, operated and secured by the Contractor in Canada.			
2.5. Requirements for Client Operation:  The Client must not be
required to install any hardware or software to operate any
facets of the ENSS.  Database capacity, data channels and phone
ports are not purchased by the Client.			


3. Security

3.1. Industrial Security Standards: The selected vendor must
have the ability to handle and secure information up to and
including PROTECTED A in accordance with Public Works and
Government Services Canada's Industrial Security Standards. 
These standards apply to all facilities and equipment used to
store and process Administrator, User and Contact information
and all messages.
			
3.2. Access Privileges: The ENSS must enable Administrators to
control access privileges, such as access requests, requests for
changes to personal information, and changes to passwords,
provided that they have appropriate access control
permissions.			

3.3. Password Change:	The ENSS must permit each Administrator,
User and Contact to change their password at any time.			

3.4. Password Strength:	The ENSS must force each Administrator,
User and Contact to configure a password in a predetermined
manner with a minimum number of characters, including capitals,
numbers and symbols.			


4. Resiliency

4.1. Recovery: Client data must be hosted in high-availability
facilities with zero failover time and automatic recovery.			

4.2. Disaster Recovery:	If a Disaster, Emergency or Hazard
renders the Contractor's primary data centre inoperable, Client
data must be dynamically rerouted so that it functions without
interruption.			
4.3. Back-Up Facilities and Services: The ENSS must have a
multi-tier, multi-server fault tolerant architecture with full
redundancy whereby the primary Contacts database server and all
ENSS functions are housed in Canada and their back-up capability
is housed in separate locations in Canada separated by a
provincial boundary (at least 200 km) so that an Emergency that
affects one facility will not affect the others.			

4.4. Location of Data Servers:	The ENSS must ensure that the
Client's database never resides outside of Canada's land
boundaries.			

4.5. Permissions and Access Controls:	The ENSS must enable and
support the designation of a minimum of 10 Master Administrators
with full access and Regional Administrators with limited access.


5. General Operation				

5.1. User Interfaces: The vendor will ensure that the ENSS
provides graphical user interfaces (GUIs) in both English and
French for Administrators and Users.			

5.2. Browsers: The ENSS must be accessible to Administrators and
Users on web browsers including Internet Explorer (min version
9.0), Apple Safari (min version 5.1), Google Chrome (min version
17.0) and Mozilla Firefox (min version 10.0) for Windows - and
compatible with 128-bit encryption.			

5.3. Quick Launch: The ENSS must have a quick-launch feature
that allows an Administrator to initiate a Message from a single
screen after logging in to the ENSS.		

5.4. Practice Modes: The ENSS must have practice modes (i.e., a
test environment) that allow the Administrators and Users to use
any facet of the ENSS without affecting real-time content or
capabilities of the ENSS and the database (i.e., the production
environment).			


6. Output

6.1. Voice Messages: The ENSS must send local or long-distance
voice Messages of up to 1 minute in duration (exclusive of
dialing time, ringing time and voice-mail response time) to at
least 5,000 Contacts including Government of Canada  Contacts
within 5 minutes of being sent.		

6.2. Voice Message Language: 	Voice messages must be delivered
in French and English with voices using contemporary Canadian
accents.			

6.3. Text-based Messages: The ENSS must send text-based SMS
Messages of a minimum of 140 characters or e-mail messages of up
to 500 words to at least 5,000 Contacts including Government of
Canada Contacts within 5 minutes of being sent.			

6.4. Reliability:	The ENSS must be fully functional and
operational 24 hours a day, 7 days a week, with at least 99.99%
availability throughout the Contract period. In the event of an
outage, the Contractor will advise the client of the outage and
the impacts on the ENSS.  In the event of a scheduled outage,
the Contractor will advise the Client well in advance of the
outage.

6.5. Native SMS in Canada: The ENSS must use short code in order
to allow for the sending of true SMS versus email-to-SMS.				


7. Database

7.1. Data Recovery: The ENSS must enable Administrators to
recover a Contact record that has been deleted for up to 5 days
after deletion.			

7.2. Database Backup: The ENSS must generate automatic database
backups to one or more other locations in Canada at least once
every 24 hours.


8. Administrator, User and Contact Information Management

8.1. Administrator and User Profiles: The ENSS must allow for
the establishment and maintenance of a database of Administrator
and User Profiles that will include
i.	Full name
ii.	Position
iii.	Region
iv.	Branch
v.	An individual ID number
vi.	Primary 24 hour emergency coordinates
vii.	Secondary 24 hour emergency coordinates
viii.	Cell phone number
ix.	Business Fax number
x.	Pager number
xi.	E-mail address
xii.	Designated alternate
xiii.	Blackberry number
xiv.	Permissions assigned.

The ENSS must allow Master Administrators to have full access
permissions and to perform all functions of the ENSS.			

8.2. Import Formats for Contact Information: The ENSS must
securely import Contact information from existing databases
(delivered to the vendor in one or more electronic files) such
as Microsoft Active Directory, PeopleSoft/Oracle HR, BCP
Software, SQL, MS SQL Server, NetHris, HRIS database, and CSV
(e.g. Excel), XML, MS Outlook and MDB files - without requiring
manual (human) intervention - at intervals prescribed by the
Client or as required. The Client must have the ability to
import Contact information manually if so desired. This process
is to be delivered through a web services Application
Programming Interface using a standards-based Service-Oriented
Architecture.			

8.3. Contact Data Fields: The ENSS must accommodate the creation
of 45 data fields per record.			
8.4. Data Revision: The ENSS must enable Administrators, Users
and Contacts to view and manually edit the information in their
own profiles, directly within the ENSS, provided they have
appropriate access control permissions.			

8.5. Data Revision: The ENSS must enable Administrators and
Users to add, modify, and delete Contacts and Contact
information, directly within the ENSS, provided they have
appropriate access control permissions.			

8.6. Log-in Data:	The ENSS must automatically assign a unique
user ID  for each Administrator and User. The Administrator must
then be allowed to set a temporary password which can later be
modified by the account holder.


9. Contact Groups

9.1. Creation: The ENSS must enable Administrators and Users to
create groups of Contacts based on variables such as Mode,
Group, Region or other criteria 
identified in the data fields of each Contact's record.			

9.2. Hierarchical Groups: The ENSS must enable Administrators
and Users to create hierarchical groupings so that groups
include up to 50 levels of sub-groups in order to appropriately
reflect an organization's structure.			

9.3. Number of Groups:	The ENSS must allow Administrators and
Users to define a Contact to be a member of up to 50 groups.			

9.4. Search feature: The ENSS must allow Administrators and
Users to conduct a search or filter Contacts based on criteria
identified in the data fields of each Contact's record.  The
ENSS must also have the capability to quickly create unique
Groups using the results of the search function.			

9.5. Sort features: The ENSS must allow Administrators and Users
to sort Contact lists alphabetically or, using any other
criteria identified in the data fields of each Contact's record.
 The ENSS must also have the capability to quickly create unique
Groups using the results of the sort function.	

9.6. Sorting Stakeholders' by Language: The ENSS must have the
capability to list stakeholders by language of correspondence in
order to allow the sending of only French messages to French
speaking stakeholders and English to English speaking
stakeholders.
		

10. Message Initiation

10.1. Service Access: 	The ENSS must enable Administrators and
Users to access the service for Contact management , message
creation (voice or text-based) or message transmission purposes
via the following methods and Devices:
i.	Computer (via the internet either through cable or WI-FI);
ii.	Landline telephone;
iii.	Cellular telephone;
iv.	Smartphone;
v.	Personal digital assistant;
vi.	Telecommunications device for the deaf; 
vii.	Voice over Internet protocol; and
viii.	Satellite telephone.			

10.2. Message Creation:	The ENSS must enable Administrators and
Users to create and record voice and text-based messages in
French and English for present or future use.			

10.3. Customizing Messages: The ENSS must enable Administrators
and Users to customize pre-recorded messages by adding
introductory and/or closing statements.			

10.4. Message verification: The ENSS must allow Administrators
and Users to hear the voice message and/or to read the
text-based message before it is sent.

10.5. Time Zone Recognition: The ENSS must have the capability
to recognize and understand time zones.			


11. Message Transmission

11.1. Media: The ENSS must send messages to Contacts via the
following media:
i.	Landline telephone;
ii.	Cellular telephone;
iii.	Smartphone, including telephone, text and e-mail
communications;
iv.	Personal Digital Assistant;
v.	SMS text message;
vi.	E-mail;
vii.	Facsimile;
viii.	Pager;
ix.	Telecommunication Device for the Deaf; and
x.	Satellite telephone.			

11.2. Safeguards: The ENSS must have an effective safeguard
(such as a prompt message) that prevents routine messages from
being sent out as emergency notifications.			
11.3. Phone Number Types: The ENSS must have the ability to make
local and long distance calls within Canada and the United
States.  The ENSS must also have the ability to dial
international numbers and phone numbers with extensions.		

11.4. Order of Contact Methods: The ENSS must allow
Administrators and Users to set the default order of devices
used to notify Contacts but also allow Users and Contacts to
override the order if they have the appropriate permissions to
do so.			

11.5. Language of Message and Contacts: The ENSS must allow
Administrators and Users to select Messages in either French or
English and to automatically transmit them in the Contact's
pre-selected corresponding language.			

11.6. Simultaneous Transmission: The ENSS must allow Users to
send a recorded voice message and a text message in a single
notification to all selected Contacts for delivery through the
media listed in 11.1.			

11.7. Caller ID:	Either globally or on a message-by-message
basis, the ENSS must allow Administrators and Users initiating a
message to customize the telephone number displayed (caller ID)
for voice Messages and the e-mail addresses for text-based
Messages.			

11.8. Escalation:	The ENSS must escalate messages when the
intended Contact has not confirmed receipt of the correspondence
(with 3 levels of person-to-person escalation) within a given
period of time. If no confirmation of receipt is received within
a given period of time, then the message will be redirected to
an alternate point of contact if one has been designated see
11.12.			
11.9. Delivery Attempts: The ENSS should allow Users and
Administrators to select the number of delivery attempts through
all Contact paths.			

11.10. E-mail Attachments: The ENSS must allow e-mails to attach
multiple files (e.g. text, spreadsheet and images) and send them
to an e mail device.		
	
11.11. Message Control:	The ENSS must allow an Administrator or
User to stop, recall or replace a Message initiated by them or
another Administrator or User with the same level of permissions
at any time during the Message sending process. Can we elaborate
on what we mean by corresponding permissions?			

11.12. Back-Up Contacts: The ENSS must automatically send
messages to a back-up Contact if a primary Contact does not
acknowledge receipt of the initial message within a period of
time defined by the sender.

11.13. First to Respond: The ENSS must have the capability to
send notifications systematically until a predetermined number
of affirmative responses are received.

11.14. Roll Call: The ENSS must have the capability to send
notifications for the purpose of soliciting a positive or
negative acknowledgement from the recipient, such as "are you
OK", "Not OK".


12. Message Delivery Features

12.1. Voice Message Repeat: The ENSS must allow Contacts to
listen to a voice Message as often as desired with a single key
press.			

12.2. Acknowledgements: The ENSS must seek and receive
acknowledgements of Messages through the device types identified
in 11.1, with the exception of facsimile and pager and SMS
transmissions.			

12.3. Re-send:	The ENSS must allow Administrators and Users to
re-send a notification to only those Contacts who did not
respond to the original notification.			

12.4. Voice-Mail: The ENSS must leave a Message when a
voice-delivered message reaches an answering machine or
voice-mail. If a message is left, the ENSS must also contact the
back-up Contact if the message was left on the primary Contact's
voice mail box. 			

12.5.  Electronic Voice: The electronic voice transmitter must
use Canadian (English and French) accents.			

12.6. Custom Response: The ENSS must allow Contacts to send
custom text-based messages in response to messages.			


13. Message Management

13.1. Recurring Messages: The ENSS must allow Administrators and
Users to set up recurring Messages.			

13.2. Scheduling: The ENSS must allow Administrators and Users
to schedule a notification to be sent at a future date and
time.			

13.3. Voice-Mail: The ENSS must distinguish when a live Contact
is reached versus when an answering machine or voicemail has
been reached on voice-delivered devices. 			


14. Reporting

14.1. Dashboard: The ENSS must provide a real-time dashboard for
each active notification broadcast allowing Administrators and
Users to view broadcast parameters (e.g. devices, start time,
duration and number of cycles) and see status of broadcast
results (e.g. confirmation and responses).			

14.2. History: The ENSS must allow Administrators and Users to
view a history of Message results for the entire period of the
contract.			

14.3. Audit Trail: The ENSS must produce real-time Message
broadcast result reports using all application data which
contains, but is not limited to, all of the following
information:
i.	Name, date and time of the Message;
ii.	Name of the Administrator or User who initiated the
broadcast;
iii.	Number of redial attempts requested by initiator;
iv.	Summary statistics, including total notified Contacts, total
confirming receipt/not confirming receipt, percentage confirming
receipt/not confirming receipt. If a polling Message, a total
for each response.  This information must be collated for
individual messages and cumulatively;  and
v.	Detailed calling information, including call-result of each
attempt within the broadcast, the addresses and associated phone
numbers attempted, the attempt number and the result (e.g.,
confirmed with date and time, busy, no answer or voicemail).			

14.4. Export: The ENSS must export all types of report data in
CSV, XLS, HTML, or PDF formats, as defined by an Administrator
or User.			

14.5. Printing: The ENSS must allow Administrators and Users to
print real-time reports of any data or statistics directly from
the GUI.			

14.6. Reports: Upon request, the Service Provider must search
and generate reports based on user-defined criteria and/or key
words including wild card searches.  In addition, the Service
Provider must retain a permanent record of all reports.


Applicability of the trade agreement(s) to the procurement

Agreement on Internal Trade (AIT)
World Trade Organization - Agreement on Government Procurement
(WTO-AGP)
North American Free Trade Agreement (NAFTA)


Justification for the Pre-Identified Supplier

ERMS Advantage is a commercial, off-the-shelf, fully hosted,
web-based emergency notification and management solution that is
used by organizations for the purpose of managing their vital
emergency processes, enabling effective communications and
management of crisis situations and incidents.  ERMS Advantage
supports Transport Canada's emergency notification requirements
without any additional configuration to TC IT infrastructure.

ERMS Advantage will allow Transport Canada to effectively manage
and maintain its industry stakeholder contact data and issue
security threat notifications in fully redundant and secure ERMS
hosting facilities. ERMS Advantage is comprised of multiple
independent yet fully integrated software modules sharing a
common database. Customers utilize various ERMS software
modules, in conjunction with ERMS telephony and messaging
services, to access and use their Stakeholder contact data to
create execute and manage notification campaigns and stay
informed in crisis situations. Stakeholder data may be imported
via multiple methods, including .csv file and may be run all at
once, or in a cumulative nature. Through ERMS' flexible APIs, it
is also possible to integrate the Advantage solution with
virtually any third party software (ie. PeopleSoft) for
automatic data updates.

Access and control is accomplished through a number of advanced
safeguards including; usage of passwords (PINs), functional
authorized access controls, rights of receipt and participation
and other security protocols. Predefined roles exist in the
solution including System Administrators (access to all system
functionality), "Agents" (designated notification campaign
managers) and Stakeholders (notification recipients). Each role
type can further be customized to allow or forbid access to
specific capabilities and modules.

ERMS Advantage is a "shared service" in that many Customers
share the infrastructure; thereby keeping the cost per Customer
at the lowest level possible while providing the greatest amount
of resources possible. The database "organizational map" and all
other customer specific information are securely protected to
comply with customer and regulatory privacy requirements. 


Government Contracts Regulations Exception(s)

Section 6 of the Government Contract Regulations is being
invoked in this procurement as only one person or firm is
capable of performing the contract.


Exclusions and/or Limited Tendering Reasons

Annex 4.4 article 506.12(b) of the AIT is applicable on the
basis of limited tendering where there is an absence of
competition for technical reasons and the goods or services can
be supplied only by a particular supplier and no alternative or
substitute exists, respectively.

Article 1016.2(b) of NAFTA is applicable on the basis of limited
tendering due to reasons where, for works of art, or for reasons
connected with the protection of patents, copyrights or other
exclusive rights, or proprietary information or where there is
an absence of competition for technical reasons, the goods or
services can be supplied only by a particular supplier and no
reasonable alternative or substitute exists.

Article XV(b) of the WTO-AGP is applicable on the basis of
limited tendering due to reasons when, for works of art or for
reasons connected with protection of exclusive rights, such as
patents or copyrights, or in the absence of competition for
technical reasons, the products or services can be supplied only
by a particular supplier and no reasonable alternative or
substitute exists.


Ownership of Intellectual Property.

Ownership of any Foreground Intellectual Property arising out of
the proposed contract will vest in the Contractor.


The period of the proposed contract or the delivery date(s)

The proposed contract is for a period of 1 years that includes 4
additonal  1-year options. All delivery mentioned in the
requirement shall be delivered within 10 days of Contract award.


Name and address of the pre-identified supplier:

ERMS Solutions Limited, Oakville, Ontario, Canada


Suppliers' right to submit a statement of capabilities

Suppliers who consider themselves fully qualified and available
to provide the goods, services or construction services
described in the ACAN, may submit a statement of capabilities in
writing to the contact person identified in this notice on or
before the closing date of this notice. 

The statement of capabilities must clearly demonstrate how the
supplier meets the advertised requirements.

The conditions of the developer's shrink-wrap license are not
acceptable to the Crown. This software is proprietary, and the
proposed Contractor must have the authority to negotiate the
terms and conditions of the contract and the related software
licensing terms including, but not limited to; limitation of
liability, indemnification, transferability of license,
termination/refund to the Crown.

Documents may be submitted in either official language of Canada


Inquiries and submission of statements of capabilities

Inquiries and statements of capabilities are to be directed to:

Jonathan Vinet
A/Supply Team Leader
Public Works and Government Services Canada
Gatineau, Québec, Canada (K1A 0S5)
Jonathan.vinet@tpsgc-pwgsc.gc.ca
Telephone 819-956-2940
Facsimile 819-953-3703 
Government of Canada
Delivery Date: Above-mentioned

You are hereby notified that the government intends to negotiate
with one firm only as identified above. Should you have any
questions concerning this requirement, contact the contracting
officer identified above.

An Advance Contract Award Notice (ACAN) allows departments and
agencies to post a notice, for no less than fifteen (15)
calendar days, indicating to the supplier community that it
intends to award a good, service or construction contract to a
pre-identified contractor. If no other supplier submits, on or
before the closing date, a Statement of Capabilities that meets
the requirements set out in the ACAN, the contracting authority
may then proceed with the award.  However, should a Statement of
Capabilities be found to meet the requirements set out in the
ACAN, then the contracting authority will proceed to a full
tendering process.

Suppliers who consider themselves fully qualified and available
to provide the services/goods described herein, may submit a
statement of capabilities in writing to the contact person
identified in this Notice on or before the closing date of this
Notice. The statement of capabilities must clearly demonstrate
how the supplier meets the advertised requirements.

The PWGSC file number, the contracting officer's name and the
closing date of the ACAN must appear on the outside of the
envelope in block letters or, in the case of a facsimile
transmission, on the covering page.

The Crown retains the right to negotiate with suppliers on any
procurement.

Documents may be submitted in either official language of Canada.