Request for Proposals

For

Development of Electronic Transcripts System Hub

Request for Proposals Number: 2015-009

Issued: December 3, 2015

Submission Date: 14:00 (Atlantic Time), December 23, 2015

Registration is required with contact person as noted in 1.1 You must register by providing your name, company name, telephone number, and email address

Page 1 of 35

TABLE OF CONTENTS

PART 1 – INTRODUCTION..........................................................................................................31.1 Invitation to Proponents.....................................................................................................31.2 Type of Contract for Deliverables......................................................................................31.3 No Guarantee of Volume of Work or Exclusivity of Contract.............................................31.4 Trade Agreements.............................................................................................................3

PART 2 – THE DELIVERABLES..................................................................................................42.1 Description of Deliverables................................................................................................42.2 Material Disclosures...........................................................................................................4

PART 3 – EVALUATION OF PROPOSALS.................................................................................53.1. Timetable and Submission Instructions.............................................................................53.2 Stages of Proposal Evaluation...........................................................................................53.3 Stage I – Mandatory Requirements, Submission and Rectification...................................63.4 Stage II – Evaluation of Rated Criteria...............................................................................63.5 Stage III – Evaluation of Pricing.........................................................................................63.6 Cumulative Score and Selection of Highest Scoring Proponent........................................6

PART 4 – TERMS AND CONDITIONS OF THE RFP PROCESS................................................74.1 General Information and Instructions.................................................................................74.2 Communication after Issuance of RFP..............................................................................74.3 Negotiations, Notification and Debriefing...........................................................................84.4 Prohibited Communications and Confidential Information.................................................94.5 Procurement Process Non-binding..................................................................................104.6 Governing Law and Interpretation....................................................................................10

APPENDIX A – MINIMUM CONTRACTUAL TERMS................................................................12APPENDIX B – SUBMISSION FORM........................................................................................15APPENDIX C – RATE BID FORM..............................................................................................18APPENDIX D – REFERENCE FORM.........................................................................................19APPENDIX E – RFP PARTICULARS.........................................................................................20APPENDIX F – BONFIRE INSTRUCTIONS...............................................................................35

Page 2 of 35

PART 1 – INTRODUCTION

1.1 Invitation to ProponentsThis Request for Proposals (“RFP”) is an invitation by the Nova Scotia Council on Admission and Transfer (NSCAT), a division of Interuniversity Services Inc. to prospective proponents to submit proposals for the provision of Development of Electronic Transcripts System Hub, as further described in Part 2 – The Deliverables (the “Deliverables”).

Interuniversity Services Inc. (ISI) is a not-for-profit company incorporated in 1984 by four independent universities. ISI currently provides selected central administrative services to eighteen member institutions in Nova Scotia, New Brunswick, Prince Edward Island, and Newfoundland/Labrador, thus reducing their overall operating costs, improving services, and providing a framework for cooperation among the membership, while maintaining their independence.

Nova Scotia Council on Admission and Transfer (NSCAT) is a consortium governed by the 11 Nova Scotia Post-Secondary Education institutions (NS-PSE’s). NSCAT has contracted ISI to provide office space and contract administration services on their behalf.

For the purposes of this procurement process the NSCAT Contact shall be: Ruth Blades, PMPProject Managerruth.blades@dal.ca

1.2 Type of Contract for DeliverablesThe selected proponent(s) will be requested to enter into negotiations for an agreement with NSCAT for the provision of the Deliverables in the form attached as Appendix E to the RFP. It is NSCAT’s intention to enter into an agreement based on Appendix A – Minimum Contractual Terms with only one (1) legal entity.

1.3 No Guarantee of Volume of Work or Exclusivity of Contract NSCAT makes no guarantee of the value or volume of work to be assigned to the successful proponent. The Agreement to be negotiated with the selected proponent will not be an exclusive contract for the provision of the described Deliverables. NSCAT may contract with others for the same or similar Deliverables to those described in the RFP or may obtain the same or similar Deliverables internally.

1.4 Trade Agreements Proponents should note that procurements falling within the scope of Chapter 5 of the Agreement on Internal Trade and the Agreement on the Opening of Public Procurement for New Brunswick and Quebec are subject to those trade agreements, but that the rights and obligations of the parties shall be governed by the specific terms of each particular tender call. For further information on the Agreement on Internal Trade, please see the Internal Trade Secretariat website at http://www.ait-aci.ca/index_en.htm.

Page 3 of 35

PART 2 – THE DELIVERABLES

2.1 Description of Deliverables

The RFP is an invitation to submit offers for the provision of services resulting in the Development of an Electronic Transcripts System Hub, as further described in Appendix E – RFP Particulars – Section A. The Deliverables.

The following is a list of NSCAT Member institutions:

Acadia University, Wolfville, NSAtlantic School of Theology, Halifax, NSCape Breton University, Sydney, NSDalhousie University, Halifax, NS (and all campuses)Mount Saint Vincent University, Halifax, NSNSCAD University, Halifax, NSNova Scotia Community College, Halifax, NS (and all campuses)Saint Mary’s University, Halifax, NSSt. Francis Xavier University, Antigonish, NSUniversité Sainte-Anne, Church Point, NS (and all campuses)University of Kings College, Halifax, NS

2.2 Material DisclosuresProponents should refer to Appendix E – RFP Particulars – Section B. Material Disclosures.

Page 4 of 35

PART 3 – EVALUATION OF PROPOSALS

3.1. Timetable and Submission Instructions

Proponents should submit their proposals according to the following timetable and instructions.

3.1.1 Timetable

Issue Date of RFP December 3, 2015Deadline for Questions December 14, 2015Deadline for Issuing Addenda December 17, 2015Submission Date 14:00 (Atlantic Time) December 23, 2015Rectification Date January 13, 2016

The RFP timetable is tentative only, and may be changed by NSCAT at any time.

3.1.2 Proposals Should Be Submitted in Prescribed MannerProponents should submit proposals to Bonfire (Online Tendering Portal) as described in Appendix F.

3.1.3 Proposals Should Be Submitted on Time at Prescribed LocationProposals should be submitted at the location set out above on or before the Submission Date. Proposals submitted after the Submission Date will be rejected.

In the case of unforeseen circumstances, a proponent may, at its option, email the NSCAT Contact prior to the Submission Date with delivery details, including the anticipated arrival time of its proposal. In the event a proposal does not arrive as scheduled, NSCAT may provide those proponents who have given such prior notice one additional Business Day to effect the delivery of their proposals. The Submission Date shall be deemed to be adjusted accordingly for the purpose of accepting those proposals. For the purposes of this Section, “Business Day” means any working day between 8:30 a.m. and 4:30 p.m., Monday to Friday inclusive, but excluding statutory and other holidays that NSCAT has elected to be closed for business.

3.1.4 Withdrawing Proposals At any time throughout the RFP process, a proponent may withdraw a submitted proposal. To effect a withdrawal, a notice of withdrawal must be sent to the NSCAT Contact and must be signed by an authorized representative. NSCAT is under no obligation to return withdrawn proposals.

3.2 Stages of Proposal EvaluationNSCAT will conduct the evaluation of proposals in the following three (3) stages:

3.2.1 Stage IStage I will consist of a review to determine which proposals comply with all of the mandatory requirements. Proposals failing to satisfy the mandatory requirements as of the Submission Date will be provided an opportunity to rectify any deficiencies. Proposals failing to satisfy the mandatory requirements as of the Rectification Date will be excluded from further consideration.

3.2.2 Stage II Stage II will consist of a scoring by NSCAT of each qualified proposal on the basis of the rated criteria.

3.2.3 Stage III Stage III will consist of a scoring of the pricing submitted. The evaluation of price will be undertaken after the evaluation of mandatory requirements and any rated requirements has been completed.

Page 5 of 35

3.3 Stage I – Mandatory Requirements, Submission and Rectification

3.3.1 Submission and Rectification DateOther than inserting the information requested on the mandatory submission forms set out in the RFP, a proponent may not make any changes to any of the forms. Proponents submitting proposals that do not meet the mandatory requirements will be provided an opportunity prior to the Rectification Date to rectify any deficiencies.

3.3.2 Submission Form (Appendix B)Each proposal must include a Submission Form (Appendix B) completed and signed by an authorized representative of the proponent.

3.3.3 Rate Bid Form (Appendix C)Each proponent must include this form completed according to the instructions contained in the form as well as those instructions set out below:

(a) rates shall be provided in Canadian funds, inclusive of all applicable duties and taxes except for sales taxes, which should be itemized separately; and

(b) rates quoted by the proponent shall be all-inclusive and shall include all labour and material costs, all travel and carriage costs, all insurance costs, all costs of delivery to NSCAT, all costs of installation and set-up, including any pre-delivery inspection charges, and all other overhead, including any fees or other charges required by law.

3.3.4 Reference Form (Appendix D)Each proponent must complete the Reference Form (Appendix D) and include it with your proposal.

3.3.5 Rectification DateProposals satisfying the mandatory requirements before the Rectification Date will proceed to Stage II. Proposals failing to satisfy the mandatory requirements will be excluded from further consideration.

3.4 Stage II – Evaluation of Rated CriteriaProponents should refer to Appendix E – RFP Particulars – Section D. Rated Criteria for a breakdown of the Rated Criteria.

3.5 Stage III – Evaluation of PricingProponents should refer to the Rate Bid Form at Appendix C and Appendix E – RFP Particulars – Section D. Pricing.

3.6 Cumulative Score and Selection of Highest Scoring ProponentAt the conclusion of Stage III, all scores from Stage II and Stage III will be added together and the highest ranked proponent will be selected for negotiations in accordance with Part 4 – Terms and Conditions of the RFP process.

Page 6 of 35

PART 4 – TERMS AND CONDITIONS OF THE RFP PROCESS

4.1 General Information and Instructions

4.1.1 Proponents to Follow InstructionsProponents should structure their proposals in accordance with the instructions in the RFP. Where information is requested in the RFP, any response made in a proposal should reference the applicable section numbers of the RFP where that request was made.

4.1.2 Proposals in EnglishAll proposals are to be in English.

4.1.3 Proponents Shall Bear Their Own CostsThe proponent shall bear all costs associated with or incurred in the preparation and presentation of its proposal, including, if applicable, costs incurred for interviews or demonstrations.

4.2 Communication after Issuance of RFP

4.2.1 Proponents to Review RFPProponents shall promptly examine all of the documents comprising the RFP, and

(a) shall report any errors, omissions or ambiguities; and(b) may direct questions or seek additional information

in writing by email on or before the proponent’s Deadline for Questions to the NSCAT Contact. All questions submitted by proponents by email to the NSCAT Contact shall be deemed to be received once the email has entered into the NSCAT Contact’s email inbox. No such communications are to be directed to anyone other than the NSCAT Contact. NSCAT is under no obligation to provide additional information.

It is the responsibility of the proponent to seek clarification from the NSCAT Contact on any matter it considers to be unclear. NSCAT shall not be responsible for any misunderstanding on the part of the proponent concerning the RFP or its process.

4.2.2 All New Information to Proponents by Way of Addenda The RFP may be amended only by an addendum in accordance with this section. If NSCAT, for any reason, determines that it is necessary to provide additional information relating to the RFP, such information will be communicated to all proponents by addenda. Each addendum forms an integral part of the RFP.

Such addenda may contain important information, including significant changes to the RFP. Proponents are responsible for obtaining all addenda issued by NSCAT. It is the Proponent’s responsibility to check the ISI or NS government websites for Addenda that may have been issued.

In the Submission Form (Appendix B), proponents should confirm their receipt of all addenda by setting out the number of each addendum in the space provided.

4.2.3 Post-Deadline Addenda and Extension of Submission DateIf any addendum is issued after the Deadline for Issuing Addenda, NSCAT may at its discretion extend the Submission Date for a reasonable amount of time.

Page 7 of 35

4.2.4 Verify, Clarify and SupplementWhen evaluating responses, NSCAT may request further information from the proponent or third parties in order to verify, clarify or supplement the information provided in the proponent’s proposal. NSCAT may revisit and re-evaluate the proponent’s response or ranking on the basis of any such information.

4.2.5 No Incorporation by Reference The entire content of the proponent’s proposal should be submitted in a fixed form, and the content of websites or other external documents referred to in the proponent’s proposal will not be considered to form part of its proposal.

4.2.6 Proposal to Be Retained by NSCAT NSCAT will not return the proposal or any accompanying documentation submitted by a proponent.

4.3 Negotiations, Notification and Debriefing

4.3.1 Selection of Top-Ranked ProponentThe top-ranked proponent, as established under Part 3 – Evaluation of Proposals, will receive a written invitation to enter into direct contract negotiations with NSCAT.

4.3.2 Timeframe for NegotiationsNSCAT intends to conclude negotiations within thirty (30) days commencing from the date NSCAT invites the top-ranked proponent to enter negotiations. A proponent invited to enter into direct contract negotiations should therefore be prepared to provide requested information in a timely fashion and to conduct its negotiations expeditiously.

4.3.3 Process Rules for NegotiationsAny negotiations will be subject to the process rules contained in this Part 4 – Terms and Conditions of RFP Process and the Submission Form (Appendix B) and will not constitute a legally binding offer to enter into a contract on the part of NSCAT or the proponent. Negotiations may include requests by NSCAT for supplementary information from the proponent to verify, clarify or supplement the information provided in its proposal or to confirm the conclusions reached in the evaluation, and may include requests by NSCAT for improved pricing from the proponent.

4.3.4 Terms and ConditionsThe terms and conditions found in the Appendix A – Minimum Contractual Terms are to form the starting point for negotiations between NSCAT and the selected proponent(s).

In accordance with Appendix E Part C; Other Mandatory Requirements

Each proponent is required to outline their compliance with the Appendix A – Minimum Contractual Terms. Any modification or addition to the Terms and Conditions contained within Appendix A should be marked on the document and submitted with your response.

4.3.5 Failure to Enter Into AgreementProponents should note that if the parties cannot execute a contract within the allotted thirty (30) days, NSCAT may invite the next-best-ranked proponent to enter into negotiations. In accordance with the process rules in this Part 4 – Terms and Conditions of RFP Process and the Submission Form (Appendix B), there will be no legally binding relationship created with any proponent prior to the execution of a written agreement. With a view to expediting contract formalization, at the midway point of the above-noted timeframe, NSCAT may elect to initiate concurrent negotiations with the next-best-ranked proponent. Once the above-noted timeframe lapses, NSCAT may discontinue further negotiations with that particular proponent. This process shall continue until a contract is formalized, until there are no

Page 8 of 35

more proponents remaining that are eligible for negotiations or until NSCAT elects to cancel the RFP process.

4.3.6 Notification to Other Proponents Other proponents that may become eligible for contract negotiations will be so notified at the commencement of the negotiation process. Once a contract is executed between NSCAT and a proponent, the other proponents may be notified directly in writing and shall or notified by public posting in the same manner that the RFP was originally posted of the outcome of the procurement process and the award of the contract.

4.3.7 DebriefingProponents may request a debriefing after receipt of a notification of award. All requests must be in writing to the NSCAT Contact and must be made within thirty (30) days of notification of award. The intent of the debriefing information session is to aid the proponent in presenting a better proposal in subsequent procurement opportunities. Any debriefing provided is not for the purpose of providing an opportunity to challenge the procurement process or to discuss any of the other proposals submitted.

4.3.8 Bid Protest ProcedureIf a proponent wishes to challenge the outcome of the RFP process, it should provide written notice to NSCAT Contact within thirty (30) days of notification of award, and NSCAT will respond in accordance with its bid protest procedures.

4.4 Prohibited Communications and Confidential Information

4.4.1 Prohibited Proponent CommunicationsThe proponent shall not engage in any Conflict of Interest communications and should take note of the Conflict of Interest declaration set out in the Submission Form (Appendix B). For the purposes of this Section, “Conflict of Interest” shall have the meaning ascribed to it in the Submission Form (Appendix B).

4.4.2 Proponent Not to Communicate with MediaA proponent may not at any time directly or indirectly communicate with the media in relation to the RFP or any contract awarded pursuant to the RFP without first obtaining the written permission of the NSCAT Contact.

4.4.3 Confidential Information of Institution All information provided by or obtained from NSCAT in any form in connection with the RFP either before or after the issuance of the RFP

(a) is the sole property of NSCAT and must be treated as confidential;

(b) is not to be used for any purpose other than replying to the RFP and the performance of any subsequent Contract;

(c) must not be disclosed without prior written authorization from NSCAT; and

(d) shall be returned by the proponents to NSCAT immediately upon the request of NSCAT.

4.4.4 Confidential Information of ProponentA proponent should identify any information in its proposal or any accompanying documentation supplied in confidence for which confidentiality is to be maintained by NSCAT. The confidentiality of such information will be maintained by NSCAT, except as otherwise required by law or by order of a court or tribunal. Proponents are advised that their proposals will, as necessary, be disclosed on a confidential basis, to NSCAT’s advisers retained for the purpose of evaluating or participating in the evaluation of

Page 9 of 35

their proposals. If a proponent has any questions about the collection and use of personal information pursuant to the RFP, questions are to be submitted to the NSCAT Contact.

4.5 Procurement Process Non-binding

4.5.1 No Contract A and No ClaimsThe procurement process is not intended to create and shall not create a formal legally binding bidding process and shall instead be governed by the law applicable to direct commercial negotiations. For greater certainty and without limitation: (a) the RFP shall not give rise to any “Contract A”–based tendering law duties or any other legal obligations arising out of any process contract or collateral contract; and (b) neither the proponent nor NSCAT shall have the right to make any breach of contract, tort or other claims against the other with respect to the award of a contract, failure to award a contract or failure to honour a response to the RFP.

4.5.2 No Contract until Execution of Written AgreementThe RFP process is intended to identify prospective vendors for the purposes of negotiating potential agreements. No legal relationship or obligation regarding the procurement of any good or service shall be created between the proponent and NSCAT by the RFP process until the successful negotiation and execution of a written agreement for the acquisition of such goods and/or services.

4.5.3 Non-binding Price EstimatesWhile the pricing information provided in responses will be non-binding prior to the execution of a written agreement, such information will be assessed during the evaluation of the responses and the ranking of the proponents. Any inaccurate, misleading or incomplete information, including withdrawn or altered pricing, could adversely impact any such evaluation, ranking or contract award.

4.5.4 Disqualification for MisrepresentationNSCAT may disqualify the proponent or rescind a contract subsequently entered if the proponent’s response contains misrepresentations or any other inaccurate, misleading or incomplete information.

4.5.5 References and Past PerformanceNSCAT’s evaluation may include information provided by the proponent’s references and may also consider the proponent’s past performance on previous contracts with NSCAT or other institutions.

4.5.6. Inappropriate Conduct NSCAT may prohibit a supplier from participating in a procurement process based on past performance or based on inappropriate conduct in a prior procurement process, and such inappropriate conduct shall include but not be limited to the following: (a) the submission of quotations containing misrepresentations or any other inaccurate, misleading or incomplete information; (b) the refusal of the supplier to honour its pricing or other commitments made in its proposal; or (c) any other conduct, situation or circumstance, as solely determined by NSCAT, which constitutes a Conflict of Interest. For the purposes of this Section, “Conflict of Interest” shall have the meaning ascribed to it in the Submission Form (Appendix B).

4.5.7 CancellationNSCAT may cancel or amend the RFP process without liability at any time.

4.6 Governing Law and Interpretation

4.6.1 Governing LawThe terms and conditions in this Part 4 – Terms and Conditions of RFP Process (a) are included for greater certainty and are intended to be interpreted broadly and separately (with no particular provision intended to limit the scope of any other provision); (b) are non-exhaustive (and shall not be construed as

Page 10 of 35

intending to limit the pre-existing rights of the parties to engage in pre-contractual discussions in accordance with the common law governing direct commercial negotiations); and (c) are to be governed by and construed in accordance with the laws of the province of Nova Scotia and the federal laws of Canada applicable therein.

Page 11 of 35

APPENDIX A – MINIMUM CONTRACTUAL TERMS

1. Vendor warrants compliance to all applicable laws and agrees to indemnify NSCAT and officers and employees, for failure to comply.

2. Vendor agrees to indemnify and save harmless NSCAT, and officers and employees, against any claims or costs initiated by third parties as a result of any negligence or wrongful acts of the Vendor or its employees, agents or subcontractors.

3. Vendor agrees to indemnity and save harmless NSCAT, and officers and employees, against any claims that any products or services supplied by the Vendor to NSCAT constitute an infringement of third party intellectual property rights.

4. Confidentiality and Privacy. Vendor shall:

4.1. treat as confidential all information (including personally identifiable information), data, documents, and materials (collectively referred as “Confidential and Personal Information”) acquired or to which access has been given in the course of, or incidental to, the performance of this Contract;

4.2. hold the Confidential and Personal Information in strict confidence and not disclose, or permit to be disclosed, to any person, corporation, or organization such Confidential and Personal Information, or any part thereof, without the express prior written consent from NSCAT;

4.3. permit only those employees who have a need to do so to access the Confidential and Personal Information, and to require such employees to hold the Confidential and Personal Information in strict confidence and to use the Confidential and Personal Information solely for the purposes of providing the work performed under the Contract;

4.4. take reasonably necessary steps in order to protect the Confidential and Personal Information from unauthorized access, use, disclosure or destruction;

4.5. not reproduce or make any copies of the Confidential and Personal Information except with the express prior written authorization of NSCAT;

4.6. store, house and back-up, if applicable, all personally identifiable information exclusively in Canada, and not allow access to the personally identifiable information from outside of Canada;

4.7. take commercially reasonable security and other measures to protect and safeguard the Confidential and Personal Information in its possession and control and protect it from unauthorized access, use and disclosure, and comply with any rules or directions made or given by NSCAT with respect to safeguarding or ensuring the confidentiality the Confidential and Personal Information;

4.8. resist all formal or legal demand or request for access to, or disclosure of, personally identifiable information to the fullest extent possible, and immediately notify NSCAT in the event that it receives a formal or legal demand or request for access to, or disclosure of, personally identifiable information;

4.9. upon completion or termination of the Contract, or upon the written request of NSCAT, immediately return the Confidential and Personal Information to NSCAT, including any copies or

Page 12 of 35

reproductions made thereof, or shall destroy such Confidential and Personal Information and any copies and certify same to NSCAT;

4.10. indemnify and hold the University, its successors, directors, officers and employees harmless from and against all claims, demands, actions, causes of action, damages, losses, costs, liabilities, and expenses (including legal costs) which NSCAT may suffer or incur, or which may be made or brought against NSCAT, as a result of, in respect of, or arising out of, any breach or non-fulfillment of any term or condition of this confidentiality or privacy obligations by the Vendor or its directors, officers, employees, agents, representatives, affiliates, subsidiaries and contractors;

4.11. acknowledge that money damages would not be a sufficient remedy for any breach of confidentiality or privacy obligations by it or its directors, officers, employees, agents, representatives, affiliates, subsidiaries and contractors and agrees that, in addition to all other remedies, NSCAT shall be entitled to specific performance and injunctive or other equitable relief as a remedy of any such breach and the Vendor further agrees to waive, and to use its best efforts to cause its officers, employees, agents, representatives, affiliates, subsidiaries and contractors to waive, any requirement for the security or posting of any bond in connection with such remedy;

4.12. acknowledge that the Confidential and Personal Information are the exclusive property of NSCAT, and that nothing in the Agreement or this agreement shall give the Vendor any ownership rights therein; and

4.13. comply at all times with all applicable privacy laws, including without limitation, the Nova Scotia Freedom of Information and Protection of Privacy Act (FOIPOP) and Personal Information International Disclosure Protection Act (PIIDPA), in respect of any personal information it stores or accesses in the course of providing the Services. For the purposes of this Section, “personal information” shall mean all personal information (as defined in FOIPOP) under the custody and control of NSCAT.

5. Insurance.

5.1. The Contractor shall maintain comprehensive general liability insurance. The minimum limits of such insurance shall not be less than $5,000,000 with respect to each occurrence or accident. NSCAT shall be included as an additional insured. This insurance shall be considered primary and any insurance or self-insurance maintained by NSCAT shall be excess of and non-contributory to the Vendor’s insurance. The Vendor shall, upon request by the University, furnish evidence of such coverage to NSCAT.

5.2. The Vendor shall maintain automobile insurance of at least $5,000,000, combined single limit, on all owned, non-owned, leased or hired automobiles. The Vendor shall, upon request by NSCAT, furnish evidence of such coverage.

5.3. The Vendor shall maintain professional liability insurance protecting the Vendor and its respective servants, agents and employees against any loss or damages arising out of the provision of professional services rendered by the Vendor and its respective servants, agents and employees pursuant to this Agreement. Such insurance shall not be less than $2,000,000 aggregate per year and $2,000,000 for each claim. In the event of a claim the Vendor will be responsible for the payment of any deductibles. The Vendor shall, upon request by NSCAT, furnish evidence of such coverage to NSCAT.

5.4. The Vendor shall, at all times, comply with all applicable provincial workers compensation laws. The Vendor shall, upon request by NSCAT, furnish a clearance certificate or other evidence

Page 13 of 35

indicating the Vendor is in good standing with the requirements of such applicable provincial workers compensation laws.

6. When using the premises of NSCAT, the Vendor shall comply with all of Dalhousie policies, procedures and security regulations in effect from time to time.

7. NSCAT shall have the right to early termination of the Contract for Vendor non-compliance, including without limitation, failure to respond to requirements in a timely manner, poor quality workmanship or failure to adhere to system requirements.

8. The Contract shall be interpreted, performed, and enforced in accordance with the laws of the Province of Nova Scotia.

9.

Page 14 of 35

APPENDIX B – SUBMISSION FORM

1. Proponent Information

Please fill out the following form, and name one person to be the contact for the RFP response and for any clarifications or amendments that might be necessary.Full Legal Name of Proponent:

[enter your response here]

Any Other Relevant Name under Which the Proponent Carries on Business:

[enter your response here]

Street Address: [enter your response here]City, Province/State: [enter your response here]Postal Code: [enter your response here]Phone Number: [enter your response here]Fax Number: [enter your response here]Company Website (If Any): [enter your response here]RFP Contact Person and Title:

[enter your response here]

RFP Contact Phone: [enter your response here]RFP Contact Facsimile: [enter your response here]RFP Contact E-mail: [enter your response here]

2. Acknowledgment of Non-binding Procurement ProcessThe proponent acknowledges that the RFP process will be governed by the terms and conditions of the RFP, and that, among other things, such terms and conditions confirm that this procurement process does not constitute a formal legally binding bidding process, and that there will be no legal relationship or obligations created until NSCAT and the selected proponent have executed a written contract.

3. Ability to Provide DeliverablesThe proponent has carefully examined the RFP documents and has a clear and comprehensive knowledge of the Deliverables required under the RFP. The proponent represents and warrants its ability to provide the Deliverables required under the RFP in accordance with the requirements of the RFP for the Rates set out in the Rate Bid Form and has provided a list of any subcontractors to be used to complete the proposed contract. The proponent encloses herewith as part of the proposal the mandatory forms set out below:

FORM INITIAL TO ACKNOWLEDGESubmission FormRate Bid FormReference Form

Notice to proponents: There may be forms required in the RFP other than those set out above. See the Mandatory Requirements section of the RFP for a complete listing of mandatory forms.

4. Non-binding Price Estimates

Page 15 of 35

The proponent has submitted its Rates in accordance with the instructions in the RFP and in the Rate Bid Form set out in Appendix C. The proponent confirms that the pricing information provided is accurate. The proponent acknowledges that any inaccurate, misleading or incomplete information, including withdrawn or altered pricing, could adversely impact the acceptance of its quotation or its eligibility for future work.

5. AddendaThe proponent is deemed to have read and accepted all addenda issued by NSCAT prior to the Deadline for Issuing Addenda. The onus remains on proponents to make any necessary amendments to their proposal based on the addenda. The proponent is requested to confirm that it has received all addenda by listing the addenda numbers or, if no addenda were issued, by writing the word “None” on the following line: ____________________________. Proponents who fail to complete this section will be deemed to have received all posted addenda.

It is the proponent’s responsibility to check the ISI or NS government websites for Addenda that may have been issued.

6. Conflict of InterestFor the purposes of this section, the term “Conflict of Interest” means

(a) in relation to the RFP process, the proponent has an unfair advantage or engages in conduct, directly or indirectly, that may give it an unfair advantage, including but not limited to (i) having, or having access to, confidential information of NSCAT in the preparation of its proposal that is not available to other proponents, (ii) communicating with any person with a view to influencing preferred treatment in the RFP process (including but not limited to the lobbying of decision makers involved in the RFP process), or (iii) engaging in conduct that compromises, or could be seen to compromise, the integrity of the RFP process; or

(b) in relation to the performance of its contractual obligations contemplated in the contract that is the subject of this procurement, the proponent’s other commitments, relationships or financial interests (i) could, or could be seen to, exercise an improper influence over the objective, unbiased and impartial exercise of its independent judgement, or (ii) could, or could be seen to, compromise, impair or be incompatible with the effective performance of its contractual obligations.

If the box below is left blank, the proponent will be deemed to declare that (a) there was no Conflict of Interest in preparing its proposal; and (b) there is no foreseeable Conflict of Interest in performing the contractual obligations contemplated in the RFP.

Otherwise, if the statement below applies, check the box.

The proponent declares that there is an actual or potential Conflict of Interest relating to the preparation of its proposal, and/or the proponent foresees an actual or potential Conflict of Interest in performing the contractual obligations contemplated in the RFP.

If the proponent declares an actual or potential Conflict of Interest by marking the box above, the proponent must set out below details of the actual or potential Conflict of Interest:

Page 16 of 35

The following individuals, as employees, advisers, or in any other capacity (a) participated in the preparation of our proposal; AND (b) were employees of NSCAT and have ceased that employment within twelve (12) months prior to the Submission Date:

Name of Individual:Job Classification:Department:Last Date of Employment with NSCAT:Name of Last Supervisor:Brief Description of Individual’s Job Functions:

Brief Description of Nature of Individual’s Participation in the Preparation of the Proposal:

(Repeat above for each identified individual)

The proponent agrees that, upon request, the proponent shall provide NSCAT with additional information from each individual identified above in the form prescribed by NSCAT.

7. Disclosure of Information The proponent hereby agrees that any information provided in this proposal, even if it is identified as being supplied in confidence, may be disclosed where required by law or if required by order of a court or tribunal. The proponent hereby consents to the disclosure, on a confidential basis, of this proposal by NSCAT to NSCAT’s advisers retained for the purpose of evaluating or participating in the evaluation of this proposal.

Signature of Witness Signature of Proponent Representative

Name of Witness Name and Title

Date:

I have authority to bind the proponent

Page 17 of 35

APPENDIX C – RATE BID FORM

FEE PROPOSAL FORM

INSTRUCTIONS: Complete this Fee Proposal Form and submit.

Name of Proponent: ______________________________________________________

Address: ______________________________________________________

______________________________________________________

______________________________________________________

Phone/Fax No: ______________________________________________________

FIXED FEE PROPOSAL

A. TOTAL PROPOSAL FEE FROM BREAKOUT PRICING $__________________________(Excludes HST)

(Breakout pricing to be be included separately in the Proponents response as per Proposal Response Elements above)

B. FEE FOR ADDITIONAL PHASES, HOURLY RATES (excluding HST)  

Principals, Executives and Other Personnel including Administrative Support approved in that capacity. Hourly rate to be fixed for the duration of the contract. Add additional lines as required.

Name Title $ Per Hour (Exclusive of HST)

% Level of Effort

Signature of Consultant

The Consultant agrees to provide ALL services requested in the Request for Proposal.

…………………………………………….. ………………………………………Signature Signature

…………………………………………….. ………………………………………Capacity Capacity

…………………………………………….. ………………………………………Email Email

END OF FEE PROPOSAL FORM

Page 18 of 35

APPENDIX D – REFERENCE FORM

Each proponent is requested to provide three (3) references from clients who have obtained similar goods or services to those requested in the RFP from the proponent in the last five (5) years. If there has been a previous agreement, references should not include NSCAT member institutions.

Reference #1Company Name:Company Address:Contact Name:Contact Telephone Number:Date Work Undertaken:Nature of Assignment:

Reference #2Company Name:Company Address:Contact Name:Contact Telephone Number:Date Work Undertaken:Nature of Assignment:

Reference #3Company Name:Company Address:Contact Name:Contact Telephone Number:Date Work Undertaken:Nature of Assignment:

Page 19 of 35

APPENDIX E – RFP PARTICULARS

A. THE DELIVERABLESTo be inserted into the final contract subject to revision on the basis of Successful Proposal for Services, but shall include the following.

A. SCOPE OF SERVICES

1. The Contractor shall, in accordance with the general objectives set out above, complete the following services:1.1. Conduct a structured requirements confirmation process for the eTranscripts System.1.2. Develop the eTranscripts System, including an administrative interface.1.3. Train administrators and content editors on website/database functionality and operations.

B. DELIVERABLE SCHEDULE

1. The Contractor shall identify if they can meet the following schedule and/or what they may propose as changes for our evaluation:1.1. Project launch: Week of March 7, 20161.2. Requirements confirmation: Week of March 14, 20161.3. System developed & ready for testing Week of July 4, 20161.4. System implemented & interfaces established: Week of September 12, 20161.5. System launch: Week of September 19, 2016

C. PROJECT MANAGEMENT

1. The successful Proponent will report to NSCAT’s Project Manager.

D. SYSTEM REQUIREMENTS

1. System Overview

1.1. The Electronic Transcript System (eTS) is intended to be a broker system in a hub and spoke model responsible for the correct reception, routing and delivery of XML messages between transcript producers (initially, Nova Scotia School Boards via the Department of Early Education and Childhood Development) and transcript consumers (initially, the 11 post-secondary institutions in Nova Scotia). It will accept Transcript Request messages from consumers and route the requests to the appropriate producer, processing synchronous responses as-necessary. It will accept batches of Transcript Response and/or Transcript messages from producers and route the messages to the appropriate consumer, processing poly-synchronous response as-required. It will also process Functional Acknowledgement messages in both directions. The system will provide a secure administrative interface which will allow viewing the message queue and examination of logs of transmission and reception events.

1.2. The eTS will leverage both the XML schemas and the Data Transfer Standard (DTS) of the P20W Education Standards Council (PESC). Although the standard protocol for the eTS to send and receive messages will be SOAP web services as defined by the DTS, it is possible that an alternative transport (e.g., SFTP) may be necessary, at least in the initial stages as the various partners develop their endpoint solutions. It should be noted, however, that even if an alternative transport is determined to be in-scope, that it will be just that, an alternative transport. All messages will still be required to be PESC Schema compliant and interactions

Page 20 of 35

will still follow the PESC DTS model, including requests, responses and functional acknowledgments.

1.3. A Technical Blueprint has been developed to provide a conceptual architecture and high-level design for the system; however, the existing work does not presuppose anything regarding the development of the solution – as long as the target hosting platform of Windows Server is acknowledged, the eTS solution could conceivably be manifested as a purpose-built application in an industry-standard language such as Java or .Net, as code developed to run on a SOA platform (e.g., Oracle SOA Suite, WSO2, Microsoft Biztalk) or as an existing software product purpose-built for PESC-compliant message exchanges.

2. Conceptual Architecture

The developer will be responsible for determining the final system architecture during the requirements confirmation and design phase.

3. Predetermined Requirements

3.1 A Technical Blueprint for the electronic transcripts project has been developed and provides specifics on technical requirements and technical architecture as well as high-level application design guidelines. Please see the attached Technical Blueprint.

3.2 The electronic Transcripts System (eTS) will operate within the following:

3.2.1 PESC Approved Standards will be used define how files should be designed an populated. These standards are available free of charge from PESC.org and were developed, reviewed and approved through an open, transparent and community-based collaborative process governed by PESC. Each standard supports a business process or transaction and each can be used one independently from another. All PESC Approved Standards include:

Page 21 of 35

3.2.1.1 XML schemas that outline how files should be designed and populated.3.2.1.2 Implementation Guides that help explain how to implement and use PESC

Approved Standards.3.2.1.3 Instance Documents which are valid examples of XML schemas based on

fictitious or 'dummy' data.

3.2.2 As detailed in the Technical Blueprint, the technologies that will be involved in the creation of the eTS have been determined as:

3.2.2.1 eXtensible Markup Language (XML) - Extensible Markup Language (XML) is an industry standard for creating messages in a format that is generally both machine- and human-readable. The PESC standards already selected for use by the eTS are XML-based, therefore XML documents will be the message format used.

3.2.2.2 XML Schema Definition (XSD) - Where XML is a markup language that simply places strictures on how document formatting, XML Schema Documents are one means to define the structure of a document such as what elements it must or may contain and what order the elements must appear. The PESC standards include XSDs suitable for structuring XML documents of various transcript exchange-related types and conformance to these schemas will ensure regular and well-structured data is passed to and from the eTS.

3.2.2.3 Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) - Although the SOAP standard allows for implementation over multiple protocols, HTTP is the most common and is considered the most desirable and the PESC DTSv2 is designed around the use of HTTP. All SOAP web service connections in which the eTS is involved will use HTTP as the transport. In addition, the administrative interface to the eTS will use HTTP as its underlying protocol.

3.2.2.4 SOAP Web Services - A web service is generally considered to be a software component that is designed to support interactions between devices on a network. Although there are multiple types of web services, the protocol specification known as SOAP is the one leveraged by the Data Transfer Standard published by PESC for data exchange. SOAP web services are defined through the use of Web Service Definition Language (WSDL) documents that specify both the operations that can be performed and the types of messages that will be sent and received in the process.

3.2.2.5 WS-Security v1.1 (aspects) - Although the Web Services Security (WS-Security) standard of the World Wide Web Consortium (W3C) defines an XML Encryption standard (XML-Enc), a means by which the payloads of SOAP web service XML messages may be protected using encryption, and though the PESC DTSv2 specifies the use of WS-Security, it does not require the use of XML-Enc for message payload encryption. It does, however, specify that SSL must be enabled for all communications sent and received by a DTS-compliant web service. Thus there is a requirement that the eTS support HTTPS communications for all transcript-related messaging.

Page 22 of 35

3.2.2.6 XML-Sig - Digital signing is a means of using public key cryptography to validate both the integrity of a message and the identity of the sending party. The WS-Security standard leverages XML Digital Signatures (XML-Sig or XML-DSig) to provide these facilities and the PESC DTSv2 specifies the use of this element of WS-Security on all transcript-related messages.

3.2.2.7 Binary Security Token - As defined in the WS-Security standard, binary security tokens are the public portion of a public/private keypair, included in an XML message in the form of a X.509 certificate. The token that is included is the public key needed to validate the digital signature applied to the XML message. While the PESC DTSv1 does not prescribe the use of binary security tokens, the v2 standard requires their use. The use of the binary security token element to include public key information alleviates the need for partners to exchange public keys out-of-band and prior to engaging in data exchanges and also the need for extensive key maintenance.

3.2.2.8 Timestamp - the PESC DTSv2 specifies the inclusion of creation and expiry elements within the timestamp element in order to protect against both man-in-the-middle interception attacks as well as transaction replay attacks.

3.2.2.9 X.509 Certificates - the aspects of WS-Security specified by the PESC DTSv2 standard provide for authentication in the form of the digital signature that is applied to each message that is sent. The digital signature is applied using the public key (X.509 certificate) of the signing party and the public key is then included in the message. The identity of the signing party is validated by examining the public key itself, which has been signed by a Certificate Authority who has done some level of due diligence to validate the identity of the party before issuing the certificate.

3.2.2.10 Zlib compression & Base64 encoding - the PESC DTS specifies that the XML body of a compliant message be both Zlib compressed and Base64 Encoded.

3.2.3 The chosen solution will operate in a Microsoft Windows Server based environment.

3.2.4 On behalf of NSCAT, the eTS will be housed on a server, to be located at Dalhousie University, and managed and maintained by Higher Education IT Shared Services. NSCAT will provide the developer with appropriate environments to complete the initiative.

3.2.5 The proposed solution may be comprised of commercial off-the-shelf (COTS) software, or a custom-built application, or any combination of the two. Licensing requirements and costs for any included COTS components must be provided as specific in section 10. Regardless of the solution architecture, details must be provided regarding ongoing support resources, system document, training and training materials, as described in sections 6 – 11 below.

4 Requested Requirements

Page 23 of 35

4.1 The chosen proponent will be required to build and/or implement a solution, following the specifications in the Technical Blueprint and others to be determined during a requirements definition/confirmation process, that will enable the following:

4.2 Inbound Data Exchange Service4.2.1 The Inbound Data Exchange Service is the web service interface that listens for

incoming messages from the exchange partners. It will be a SOAP Web Service that implements the PESC DTS version 2 using the WSDL provided by PESC. This web service will be the only entry point for data to be exchanged through the eTS. SOAP Request messages received by this service that do not generate an error will be forwarded by this service to the Routing and Transformation service.

4.2.2 PESC Data Transfer Standard WSDL - PESC provides a Web Services Definition Language (WSDL) document that can be used to create a DTS-compliant web service. It is recommended that this WSDL be used unmodified to create the listening web service for the eTS. Doing so should minimize the effort involved in integrating with additional external partners, especially if those partners have already done previous PESC integrations.

4.2.3 As with all WSDL documents used to define SOAP services, the DTS WSDL effectively creates a contract that must be fulfilled in order for messages to be passed.

4.2.4 Validation and Error Handling - The PESC DTS Specification provides a complete SOAP error handling definition using SOAP faults that will need to be implemented as part of the Inbound Data Exchange Service. Doing so will ensure that errors are caught in a timely fashion. Because the DTS describes a synchronous web service, the processing required to validate the message against the error handling requirements will need to be performed immediately upon receipt of the message.

4.2.5 Non-SOAP Errors - Several types of errors are possible outside the SOAP specification, generally occurring before a message sending event is complete. These types of errors include: TCP/IP errors; HTTP/S errors; and Web Service errors generated natively by programming toolkits (SDK). These errors will be reported and handled in the fashion standard to their nature, generally by the underlying components (e.g., Web Server for HTTP/S errors).

4.2.6 Validation Checks - According to the DTS, the validation checks that will lead to the return of a SOAP fault include:

4.2.6.1 WS-Security - The aspects of WS-Security defined for implementation by the DTS must validate, including:4.2.6.1.1 The presence of the required elements, including Timestamp,

Binary Security Token and Digital Signature as well as the elements required to support them;

4.2.6.1.2 The validation of the sender's public key included as a Binary Security Token, including that the certificate chain is valid and leads to a recognized provider, that the certificate is not expired and that the certificate has not been revoked; and,

4.2.6.1.3 The validation that the digital signature is valid: that it decrypts correctly with the sender's public key and that the message

Page 24 of 35

digest compares correctly with a message digest created locally from the message.

4.2.6.2 SOAP Header Checks4.2.6.2.1 /DTSRequestHeader - element must be present.4.2.6.2.2 The following elements must both be present and non-empty:

4.2.6.2.2.1 /DTSRequestHeader/DTSRouting/DTSSourceID4.2.6.2.2.2 /DTSRequestHeader/DTSRouting/DTSRecipientID4.2.6.2.2.3 /DTSRequestHeader/DTSRouting/DTSUUID4.2.6.2.2.4 /DTSRequestHeader/DTSRequestPayloadType 4.2.6.2.2.5 /DTSRequestHeader/DTSRequestServiceExpectation4.2.6.2.2.6 /DTSRequestHeader/DTSRequestPayloadBytes

4.2.6.3 SOAP Body Checks4.2.6.3.1 /DTSRequest - an appropriately compressed and encoded

payload must be present (element must be non-empty)4.2.6.3.2 The decoded and decompressed message payload size, as

specified in the header by /DTSRequestHeader/DTSRequestPayloadBytes is larger than the system is configured to handle.

4.2.6.3.3 The contents of the DTS Request element must decode using Base64 without error.

4.2.6.3.4 The result of the Base64 decoding must in turn decompress without error.

4.2.6.4 If any of the above checks fail, the appropriate SOAP Fault as defined in the DTS specification will be returned by the Inbound Data Exchange service to the caller instead of a SOAP Response.

4.2.6.5 Additional SOAP Faults - Whereas additional agreements may be put into place regarding what is included in the DTSRequestHeader sub-elements such as DTSRequestServiceExpectation and DTSRequestPayloadType, additional SOAP Faults may be defined in the detailed design of the service, for example "Payload type not supported" to indicate that the eTS does not yet support the type of payload that the client is trying to send.

4.2.6.6 SOAP Response Messages - Upon successfully validating a message, the Inbound Data Exchange Service will be responsible for generating and sending a synchronous SOAP Response message for each SOAP Request message received.

4.2.6.7 Logging - All SOAP request messages sent to the web service of the Inbound Data Exchange interface must be logged. The logged information should include (but may not be limited to):4.2.6.7.1 The timestamp of the receipt of the request message and every

other event logged;4.2.6.7.2 The timestamp information included in the SOAP header of the

request message;4.2.6.7.3 The UUID included in the SOAP header of the request

message;4.2.6.7.4 The source of the message as recorded in the SOAP header of

the request message; and,4.2.6.7.5 Any errors that were generated in the reception of the message.

Page 25 of 35

4.2.6.8 Similar information should be logged pertaining to each SOAP response message sent in response to the request.

4.3 Message Processing Service - The Message Processing Service is responsible for examining the received messages, determining their type and their ultimate destination and performing any transformations required. It is acknowledged that for the initial deployment with a single exchange type (e.g., High School Transcripts) the Message Processing Service will likely have a minimal implementation, however future phases are likely to bring the need for increased capabilities in this service.

4.4 The Inbound Data Exchange Service will be responsible for providing the message to the Message Processing Service. This will include the previously decoded and decompressed payload included in the received SOAP message body, but ideally will also include the SOAP header information in order to maximize the information available. How this is accomplished will be up to the implementation.

4.4.1 Message Classification - Although it ultimately depends on the business design and agreement between exchange partners, the most likely means of determination for the type of message is the SOAP header element DTSRequestPayloadType. The /AcademicRecordBatch/BatchEnvelope element does not contain a sub-element defining the type(s) of document contained in the batch and the XML documents contained in the BatchContent element of an AcademicRecordBatch document are not guaranteed to be homogenous.

4.4.2 Message Routing - For High School Transcript-related exchanges, determination of the message routing will necessarily involve examination of the payload. There are at least two locations where the destination may be contained:

4.4.2.1 The contents of the AcademicRecordBatch/BatchEnvelope/DestinationAgency element; and,

4.4.2.2 The contents of one (or more) individual XML Documents contained in the AcademicRecordBatch/BatchContent/ element, querying the TransmissionData element that is common to all accepted document types for the identifier of the destination.

4.4.3 Assuming that the BatchEnvelope is being used and all messages in a batch are guaranteed to have the same destination, the former method is preferred.

4.4.4 Message Transformation - Ideally downstream partner services will allow the eTS to forward batches of messages exactly as they are received. It is possible, however, that one or more partners may implement an exchange service that does not accept PESC Academic Record Batch XML Documents. In that case, a transformation will be required from the Academic Record Batch schema to whatever schema is accepted by the exchange partner.

4.4.5 If this is the case, a means of identifying what partners require transformation will be required and available to the Message Transformation component. Message transformation will be accomplished through the use of a XML Stylesheet Language Transformation (XSLT) that takes a PESC Academic Record Batch

Page 26 of 35

XML Document as an input and produces an XML Document in the required format for partner compatibility.

4.4.6 Logging - The Message Processing Service should log all messages and all actions taken with each message. At a minimum the following should be logged:4.4.6.1 A timestamp for every event logged;4.4.6.2 The UUID of the message for correlation with log messages from the

Inbound Data Exchange Service;4.4.6.3 The BatchID, if the BatchEnvelope element is present;4.4.6.4 An indicator of the message classification (e.g., Transcript Request Batch,

Transcript Response Batch);4.4.6.5 An indicator of the message source as taken from the message itself or

information provided by the Inbound Data Exchange Service;4.4.6.6 An indicator of the routing destination determined for the message;4.4.6.7 An indicator of any transformations performed on the message and any

subsequent identifiers generated; and,4.4.6.8 Any errors encountered during the processing of the message.

4.5 Message Transfer Service - The Message Transfer Service will be responsible for repackaging the message in a format suitable for transfer to its destination, managing a send queue and sending the messages. This service will be highly dependent on the nature of the partner systems with which it must integrate and thus may be required to deal with multiple types of partner service (e.g., SOAP web service, RESTful web service, etc.).

4.5.1 Message Creation and Packaging - Message creation and packaging refers to the process of taking the payload that was received and potentially transformed and then adding whatever additional information is required in order to make the message acceptable to the service the message will be sent to. This is analogous to what partner systems do to create a message that will be sent to the eTS.

4.5.2 Each partner will create and publish an appropriate service that will listen for messages; the message creation and packaging component must be capable of inserting the PESC payload into generated messages that are compatible with all of these services, regardless of the service type.

4.5.3 Message Queuing - In order to deal with the possibility of a partner endpoint being unavailable for some period of time, e.g., due to a network or service outage, the eTS must have the capability to queue messages for some length of time, retrying until a time or attempt threshold is reached and an error message is generated and returned to the sender. This queue will be implemented within the Message Transfer Service.

4.5.4 Message Sending - The message sending component will be capable of taking a packaged message, adding any last-minute items (e.g., WS-Security-related elements for compliance with the security model of the downstream service) and actually sending the message to the listening endpoint of the partner service. This component will also be responsible for handling any synchronous replies or error messages returned by the exchange partner.

4.5.5 Logging - The Message Transfer Service should log all messages and all actions taken with each message. At a minimum the following should be logged:4.5.5.1 A timestamp for every event logged;

Page 27 of 35

4.5.5.2 The newly-generated UUID of the message for correlation with log messages;

4.5.5.3 The BatchID, if the BatchEnvelope element is present for correlation purposes;

4.5.5.4 An indicator of the message classification (e.g., Transcript Request Batch, Transcript Response Batch);

4.5.5.5 An indicator of the original message source;4.5.5.6 An indicator of the message destination;4.5.5.7 An indicator of any actions performed on the message and any subsequent

identifiers generated;4.5.5.8 A log entry for each attempt to send the message; and,4.5.5.9 Any errors encountered during the processing of the message, including

those returned by the downstream service.

4.5.6 Errors - The Message Transfer Service will be responsible for reporting errors back to the original sender of a message. This will necessarily include both any errors returned by the downstream exchange service when an attempt is made and errors specifying failure to forward the message due to an issue in communicating with the downstream service at all.

4.5.7 Although this will need to be formally decided as part of the business design, it is likely that the PESC Functional Acknowledgement schema can be used to generate error messages to be returned to the original message sender in the event that a payload cannot be delivered to the desired partner.

4.6 Administration Interface - Other than the Inbound Data Exchange interface, the administrative interface will be the only means of interaction with the eTS and the only one with a user interface. This interface is not intended to be full-featured, but must provide certain functionality in order to assure that the business requirements are met.

4.6.1 User Access - As described elsewhere in this document, user access to the Administration interface will be protected with username and password authentication and all interactions will take place over encrypted HTTPS connections.

4.6.2 Because there is not anticipated to be a large number of users with access to the administrative interface user management (e.g., user creation, modification and deletion) is expected to be either built-in to the eTS or leveraged from the platform upon which it is built.

4.6.3 Access levels are not expected to be complex and either a one- or two-tier access model should be implemented. In the case of a two-tier model, the only difference in access levels will be the ability to manage other users in the system.

4.6.4 Queue Viewing - Users with access to the Administrative interface will be granted the ability to view the queue of messages waiting to be sent to downstream partners. The information that expected to be presented in the interface includes:

4.6.4.1 Timestamp indicating when the message entered the queue;4.6.4.2 Destination of the message;4.6.4.3 Original source of the payload included in the message;

Page 28 of 35

4.6.4.4 Message type (e.g., Transcript Request Batch, Transcript Response Batch, Acknowledgement);

4.6.4.5 An indication of how many attempts to send the message have previously been made; and,

4.6.4.6 An indication of why the message has not yet been sent (e.g., brief error message from previous attempt).

4.6.5 Information about messages that have successfully sent should appear in the queue viewer for a period of time after sending. Similarly, messages that have failed permanently and will not be attempted again should also continue to appear for a time in this interface.

4.6.6 The interface will support sorting and filtering of the queue display.

4.6.7 Log Viewing - Similar to the Queue Viewing interface, a basic Log Viewing interface will be available to view the log messages generated by the eTS. This should allow for a more detailed examination of events in the system. Log messages should include all information available from the relevant log entries and the interface should support sorting and filtering of the log display.

4.6.8 Configuration - There are various elements of the operation of the system that are expected to be configurable. These include, but are not limited to:4.6.8.1 Service addresses for downstream partner exchange services;4.6.8.2 Message types for downstream partner exchange services;4.6.8.3 Number of retries to attempt when sending a message to a downstream

partner;4.6.8.4 Total queue time allowed when sending a message to a downstream

partner; and,4.6.8.5 The ability to disable data exchange.

4.6.9 An interface will be required to manage these configuration items through the web interface.

4.6.10 Logging - As with the rest of the application, the administrative Interface should log events that take place within its functional areas. This should include at minimum:

4.6.10.1 A timestamp for all events;4.6.10.2 An identifier for the user associated with the event; and,4.6.10.3 Any configuration changes made by the user.4.6.10.4 These logs should themselves be visible in the Log Viewing

interface.

4.6.11 Disabling Data Exchange - It is a common practice for message-passing systems to require a means by which data exchange can be disabled. This capability can be required for a myriad of reasons, including:

4.6.11.1 The detection of a security issue and the need to prevent the transport of personal information until the issue can be investigated and addressed;

Page 29 of 35

4.6.11.2 An issue with communications to one or more exchange partners that makes the acceptance of further messages problematic and likely to create a queue of messages waiting to be sent; and

4.6.11.3 In preparation for a service outage that will affect the eTS.

4.6.12 Towards the end of handling these situations and potentially others, it is recommended that the eTS have the following capabilities built-in to the administration interface with respect to disabling data exchange:

4.6.12.1 The ability to selectively disable delivery attempts to each exchange partner; and

4.6.12.2 The ability to disable the listening web service that receives messages from all exchange partners.

4.6.13 These capabilities should be mutually exclusive so that, e.g., if listening is disabled, queued messages can still be delivered until the queue is drained.

4.6.14 It is not anticipated as a requirement that the eTS be able to selectively disable receiving messages destined for a particular partner.

4.7 The primary interface via which the eTS will interface with EECD and PSI systems will be through SOAP Web Services as defined by the PESC DTS. This will involve both listening web services which will receive SOAP requests and provide synchronous responses, as well as web service client code, which will contact web services published by trading partners and process synchronous responses. As mentioned elsewhere in this document, a secondary transport may be determined to be in-scope; this will most likely be implemented via SFTP, however alternative transports will be considered.

4.7.1 An approach to simulating interfaces with multiple trading partners at one time will be necessary to ensure that all trading partners can develop their respective solutions simultaneously and to ensure that the solution being developed fits the multi-partner model required for production.

4.7.2 No restrictions will be placed on the platform or tools that are used to develop the interfaces other than that they must operate within a Microsoft Windows Server environment. With that said, it is expected that standard libraries and tools will be leveraged within the platform or development paradigm proposed (e.g., readily available SOAP libraries) and that an intention to write such components from scratch be well-justified.

5 Not in Scope5.1 The developer will not be responsible for developing any additional systems, processes or

procedures for the supplier (EECD) or any specific receivers (PSIs). Each institution will be responsible for developing its own interface to the eTS hub following the protocols as defined (section 1.1.2).

6 Ongoing support6.1 The proponent must be prepared to commit sufficient skills and resources to support the

system on an ongoing basis post-implementation. An initial 2-year agreement to provide support is expected, with NSCAT reserving an option to cancel after year 1, subsequent to

Page 30 of 35

an operational review at the 6-month point. Clear and ample notification will be provided as to whether the support will continue into the second year.

6.2 Please provide costing details of the skills and resources required to support all components of the system for a two year period as a separate element of the financial proposal.

7 Documentation7.1 Regardless of the implementation platform (e.g., custom build, SOA platform or COTS

product, the successful proponent will provide full documentation of the system and its support. This will include all relevant information to preparing the system, installing required software, building custom code, deploying components, configuration and any ongoing maintenance tasks.

8 Ownership of Source Code8.1 NSCAT will own any custom-built source code in perpetuity.

9 Training9.1 The developer will provide system administrators with comprehensive training on all

systems – custom built or off-the-shelf9.2 Outline your approach to training – delivery method. 9.3 All training materials will be available in PDF and/or online for future reference for new

employees.

10 Software licensing & maintenance10.1 The proponent must provide all relevant details pertaining to software licensing agreements

required for the proposed solution. This must include initial licensing costs as a separate budget item and, where possible, generic copies of any pertinent software license agreements.

10.2 The proponent must provide all relevant details pertaining to ongoing software maintenance costs that will be associated with the proposed solution, including the main elements of software maintenance and associated updates. Where possible, a generic copy of any such software maintenance agreements should be included in the proposal.

11 Software Warranty11.1 Provide details on all software warranty arrangements for any custom built elements.

Include warranty costs as a separate budget item. Where possible, include a generic copy of software warranty agreement.

12 Minimum Contractual Terms12.1 Ability to comply with Minimum Contractual Terms as listed in Appendix A.

E. MATERIAL DISCLOSURES

1. MATERIAL DISCLOSURES

1.1 Nova Scotia is home to eleven post-secondary education institutions, made up of ten universities and the Nova Scotia Community College. Together, these institutions deliver post-secondary education programs to more than 56,000 students.

Page 31 of 35

1.2 Working collaboratively, Nova Scotia’s publicly-funded universities and colleges have identified new approaches to information delivery and distribution that will improve service to students throughout the province.

1.3 The ultimate goal of the Electronic Transcripts System is to facilitate the application process to encourage Nova Scotia’s high school students to remain in the province to pursue post-secondary education. The system will support more people to stay and study here and make it more straightforward for more people to pursue higher education.

1.4 Phase 1 of the project will focus on the transfer of Nova Scotia high school transcripts from the eight provincial boards in the province to the post-secondary institution(s) to which the student is applying. By using the existing Provincial Student Number (PSN) institutions will be able to match high school transcripts with applications.

1.5 Built on the internationally accepted PESC XML standard, the exchange process will allow our institutions to improve turnaround time for high school applicants, eliminate the need for follow-up communications, and reduce the staff time spent manually entering grades into the student information systems.

1.6 The outcomes from this phase will include better service to students with faster turnaround of application decisions, reduction of paper transcript processing costs at the high school / school board, and timelier decision-making at the post-secondary institutions, which will free up staff time to provide more valuable service to students. The implementation of e-transcripts in Nova Scotia will keep our systems in line with other provinces, and ultimately allow our institutions to exchange transcripts with systems in those provinces.

1.7 In future phases it is anticipated that the system will be expanded to include the transfer of transcripts between post-secondary institutions, thereby improving turnaround time for applications from students that have previous post-secondary education experience in Nova Scotia. This process will also eliminate the risk of fraudulent transcripts, as the exchange will be direct between the institutions via secure channels.

1.8 NSCAT is leading this collaborative initiative, with active participation from all publicly funded post-secondary institutions in the province as project partners.

2. ESTIMATED BUDGET

2.1 Total estimated budget of approximately $200,000 Canadian Dollars (HST excluded).

F. OTHER MANDATORY REQUIREMENTSEach proponent is required to outline their compliance with the Appendix A – Minimum Contractual Terms. Any modification or addition to the Terms and Conditions contained within Appendix A should be marked on the document and submitted with your response.

G. RATED CRITERIA

The following is an overview of the categories and weighting for the rated criteria of the RFP.

The submission should be a concise explanation of the proponent’s qualifications to perform this work for NSCAT. In preparing a submission Proponents shall strictly follow the format as outlined below. If the stated space is insufficient (where listed), additional information may be included in a separate

Page 32 of 35

attachment. The intent of this restriction is to have similar length documents to compare proponents fairly.

Rated Criteria Category Weighting (%)Composition & History of Firm 15%Key Personnel 20%Methodology 30%Value Added Options 5%Pricing 10%Experience From Related Work 20%Total Points 100%

1. COMPOSITION & HISTORY OF FIRM – 15% 1.1. The proponent firm’s background including status, size, location of office, clients and principals,

areas of expertise, and preferred approach to assignments of this nature (2 pages).1.2. Description of the firm's character as established by completed projects (2 pages)1.3. What makes your company, not your product, different from your competitors (1 page)

2. KEY PERSONNEL – 20%2.1. The name, credentials and experience of the person who will lead the proponent’s development

team including specific references to similar projects for which she or he has been responsible (2 pages).

2.2. The names, credentials and experience of all other persons who will contribute to the proponent’s efforts, including all sub-consultants, on the project and a description of their roles (1 page per individual team member).

2.2.1. Comment on their suitability for this project based on the anticipated project needs and their related project experience and training

3. METHODOLOGY – 30%3.1. Provide description and methodology of services (software design, development, testing,

deployment and support process) to complete this project. Indicate the consultation process throughout this project with NSCAT and a timeframe which reflects the Proponent’s ability to comply with the dates indicated in the RFP.

3.1.1. Details should include estimates of hours for each stage of the project.

3.2. A description of the proponent’s intended work plan and the commitment to the project that each member of the proponent’s team is expected to devote to the work (4 pages).

3.2.1. Key milestones3.2.2. Risks we should be aware of (technical, schedule or otherwise)3.2.3. Project management approach including change management.

4. VALUE ADDED OPTIONS – 5%4.1. The Proponent is to identify any value added options, ideas, or services that are recommended

for adjustment beyond the standard requirements in the RFP. Details regarding both the implementation and ongoing contract should be provided accordingly. An explanation of “Why it is a Value Add” must be provided for each item. The corresponding cost impact of each value added option must be included. Follow the format below for each value added item:

4.1.1. Item # (1, 2, 3 etc.)4.1.2. Why is it a Value Add?4.1.3. Financial Impact ($)

5. PRICING – 10%

Page 33 of 35

5.1. Completion of Rate Bid Form (Appendix C) stipulating the total proposed project cost as a result of the breakout pricing which shall be included separately in the Proponents response.

5.2. Breakout Pricing:5.2.1. Submit detailed breakout pricing including unit rates and hourly fees for each stage of

the project.5.2.2. Unit rates and hourly fees shall be provided for all estimated costs to be used for any

changes to scope and potential future project phases.5.3. Proponents shall identify any pricing mechanisms (e.g. percentage not to exceed) to be used for

future contract term pricing on additional phases of the project (outside the of this proposals original scope).

5.4. Identify all costs for value added options (beyond the standard requirements in the RFP).5.5. Identify costs for ongoing support services as identified in Requirements section 1.6.

6. EXPERIENCE FROM RELATED WORK – 20%6.1. Please list at least three (3) clients that you have done business within the past. For each

reference, include the company’s name, mailing address, telephone number, contact name, and number of years as a customer. NSCAT may contact referenced clients during the evaluation process. Please include references comparable to our needs in your list of references, if possible.

6.2. A list of clients with similar needs.

7. PROPOSED CONTRACT7.1. In consideration of Appendix A - Minimum Contractual Terms the Proponent shall provide a copy

of their proposed contract with their proposal submission.

8. EVALUATION INTERVIEWS8.1. There may be a proposal presentation given by the proponent’s Key Personnel to NSCAT. The

list of proponents invited to present will be at NSCAT’s discretion. NSCAT will not be responsible for any costs incurred by proponents in preparing and submitting their proposals.

Page 34 of 35

APPENDIX F – BONFIRE INSTRUCTIONS

Submission Instructions for Suppliers

Please follow these instructions to submit via our Public Portal.

1. Prepare your submission materials:

Requested Information

Name Type RequirementAppendix B File Type: PDF (.pdf) RequiredAppendix C File Type: Word (.doc, .docx) RequiredAppendix D File Type: PDF (.pdf) RequiredAppendix E File Type: Word (.doc, .docx) Required

Please note that only ONE (1) file can be uploaded for each Requested Document above. If you upload more than one file into the same slot, the previous file will be overwritten.

Please do not embed any documents within your uploaded files, as they will not be accessible or evaluated.

2. Upload your submission at:

https://interuniversity.bonfirehub.ca/opportunities/3323

Your submission must be uploaded, submitted, and finalized prior to the Closing Time of Dec 23, 2015 2:00 PM AST. We strongly recommend that you give yourself sufficient time and at least ONE (1) hour before Closing Time to begin the uploading process and to finalize your submission.

Important Notes:

Each item of Requested Information is instantly sealed and will only be visible after the Closing Time.

Uploading large documents may take significant time, depending on the size of the file(s) and your Internet connection speed.

You will receive an email confirmation receipt with a unique confirmation number once you finalize your submission.

Each Requested Document has a maximum size of 100MB. Any Requested Document exceeding this limit will not be accepted.

Minimum system requirements: Internet Explorer 8/9/10+, Google Chrome, or Mozilla Firefox. Javascript must be enabled and Adobe Flash Player version 9+ installed.

Need Help?

Interuniversity Services Inc uses a Bonfire portal for accepting and evaluating proposals digitally. Please contact Bonfire at Support@GoBonfire.com for technical questions related to your submission. You can also visit their help forum at https://bonfirehub.zendesk.com/hc

Page 35 of 35