Ministry of Health Joint Solution Procurement for the Pan ... · d) “Business Requirements” means the functional requirements of public health communicable disease surveillance

Ministry of Health

Release Version Page i

Joint Solution Procurement for the

Pan-Canadian Public Health Communicable Disease Surveillance and Management Project

Project Coordinator Contact: All enquires related to this Joint Solution Request for Proposal, JSRFP# SATP-151 are to be directed in writing to the person set forth below, who will respond to all enquires if time permits. Information obtained from any other source is not official and should not be relied upon. Enquires and any responses will be recorded and may be distributed to all Proponents at the Project Coordinator’s option.

Brad Boquist Manager, Commercial Services

Strategic Acquisitions and Technology Procurement Branch Ministry of Labour and Citizens’ Services

email: [email protected] Facsimile: (250) 356-0846

Delivery of Proposals: Proposals must not be sent by mail, facsimile or email. Proposals and their envelopes must be clearly marked with the name and address of the Proponent, the JSRFP number, and the Project title. Ten (10) complete hard-copies and one electronic copy on CD, (documents may be PDF or Microsoft Word) must be delivered by hand or courier, and received prior to 2:00 pm, Pacific Time on, Thursday, October 27, 2005 at:

Ministry of Labour and Citizens’ Services Strategic Acquisitions and Technology Procurement Branch

c/o Commissionaires Desk 1st Floor, 548 Michigan Street

Victoria, British Columbia, V8V 1S3 Attention: Brad Boquist

Proponent Meeting: A Proponent Meeting will be held in: Vancouver – Wednesday, September 28, 2005 at 9:00am at the Fairmont Vancouver Airport, Vancouver International Airport, 3111 Grant McConachie Way, Richmond, BC. Please email the Project Coordinator Contact above, stating the number of attendees, if you plan to attend. Please note that this meeting is intended to provide further information and address questions regarding the Pan-Canadian Public Health Communicable Disease Surveillance and Management Project. Attendance is optional. Minutes will be taken. A copy of the recorded minutes and a list of attendees may also be posted as an Addendum to this JSRFP on BC Bid. Dial-in access may be provided. Instruction on how to dial-in can be requested from the Project Coordinator contact above.

Immediately following the Proponent Meeting, in the same location as the Proponent Meeting, there will be a demonstration of iPHIS and CIOSC. There will be no dial-in access available for the demonstration(s) but they will be videotaped. If the videos are of sufficient quality, copies will be made available to Proponents who request such from the Project Coordinator contact.

SATP-151

Release Version Page i

Summary

A system for the Pan-Canadian Public Health Surveillance Program is important to provide the ability to collect, share and analyze health information to assist public health officials to better manage public health outbreaks such as SARS, West Nile Virus, Avian Influenza and other communicable diseases. This System will enable Canada to better manage outbreaks through early detection, rapid verification and appropriate response to epidemic-prone and emerging disease threats.

The Government of Canada, through Canada Health Infoway, has provided funding to develop and deploy an integrated Solution for the Pan-Canadian Public Health Communicable Disease Surveillance and Management Project. The Solution will include a System that will support communicable disease case management, outbreak management, immunization management, materials and vaccine inventory management, alerts management, and workflow management processes as well as ongoing implementation, maintenance and support services. Once built, the System will be available to all Canadian Jurisdictions.

The Province of British Columbia, as Project Coordinator, has been identified as the entity to lead the procurement of this opportunity and has chosen to do so using the Joint Solution Procurement Process.

The key objectives of this procurement process and the resulting Final Contract are:

a) the design, development and on-going maintenance by the Contractor of a System that is expected to be implemented, in whole or in part, by every Jurisdiction in Canada;

b) the opportunity to utilize the services of the Contractor to integrate, implement, and possibly manage production instances of the System in one or more Jurisdictions; and

c) the Project Coordinator’s intention that the procurement process meets the Jurisdictions’ procurement policies and procedures, thus enabling them, at their sole discretion, to directly procure implementation and maintenance services for the deployment of the System in their respective jurisdictions.

A Proponent meeting is planned for Wednesday, September 28, in Vancouver, British Columbia.

SATP-151

Release Version Page ii

Table of Contents 1 DEFINITIONS AND ADMINISTRATIVE REQUIREMENTS .................................................................1

1.1 Definitions.....................................................................................................................1 1.2 JSP Process.................................................................................................................4 1.3 Proponent Qualification Phase.....................................................................................4

1.3.1 Terms of the Proponent Qualification Phase....................................................4 1.3.2 Joint Solution Definition Phase.......................................................................10 1.3.3 Due Diligence & Negotiation Phase ...............................................................11 1.3.4 Contract Negotiation Phase............................................................................11 1.3.5 Legal Consent ................................................................................................11 1.3.6 JSP Process Locations...................................................................................11 1.3.7 Exclusive Arrangements.................................................................................11 1.3.8 Proponents Who Are COTS Vendors.............................................................11

2 JOINT SOLUTION REQUEST FOR PROPOSAL INTRODUCTION....................................................12 2.1 Purpose of the JSRFP and JSP Process ...................................................................12

2.1.1 JSRFP Overview ............................................................................................12 2.1.2 Pan-Canadian Procurement ...........................................................................12 2.1.3 Project Commitment .......................................................................................13

3 DEFINING THE OPPORTUNITY.................................................................................................14 3.1 Overview And Business Challenges...........................................................................14

3.1.1 Project Overview ............................................................................................14 3.1.2 Business Challenges ......................................................................................16 3.1.3 Solution Procurement Objectives ...................................................................16

3.2 Strategic Intent and Scope of Procurement................................................................17 3.2.1 Original Project Intent .....................................................................................17 3.2.2 Revised Scope ...............................................................................................18 3.2.3 System Functional Components.....................................................................18 3.2.4 The Solution Elements ...................................................................................19 3.2.5 Funding Model................................................................................................26

3.3 System Architecture and Scope .................................................................................27 3.3.1 Operational Context........................................................................................27 3.3.2 Notional System Architecture .........................................................................27 3.3.3 Functional Scope............................................................................................34

3.4 Project Dependencies ................................................................................................41 3.4.1 Special Task Group ........................................................................................41 3.4.2 Standards Development .................................................................................41 3.4.3 Data Analysis Tools........................................................................................42 3.4.4 Jurisdiction Implementation Planning Projects ...............................................42

3.5 Project Execution - Roles and Responsibilities ..........................................................43 3.5.1 Project Governance and Oversight ................................................................43 3.5.2 Role of Infoway, through the Project Coordinator...........................................43 3.5.3 Role of the Steering Committee .....................................................................44 3.5.4 Role of the Design Working Group.................................................................44 3.5.5 Role of the Project Coordinator ......................................................................45 3.5.6 Role of the Jurisdictions .................................................................................45

SATP-151

Release Version Page iii

3.5.7 Project Time Frames ......................................................................................45 3.6 Policy and Compliance ...............................................................................................46

3.6.1 Privacy Legislation in Canada ........................................................................46 3.6.2 Other Legislation, Policies and/or Regulations that may Impact the Solution 49

3.7 Role of Project Coordinator Contractors in this Project ..............................................49 3.7.1 Use of Contractors..........................................................................................49

4 OVERVIEW OF THE END-TO-END JSP PROCESS......................................................................52 4.1 Overview.....................................................................................................................52

4.1.1 Tentative JSP Process Schedule ...................................................................53 4.2 Key Success Factors in the JSP Process ..................................................................53

4.2.1 Sharing of Risks and Rewards .......................................................................53 4.2.2 JSP Process Communications Protocol .........................................................53

5 DETAILED JSP PROCESS ......................................................................................................55 5.1 JSP Process...............................................................................................................55 5.2 Proponent Qualification Phase...................................................................................56

5.2.1 Approach and Timeline Overview...................................................................56 5.2.2 Role of Lead Proponent in the JSP Process ..................................................57 5.2.3 Release JSRFP & Evaluate Proposals...........................................................57 5.2.4 If only two short-listed Proponents .................................................................57 5.2.5 Restricted Documents Room..........................................................................57 5.2.6 Workshops......................................................................................................58 5.2.7 Proponent Concept Presentations..................................................................59 5.2.8 System Concept Demonstrations ...................................................................60 5.2.9 Preferred Proponents Selection .....................................................................60 5.2.10 Post Presentations and Debriefings .............................................................60

5.3 Joint Solution Definition Phase...................................................................................61 5.3.1 Discovery Cycle..............................................................................................62 5.3.2 Defining the Solution ......................................................................................62 5.3.3 Framing the Solution ......................................................................................62 5.3.4 Joint Solution Definition Phase Presentation..................................................63

5.4 Due Diligence & Negotiation Phase ...........................................................................64 5.4.1 Validate Commitment .....................................................................................64 5.4.2 Due Diligence Assessment.............................................................................64 5.4.3 Confirm Solution .............................................................................................65

5.5 Contract Negotiation Phase........................................................................................65 5.5.1 Deal Structuring..............................................................................................65 5.5.2 Negotiating and Drafting the Agreement ........................................................65 5.5.3 Finalize and Sign Contract .............................................................................66

5.6 Decision Points...........................................................................................................66 5.7 Evaluation Criteria ......................................................................................................66

5.7.1 Proponent Qualification Phase - Evaluation Criteria ......................................66 5.7.2 Joint Solution Definition Phase – Evaluation Criteria .....................................69

5.8 Proponent Response Section.....................................................................................69 5.8.1 Proposal Format Guidelines ...........................................................................69 5.8.2 Response Guidelines .....................................................................................70 5.8.3 Capability........................................................................................................70 5.8.4 Capacity..........................................................................................................71

SATP-151

Release Version Page iv

5.8.5 Commitment ...................................................................................................71 5.8.6 High Level Solution Vision..............................................................................72 5.8.7 Corporate References ....................................................................................73 5.8.8 Statement that Proponent is not in receivership or Insolvent .........................73 5.8.9 Signed Letter in substantially similar form to that of Appendix A....................73

APPENDICES ................................................................................................................................74 Appendix A – Proposal Covering Letter...............................................................................74 Appendix B – Joint Solution Definition Agreement ..............................................................75 Appendix C – How to Access the Project Extranet ..............................................................77 Appendix D – Requirements Definition ................................................................................78 Appendix E – iPHIS Analysis ...............................................................................................79 Appendix F – Initial Application Architecture Document ......................................................80 Appendix G – Initial Data Architecture Document................................................................81 Appendix H – Initial Logical Design Document ....................................................................82 Appendix I – Privacy Protection Schedule ..........................................................................83

SATP-151

Release Version Page v

Table of Figures Figure 1 – Participants ................................................................................................................14 Figure 2 – Examples of Jurisdictional Deployment Options........................................................25 Figure 3 – Notional System Architecture ....................................................................................28 Figure 4 – Business Processes ..................................................................................................30 Figure 5 – Component Model .....................................................................................................32 Figure 6 – Communicable Disease Case Management – High Level ........................................35 Figure 7 – Outbreak Management ..............................................................................................36 Figure 8 – Immunization Management .......................................................................................37 Figure 9 – Materials/Vaccine Inventory Management.................................................................38 Figure 10 – Health Alert Management ........................................................................................39 Figure 11 – Work Management ..................................................................................................40 Figure 12 – Interdependent Projects...........................................................................................41 Figure 13 – Participant Relationships .........................................................................................43 Figure 14 – JSP Process Overview ............................................................................................52 Figure 15 – Joint Solution Procurement Process........................................................................55 Figure 16 – Overall Timeframe ...................................................................................................56 Figure 17 – Joint Solution Definition Phase ................................................................................61

SATP-151

Release Version Page 1

1 DEFINITIONS AND ADMINISTRATIVE REQUIREMENTS

1.1 DEFINITIONS Throughout this JSP process, the following definitions will apply:

a) “3Cs” mean, capability ,capacity, and commitment to jointly achieve the best business outcomes for the Project;

b) “Ancillary Services” means services which the Jurisdictions may, at their sole discretion, contract with the Contractor to provide to implement and operate the System, including Jurisdictional Implementation Services and Application Management Services (see section 3.2.4.7);

c) “Application Management Services” means responsibility for operating the System in a Jurisdiction that may include hosting, service hours, availability, reliability, etc. as described in section 3.2.4.7.2;

d) “Business Requirements” means the functional requirements of public health communicable disease surveillance and management as described in sections 6.2 to 6.5 (inclusive) of Appendix D, as well as the related non-functional/technical requirements described in section 7 of Appendix D. It is anticipated that these requirements will be further refined, clarified and possibly modified through the Joint Solution Definition Phase and subsequent phases;

e) “CIOSC” means the national, secure, web-based communication system that allows for the dissemination of public health intelligence and is operated by the Canadian integrated outbreak surveillance centre;

f) “Colleagues” means public health professionals selected from the Jurisdictions that represent the eventual users of the System and who provide input to the Representatives during the evaluation process;

g) “Concept” means the high level concept relating to the Solution presented orally and in writing by a Proponent to the Project Coordinator during Stage 3 of the Proponent Qualification Phase;

h) “Contract Negotiation Phase” means Phase 4 of this JSP process which commences upon the Project Coordinator indicating that it is prepared to start negotiation of the Final Contract with the Successful Proponent and ends upon the execution of the Final Contract;

i) “Contractor” means the Successful Proponent who enters into the Final Contract with the Project Coordinator;

j) “Contractor Code” means software or tools developed or otherwise implemented by the Contractor in order to integrate the Products and otherwise to build the System;

k) “COTS” means commercially available, or ‘off the shelf’ software that provides some or all of the functionality of one or more Functional Components;

l) “COTS Vendor” means an entity that owns or has rights to distribute in Canada one or more COTS products;

m) “Due Diligence & Negotiation Phase” means Phase 3 of this JSP process which commences upon an invitation being extended by the Project Coordinator to the Successful Proponent to enter into Phase 3 of this JSP process and ends upon the Project Coordinator indicating that it is prepared to start negotiation of the Final Contract with the Successful Proponent;

n) “Electronic Health Record” or “EHR” has the meaning as outlined in section 3.1.1.3;

o) “Exclusive Arrangement” means an exclusive relationship between a Proponent and a COTS Vendor that precludes or otherwise limits the COTS Vendor from entering into a commercial relationship with other Proponents including, without limitation, precluding other Proponents from including the applicable COTS into their proposed Solution;

p) “Final Contract” means the written agreement executed by the Project Coordinator and the Successful Proponent resulting from completion of the Contract Negotiation Phase;

q) “Functional Components” means the conceptual units into which the functional requirements for the System have been grouped and are more particularly described in sections 3.2.3 and 3.3.2. The Functional Components will be operationally defined by the function interfaces which they expose to other Logical Components or systems. The Functional Components may or may not directly map to System Components. The System is expected to behave as if it literally contains the Functional Components. It is recognized that the appropriate number of Functional Components and their associated interfaces will be refined during the Joint Solution Definition Phase and subsequent phases;

SATP-151


r) “GOTS” means software products that have been produced and/or owned by Jurisdictions or other public sector entities and which provide some or all of the functionality of one or more Functional Components;

s) “Information Control Office” means the JSP process information management control structure that is established to control the flow of information between the Project Coordinator and Preferred Proponents during the Joint Solution Definition Phase and subsequent phases of the JSP process;

t) “Infoway“ means Canada Health Infoway Inc.;

u) “Intellectual Property” means any and all patents, trademarks rights in designs ,trade, business or domain names, copyright, rights in concepts, inventions, know how, trade secrets and all other intellectual property rights which may now or in the future exist;

v) “iPHIS” means the integrated public health information system that is in use in several Jurisdictions and incorporates a variety of functional modules ranging from case management, immunization management, outbreak management and aspects of health surveillance;

w) “Joint Solution Definition Agreement” means the agreement that will be entered into by the Project Coordinator and each Preferred Proponent prior to the Joint Solution Definition Phase which will include the provisions described in Appendix B;

x) “Joint Solution Definition Phase” means Phase 2 of this JSP process which commences upon invitations being extended to Preferred Proponents to enter into Phase 2 of this JSP process and ends upon an invitation being extended by the Project Coordinator to one of the Preferred Proponents to become the Successful Proponent;

y) “JSP process” means the Joint Solution Procurement process for the Project;

z) “JSRFP” means this joint solution request for proposal document and any amendment to it;

aa) “Jurisdiction” means a province or territory in Canada or the federal government of Canada;

bb) “Jurisdictional Implementation” means the implementation of one or more parts of the System by a Jurisdiction or multiple Jurisdictions or a public body related thereto including provincial health authorities and health related agencies, along with the potential utilization by the Jurisdiction of other aspects of the Solution;

cc) “Jurisdictional Implementation Services” means Jurisdiction-specific planning, rollout,

implementation and integration services provided by the Contractor, either directly or in support of another contractor, as particularly described in section 3.2.4.7.1;

dd) “Letter of Intent” means the letter of intent that will be entered into by the Successful Proponent at the commencement of the Due Diligence & Negotiation Phase;

ee) “Logical Components” means the combined set of Functional Components and Support Components which have been conceived to organize the functions of, and the interfaces to, the System;

ff) "must” or “mandatory” in respect of section 1 Definitions and Administrative Requirements and section 5.7.1.1 Mandatory Criteria means a requirement that must be met in order for a Proposal to receive consideration;

gg) ”Pan-Canadian” is a term used herein to include all of the Jurisdictions;

hh) “Pan-Canadian Public Health Surveillance Program” is a strategy to improve health surveillance across Canada and is comprised of several parallel projects as described in section 3.4, including this Project;

ii) “Preferred Proponents” means the Proponents who are invited by the Project Coordinator to advance to the Joint Solution Definition Phase and who sign the Joint Solution Definition Agreement;

jj) “Products” means COTS, GOTS and supporting commercial software included among the System Components;

kk) “Project” means the Pan-Canadian Public Health Communicable Disease Surveillance and Management Project beginning with the JSP process and continuing through Jurisdictional Implementations and throughout the life of the Final Contract;

ll) “Project Coordinator” means Her Majesty the Queen in Right of the Province of British as represented by the Minister of Health;

mm) “Project Extranet” means an access-controlled website that will be established by the Project Coordinator for the purposes of disseminating information as more particularly described in Appendix C;

nn) "Proponent" means the entity that submits, or intends to submit, a Proposal in response to this JSRFP, and where the Proposal consists of a joint submission or contemplates the use of Subcontractors, then the Proponent is the lead entity or prime-contractor responsible for the Proposal, as more particularly described in section 1.3.1.25;

SATP-151


oo) “Proponent Qualification Phase” means Phase 1 of this JSP process which commences upon the release of this JSRFP and ends upon invitations being extended by the Project Coordinator to Preferred Proponents to enter into the Joint Solution Definition Phase;

pp) “Proposal” means the written submission required for Stage 1 of the Proponent Qualification Phase;

qq) “Reference Implementation” means a stand-alone operational instance of the System which provides the full functionality of the System in an environment which is accessible to all Jurisdictions;

rr) “Representatives” means public health professionals who represent Colleagues during evaluation for this JSP Process;

ss) “Restricted Documents Room” means the documents room the Project Coordinator may establish and, if so established, will be made available to short-listed Proponents as more particularly described in section 5.2.5;

tt) “should” or “desirable” in respect of evaluation criteria means a requirement having a significant degree of importance to the objectives of the Project;

uu) “Solution” means the services and deliverables as defined during the Joint Solution Definition Phase in response to the Project Coordinator’s and Jurisdiction’s business goals and desired outcomes for the Project; and will include the System and the services that the Contractor could deliver as more particularly described in section 3.2.4;

vv) “Stage 1” means the initial stage of the Proponent Qualification Phase during which Proposals will be created by Proponents and evaluated by the Project Coordinator;

ww) “Stage 2” means the second stage of the Proponent Qualification Phase during which up to four Proponents will be asked to participate in separate Workshops with the Project Coordinator and be provided with

access to any Restricted Documents Room that is established;

xx) “Stage 3” means the final stage of Proponent Qualification Phase during which the Proponents who participated in the Workshops will present their Concepts to the Project Coordinator, both orally and in writing;

yy) ”Subcontractors” mean entities that a Proponent intends to contract with as part of the Solution and entities that the Contractor does in fact contract with to perform certain services in respect of the Final Contract;

zz) “Successful Proponent” means the Preferred Proponent who is invited by the Project Coordinator to advance to the Due Diligence & Negotiation Phase and who signs a Letter of Intent;

aaa) “Support Components” means the conceptual units into which the various supporting requirements have been grouped. The Support Components will be operationally defined by the interfaces which they expose to other Logical Components or systems. The Support Components may or may not directly map to System Components. The System is expected to behave as if it literally contains the Support Components. It is recognized that the appropriate number of Support Components and their associated interfaces will be refined during the Joint Solution Definition Phase and subsequent phases;

bbb) “System” means the software deliverable of the Solution that supports the Business Requirements, being comprised of the System Components along with associated documentation that is prepared in conjunction therewith;

ccc) “System Components” means the Products and Contractor Code; and

ddd) “Workshops” means the working sessions between a Proponent and the Project Coordinator during Stage 2, as more particularly described in section 5.2.6.

SATP-151


1.2 JSP PROCESS This JSP process will consist of four (4) phases: the Proponent Qualification Phase; the Joint Solution Definition Phase; the Due Diligence & Negotiation Phase; and the Contract Negotiation Phase.

1.3 PROPONENT QUALIFICATION PHASE

1.3.1 TERMS OF THE PROPONENT QUALIFICATION PHASE

The following terms apply to the Proponent Qualification Phase of this JSRFP. In consideration of the Project Coordinator’s preparation of this JSRFP document, in conducting this JSP process and the Proponents’ opportunity to submit a Proposal, each Proponent hereby acknowledges and agrees by submitting a Proposal in response to this JSRFP that the Proponent is accepting and agreeing to be bound by the terms of this JSRFP. Provisions in a Proposal that conflict or are inconsistent with any of the terms of this JSRFP shall be of no force or effect.

1.3.1.1 Process of the Proponent Qualification Phase The Proponent Qualification Phase will consist of three (3) stages:

a) Stage 1 – During this stage, Proponents will submit Proposals in accordance with the terms of this JSRFP. Each Proposal will be evaluated. Up to four Proponents will advance to Stage 2 of the Proponent Qualification Phase based upon the evaluation of the Proposals;

b) Stage 2 – During this stage, Workshops will be held with up to four Proponents who have advanced from Stage 1. Immediately prior to the Workshops, Proponents may be provided with access to the Restricted Documents Room that may be established. Subject to the terms of this JSRFP, each of the Proponents from Stage 2 will advance to Stage 3 of the Proponent Qualification Phase; and

c) Stage 3 - During this stage, each of the Proponents who have advanced from Stage 2 will present their Concepts. Up to two Proponents will be selected to become Preferred Proponents and will advance to the Joint Solution Definition Phase.

Neither the acceptance by the Project Coordinator of any Proposal, the conducting of any Workshop nor the receipt by the Project Coordinator of any Concept in any format whatsoever shall under any circumstances cause any express or implied commitment or undertaking on the part of the Project Coordinator to advance any Proponent to the next Stage or Phase, to receive any presentation from a Proponent, to acquire services, to undertake any form of transaction or to continue this JSP process.

1.3.1.2 Amendments and Additional Information All subsequent information that the Project Coordinator intends to make generally available to Proponents regarding this JSRFP process, including changes made to this JSRFP will be posted on the BC Bid website (www.bcbid.ca) or the Project Extranet until closing. After the closing of this JSRFP, only short-listed Proponents will have access to the Project Extranet.

SATP-151


Proponents are advised to monitor these sites to ensure they have the most recent information.

1.3.1.3 Enquiries All enquiries related to this JSRFP are to be directed, in writing, to the person set forth below. Information about this JSRFP obtained from any other source is not official and should not be relied upon. Enquiries and responses will be recorded and may be distributed to all Proponents at the Project Coordinator’s option.

Brad Boquist E-Mail: [email protected]

Fax: (250) 356-0846

The Project Coordinator has no obligation to ensure consistency between each of the Workshops or each of the Concept presentations. Accordingly, during Stages 2 and 3, questions and responses exchanged between the Project Coordinator and one Proponent may differ from questions and responses exchanged between the Project Coordinator and any other Proponent. The Project Coordinator does not intend to share the questions or answers that are exchanged with a Proponent during Stages 2 and 3 with any other Proponents; however, if a Proponent makes a request for information during a Workshop that the Project Coordinator determines to be a request for basic information that should be made available to all Proponents, then the Project Coordinator, in its sole discretion, may distribute that basic information to all Proponents participating in the Workshops.

1.3.1.4 Closing Date and Time Ten (10) complete hard-copies and one electronic copy on CD, (documents may be PDF or Microsoft Word) must be delivered by hand or courier, and received prior to 2:00 PM, Pacific Time, on Thursday, October 27, 2005 at:

Ministry of Labour and Citizen’s Services Strategic Acquisitions and Technology Procurement Branch

c/o Commissionaires Desk 1st Floor, 548 Michigan Street

Victoria, B.C., V8V 1S3 Attention: Brad Boquist

Proposals must not be sent by mail, facsimile or email. Proposals and their envelopes must be clearly marked with the name and address of the Proponent, the JSRFP number, and the Project title.

1.3.1.5 Late Proposals Proposals will be marked with their receipt time at the closing location described in the cover page of this JSRFP. Late Proposals will not be accepted and will be returned to the Proponent. In the event of a dispute, the Proposal receipt time as recorded at the closing location will prevail whether accurate or not.

SATP-151


1.3.1.6 Signed Proposals The Proposal must be signed by a person authorized to sign on behalf of the Proponent and to bind the Proponent to the terms of this JSRFP and any statements made in response to this JSRFP. The Proponent must ensure that its Proposal includes a letter or statement(s) substantially similar in content to the sample Proposal Covering Letter provided in Appendix A.

1.3.1.7 Changes to Proposals By submission of a clear and detailed written notice, the Proponent may amend or withdraw its Proposal prior to the closing date and time. The Proponent cannot change the wording of its Proposal after closing and no words or comments will be added to the Proposal after closing unless requested by the Project Coordinator for purposes of clarification, or to correct minor defects pursuant to section 1.3.1.15 below.

1.3.1.8 Eligibility A Proposal will not be evaluated if the Proponent’s current or past corporate or other interests may, in the Project Coordinator’s opinion, give rise to a conflict of interest in connection with the Project. Subcontracting to any firm or individual whose current or past corporate or other interests may, in the Project Coordinator's opinion, give rise to a conflict of interest in connection with the Project or ongoing delivery of Solution services, will not be permitted. The Project Coordinator may also remove a Proponent from any later stage of the Proponent Qualification Phase where the Project Coordinator determines, in its opinion, that such Proponent's current or past corporate or other interests may give rise to a conflict of interest in connection with the Project, or ongoing delivery of Solution services. Any such determination by the Project Coordinator of a conflict of interest shall be final and shall be based upon such information as the Project Coordinator, in its sole discretion, determines to be relevant.

It is not the Project Coordinator’s intent that BearingPoint LP or Sierra Systems Group Inc. be conflicted from bidding on this opportunity as a result of their prior involvement on this Project (see section 3.7). In addition, the Project Coordinator does not anticipate that the Contractor would be precluded from competing on opportunities for Jurisdictional Implementations. Notwithstanding the forgoing, the Project Coordinator will not be liable for any preclusion that the Contractor may have on competing for Jurisdictional Implementations that may be determined by a Jurisdiction.

1.3.1.9 Evaluation Committee The evaluation of Proposals and Stage 3 Concepts will be undertaken by a committee formed by the Project Coordinator, which committee may include Representatives, and employees and contractors of the Project Coordinator, Infoway and other Jurisdictions. The evaluation committee may consult with such technical advisors, including financial, legal, operating, marketing and other experts, as the evaluation committee may, in its discretion, determine to be necessary. The evaluation committee may be expanded, or composition altered, by the Project Coordinator in its sole discretion.

SATP-151


1.3.1.10 Evaluation The Project Coordinator will check Proposals against the mandatory criteria. Proposals that do not meet all of the mandatory criteria will be rejected without further consideration. Proposals that do meet all of the mandatory criteria will also be evaluated by the evaluation committee against the desirable criteria.

The Concepts will be evaluated against Stage 3 evaluation criteria. The Project Coordinator will finalize the evaluation criteria for Stage 3 prior to opening of the Proposals and will distribute the finalized evaluation criteria to the short-listed Proponents.

Representatives may receive input from Colleagues regarding Products during the JSP process, but Colleagues will not be directly participating in, or voting in, the evaluation process.

1.3.1.11 Debriefing At the conclusion of Stage 1, Proponents who are not invited to advance to Stages 2 and 3 of the Proponent Qualification Phase will be so notified in writing, and may then request a debriefing meeting with the Project Coordinator, which will be scheduled by the Project Coordinator after the Final Contract has been executed. Proponents who will not be invited to participate in the Joint Solution Definition Phase will be so notified in writing at the end of the Proponent Qualification Phase, and may then request a debriefing meeting, which will be scheduled by the Project Coordinator following the execution of the Final Contract.

1.3.1.12 Proponent Expenses Proponents are solely responsible for their own expenses in preparing a Proposal and for participating in any or all Stages of the Proponent Qualification Phase including, without limitation, if the Project Coordinator elects to reject all Proposals or to not ask any Proponents to advance to the Joint Solution Definition Phase. In no event will the Project Coordinator, Infoway or any Jurisdictions, or any of their employees, representatives or contractors, the Colleagues or Representatives be liable to any Proponent for any claims, whether for costs or damages incurred by the Proponent in preparing the Proposal, or in preparing for or participating in Stages 1, 2 or 3, or any phase of this JSP process, or for any loss of opportunity, loss of anticipated profit in connection with any Final Contract (whether or not the Final Contract is awarded to the Proponent or at all), or for any other loss, damage or claim of any kind whatsoever relating in any way to all or any portion of this JSRFP or the JSP process.

1.3.1.13 Limitations of Damage Further to the preceding section, the Proponent, by submitting a Proposal, agrees that it will not claim for any loss, costs or damages, for whatever reason, relating to the Final Contract (whether or not the Final Contract is awarded to the Proponent or at all) or in respect of the Proponent’s preparation for or participation in, or failure to be invited to participate in, any one or more Stage or phase of this JSRFP or the JSP process. If, contrary to the terms of this JSRFP the Project Coordinator, Infoway or a Jurisdiction, or any of their employees, representatives or contractors, a Colleague or a Representative, should be held liable for any reason whatsoever (whether in contract or in tort) for any of the foregoing losses, costs or damages, then such losses, costs or damages shall not, in any circumstances, exceed an

SATP-151


amount equivalent to the lesser of (a) reasonable costs incurred by the Proponent in preparing its Proposal; and (b) CDN$100,000.

1.3.1.14 Right of the Project Coordinator to Check References The Project Coordinator reserves the right to verify a Proponent’s references at any Stage in the Proponent Qualification Phase or in any subsequent Phase of this JSP process. As a courtesy, the Project Coordinator may notify the Proponent in advance of calling references.

1.3.1.15 Correction of Minor Defects The Project Coordinator reserves the right, in its sole discretion, to correct minor defects in the Proposals.

1.3.1.16 Acceptance of Proposals This JSRFP should not be construed as an agreement to purchase goods or services. The Project Coordinator is not bound to enter into any contract with any Proponent including, without limitation, any Proponent who submits the lowest priced Proposal or Concept. Proposals and Concepts will be assessed in light of the evaluation criteria described or referenced in this JSRFP. The Project Coordinator will be under no obligation to receive further information, whether written, oral, or otherwise, from any Proponent at any Stage in the Proponent Qualification Phase.

1.3.1.17 Restriction on Contact/No Lobbying Proponents must not attempt to communicate about this Project directly or indirectly with any Representative, Colleague or any employee, representative or contractor of the Project Coordinator, the Jurisdictions or Infoway, including the evaluation committee, during the Proponent Qualification Phase or discuss the Project described in this JSRFP with members of the public or the press, other than as expressly directed or permitted by the Project Coordinator during this Project.

1.3.1.18 No Contract By submission of a Proposal, Proponents agree that no Proponent will acquire any legal or equitable rights or privileges relative to the Project described in this JSRFP prior to the full execution of a Final Contract. Further, the Project Coordinator reserves the right not to enter into a Final Contract with any of the Proponents.

1.3.1.19 Liability for Errors While the Project Coordinator has used considerable efforts to ensure an accurate representation of information in this JSRFP, and provided pursuant to this JSP process, the information is supplied solely as a guideline for Proponents. The information is not guaranteed or warranted to be accurate by the Project Coordinator, nor is it necessarily comprehensive or exhaustive. Nothing in this JSRFP is intended to relieve Proponents from forming their own opinions and conclusions with respect to the matters addressed in this JSRFP.

SATP-151


1.3.1.20 Modification of Process or Project The Project Coordinator reserves the right to modify this JSP process, JSRFP or the scope of the Project being tendered at any time at its sole discretion. This includes, but is not limited to, the right to extend the closing time, change the number of Proponents asked to advance to any Stage or Phase of this JSRFP or JSP process, re-commence a Stage or Phase of this JSRFP or JSP process, alter the Project requirements or make other changes to the process or to a term set out in this JSRFP. If a modification is communicated to the Proponents prior to closing time, it is the Proponents’ sole responsibility to ensure that they make appropriate use of that information.

1.3.1.21 Cancellation of the JSRFFP, the JSP Process or the Project In addition to the rights set out in section 1.3.1.20, the Project Coordinator reserves the right, in its sole discretion to cancel this JSRFP, the JSP process or the Project at any time. This expressly includes, but is not limited to, because the Project Coordinator is unable to adequately negotiate certain procurement and Final Contract risk management issues with Infoway and the other Jurisdictions prior to the closing time of the JSRFP.

1.3.1.22 Ownership of Proposals and Confidentiality Subject to the qualifications otherwise set out herein, all Proposals and Concepts will be received and, to the extent reasonably possible, held in confidence by the Project Coordinator and the Project Coordinator hereby advises Proponents that it does not intend to share a Proponent’s Concept with the other Proponents. Proponents acknowledge that the following qualifications and provisions apply to any information in any media or format that Proponents submit or make available to the Project Coordinator, Infoway or any Jurisdiction (including any employees, representatives or contractors thereof) in respect of or related to this Project:

a) All documents, and electronic media, including the Proposals and Concepts, submitted to the Project Coordinator become the property of the Project Coordinator and will be held in confidence subject to the British Columbia Freedom of Information and Protection of Privacy Act. The Project Coordinator may make such copies as the Project Coordinator may require for evaluation purposes;

b) The Project Coordinator will in no way be liable or responsible if another Proponent suggests a framework or idea similar to one contained in a Concept that was originally submitted by another Proponent;

c) The Project Coordinator reserves the right to suggest alternative Concept structures (including alternative Products) that may or may not be otherwise proposed by another Proponent;

d) Proponents acknowledge that the Pan-Canadian nature of this Project does present a lower level of confidentiality than in previous JSP processes and as a result the Project Coordinator is not responsible for any disclosure of information that a Proponent might otherwise expect to be held in confidence;

e) In keeping with the Project Coordinator’s general objective of transparency, the Proponents acknowledge that the Project Coordinator will generally not agree to keep any portion of the Final Contract in confidence unless the information is of a highly sensitive nature and then only to the extent that such restrictions would only apply to small portions of the Final Contract; and

SATP-151


f) The Project Coordinator’s principles with respect to confidentiality in the Final Contract are anticipated to evolve over time. Proponents will be advised of any changes to the extent that such changes affect the Proponent in respect to this JSP process and the Final Contract.

1.3.1.23 Use of JSRFP Document No portion of this JSRFP document, nor any information supplied by the Project Coordinator in relation to this JSRFP, may be used or disclosed by a Proponent in any manner other than for the sole purpose of submitting a Proposal and participating in this JSP process.

1.3.1.24 Working Language of the Project Coordinator The working language of the Project Coordinator is English and all responses to this JSRFP must be in English.

It is the expectation that while the procurement process will be conducted in English, the System and select other deliverables will be bilingual (i.e. French and English).

1.3.1.25 Proposals with Joint Submissions or Subcontractors A Proponent may submit a Proposal consisting of a joint submission by the Proponent together with one or more other entities, or which proposes the use of Subcontractors in the Final Contract. In either case, the Proponent will be the only party responsible to the Project Coordinator for the Proposal, will act as the liaison and main contact with the Project Coordinator in respect of the Proposal, this JSRFP and JSP process, and will take overall responsibility for the successful inter-relationship among the Proponent and the other entities involved in the joint submission, or contemplated as Subcontractors, as the case may be. This includes the Proponent keeping its Subcontractors fully apprised of the JSP process and negotiations and information exchanged in respect thereof along with the Proponent making all reasonable efforts to ensure that its contractual and business relationships with its Subcontractors do not adversely affect the timing of the JSP process or the Solution ultimately determined as part of this JSP process. The Successful Proponent, upon becoming the Contractor, will be responsible for the acts and omissions of its Subcontractors in providing the services. Accordingly, the Proponent who responds to this JSRFP should be the lead entity who has the capacity and will be able to demonstrate to the Project Coordinator that it has the ability (financial and otherwise) to accept and fulfill this responsibility. During the JSP process, there will be no switching of the lead entity that is the Proponent with a Subcontractor or other entity. The Project Coordinator will have no obligations with respect to those other entities or Subcontractors under this JSRFP, JSP process, the Final Contract or otherwise.

1.3.2 JOINT SOLUTION DEFINITION PHASE

Prior to participation in the Joint Solution Definition Phase, the Project Coordinator will enter into a Joint Solution Definition Agreement with each of the Preferred Proponents, which will include the provisions described in Appendix B as well as such other provisions as may be determined by the Project Coordinator, in its discretion, to be necessary, desirable or useful.

SATP-151


1.3.3 DUE DILIGENCE & NEGOTIATION PHASE The Due Diligence & Negotiation Phase will substantially follow the process described in section 5.4.

1.3.4 CONTRACT NEGOTIATION PHASE

The Contract Negotiation Phase will substantially follow the process described in section 5.5.

1.3.5 LEGAL CONSENT McCarthy Tetrault LLP has provided and continues to provide legal advice to the Project Coordinator in respect of this Project. By submitting a proposal each Proponent and its Subcontractors hereby expressly consent to McCarthy Tetrault LLP continuing to act for the Project Coordinator notwithstanding any unrelated solicitor-client relationship that each Proponent or its Subcontractors may have or previously had with McCarthy Tetrault LLP.

1.3.6 JSP PROCESS LOCATIONS The Proponent Meeting will be in Vancouver, BC and all other aspects of the JSP process are currently set to take place in Victoria, BC. Due to the Pan-Canadian nature of the Project, however, the Project Coordinator reserves the right to schedule some aspects of the JSP process in different locations in Canada.

1.3.7 EXCLUSIVE ARRANGEMENTS

Proponents shall not, whether before or after the date of posting this JSRFP, enter into Exclusive Arrangements in respect of or related to this Project. To the extent that a Proponent has, or reasonably believes that it has, a pre-existing Exclusive Arrangement then the Proponent shall (a) disclose such Exclusive Arrangement as part of its Proposal including particulars regarding the specific limitations that restrict a COTS Vendor from participating in other Solutions; and (b) waive, for the benefit of such COTS Vendor, all rights that the Proponent has with respect to such Exclusive Arrangement; and (c) where the Proponent has commitments or obligations with respect to such Exclusive Arrangement, make reasonable commercial efforts to negotiate a waiver of such commitments or obligations from the applicable COTS Vendor.

Proponents shall make reasonable commercial efforts to ensure that any COTS Vendors that form part of their Proposal or Solution shall also work equitably with any other Proponents that want to collaborate with such COTS Vendors as part of their Proposal or Solution.

1.3.8 PROPONENTS WHO ARE COTS VENDORS

Where a Proponent is a COTS Vendor, then such Proponent shall, upon notice from the Project Coordinator, make its COTS product available to all other Proponents on terms that are at least as favourable as the terms upon which such COTS product is incorporated into its own Proposal.

SATP-151


2 JOINT SOLUTION REQUEST FOR PROPOSAL INTRODUCTION

2.1 PURPOSE OF THE JSRFP AND JSP PROCESS

2.1.1 JSRFP OVERVIEW

Through Infoway, the Government of Canada has provided funding for Canada’s provincial, territorial and federal governments to develop an integrated Pan-Canadian Public Health Communicable Disease Surveillance and Management Solution System.

The purpose of this JSRFP is to identify Proponents with the optimum combination of the capability, capacity, and commitment (3Cs) to be the Contractor to the Project Coordinator, and optionally to the Jurisdictions, to develop and assist in implementing an integrated Pan-Canadian health surveillance solution.

The Project Coordinator has been identified as the entity to lead the procurement of this opportunity and to work with the Contractor to develop and implement the System in a Reference Implementation.

The Solution may be the result of integrating existing COTS components, objects and business rules from GOTS systems, and Contractor Code.

The key objectives of this procurement process and the resulting Final Contract are:

a) the design, development, on-going maintenance, support and enhancement by the Contractor of a System that may be implemented, in whole or in part, by every Jurisdiction in Canada; and

b) the opportunity to utilize the services of the Contractor to integrate, implement, and possibly manage production instances of the System in one or more Jurisdictions.

2.1.2 PAN-CANADIAN PROCUREMENT

It is the intent of the Project Coordinator that this procurement:

a) meets each of the Jurisdiction’s procurement policies and procedures, thus enabling them to directly procure and implement the System, in whole or in part, that is developed as a result of this JSP process; or

b) can be exempt from any policy restrictions to the contrary due to the Pan-Canadian nature of the Project and the need for Jurisdictions to collaborate so as to achieve their objectives.

Use of the Final Contract that results from this procurement to implement the System in a Jurisdiction, however, is discretionary. This procurement does not limit any Jurisdiction’s right to perform a separate procurement process for its own Jurisdictional Implementation.

It is the intent that this procurement process may be used to secure the services of the Contractor to implement the System in one or more Jurisdictions.

SATP-151


2.1.3 PROJECT COMMITMENT A core team of experts are dedicated to this Project, supported by the executive Project co-sponsors who are the BC Deputy Minister of the Ministry of Health, Penny Ballem, and Richard Alvarez, President and Chief Executive Officer of Infoway.

In addition, the Project is overseen by a steering committee co-chaired by Ron Danderfer, Assistant Deputy Minister, Knowledge Management and Technology, BC Ministry of Health, and Trevor Hodge, Senior Vice-President, Investment Strategies and Alliances, Infoway. The Pan-Canadian steering committee is composed of federal, provincial and territorial public health and information technology representatives, as well as other leading health organizations’ representatives.

Through this JSP process, the Project Coordinator will endeavor to identify the Successful Proponent with whom to negotiate a Final Contract. The Project Coordinator and its representatives are looking for a Contractor to produce a creative, functionally and technically robust, easy to implement Solution that can be leveraged and rolled out in multiple Jurisdictions across Canada. The Project Coordinator is looking to establish a long-term relationship with the Contractor. The Project Coordinator will require the Contractor to build, test and integrate the System in a development/test environment and maintain the System over the life of the Final Contract.

In addition, subject to the decision by each Jurisdiction, the Project Coordinator may request that the Contractor directly negotiate in good faith with one or more Jurisdictions, to contract for Ancillary Services.

This space intentionally left blank.

SATP-151


3 DEFINING THE OPPORTUNITY

3.1 OVERVIEW AND BUSINESS CHALLENGES

3.1.1 PROJECT OVERVIEW

The Project is intended to produce a design, technical architecture and plan to build and/or integrate a System that can provide high quality, timely surveillance data at the regional, provincial/territorial and federal levels from feeder systems that support health delivery. This Solution developed as part of the Project will include detailed design, development and system integration phases. Ultimately the System will be appropriately integrated into the Electronic Health Record architecture and ‘infostructure’, and will make health surveillance information available to authorized users regardless of where one enters the health system or resides in Canada.

Figure 1 provides a high-level business overview of the main participants with direct or indirect involvement in public health communicable disease surveillance and management, with a particular focus on communicable disease. The intent is not to show detailed data flows but rather how the participants generally inter-relate.

Communicable DiseaseSurveillance and

Management

Health CareProviders

Treatment,Results

Diagnosis,Tests Requests,Treatment Plans

Alerts, Feedback,

Labs

Public HealthAction

ResponseAgencies

HealthAgencies

EnvironmentalContacts

PatientContacts

Alerts &Feedback

Detailed DataAnalysisCollect Lab &

Case DataPreliminary

Analysis

TestResults

TestRequests

Inform &Question

Alerts & Feedback

Investigation,Action,

Follow-up

Investigation,Action,

Follow-up

SuspectCondition,Illness or

Symptoms

ResearchAgencies

ResearchResults

Clinical Data

Information

Population

Generalinformation

Demographics

IndividualPatient

Illness orSymptoms

Figure 1 – Participants

Health surveillance is a collection of processes that work together to prevent or reduce the burden of disease in the population, through better intelligence. While surveillance is a key component of the Solution, it is important to note that it is broader than the name implies, and

SATP-151


includes communicable disease case management, outbreak management, immunization management and alerts management as explained in more detail below.

Today, there is considerable variability at the federal, provincial, territorial, and regional levels pertaining to how and by whom public health services are delivered. Variability also exists in the degree to which this work is supported by appropriate technologies and the extent to which information can be shared and leveraged among and between Jurisdictions.

3.1.1.1 Key Business Drivers The Pan-Canadian Public Health Surveillance Program has been undertaken in response to a number of key business drivers:

a) emergence of new threats to public health (e.g. Severe Acute Respiratory Syndrome (SARS), West Nile Virus, Avian Influenza Virus, etc.) that demand new approaches to detection and control;

b) public concern that public health authorities’ ability to respond to communicable disease threats may be inadequate;

c) increased demand for preventative measures (e.g., influenza immunization); and d) recent reports outlining lessons learned from recent threats and possible preventive

measures i. ‘Report of the Walkerton Inquiry – Events of May 2000 and related issues’ – 2002, ii. ’Learning from SARS: Renewal of Public Health in Canada (Naylor Report)’ – 2003,

and iii. ‘The SARS Commission Interim Report: SARS and Public Health in Ontario

(Walker Report)’ – 2004.

3.1.1.2 System Purpose When complete, the System will enhance the ability of public health officials to work within and across multi-disciplinary teams, regions, provinces and territories in order to:

a) improve health outcomes related to communicable diseases; b) identify, investigate and manage communicable disease cases and contacts; c) identify, investigate and manage communicable disease outbreaks and risks to the

public’s health related to communicable diseases; d) manage immunization programs efficiently; e) communicate important public health information related to communicable diseases

through alerts and notifications; and f) conduct research and analysis to support improved preparedness for future

communicable disease outbreaks and risks to health related to communicable diseases.

The System will be designed for adaptability as well as inter-operability; consequently it is expected to consist of multiple interacting components or modules, each accessed through a consistent and flexible user interface.

3.1.1.3 Relationship to the Electronic Health Record Health surveillance consists of a number of key business functions, supported by appropriate technologies. The Solution developed as a result of this JSP process may eventually be integrated into the various Jurisdictions’ Electronic Health Record (EHR) architecture and infrastructure. The EHR will be a secure and private lifetime record of an individual’s key health history and care within the health system. The record is available

SATP-151


electronically to authorized health care providers and the individual anywhere, anytime, in support of high quality care. The EHR will be the central component that stores, maintains and manages clinical information about patients. The EHR will hold data replicated from feeder or application systems and is an operational data store within the EHR solution.

Some elaboration of this EHR architecture can be found in the Infoway EHRS Blueprint (found at http://www.infoway-inforoute.ca/).

3.1.2 BUSINESS CHALLENGES The public health community across Canada has a number of business challenges that should be taken into account when defining the Solution:

a) different public health business and privacy legislation and practices across and within Jurisdictions, and with limited support for alignment;

b) Jurisdictions at various levels of maturity in terms of technology infrastructure, supporting systems (e.g. registries), and integration or interoperability between health systems (e.g. Electronic Health Record);

c) a limited supply of public health professionals; d) differing levels of public health delivery integration with other health services. For example,

smaller or remote areas tend to deliver public health and primary health care together, while larger areas may keep the two functions segregated;

e) the requirement that Jurisdictional Implementation projects are cost shared with Infoway, implying both budget pressures and timing constraints for some Jurisdictions;

f) a lack of information technology planning for public health in some of the Jurisdictions; and g) different legacy COTS and GOTS implemented throughout the Jurisdictions.

3.1.2.1 Existing Infrastructure Currently seven of the Jurisdictions have implemented some functionality from iPHIS; however, implementations are inconsistent in depth and breath. iPHIS was originally developed by the Province of British Columbia, and is currently maintained by the Public Health Agency of Canada, and available to all Jurisdictions.

While iPHIS is the single largest surveillance system in use in Canada today, it is by no means the only one. There are numerous applications in use in various Jurisdictions, mostly custom developed to address discrete functions, such as immunization registries and case management.

Some COTS products are also in use, although these are more prevalent at the local/regional level, than for a Jurisdiction as a whole.

3.1.2.2 Bilingual Requirement The System and select other deliverables will be required to support both French and English languages.

3.1.3 SOLUTION PROCUREMENT OBJECTIVES The procurement process should result in a relationship with a Contractor that promotes the long-term objectives of the Jurisdictions by:

SATP-151


a) ensuring that the highest levels of privacy protection are in place to ensure that the personal health information of Canadians is protected in accordance with the legislation, policy and regulations of the Jurisdictions and taking reasonable and necessary measures to ensure the privacy of personal information is protected from access (directly or indirectly) by foreign entities;

b) creating a modularized, standard-based Solution that can be implemented in whole or part in each Jurisdiction, and that facilitates communication among and between the Jurisdictions, when and as appropriate according to Jurisdiction privacy legislation;

c) using risk-sharing approaches that distribute risks between parties according to the principle that the party that controls the risk, assumes the risk;

d) developing a flexible model that allows Jurisdictions the option to procure Ancillary Services (at predictable and stable prices and risk levels) over the duration of the Final Contract;

e) encompassing a pricing approach that is transparent over the lifetime of the Final Contract, providing a reasonable profit for the level of risk being absorbed;

f) implementing flexible technical and process models that can accommodate evolving operating and policy environments; and

g) establishing a consistent and streamlined decision-making and governance model, that provides a single point of contact and guidance for the Contractor, which in turn reflects the priorities and requirements of the user Jurisdictions and other relevant stakeholders.

3.2 STRATEGIC INTENT AND SCOPE OF PROCUREMENT The Project Coordinator is seeking a System that is capable of being implemented across Canada, in all Jurisdictions. The System will electronically support and coordinate the communicable disease surveillance and response activities of the individual participating Jurisdictions. The Project Coordinator reserves the right to implement the System that will be developed by the Contractor.

3.2.1 ORIGINAL PROJECT INTENT To understand the scope of the goods and services being procured through this process, it is important to understand some of the relevant background. Shortly after execution of the ‘Funding Agreement’ for this program between the Government of Canada and Infoway, scoping work was carried out to define the components of a fully-functional communicable disease and immunization management and surveillance solution. The refinement of this work concluded that there were eight important components required:

I. communicable disease case management;

II. outbreak management;

III. immunization management;

IV. health alert management;

V. reference management;

VI. operational data repository;

VII. portal; and

SATP-151


VIII. data warehouse and analytic tools.

3.2.2 REVISED SCOPE In strategizing about how best to deliver these capabilities to the Jurisdictions, it became clear that they fell into two categories:

a) those components for which specific software tools should be selected and integrated to form part of the Pan-Canadian Solution that would then be offered to the Jurisdictions. These ‘common components were determined to be the first four in the list above:

I. communicable disease case management;

II. outbreak management;

III. immunization management; and

IV. health alert management.

b) those components that should be left to each Jurisdiction to select and procure as part of its implementation project. These ‘jurisdiction-specific components’ were determined to be the final four items in the list above:

V. reference management;

VI. operational data repository;

VII. portal; and

VIII. data warehouse and analytic tools.

This is based partly on the reality that some Jurisdictions already had some of these tools in place (e.g., portals, analytic tools, data warehouse facilities), as well as recognition that some of them could be shared by public health surveillance with other business functions.

3.2.3 SYSTEM FUNCTIONAL COMPONENTS

Further refinement of the requirements for the common components has expanded the list to include two supporting capabilities. The resulting six capabilities (defined as the Functional Components) are the scope of the System being procured through this JSP process:

a) Key business capabilities i. communicable disease case management, ii. outbreak management, iii. immunization management, including

• immunization registry, and • immunization service delivery,

iv. health alert management, b) Supporting capabilities

v. materials / vaccine inventory management, and vi. work management.

The Successful Proponent will enter into a Final Contract with the Project Coordinator for a System that encompasses the functional scope of the Functional Components as further

SATP-151


described in sections 3.3.2 and 3.3.3, and to perform certain services (collectively called the Solution). The specific elements of the Solution are generally described in section 3.2.4 below.

3.2.4 THE SOLUTION ELEMENTS The Solution is made up of the following elements:

a) the integration project, which involves the design and building of the System; b) establishing and operating a Reference Implementation; c) providing maintenance, support and enhancement services to the Project Coordinator with

respect to the System; d) providing maintenance and support to Jurisdictions in respect of Jurisdictional

Implementations; e) providing structured licensing, maintenance and support for the Products utilized in

Jurisdictional Implementations; and f) Ancillary Services which are comprised of Jurisdictional Implementation Services and

Application Management Services.

It is anticipated that the Contractor would first design and then build the System, which itself would be a combination of Products, Contractor Code and associated documentation. The design of the System would be based upon the Business Requirements and organized in a manner consistent with the Logical Components. It is anticipated that the Business Requirements and the Logical Components would be finalized as part of Joint Solution Definition Phase and subsequent phases.

The Contractor will be required to create a Reference Implementation. The Reference Implementation will be a standard reference environment used to develop and test the System, as well as allow all Jurisdictions the opportunity to examine the System in detail. The Reference Implementation may also be used for ongoing testing, maintenance, support and Jurisdictional Implementations and version management as the System is upgraded over the term of the Final Contract.

Maintenance, support and enhancement services of the System is another element of the Solution. The Contractor will have general maintenance and support obligations under the Final Contract that will provide for general maintenance of the System along with System enhancements as directed by the Project Coordinator. These services may include operation of a common infrastructure necessary to support Jurisdictional Implementations.

The Contractor will offer to Jurisdictions, and/or their contractors, maintenance and support services in respect of their Jurisdictional Implementations under terms more specifically set out in the Final Contract.

The System is anticipated to include Products. Any Jurisdictional Implementation will require licensing, maintenance and support of the Products to the relevant Jurisdiction. The Solution will include a licensing, maintenance and support structure for the Products that the Contractor will make available to the Jurisdictions. This will require the Contractor to establish corresponding contractual relationships with the Product owners.

Ancillary Services may be required for Jurisdictions that choose to do a Jurisdictional Implementation. It is the intent of the Project Coordinator to establish a contractual arrangement to allow the Project Coordinator to purchase Ancillary Services for itself as well as

SATP-151


provide a framework for other Jurisdictions to purchase these services from the Contractor. Whether, and the extent to which, the System is implemented by a Jurisdiction (including by the Project Coordinator) is at the sole discretion of the specific Jurisdiction.

Licensing of the System (other than the Products) to the Jurisdictions will not be part of the Solution. Such licensing will be directly undertaken by the Project Coordinator with the Jurisdictions.

3.2.4.1 Solution Timing The Solution elements differ in their timing, scope and duration. The initial build of the System and the creation of the environment for the Reference Implementation are one-time efforts, aimed at rendering the System deployment-ready, to be performed during 2006 according to a mutually-negotiated schedule.

It is anticipated that the Reference Implementation environment would be ready prior to completion of the System build. The Project Coordinator expects that the Reference Implementation will then continue to be operated by the Contractor for the full term of the Final Contract subject to certain termination rights of the Project Coordinator.

Subsequent System maintenance, support and enhancement services to the Project Coordinator would begin when the System integration is complete and the System is accepted as being deployment-ready, and would continue for the full term of the Final Contract.

The maintenance and support to the Jurisdictions would begin once a Jurisdictional Implementation has commenced.

The Ancillary Services would be offered, on an optional basis, at the discretion of the Jurisdictions. These could extend over many years if they include ongoing Application Management Services of the System implemented in some Jurisdictions.

3.2.4.2 Products It is anticipated that the Proponents will propose to supply one or more COTS, perhaps combined with elements of GOTS products. Included in the scope of commitment in this JSP process is procuring the minimum number of development license(s), and associated license maintenance, necessary to build this System and operate it in a Reference Implementation environment.

In addition to COTS, it is important to note that the Project Coordinator is receptive to proposed Solutions that incorporate GOTS. Proposals that include such GOTS products will be further explored during the latter phases of the JSP process to determine a licensing model for them, as well as detailing any salient terms related to their availability for use and/or modification.

The iPHIS system is an application in use, at least in part, in seven Jurisdictions today to support communicable disease case management, immunization management and other functions. The iPHIS system incorporates significant intellectual capital from the Jurisdictions regarding the business processes and rules relevant to communicable disease management and immunization in practice in Canada today, and it is the Project Coordinator’s desire that this intellectual capital be retained and reflected in the System.

SATP-151


However, as noted in Appendix E the underlying technical architecture of iPHIS is based on approaches which were best-practice at the time of development, but which have been superseded by advances in recent technology. There is a large community of users in Canada today who are accustomed to iPHIS. Proponents may want to take into account this factor in assessing the suitability and capability of other component products to support business functions supported by iPHIS today. Additional information on iPHIS may be available on the Project Extranet.

CIOSC is a secure, web-based system which is operated by the Canadian Network for Public Health Intelligence. It provides strategic dissemination of timely laboratory and epidemiology intelligence (including syndromic surveillance, food safety, international disease reporting, and other relevant national surveillance information). This occurs through the early recognition of geographically dispersed events.

The Project Coordinator intends to provide, directly after the Proponent meeting, a demonstration of iPHIS and CIOSC for any Proponents that are interested.

3.2.4.3 Integration Project The Contractor will be responsible for carrying out a one-time project encompassing the integration of component Products into an operational System, including whatever management of Subcontractors and Product vendors is required in this process.

It is currently anticipated that the Contractor will own the relationship with the Product vendors, and that the Project Coordinator will deal directly with only the Contractor. The Project Coordinator reserves the right to look at other relationship models, should the Project Coordinator so choose.

This System integration project will take place in a controlled development/test environment, likely on a Proponent-supplied hardware platform that is compatible with the Project Coordinator infrastructure. It will conclude when acceptance testing verifies that the System is functioning properly, is thoroughly and accurately documented, and is thus ‘deployment-ready’ as demonstrated by the Reference Implementation.

This integration project will result in a single instance of the System being developed in a controlled development/test environment. However, the System should be designed to provide a high degree of scalability, to accommodate the range of sizes (numbers of patients/clients, numbers of users, etc.) of the different Jurisdictions that will implement it.

While this procurement process may result in a Final Contract that includes Jurisdictional Implementation Services (see Ancillary Services below), it should be noted that Jurisdictions will draw upon these services entirely at their own discretion. It is likely that some Jurisdictions will not choose to utilize the Contractor for their Jurisdictional Implementations, and may wish to carry out the implementation themselves, or with other contracted assistance. Therefore, the System produced by the Contractor through the integration project will be fully tested, documented and rendered ‘deployment-ready’ by any Jurisdiction and/or their contractors. Access to the ongoing Reference Implementation by Jurisdictions and their contractors will be an important service for the purposes of the Jurisdictions doing their own Jurisdictional Implementations.

SATP-151


Related to the foregoing, it is expected that the Contractor will do extensive work in preparation for Jurisdictional Implementations that will include pre-implementation planning, training and system validation.

More specifically, this integration project will encompass:

a) detailed System design (technical design and all aspects of architecture – application, data and technology) that integrates the System Components in a manner consistent with the Logical Components;

b) conformance to standards as defined by the Infoway standards collaboration process, including commitment to support Pan-Canadian standards as they emerge, as well as commitment to participate in the Pan-Canadian standards development process;

c) component testing; d) integration testing; e) supplying all aspects of infrastructure, together with associated configuration

management utilities, tools and services i. development environment(s), ii. integrated testing environment(s), iii. staging environment(s) as required, and iv. user acceptance testing environment(s);

f) provision of a Reference Implementation of the System. Proponents should assume the Reference Implementation will be available on a remote basis to the Jurisdictions for the duration of the Final Contract during business hours with up to 10 simultaneous users. Reference Implementation service levels will be further refined during the JSP process;

g) detailed documentation that can be shared with Jurisdictions and their associated system providers/implementers; and

h) an implementation approach that supports the implementation of the integrated System into operational environments in the Jurisdictions.

The Reference Implementation will be used for multiple purposes including demonstration and evaluation purposes and will support Jurisdiction-specific planning and knowledge transfer. It is expected that the Reference Implementation will be maintained beyond acceptance of the System, in an environment which is accessible to all Jurisdictions. It is the intent of the Project Coordinator that the Reference Implementation could also be used for ongoing version management, upgrades, Jurisdictional Implementations, testing and other uses that the Project Coordinator reasonably determines from time to time.

It is anticipated that the integration project will result in the creation and assembly of a significant amount of Intellectual Property. It is expected that all Intellectual Property created as part of the Solution will be subject to the principles respecting Intellectual Property that are specified in this JSRFP (see section 3.2.4.9).

3.2.4.4 System Maintenance, Support and Enhancements Maintenance services will include regular upgrades, management and upgrades as required, and the potential for the Project Coordinator to draw upon the Contractor for enhancements and updating functionality, interfaces/integration points, etc.

It is expected that the Contractor will continue to maintain the Reference Implementation environment they initially established in the integration project (making reasonable upgrades

SATP-151


to it as required during the period of the Final Contract) to support the ongoing maintenance and support of the System. However, if there are good reasons for doing so and with the agreement of the Project Coordinator, it is also possible that the Contractor could use a different environment for ongoing maintenance than the one used for initial integration.

As part of the System maintenance and support process, the specific deliverables expected of the Contractor will include:

a) a service delivery model that clearly outlines the methods, process, tools and resources required to provide ongoing System maintenance and support services, including responses to extraordinary requirements;

b) ongoing System maintenance and support, in conformance with a rigorous set of service level agreements; and

c) ongoing enhancements as directed by the Project Coordinator from time to time.

3.2.4.5 Jurisdictional Maintenance and Support The Contractor will offer to Jurisdictions, and/or their contractors, maintenance and support services in respect of their Jurisdictional Implementations under terms more specifically set out in the Final Contract.

3.2.4.6 Jurisdictional Product Licensing and License Maintenance The Project Coordinator wishes to understand the economic, pricing and licensing model of the Proponents, and intends, if sufficiently favorable terms could be established, to extend the software licensing model so that the resulting Final Contract could be used to subsequently purchase Product licenses, and associated license maintenance, required for implementation and operation of the System in one or more Jurisdictions.

It is the intent of the Project Coordinator to establish a contractual arrangement to give the Jurisdictions the option to purchase on terms specified in the Final Contract, from the Contractor, the Products licenses and associated maintenance comprising the System. The intent is that the Final Contract may be drawn upon by the Jurisdictions to procure any or all of the Solution Components. The extent to which the System is adopted and adapted by a Jurisdiction is at the sole discretion of the specific Jurisdiction.

The Project Coordinator expects that prices quoted for Product licenses and associated maintenance will take into consideration the premise that licensing and maintenance is being purchased on a national scale, given the fact that multiple Jurisdictions will likely be implementing the Solution.

3.2.4.7 Ancillary Services It is the Project Coordinator’s intent to include in the Final Contract the ability for the Contractor to provide Jurisdictional Implementation Services which the Jurisdictions may, at their sole discretion, draw upon to implement the System. The Final Contract will have terms for Application Management Services which may be similarly drawn upon by the Jurisdictions at their sole discretion.

It may also be possible for the Contractor, with the consent of the Project Coordinator, to conduct parallel negotiations with one or more Jurisdictions for Ancillary Services, including Jurisdictional Implementation Services. This could result in separate contracts being signed concurrent with the Final Contract or at some point soon thereafter.

SATP-151


Jurisdictional Implementation Services and Application Management Services are described further below.

3.2.4.7.1 Jurisdictional Implementation Services For the purposes of this JSP process, Jurisdictional Implementation Services are deemed to include: a) Jurisdiction rollout and integration. Jurisdiction-specific adoption and adaptation of

the integrated Solution in whole or in part (i.e. technical integration services such as designing, configuring, building and testing interfaces);

b) Jurisdiction-specific planning; c) business process changes; d) change management services; e) training services; f) testing services; and g) implementation support services where a Jurisdiction is implementing the system

either itself or using another third party contractor.

The Jurisdictional Implementation Services, as required, may be procured directly by the Jurisdiction using their local procurement methods, or leverage this procurement process for their Jurisdiction.

3.2.4.7.2 Application Management Services For the purposes of this JSP process, Application Management Services could include: a) hosting the application; b) service hours; c) service availability; d) service reliability; e) service response; f) IT service continuity; g) security; h) service desk; i) incident management; j) services related to failover and business continuity; k) problem management; and l) change management.

The Application Management Services as required may be procured directly by the Jurisdiction using their local procurement methods, or leverage this procurement for their Jurisdiction.


SATP-151


3.2.4.8 Use of Solution Elements in Jurisdictional Deployments It is anticipated that Jurisdictional Implementations will vary from Jurisdiction to Jurisdiction. The following figure and subsequent explanation provides certain examples of the potentially varied nature of Jurisdictional Implementations and how Jurisdiction deployment choices affect the Product licensing and maintenance and the Ancillary Services Solution elements.

Figure 2 – Examples of Jurisdictional Deployment Options

Jurisdiction 1 has elected to deploy the complete System, including using the services of the Contractor for Jurisdictional Implementation Services and Application Management Services.

Jurisdiction 2 has elected to deploy only part of the System, choosing not to use either Functional Component 2 or Support Component 3. This in turn means that licenses for Products 2 and 3 are not required. Jurisdiction 2 is not using the services of the Contractor for Jurisdictional Implementation Services or Application Management Services.

Jurisdiction 3 has elected to deploy only part of the System, choosing not to use Functional Component 1. This in turn means that license for Product 1 is not required. Jurisdiction 3 will use the services of the Contractor for Jurisdictional Implementation Services, but will not use the Application Management Services.

Examples of Jurisdictional Deployment Options

System

Jurisdictional Licenses,Support and Maintenance

Functional Components1

2

3

etc.

Support Components1

2

3

etc.

Products1

2

3

etc.

Ancillary Services

Jurisdictional Implementation Services

Application Management Services

Jurisdiction 1

Jurisdiction 2

Jurisdiction 3

Jurisdiction 4

System Maintenance and Support

Examples of Jurisdictional Deployment Options

System

Jurisdictional Licenses,Support and Maintenance

Functional Components1

2

3

etc.

Support Components1

2

3

etc.

Products1

2

3

etc.

Ancillary Services

Jurisdictional Implementation Services

Application Management Services

Jurisdiction 1

Jurisdiction 2

Jurisdiction 3

Jurisdiction 4

System Maintenance and Support

SATP-151


Jurisdiction 4 has elected to use the complete System, and will use the services of the Contractor for Application Management Services, but will not use the Jurisdictional Implementation Services.

3.2.4.9 Intellectual Property Requirements The Project Coordinator has the following objectives with respect to Intellectual Property related to the Project:

a) The Project Coordinator would own the Solution or have rights to the Solution that are substantially the same as ownership. These rights would extend to future modifications and enhancements to such Intellectual Property made by the Contractor. These rights would not need to extend to i. the Products incorporated into the Solution, which the Project Coordinator anticipates

will be licensed, ii. conditional use of the Solution outside of Canada, and iii. conditional use of the Solution for purposes that are outside of the scope of the Project,

such as for an entirely different business application; b) For any parts of the Solution not owned by the Project Coordinator, risks associated with

bankruptcy and insolvency should be addressed; c) The Contractor would bear risks associated with the Solution Intellectual Property including

Intellectual Property claims by third parties; and d) All Intellectual Property rights and benefits granted to the Project Coordinator (including risk

allocation) would also be for the benefit of all relevant participants in the Project (such as the Jurisdictions).

Many of these objectives could be achieved by granting ownership of the Solution deliverables (other than the Products) to the Project Coordinator, having the Project Coordinator granting a royalty free conditional license back to the Contractor for the excluded uses noted above, and the Contractor granting a full Intellectual Property indemnity to the Project Coordinator and other bodies associated with the Project. The specific license conditions would relate to the continued commercialization of such Intellectual Property by the Contractor. There are other methods that can also be used to achieve these objectives. The Project Coordinator is prepared to explore all reasonable methods with Proponents.

3.2.5 FUNDING MODEL

As a key supporter of the Solution, Infoway will be providing a significant proportion of the funding for the Solution. Infoway, through the Project Coordinator, will be providing the full funding for the design and integration of the System. The Jurisdictions will get access to the System without charge, but will be responsible for providing funding to support the maintenance services associated with the System.

One of Infoway’s key objectives for the Project is to financially assist those Jurisdictions that choose to deploy the Solution within their specific jurisdiction. To that end, Infoway’s intent is to provide funding of up to $70 million (in total across all Jurisdictions), to assist the Jurisdictions with implementing the Solution. Access to this funding will be available to all Jurisdictions that choose to implement the Solution. Jurisdictions that opt not to implement the Solution, including those that choose to implement another system or solution, will not gain access to the implementation funding from Infoway. Infoway’s mandate is currently set to expire in 2009.

SATP-151


In addition to these funds, the Jurisdictions will be providing additional funding, according to a matching formula, for a significant portion of the Jurisdictional Implementations. The Jurisdictions which opt for Application Management Services will be responsible for its ongoing funding.

The Project Coordinator expects that if the Solution was implemented in most of the Jurisdictions, the total spending on the Solution from all sources could be in excess of $200 million.

3.3 SYSTEM ARCHITECTURE AND SCOPE

3.3.1 OPERATIONAL CONTEXT

The System will be implemented independently in participating Jurisdictions, with each having its own unique pre-existing infrastructure.

In some cases, Jurisdictions may have existing systems that they may wish to continue to use. It is expected that the design of the System will allow Jurisdictions to forego implementing one or more specific Functional Components, and instead use existing systems to accomplish the same objectives.

Most Jurisdictions have their own unique infrastructure that the System will either need to rely on (such as privacy and security systems, lab systems, client registry, physician electronic medical record systems, etc.), or need to provide data to (such as data warehouse and data analysis systems, geographic information systems, etc.).

3.3.2 NOTIONAL SYSTEM ARCHITECTURE The Project Coordinator is flexible with respect to the detailed architecture of the System. However, in order to meet the two requirements of integration and functional ‘separability’, the Project Coordinator believes that the System will be organized as a component-based architecture with standards-based inter-component communications.

The System should present standards-based component interfaces for each of the key function areas. Furthermore, these interfaces should support all interactions among the key functional areas.

In addition, the System should present component interfaces for a variety of supporting functions. The System will be expected to use standards-based protocols for external communications.

The standards-based communication will be designed to allow the System to be adopted and adapted in whole or in part by the participating Jurisdictions.

The following figure represents the Project Coordinator’s current vision of the System architecture:

SATP-151


Figure 3 – Notional System Architecture

This figure draws a distinction between System Components and Logical Components, and further sub-divides Logical Components into Functional Components and Support Components.

The System Components are the Products (COTS, GOTS and supporting commercial software) and the Contractor Code. This is the software that ultimately will comprise the System and which will support the business of communicable disease management.

The Logical Components are a way of conceptually organizing the functions of, and the interfaces to the System. Logical Components are divided into Functional Components (which are directly involved in the major functional processes) and Support Components (which support the Functional Components).

Logical Components may or may not directly map to System Components. The System is expected to behave as if it literally contains the Logical Components. It is recognized that the appropriate number of Logical Components and their associated interfaces will be refined during the Joint Solution Definition Phase and subsequent phases.

Functional Components are the conceptual units (currently six) into which the functional requirements have been grouped. The Functional Components will be operationally defined by the function interfaces which they expose to other Logical Components or systems.

SATP-151


Included with the Logical Components is a rectangle labeled ‘unified presentation’. This is intended to indicate that regardless of the individual System Components that make up the System, the user interface should present the appearance of a single system.

The System should also allow the interface to be configured to support differences in workflow and job function across the Jurisdictions.

The vision described in this section is supported and expanded by the following three design documents: a) Appendix F – ‘Initial Application Architecture Document’; b) Appendix G – ‘Initial Data Architecture Document’; and c) Appendix H – ‘Initial Logical Design Document’.

These appendices reflect the preliminary requirements and design for the System. It is anticipated that the Project team and Proponents will review these documents during the JSP process to refine the design. The Proponents will be encouraged to provide critical commentary and identify opportunities for innovation and improvement during the JSP process.

Note that some of the language, wording and terminology used within the architectural documents may not be consistent with those used in public health or with the text of this JSRFP; however, the logical interrelationships among key items (data objects, supported functions, etc.) are the key things that should be noted from these documents. The Project Coordinator will be aligning the terminology during the JSP process.

3.3.2.1 Application Architecture The ‘Initial Application Architecture Document’ (Appendix F) provides a more detailed description of the architecture envisioned to support the variety of potential deployments. This document’s intent is to explain the following aspects of the architecture of the System:

a) the ‘Application Architecture Context’, which describes the context and drivers that will affect the selection of an application architecture;

b) how the software components of the architecture should be separated and connected in order to provide the flexibility and integration required. This is referred to as the ‘Implementation View’;

c) the various scenarios for physical deployment of the Solution, and their implications on the System architecture. This is referred to as the ‘Deployment View’; and

d) the non-functional requirements for the System (such as performance, availability, capacity). These are referred to as the ‘Quality Attributes’.

3.3.2.2 Data Architecture The ‘Initial Data Architecture Document’ (Appendix G) provides a more detailed description of the data architectural requirements and includes:

a) the ‘Logical Data Model’, presented as a series of ‘Entity Relationship Diagrams’ showing the significant entities and their relationships; and

b) an alphabetic list of significant entity descriptions along with a representative selection of attributes for each entity.

The ‘Entity Relationship Diagrams’ are being mapped to the ‘HL7 Version 3 Reference Information Model’ and a preliminary ‘HL7 PHS Domain Message Information Model

SATP-151


(DMIM)’. It is expected that the Proponent will map their ‘Logical Data Model’ to the ‘HL7 V3 RIM’.

3.3.2.3 Logical Design The ‘Initial Logical Design Document’ (Appendix H) describes the interrelationship between the six key business processes (communicable disease case management, outbreak management, immunization management, alerting, work management and materials and vaccine inventory management) by describing three views of the System:

a) the inventory of business use cases, and detail for all architecturally-significant ones. This is referred to as the ‘Use Case View’;

b) the definition of end-to-end business processes, and their use of the architecture. This is referred to as the ‘Process View’; and

c) the allocation of requirements to components, and the definition of inter-component interfaces - the service-oriented architecture for the System. This is referred to as the ‘Logical View’.

The interrelationships between the six processes are complex, reflecting the interrelationships of these public health business areas. The currently envisioned relationships among these six processes are represented in figure 4. Some further elaboration of these processes is also provided in section 3.3.3.

Figure 4 – Business Processes

SATP-151


3.3.2.3.1 Design Challenges Each Jurisdiction deploying the System will require it to integrate with a unique set of Jurisdiction-specific legacy and new healthcare systems, such as laboratory and pharmacy systems, jurisdiction-wide client and provider registries, etc. This presents at least two fundamental design challenges: a) the System needs to be capable of stand-alone operation, while at the same time

being configurable such that each Jurisdiction can, at its sole discretion, opt to use pre-existing applications instead of the System’s Logical Components, on a piecemeal basis; and

b) to the extent that the System relies on the internal databases of its constituent System Components, the System needs to be capable of provisioning and synchronizing those internal databases with data from external jurisdictional registries or other data sources.

3.3.2.4 Component Model The System is envisioned as a service-oriented, component-based architecture with a logically discrete Functional Component supporting each major functional process. In addition, the System will incorporate a number of additional services and reference tables to support system operation, administration and communication with external systems. Figure 5, taken from ‘Section’ 5 of Appendix H – ‘Initial Logical Design Document’ - illustrates the set of Logical Components as currently envisioned.


SATP-151


id Component Model

Alerts Management

Communicable Disease Case Management

Outbreak Management

Electronic Health Record

Disease Profile Registry

Vaccine Registry

Provider Registry

Client Registry

Immunization Management

EHR Management Service

Surveillance

Location/Facility Registry

Audit Service Privacy/Security Services

Pharmacy System

Document Management

Service

Lab Service

Reporting Service

GIS System

Questionnaire Management

Service

Work Management

Materials/Vaccine Management

Contact Management/Tracing

Service

Prescription Management

Service

Client Registry Management

Provider Registry Management

Disease Profile Registry

Management

Vaccine Registry Management

Location/Facility Registry

Management

Lab System

Drug Registry Drug Registry Management

User Management Service

Shared Services

External Systems

Registries RegistrySupport

Administrative Functions

Infrastructure Functions

Applications External Systems Support/Proxy

Analysis and Reporting

Clinical Tools

Immunization Registry

Management

Immunization "Registry"

Code Table Management

Service

Electronic Medical Record

Immunization Profiling Service

Figure 5 – Component Model

3.3.2.5 Component Model Walkthrough a) Functional Components: The “Applications” are the six Functional Components as

described in section 3.2.3. Note that the figure includes a surveillance application that is not a Functional Component. It is concerned with identifying trends and nascent outbreaks of disease using statistical and other analyses of data from a variety of sources. Although this surveillance capability is a key aspect of a fully implemented surveillance system in a Jurisdiction, the analytic tools that would support it are Jurisdiction-specific, and are not being procured through this JSP process.

SATP-151


b) Support Components include i. ‘Shared Services’: The System will be expected to use and communicate with the

shared services components as appropriate using standards-based messaging, ii. ‘Administrative and Infrastructure Functions’: The System will be expected to

access and use these functions to ensure consistent implementations of the functionality represented by the components throughout a Jurisdiction, and

iii. ‘Registries and Registry Support’: The System needs to support standards-based integration with the registry components and use the registry support components to ensure that any internal master-file tables are maintained and synchronized with the information stored in a Jurisdiction’s client registries and provider registries.

c) ‘External Systems’: It is not intended that the System include these components. However, appropriate standards-based information exchanges with these components will be necessary.

There is a particular challenge inherent in the interface with registries. The figure shows the eventual ‘end-state’ that will exist when a Jurisdiction implements many or all of the ‘EHR'-related solutions being sponsored by Infoway. In this situation, the System will be able to access and download information from the client registries and provider registries dynamically, without duplicating any of their content or functionality.

It is possible, however, that the System might be implemented in a Jurisdiction before these registries are implemented. In such a case, the System needs to be able – perhaps for a temporary period – to manage its own data on clients and providers. Proponents are encouraged to consider how their design could meet this requirement for both self-sufficiency (perhaps temporary, with a capability of being disabled) with respect to these information domains, and reliance on a registry interface.

3.3.2.6 Messaging and Other Standards There are four main reasons why incorporation of workable standards is an essential aspect of designing and developing this System:

a) to facilitate data communication among the various Logical Components of the System itself;

b) to facilitate communication between these Logical Components and other applications, utilities and services in a Jurisdiction, as discussed in the preceding section and illustrated in the figure above;

c) to ensure that multiple instances of the System can exchange information (e.g., for one Jurisdiction to transfer case-related data to another when a patient relocates); and

d) to ensure that information related to a client’s communicable diseases and immunizations becomes part of his/her Electronic Health Record.

To ensure that these standards are created, Infoway has launched, concurrent with this Project, a sequence of projects aimed at developing the data, messaging and terminology standards that will be needed by the System. During the course of this procurement process, and in the development/integration project that results from it, information will become available to Proponents on specific standards that have been selected/developed and accepted through the Infoway-sponsored ‘Standards Collaboration Process’.

Proponents should identify the capabilities of their proposed Solutions to support relevant data, messaging and terminology standards.

SATP-151


Messaging standards are one important type of standards needed by the Solution. Infoway’s ‘Standards Collaboration Process’ has made a strategic decision to emphasize ‘HL7 Version 3’ as the basis for messaging standards in Canada’s emerging set of integrated electronic health record systems. Accordingly, this System is expected to support ‘HL7 Version 3’ message-oriented integration with external systems.

There could be certain advantages to architectures where the Functional Components of the System use ‘HL7 V3’ messaging to communicate among themselves, but the Project Coordinator is also open to a proposed System that use other internal data transport mechanisms.

3.3.3 FUNCTIONAL SCOPE The Solution is focused on the management of communicable diseases. The current scope does not include systems to support the management of chronic diseases (e.g. diabetes) and health determinants (e.g. smoking).

The System will support the following processes:

a) communicable disease case management; b) outbreak management; c) immunization management, including

i. immunization registry, and ii. service delivery;

d) health alert management; e) materials / vaccine inventory management; and f) work management.

These processes are briefly described in the following sections.


SATP-151


3.3.3.1 Communicable Disease Case Management The purpose of communicable disease case management is to identify, investigate and manage cases and contacts in order to reduce the risk to the public’s health from instances of communicable disease.

This includes supporting:

a) how a communicable disease risk is identified and the resulting disease case initiated for a person, non-person, group, organization or unspecified;

b) how exposures are investigated and the process of establishing a contact list; c) how interventions and treatment plans and control measures are managed to control the

risk; and d) the closure of a communicable disease case when the risk to the public’s health has

been controlled.

Figure 6 – Communicable Disease Case Management – High Level


SATP-151


3.3.3.2 Outbreak Management The purpose of the outbreak management is to identify, investigate and manage an outbreak of a disease.


a) the identification and confirmation of an outbreak occurrence (suspect or confirmed); b) quantification of an outbreak occurrence including investigation and assessment of the

at-risk population; c) tracking, containing and identifying, implementing and following-up on interventions and

control measures to manage an outbreak occurrence; and d) closing an outbreak (suspect or confirmed) when the investigation is complete and the

outbreak is controlled.

Figure 7 – Outbreak Management


SATP-151


3.3.3.3 Immunization Management Immunization management consists of an immunization registry component and a service delivery component.

3.3.3.3.1 Immunization Registry The purpose of the immunization registry is to support the recording and maintenance of immunization event information including information on consents and any related adverse reactions.

3.3.3.3.2 Service Delivery The purpose of immunization management is to limit the spread of a communicable disease by ensuring protection of populations and individuals through immunization.


a) the definition of a Jurisdictional immunization schedule for segments of the population within a Jurisdiction (e.g. infants, children, adults);

b) the planning of an immunization session, including generating the immunization candidate list;

c) the delivery of an immunization session; d) the provision of an immunization profile for an individual or for a select population; e) the generating a list of clients who are eligible for one or more vaccinations; f) the tracking of adverse reactions; and g) the tracking of vaccine failures.

Figure 8 – Immunization Management

SATP-151


3.3.3.4 Materials/Vaccine Inventory Management The purpose of Materials/Vaccine Inventory Management is to maintain appropriate levels of vaccine and other materials, at locations where they are needed.


a) how inventory is allocated for use; and b) the maintenance of inventory at a pre-configured level.

Figure 9 – Materials/Vaccine Inventory Management


SATP-151


3.3.3.5 Health Alert Management The purpose of Alert Management is to ensure the appropriate dissemination of information about significant events based on defined rules.


a) the administration of alert rules and templates to ensure proper processing of incoming and outgoing alerts;

b) the sending of an alert/notification; and c) the receipt and processing of an alert.

Figure 10 – Health Alert Management


SATP-151


3.3.3.6 Work Management The purpose of Work Management is to ensure the quality and effectiveness of disease surveillance business processes by:

a) managing the allocation of work; b) monitoring the status of work items; and c) reporting on work load and volumes.

Figure 11 – Work Management


SATP-151


3.4 PROJECT DEPENDENCIES The Project is an integrated component of the Pan-Canadian Public Health Surveillance Program strategy and is consequently dependent upon the successful completion of several parallel projects. These projects include the ‘Special Task Group on Governance’, the ‘Standards Development Project’ and the ‘Jurisdictional Implementation Planning Projects’.

Figure 12 – Interdependent Projects

3.4.1 SPECIAL TASK GROUP A ‘Special Task Group’ was formed in January 2005, led by Dr. David Butler-Jones of Public Health Agency of Canada with membership from Infoway and certain Jurisdictions. The ‘Special Task Group’ is undertaking the definition of the governance and ongoing sustainability of the Project.

The ‘Special Task Group’ has determined that its work will continue until at least December 31, 2005, by which time it is expected that concrete recommendations would be available for review by the ‘Conference of Deputy Ministers of Health’.

One of the mandates of the ‘Special Task Group’ will be to make recommendations as to the governance model/entity best suited to hold the Final Contract and related Intellectual Property for this initiative in the future. The Final Contract may eventually reside under a different governance structure, which may include assignment to a different entity.

The implication for the Contractor is that the entity that is defined through this ‘Special Task Group’ process could become the Contractor’s client for its ongoing relationships under the Final Contract.

3.4.2 STANDARDS DEVELOPMENT

The ‘Standards Development Scoping Project’ is an Infoway-sponsored project initiated in July 2005. To ensure interoperability, the System should be standards-based, incorporating the standards needed to ensure that Jurisdictions can exchange information on communicable disease cases and immunizations.

This project is the first in a succession of projects to adopt/adapt/develop those standards needed on a Pan-Canadian basis for exchanging information on communicable disease cases and immunization.

SATP-151


The purpose of the early work of the ‘Standards Development Scoping Project’ is to develop an inventory of specific standards needed to support the System. The inventory will include messaging, terminology and data standards. The inventory will include an assessment of available existing standards as candidates from Canadian and international sources and make adopt/adapt/develop decisions and plan subsequent work. The project deliverables will include the standards inventory as well as a project charter for the next phase of the project. It is expected to complete by November 2005. This project will also establish the ‘Pan-Canadian Standards Group(s)’ for the Public Health Surveillance program.

Once scoping is complete it is expected that one or more projects will be initiated to define System-specific data, messaging and terminology standards. It is expected that the System will support the standards identified by the subsequent standards development projects.

It is possible that the standards will not be completely defined and available for the Joint Solution Definition Phase, or for the subsequent development under the Final Contract. If Pan-Canadian standards are not available in time for the integration part of the System development, the Project Coordinator will reserve the right to provide interim standards and will also reserve the right to move the Solution to new, Pan-Canadian standards when those standards are defined. The mechanism for moving to Pan-Canadian standards will be refined during the Joint Solution Definition Phase.

Achieving broad acceptance of standards can be an extended process that may result in incremental adjustments to the standards. The Final Contract will include a change management process that will be used to manage any required adjustments to the standards.

3.4.3 DATA ANALYSIS TOOLS It is also possible that Jurisdictions may want to collaboratively develop some standard or shared toolsets for data analytics and reporting particular to health surveillance (e.g., analytics to detect abnormal spikes in the incidence of communicable disease in a health Jurisdiction or region). Since analytics and reporting tools are not part of the System being procured through this JSP process, this will not likely have a direct impact on the Proponents or the solutions they propose. However, maintenance of some of these analytics could be relevant to the Contractor’s ongoing System maintenance work.

3.4.4 JURISDICTION IMPLEMENTATION PLANNING PROJECTS

The purpose of the Jurisdiction implementation planning projects is for each Jurisdiction to complete the preparatory work necessary to plan a Jurisdictional Implementation:

a) decide which elements of the System they will be adopting within their Jurisdiction; b) based on the components selected, define integration requirements with existing

Jurisdictional system(s) to form a Jurisdiction-specific health surveillance system; and c) develop a detailed implementation plan and cost estimate for the work required.

A number of Jurisdictional Implementation planning projects have recently begun. These will be the major inputs to the subsequent implementation projects in the Jurisdictions, some of which may be carried out by the Contractor. See also section 3.2.4.

SATP-151


3.5 PROJECT EXECUTION - ROLES AND RESPONSIBILITIES

3.5.1 PROJECT GOVERNANCE AND OVERSIGHT

The project organization for the execution of this Project has been designed to leverage the vast content knowledge that exists in the Jurisdictions while ensuring clear lines of accountability and responsibility for the successful execution of this initiative. The Project Coordinator will be accountable and responsible for certain aspects of the delivery of this Project. The Contractor will report to the Project Coordinator for all aspects of the delivery.

A Jurisdiction may be asked, by the Project Coordinator, to advise the Project Coordinator on particular components of the Project with which the Jurisdiction has special knowledge.

Figure 13 – Participant Relationships

3.5.2 ROLE OF INFOWAY, THROUGH THE PROJECT COORDINATOR

Infoway, in the role of strategic investor, will be responsible for:

a) providing the overall investment strategy for the Pan-Canadian Public Health Surveillance Program;

b) providing funding for the design and development of the System; c) with the Project Coordinator, providing management oversight of development of the

Solution; d) actively monitoring progress and quality of deliverables to ensure that the System can be

leveraged across multiple Jurisdictions; e) setting standards and requirements for robust, interoperable products and outcomes;

Pan-Canadian Public HealthStakeholders

Jurisdictions Infoway

PHS SteeringCommittee

PHS WorkingGroup

Pan-CanadianPHS Collaborative

GovernanceTBA

Project Coordinator(Build/Integration Phase)

Selected Proponent

ContractingRelationship

ReportingRelationship

SATP-151


f) participating in the development and issuance of the procurement vehicle, evaluation and selection of the Contractor;

g) communications with ‘Infoway Board’ and stakeholders; h) co-establishing success criteria for the Project; and i) flowing funds to the Project Coordinator consistent with payment obligations under the Final

Contract.

3.5.3 ROLE OF THE STEERING COMMITTEE The role of the steering committee is to support the Pan-Canadian Public Health Surveillance Program, particularly in its earlier stages, where the focus will be on defining and building the System, and setting interoperability standards for information exchange among Jurisdictions.

The steering committee is sponsored jointly by the Infoway CEO and the BC Ministry of Health Deputy Minister. It is chaired jointly by Infoway and the BC Ministry of Health. Its membership consists of a senior public health official and a senior information technology official from each of the provinces and territories as well as representatives from Pan-Canadian health and information technology bodies, such as the Canadian Institute for Health Information and the Canadian Medical Association.

The steering committee will provide this support in two distinct capacities:

a) As an advisory body contributing to the planning and execution of the Pan-Canadian Public Health Surveillance Program investment program by i. facilitating input from senior public health practitioners to the program, ii. facilitating input from senior health ‘Information Technology’ officials to the program, iii. serving as a forum for interchange and dialogue between these two communities, each

of whose contributions is essential to the program’s success, iv. serving as a forum where issues related to the System and its implementation can be

raised, discussed and resolved, and v. providing advice, recommendations and guidance to the ‘Infoway Board’ for the Pan-

Canadian Public Health Surveillance Program at many stages and decision points; and b) As a strategic decision making body contributing to the planning and execution of Pan-

Canadian projects under the Pan-Canadian Public Health Surveillance Program by i. setting strategic direction on key items affecting the project, ii. providing expert guidance to the Project to ensure it remains responsive to the needs of

key stakeholders, iii. defining the mandate, appointing and supporting the working groups and sub-

committees of the steering committee tasked with specific project agendas, and iv. accepting (or rejecting) the recommendations of the working groups, subcommittees,

and other entities established by the steering committee. Members of the steering committee may be on the evaluation committee, but the steering committee in its entirety will not be evaluating the Proponents.

3.5.4 ROLE OF THE DESIGN WORKING GROUP

The design working group consists of seven steering committee members from a cross-section of Jurisdictions. The group includes both members with public health surveillance expertise, and information technology experts.

SATP-151


The design working group’s role is to guide the work of the Project team producing the deliverables. Specifically it is responsible for:

a) serving as expert spokespersons for the wider public health and information technology communities, to be a direct source of input on requirements and priorities (functional and technical);

b) reviewing and providing input on outlines or early specifications for deliverables before the reports are produced;

c) reviewing the deliverables in draft form and provide input to their refinement; d) identifying and sharing useful documents for the Project team’s review; and e) guiding the work of the Project team, providing advice and input in both structured and ad

hoc forms, but not, for greater certainty, evaluating Proponents which function is solely reserved for the evaluation committee.

3.5.5 ROLE OF THE PROJECT COORDINATOR The Project Coordinator’s intention is to setup a procurement mechanism with the Contractor that all Jurisdictions can draw upon. The Project Coordinator will be responsible for:

a) providing management oversight of the Project; b) reviewing and signing off on performance and deliverables related to the scope of the Final

Contract negotiated with the Contractor; c) providing resources (subject matter experts, business analysts and architects) as

necessary throughout the Project to ensure adequate business input, verified requirements, conduct acceptance testing and other functions;

d) developing and issuing this JSRFP; e) facilitating evaluation during the JSP process; f) negotiating and executing the Final Contract with the Contractor; g) informing Infoway on the status of this JSP process, particularly as it impacts the Project

schedule; h) communicating with the Project steering committee; i) liaising with business stakeholder communities, the design working group, and

Jurisdictions; and j) paying the Contractor for accepted deliverables in accordance with the provisions of the

Final Contract based upon funding received from Infoway.

3.5.6 ROLE OF THE JURISDICTIONS Employees and contractors from the Jurisdictions participate in the design working group, on the steering committee and will participate as part of the evaluation committee. In addition, multiple Jurisdictions will advise the Project Coordinator on specific topics throughout the course of the Project.

3.5.7 PROJECT TIME FRAMES The final time frame to carry out the Project as outlined in this JSP process will be confirmed during the Joint Solution Definition Phase.

SATP-151


The term of the Product license, maintenance and support services and other select services will be determined during the Joint Solution Definition Phase and documented in the Final Contract.

With respect to the integration project involved in the development of the System, it is anticipated that the System, operating in the Reference Implementation, will have received final acceptance in 2006.

The term of the Solution maintenance and support services is anticipated to be for an initial period of seven (7) to ten (10) years, with a potential renewal of between three (3) to five (5) years; for a possible total duration of between ten (10) and fifteen (15) years. The start of the implementation phase of the Project will be at the end of the successful conclusion of the integration project and acceptance of the System as being deployment-ready. It is anticipated that the Contractor will be required to provide the Reference Implementation environment for an extended period of time, likely the term of the Final Contract. If after a reasonable period of time of the System being deployment-ready, depending on the number of Jurisdictions that ultimately decide to implement the System, the Project Coordinator reserves the right to discontinue System maintenance and support services, the provision of the Reference Implementation environment as well as other associated services that form part of the Solution.

The length of time the Ancillary Services will need to be provided will be determined during the Joint Solution Definition Phase, and subsequent phases, and documented in the Final Contract.

3.6 POLICY AND COMPLIANCE

3.6.1 PRIVACY LEGISLATION IN CANADA

Protection of privacy of personal information including health records, financial and other personal information will be ensured. This requires a demonstrable ability to fully comply with all applicable privacy legislation in all jurisdictions in Canada.

Note that it is anticipated that the Contractor, as part of the Reference Implementation and System maintenance and support services, will not be privy to any personal information. Compliance with relevant privacy requirements is nevertheless important, because they may impose design constraints on the System that should be taken into account in the design and integration work.

As part of delivering Ancillary Services, on the other hand, the Contractor could host or otherwise support a production instance of the System on behalf of a Jurisdiction, which would more directly require it to ensure compliance with relevant safeguards on sensitive health data.

The following is a list (with hyperlinks) of privacy legislation and regulation believed to be in force in Canada at this time. All ten provinces, three territories and the federal government are included. There could be other legislation and regulation that may impact privacy and are not listed here.

SATP-151


Jurisdiction Legislation Links

Federal The Privacy Act http://laws.justice.gc.ca/en/P-21/index.html The Personal Information Protection

and Electronic Documents Act http://www.parl.gc.ca/36/2/parlbus/chambus/house/bills/government/C-6/C-6_4/C-6_cover-E.html

The Personal Information Protection and Electronic Documents Act Regulations

http://www.privcom.gc.ca/legislation/02_06_01_02_e.asp


Provincial Alberta Freedom of Information and

Protection of Privacy Act http://www.qp.gov.ab.ca/documents/acts/F25.cfm

Freedom of Information and Protection of Privacy Act Regulations

http://www.qp.gov.ab.ca/documents/regs/1995_200.cfm

Health Information Act http://www.qp.gov.ab.ca/documents/acts/H05.cfm Health Information Act Regulation http://www.qp.gov.ab.ca/documents/regs/2001_070.cfm Personal Information Protection Act: http://www.qp.gov.ab.ca/documents/Acts/P06P5.cfm?frm_

isbn=0779726316 Personal Information Protection Act

Regulations http://www.qp.gov.ab.ca/documents/Regs/2003_366.cfm?frm_isbn=0779725050

British Columbia

Freedom of Information and Protection of Privacy Act

http://www.oipcbc.org/legislation/FOI-ACT%20(2004).pdf


http://www.oipc.bc.ca/legislation/Reg%20323_93%20(2004).pdf

Personal Information Protection Act: http://www.oipc.bc.ca/legislation/PIPA2003%20(2004).pdf Personal Information Protection Act

Regulations http://www.qp.gov.bc.ca/statreg/reg/P/PersonalInformation/473_2003.htm

Manitoba Freedom of Information and Protection of Privacy Act

http://www.ombudsman.mb.ca/fippaact.htm

Personal Health Information Act http://www.ombudsman.mb.ca/phiaact.htm New Brunswick Protection of Personal Information

Act http://www.gnb.ca/0062/acts/acts/p-19-1.htm

Newfoundland Access to Information and Protection of Privacy Act

http://www.hoa.gov.nl.ca/hoa/statutes/a01-1.htm

Nova Scotia Freedom of Information and Protection of Privacy Act

http://www.gov.ns.ca/legi/legc/statutes/freedom.htm

Ontario Freedom of Information and Protection of Privacy Act

http://www.e-laws.gov.on.ca/DBLaws/Statutes/English/90f31_e.htm

Municipal Freedom of Information and Protection of Privacy Act

http://www.e-laws.gov.on.ca/DBLaws/Statutes/English/90m56_e.htm

Personal Health Information Protection Act

http://www.e-laws.gov.on.ca/DBLaws/Statutes/English/04p03_e.htm

SATP-151



Provincial Prince Edward Island

Freedom of Information and Protection of Privacy Act

http://www.gov.pe.ca/law/statutes/pdf/f-15_01.pdf

Freedom of Information and Protection of Privacy Regulations

http://www.gov.pe.ca/law/regulations/pdf/F&15-01G.pdf

Quebec Act Respecting Access to Documents Held by Public Bodies and the Protection of Personal Information

http://www2.publicationsduquebec.gouv.qc.ca/dynamicSearch/telecharge.php?type=2&file=/A_2_1/A2_1_A.html

Act Respecting the Protection of Personal Information in the Private Sector

http://www2.publicationsduquebec.gouv.qc.ca/dynamicSearch/telecharge.php?type=2&file=/P_39_1/P39_1_A.html

Saskatchewan Freedom of Information and Protection of Privacy Act

http://www.qp.gov.sk.ca/documents/English/Statutes/Statutes/F22-01.pdf


http://www.qp.gov.sk.ca/documents/English/Regulations/Regulations/F22-01R1.pdf

Local Freedom of Information and Protection of Privacy Act

http://www.qp.gov.sk.ca/documents/English/Statutes/Statutes/L27-1.pdf

Health Information Protection Act http://www.qp.gov.sk.ca/documents/english/Statutes/Statutes/H0-021.pdf


Territorial Northwest Territories

Access to Information and Protection of Privacy Act

http://www.justice.gov.nt.ca/pdf/ACTS/Access_to_Information.pdf

Nunavut Access to Information and Protection of Privacy Act

http://nunavutcourtofjustice.ca/library/consol-stat/CSNu_1999_002_Access_Info_Privacy.pdf

Yukon Access to Information and Protection of Privacy Act

http://www.ombudsman.yk.ca/infoprivacy/atippact.pdf

Note: The Project Coordinator does not assume any responsibility for the accuracy of this list nor its relevance to the

specific privacy requirements associated with this Project. It is each Proponent’s sole and exclusive responsibility to ensure that it is sufficiently aware of statutory, policy and other privacy requirements relevant to this Project.

Source: Federal and ‘Provincial Privacy Commissioner’ websites.

Original document created: May 2005

Attached as Appendix I is the privacy schedule that currently appears for a general contract entered into with British Columbia that involves personal information. Note that the nature of the personal information involved in this Project is more sensitive than most other types of personal information provided under a general services contract. Information on other Alternative Service Delivery initiatives in British Columbia that have used the JSP process, and the mitigation strategies employed by the contractors (including with respect to health related personal information), can be viewed at the following URL: http://www.saip.gov.bc.ca/ASD_Projects.htm.

SATP-151


It is not anticipated that the Reference Implementation will involve any access to personal information. Jurisdictional Implementations will require the Contractor to have access to personal information. Therefore sufficient measures need to be taken in order to address the nature of the personal information involved and the specific legal environment of the relevant Jurisdiction. In any of the contracts that are entered into between the Contractor and a Jurisdiction for Jurisdictional Implementations, these factors will need to be taken into consideration. In addition, further security and mitigation strategies for improved privacy will be negotiated as part of the Final Contract for the purposes of other aspects of the Solution such as System maintenance and support services.

Mitigation strategies to ensure that personal health data would be protected from disclosure under the laws of other countries (e.g., potential disclosure requirement under the USA PATRIOT Act, or other anti-terrorist legislation) will also need to form a part of any Solution. Additional background information on this issue can be accessed at the following URL: http://www.oipcbc.org/sector_public/usa_patriot_act/pdfs/report/privacy-final.pdf.

3.6.2 OTHER LEGISLATION, POLICIES AND/OR REGULATIONS THAT MAY IMPACT THE SOLUTION

The Solution will need to be compliant with all Jurisdictional legislation, regulation and policy. The following are examples of legislation, regulation and policy in British Columbia considered relevant to the delivery of the Solution. The Proponents should become familiar with all similar legislation, regulation and policy in all other Jurisdictions:

a) Freedom of Information and Protection of Privacy Act; b) Personal Information Protection Act; c) Document Disposal Act; d) Evidence Act; e) Health Professions Act; f) Privacy Impact Assessment; g) Ministry Data Access Agreements; and h) Health Act.

3.7 ROLE OF PROJECT COORDINATOR CONTRACTORS IN THIS PROJECT The Project Coordinator, Infoway and the Jurisdictions will use contractors to assist them through this procurement process, and help ensure that their particular requirements and interests are addressed. It is intended that non-disclosure documents will have been signed by all employees and contractors of these organizations that have any involvement with this JSP process.

3.7.1 USE OF CONTRACTORS

Contractors have been used by all jurisdictions, including British Columbia and Infoway for many years on a variety of projects. Large consulting firms, as well as independent contractors, have been used in the past to help support public health programs.

SATP-151


Both BearingPoint LP and Sierra Systems Group Inc. were engaged by British Columbia in early planning stages of this work, prior to the commencement of this Project. To produce the deliverables, they interviewed working group members, reviewed existing documentation and analyzed the current jurisdictional situations. The deliverables produced are available either as attachments to this JSRFP, or on the Project Coordinator’s Project Extranet site.

3.7.1.1 BearingPoint LP BearingPoint LP has performed work in previous preparatory phases of the Project. The working relationship between BearingPoint LP and the Project Coordinator has concluded. The material, while accepted by the Project Coordinator, does not necessarily represent the views of all Jurisdictions. This work included producing the following documents.

a) ‘Requirements Definition’ – Appendix D; b) ‘iPHIS Analysis’ – Appendix E; c) ‘iPHIS Analysis Overview’; d) ‘Requirements Definition – Overview’; e) ‘Solution Specification’; and f) ‘Needs Assessment - Final Report’.

All of these documents are available on the Project Coordinator’s Project Extranet site (https://hlth002.gov.bc.ca/pchs/jsrfp/default.aspx).

3.7.1.2 Sierra Systems Group Inc. Sierra Systems Group Inc. provided project management services during one BearingPoint LP engagement with British Columbia. Subsequently British Columbia issued a Request for Proposal to secure a contractor to assist with preparation of a further Request for Proposals for the selection of COTS products which would be integrated into a future Pan-Canadian Public Health Surveillance System. Sierra Systems Group Inc. was successful and did some initial work on the following requirements documents, which have subsequently been modified by the Project Coordinator:

a) ‘Initial Application Architecture Document’ – Appendix F; b) ‘Initial Data Architecture Document’ – Appendix G; and c) ‘Initial Logical Design Document’ – Appendix H.

These documents are available on the Project Coordinator’s Project Extranet site https://hlth002.gov.bc.ca/pchs/jsrfp/default.aspx.

Once the decision was made to do a JSRFP for the design and development of the entire Pan-Canadian Public Health Surveillance System, Sierra Systems Group Inc. was asked to do some initial work on their early ideas of what should be in the JSRFP, the process and in the response template. They had some meetings with the working group and Infoway.

The contract with Sierra Systems Group Inc. has now ended. The response template from Sierra Systems Group Inc. has not been used by the Project team, and with the exception of certain sections incorporated from the technical work done by Sierra Systems Group Inc. and included in the appendices to this JSRFP, little other material was utilized from this early work.

SATP-151


This JSRFP was created by the Project Coordinator’s employees and independent contractors, with input from the Pan-Canadian design working group, based on the Project Coordinator’s template for the JSP process, not the work that Sierra Systems Group Inc. had created under their contract. Although there are some similarities, the approach contemplated in this Project and JSRFP, and the level of detail and evaluation criteria at each stage and phase, was developed subsequent to Sierra Systems Group Inc.’s involvement in the preliminary steps prior to this Project.


SATP-151


4 OVERVIEW OF THE END-TO-END JSP PROCESS

4.1 OVERVIEW A JSP process is a multi-stage procurement process. The first phase of the JSP process is the Proponent Qualification Phase which is designed to short-list Proponents based primarily on their capacity, capability, and commitment to be a Preferred Proponent. There follows three distinct phases consisting of a Joint Solution Definition Phase (where Solution refinement will occur), followed by a Due Diligence & Negotiations Phase, and ending with a Contract Negotiations Phase (where the Final Contract terms are framed, finalized and executed by the parties).

6 - 9 weeks

Qualify JSP

Qualify JSP

JSP Preparation

JSP Preparation

9 - 12 Weeks

Joint Solution Definition

Joint Solution Definition

10-12 Weeks

A A B B 1 1

Due Diligence/ Negotiation

Due Diligence/ Negotiation

22

Depends on Solution

Implementation Implementation

Project Management Project Management • Issues and risk management• Cost controls and economic/deal

modelling expertise • Research and rapid response• Meeting/workshop logistics• Business analysis

• Clean rooms and Proponent facilities • Legal and procurement assistance

Contract Negotiation

Contract Negotiation

33

Phase A – Assess suitability of potential opportunities for Joint Solution Procurement process

Phase B – Prepare JSRFP with evaluation criteria for release to Proponents

Phase 1 - Select two Proponents based on Capability, Capacity and Commitment (3 C’s) for Joint Solution Definition phase

Phase 2 – Jointly develop proposed Solution frameworks through iterative design cycles. Select Successful Proponent for negotiation

Phase 3 – Conduct rigorous due diligence in preparation for contractual agreement

Phase 4 – Negotiate and sign contractDecision “Gates”Decision “Gates”

Many 2 4 1+1 1

Proponent Qualification Proponent

Qualification

44

46- 6 Weeks

to to to to

Figure 14 – JSP Process Overview

SATP-151


4.1.1 TENTATIVE JSP PROCESS SCHEDULE

Task/Activity Anticipated Date Proponent meeting September 28, 2005

JSRFP closing date October 27, 2005

Stage 1 decision November 4, 2005

Concept presentations completed December 1, 2005

Preferred Proponents announced December 5, 2005

Joint Solution Definition Phase initiated December 7, 2005

Joint Solution Definition Phase completed & Successful Proponent identified

March 24, 2006

Letter of Intent signed and Successful Proponent announced April 13, 2006

Proponents should be aware of the timelines for this procurement and resource accordingly. The Project Coordinator anticipates that the Joint Solution Definition activities will be compressed and take place over an 8-10 week period. Details regarding the schedule will be shared with the Preferred Proponents.

4.2 KEY SUCCESS FACTORS IN THE JSP PROCESS

4.2.1 SHARING OF RISKS AND REWARDS In order for a mutually beneficial, long term business relationship to exist, the Contractor and Project Coordinator will have to share a common vision and share the economic risks and rewards associated with the Solution. These opportunities for risk and reward will be explored during the JSP process.

4.2.2 JSP PROCESS COMMUNICATIONS PROTOCOL Maintaining proper communications protocol throughout the JSP process is important in order to protect the integrity of the procurement process and the Project, as well as to protect the interests of the Proponents, the Project Coordinator and the Jurisdictions. The following communication protocol will apply during the JSP process. Failure of a Proponent to adhere to the communication protocol may result in the Proponent being disqualified from the JSP process.

4.2.2.1 Communications related to the JSRFP Document All communication related to the JSRFP document are to be referred to the Project Coordinator contact listed on the front page of this JSRFP document.

SATP-151


4.2.2.2 Proponent Qualification Phase – Stage 2

4.2.2.2.1 Restricted Documents Room Guidelines for use of the Restricted Documents Room will be provided to short-listed Proponents prior to the opening of the Restricted Documents Room. For further information on the Restricted Documents Room, see section 5.2.5.

4.2.2.2.2 Workshops Face-to-face communications between Proponents and the Project Coordinator and its representatives as part of the Workshops is expected, see section 5.2.6. Please note that the Project Coordinator reserves the right to withhold information at the Workshops that may impact its negotiating position during the subsequent phases of the JSP process.

4.2.2.3 Joint Solution Definition Phase The Project Coordinator will facilitate access to the Information Control Office during the Joint Solution Definition Phase. Guidelines for use of the Information Control Office will be provided to Preferred Proponents prior to the opening of the Information Control Office. All communications between Preferred Proponents and the Project Coordinator will be made through the Project Coordinator’s Information Control Office manager. For further information on the Information Control Office, see section 5.3.1.

4.2.2.4 Due Diligence & Negotiation Phase The Project Coordinator will facilitate access to individuals capable of providing information during the Due Diligence & Negotiation Phase of the JSP process, see section 5.4.

4.2.2.5 Contract Negotiation Phase The Project Coordinator will facilitate access to individuals capable of providing information during the Contract Negotiation Phase of the JSP process, see section 5.5.


SATP-151


5 DETAILED JSP PROCESS

5.1 JSP PROCESS The JSP process is a multi-stage procurement process.

Figure 15 – Joint Solution Procurement Process

The first phase of the JSP process (Proponent Qualification Phase) is designed to qualify and short-list up to four (4) Proponents primarily on their capacity, capability and commitment to be the Contractor for this Project.

Following the Proponent Qualification Phase, two Preferred Proponents will be identified and invited to enter into the second phase of the JSP process (Joint Solution Definition Phase). The Joint Solution Definition Phase allows for the joint development of a Solution and an evolving approach that will maximize the business outcomes for the Project. The form of deal structure to give effect to the Solution will depend on the results of the Joint Solution Definition Phase.

Ultimately, the Successful Proponent will be invited by the Project Coordinator to advance to the third, (Due Diligence & Negotiation Phase) and fourth, (Contract Negotiation Phase) phases of the JSP process which will result in a Final Contract.

The Proponent Meeting will be in Vancouver, BC and all other aspects of the JSP process are currently set to take place in Victoria, BC. Due to the Pan-Canadian nature of the Project, however, the Project Coordinator reserves the right to schedule some aspects of the JSP process in different locations in Canada.

SATP-151


5.2 PROPONENT QUALIFICATION PHASE

5.2.1 APPROACH AND TIMELINE OVERVIEW

A Proponent’s Proposal in response to this JSRFP is the initial step in qualifying to participate in the JSP process. Proponents should keep in mind that the Project Coordinator is not only looking for information on how to design, develop and deliver the System, but also on proof that the Proponent has demonstrated capacity and capability to fulfill the objectives of this Project.

Overall Timeframe

WS 1

Vendor 1 W

S 1

Ve

ndor

1

WS 2

Vendor 2 W

S 2

Ve

ndor

2

WS 3

Vendor 3 W

S 3

Ve

ndor

3

Proponent Workshops

Short-listedProponentWorkshops

(up to 4)

Preferred Proponent Selection

PreferredProponentSelection

(2)

28 - 45 days 5 - 14 days 7-14 daysRelease JSRFP & Evaluate

Proposals

Release JSRFP & Evaluate

Proposals

Overall Timeframe

WS 3

Vendor 4 W

S 3

Ve

ndor

4

Decision Points Decision Points

Figure 16 – Overall Timeframe

Identification of the Preferred Proponents is based on the evaluation of a number of areas, including a Proponent’s Concept and 3Cs, in order to assess the ability of a Proponent to work with the Project Coordinator in developing a System that meets the needs of the Jurisdictions and Infoway, and desired business outcomes for the Project. As a guideline, the Project Coordinator will be looking for a logical trend or progression in the Proponent’s demonstrated skills as the Proponent moves through the Proponent Qualification Phase, from Stage 1 (evaluation of Proposals), gains more knowledge of the Project business environment and needs during Stage 2, (the Workshop stage), and finally delivers a more focused but still conceptual solution during Stage 3, (the Concept stage), of the Proponent Qualification Phase.

The Concept provided by the Preferred Proponents will be validated early in the Joint Solution Definition Phase of the JSP process. Proponents should be aware that the Concept may be subject to significant change as the Joint Solution Definition Phase progresses.

Proponents should carefully consider the timelines outlined in this JSRFP. There is an expectation that a solid Concept will need to be presented to the evaluation committee at the Stage 3 Concept presentations. Proponents may only have three weeks, from notification of short-listed Proponents, to prepare for this Concept presentation.

SATP-151


5.2.2 ROLE OF LEAD PROPONENT IN THE JSP PROCESS Proponents should take care when determining their initial team structure and identifying the lead. The Project Coordinator’s intention is not to permit the firm who is identified as the lead Proponent to swap its primary role with a Subcontractor later in the process. Please note that this does not preclude a new entity to be created as a result of this JSP, provided that entity includes the designated lead as the organization assuming the primary responsibility stated in its Proposal.

5.2.3 RELEASE JSRFP & EVALUATE PROPOSALS

Upon completion of the evaluation of the Proposals, a short-list of up to four Proponents will be created and those Proponents will be invited to participate in Stage 2 of the Proponent Qualification Phase (the Workshop stage). The remaining Proponents will be advised of their standing in writing and offered debriefing sessions. The Project Coordinator proposes to hold the debriefing sessions after the execution of the Final Contract.

5.2.4 IF ONLY TWO SHORT-LISTED PROPONENTS

In the event that only two Proponents are deemed to qualify as a result of the evaluation of the Proposals in Stage 1, then the Project Coordinator reserves the right to consider these short-listed Proponents as Preferred Proponents and to proceed directly to the Joint Solution Definition Phase. In this case some aspects of the Workshops may be performed prior to, or during the early part of the Joint Solution Definition Phase in order to set the stage for System development. The Project Coordinator also reserves the right to invite the two Preferred Proponents to present their Concepts and/or their 3Cs to the Project Coordinator to ensure that they have the necessary 3Cs required to undertake the Project and deliver the final System. These presentations may take place either prior to the commencement of the Solution definition activities, or at any other time during the Joint Solution Definition Phase. Notwithstanding the foregoing, this does not preclude the Project Coordinator from proceeding with the scheduled Workshops.

5.2.5 RESTRICTED DOCUMENTS ROOM If there is a need to establish a Restricted Documents Room, short-listed Proponents will be provided access immediately prior to the Workshops. If required, the Restricted Documents Room will serve as a repository for information relevant to the preparation of the short-listed Proponent’s Concept presentations. Access will be controlled and monitored to ensure equitable viewing time for each of the short-listed Proponents. Inquiries regarding the Restricted Documents Room must be referred to the government contact listed on the front of this JSRFP document. The Project Coordinator may make this a ‘virtual’ online room.

In addition, it is the Project Coordinator’s intention to provide access to both the iPHIS and CIOSC demonstration systems at this time. This will allow the short-listed Proponents the opportunity to explore these systems in more detail, at their own pace, to determine how they may be used or incorporate the business logic into their Solution.

SATP-151


5.2.6 WORKSHOPS The purpose of the Workshops is to allow short-listed Proponents the ability to further explore the Project and to provide an avenue for them to assess whether the Project is of sufficient interest to engage in a significant amount of work at the Joint Solution Definition Phase and, if the Proponent is the Successful Proponent, at the Due Diligence & Negotiation Phase and the Contract Negotiation Phase.

The guidelines that will govern the Workshops are outlined below. The Project Coordinator reserves the right to alter these guidelines, (and any scheduling) as needed, but will only do so after notifying the short-listed Proponents.

During this stage, short-listed Proponents are invited to attend a half-day morning presentation, from the Project Coordinator and key project stakeholders (individuals representing the Jurisdictions and Infoway) to further inform the short-listed Proponents of the Project scope, objectives, and other information deemed relevant by the Project Coordinator. All of the short-listed Proponents will be together for this presentation, as it is intended to be a one-way Project Coordinator-led session, to ensure that the short-listed Proponents receive identical information at the same time. In the afternoon of the same day, the Project Coordinator will meet individually with each of the short-listed Proponents for one hour to provide feedback on the high-level vision contained in their written Proposals. This is intended to provide feedback on strengths and weaknesses, and to identify areas that they may want to explore and/or explain further.

The following week, the Project Coordinator will meet individually with each of the short-listed Proponents for a Proponent led three hour question-and-answer Workshop. The order of the meetings will be randomly determined, and the short-listed Proponents notified. The Project Coordinator reserves the right to increase the number of Workshops.

During the question and answer Workshops, short-listed Proponents will have the opportunity to further explore the Project and to ask questions that the short-listed Proponents feel are necessary in order to deliver a more definitive solution at the next stage of the selection process. The question and answer Workshops will be staffed by key members of the Project Coordinator and may include Representatives, Colleagues and other individuals who represent the Jurisdictions and Infoway. Wide latitude will be afforded to all short-listed Proponents with respect to the questions being asked. While the Project Coordinator will make every effort to ensure that the right people are available to answer questions, there may be some questions that cannot be answered during the question and answer Workshops. In this case the Project Coordinator will try to communicate the response to the short-listed Proponent within one working day of the Workshops. The Project Coordinator will not, however, be liable whatsoever for any delays in providing a response to any unanswered questions.

The Workshops will not be electronically recorded and the Project Coordinator intends that all information communicated in the Workshops will be treated in the manner contemplated in section 1.3.1.22. In addition, answers to questions asked during the Workshops which could not be answered by the Project Coordinator immediately will be communicated to the respective Proponent only. Proponents are advised however, that if a question is asked in these Workshops that the Project Coordinator deems to be of a general nature, it reserves the right to communicate the question and answer to other Proponents.

SATP-151


Proponents are asked to limit themselves to questions related to gaps in their knowledge of the business, requirements and Project concepts. The opportunity to present refined Systems will take place during the Stage 3 Concept presentation.

The Project Coordinator will not require short-listed Proponents to bring specific staff to the Workshops. Each short-listed Proponent must decide who from their organization is best suited to gather the necessary information, participate in the Workshops and the Stage 3 Concept presentation. Proponents should note that the Workshops will not be evaluated.

5.2.7 PROPONENT CONCEPT PRESENTATIONS

5.2.7.1 Overview The purpose of the Stage 3 Concept presentation is to allow each short-listed Proponent to present their Concept for the Project to the Project Coordinator. It is expected that the proposed Concept would be consistent with a refining process, rather than a shift in Solution design previously outlined in their Proposal. If it is significantly different, it is expected that the rationale for the changes will be explained.

5.2.7.2 Scheduling The presentation day, for each short-listed Proponent, is intended to take place over an eight-hour period. The Project Coordinator anticipates that the day will be organized as follows.

Time Activity 8:30 to 12:00 Concept presentation – with a 10 minute break.

12:00 to 1:00 Lunch.

1:00 to 3:00 Products demonstration and explanation of how the Proponent will integrate the proposed Products into the final System. Proponents are expected to clearly demonstrate how their proposed Solution meets the Business Requirements and is consistent with the Logical Components.

3:00 to 4:00 Proponent leaves the room and the Project Coordinator prepares questions.

4:00 to 5:00 Proponent answers questions with respect to their presentation.

5.2.7.3 Concept Presentation Content It is important for Proponents to remember that the Concept delivered at the Stage 3 presentations has to represent a more detailed understanding of the Project than in their written Proposals.

The short-listed Proponents will be required to deliver handouts of the presentations, along with any embedded speaking notes.

The key points that Proponents should anticipate addressing in their Concept presentations are enumerated below:

a) overview of the overall solution Concept including identification of constituent Products and/or custom-developed code;

b) mapping of Logical Component requirements to Products; and

SATP-151


c) product integration approach, including i. approach to translating between functionality of Products and/or custom-developed

code, and the required Logical Component interfaces, ii. approach to providing unified user interface, iii. approach to supporting user interface configurability, for example to accommodate

Jurisdictional differences in workflow or job duties, and Jurisdiction-specific ‘branding’ (e.g. Jurisdiction logo) of System,

iv. potential need for, and approach to, integration or synchronization between internal data stores of constituent Products and the external client and provider registries,

v. approach to support System configurability and the ability to separate the Logical Components,

vi. approach to integrating with Jurisdiction-specific security infrastructure, such as authentication, authorization, and logging, etc.,

vii. inherent support for standards (data, messaging and vocabulary) provided by the constituent Products, and

viii. estimated duration between contract signing and delivery of the Reference Implementation.

See section 5.7.2 for the draft criteria upon which the Concept presentations will be assessed.

Hard copies of the presentation materials for the attendees will be required; the expected quantity will be communicated prior to the Concept presentation. Soft copies of all material will also be required.

5.2.8 SYSTEM CONCEPT DEMONSTRATIONS

As described above, a demonstration of the proposed Products will be required as part of the Concept presentation. This is intended to provide a first glimpse from an end users’ perspective of the proposed System, and demonstrate the Proponent understanding of the issues with the existing GOTS products, as well as the functionality of their proposed components. Colleagues will be attending this portion of the Concept presentation.

5.2.9 PREFERRED PROPONENTS SELECTION

On completion of the evaluation process, the Project Coordinator will tabulate the evaluation results from Stage 1 and Stage 3 (see section 5.7.1.4 – Stage 3 evaluation criteria) of the Proponent Qualification Phase and rank the short-listed Proponents. The top two ranked short-listed Proponents will be deemed Preferred Proponents and will be invited to engage in the Joint Solution Definition Phase.

5.2.10 POST PRESENTATIONS AND DEBRIEFINGS Once the Preferred Proponents have been declared, a Joint Solution Definition Agreement will have to be executed by the Project Coordinator and each of the Preferred Proponents prior to commencing the Joint Solution Definition Phase activities.

In the event Joint Solution Definition Phase activities or negotiations with one of the Preferred Proponents fail, the Project Coordinator reserves the right to contact the next highest ranked

SATP-151


short-listed Proponent and invite them to engage in Joint Solution Definition Phase activities with the Project Coordinator.

Proponents who are not invited to the Joint Solution Definition Phase may request a debriefing session which will be scheduled by the Project Coordinator after the execution of the Final Contract.

5.3 JOINT SOLUTION DEFINITION PHASE The Joint Solution Definition Phase of the JSP process will require significant investment on the part of the Project Coordinator, the Jurisdictions and Infoway, as well as the Preferred Proponents. The Joint Solution Definition Agreement that is signed by the Project Coordinator with each of the Preferred Proponents will govern the conduct of the remaining phases of the JSP process.

Preferred Proponents are cautioned not to delay in finalizing the Joint Solution Definition Agreement, as once one Preferred Proponent has satisfactorily executed the Joint Solution Definition Agreement, the discovery cycle of the Joint Solution Definition Phase described in section 5.3.1 may begin immediately with that Preferred Proponent.

The following figure should be used as a guideline only. Modules and timelines may be modified as required by the Project.

Overall Timeframe

ICO Opens Defining the

Solution

Defining

Solution

Week 1

-2

Economic Model &

Deal Structure

28 days 7-21 days Discovery Cycle

14 days

A series of iterative workshops followed by synthesis session

Framing the

Solution

Framing the

Solution

Week 7

-8

Synthesize Solution

Week 9

-10

Optional Design

Module

Oth

er w

orks

hops

as

requ

ired

Week 3

-4

Business Processes

& TechnologyW

orks

hop

1

Wor

ksho

p 2

Comply with

Policy

Comply with

Policy

Week 5

-6Policy and

Compliance

Sliding Decision PointSliding Decision Point

Discovery Cycle

ICO Closes

Wor

ksho

p 4

the

Wor

ksho

p 3

Figure 17 – Joint Solution Definition Phase

The objective of the Joint Solution Definition Phase is to work with both Preferred Proponents to develop the Solution and economic model for the Project. These activities (and series of meetings) will be performed jointly with the Project Coordinator, its representatives and individuals from the Jurisdictions and Infoway, but independently with each Preferred Proponent.

This Solution is the platform that will be subject to due diligence and negotiations at the subsequent Due Diligence & Negotiation Phase of the JSP process.

SATP-151


There are four (4) key components, as follows, that describe how the Joint Solution Definition Phase will proceed.

5.3.1 DISCOVERY CYCLE The discovery cycle is a one time period of activity when Preferred Proponents are permitted access, at the Project Coordinator’s discretion, to staff, other representatives and individuals from the Jurisdictions and Infoway, documents, technology assets and records and software (where applicable) as well as information that a Preferred Proponent may feel is necessary in order to prepare for the process of creative Solution definition.

During the discovery cycle, the Information Control Office will facilitate the controlled exchange of confidential information between the Preferred Proponents and the Project Coordinator. Information requests are Proponent driven and will not be shared between Preferred Proponents. Preferred Proponents and their employees and contractors must sign a confidentiality agreement prior to accessing the Information Control Office. Details of the Information Control Office will be provided to the Preferred Proponents as the JSP process progresses.

5.3.2 DEFINING THE SOLUTION

This period of activity consists of a series of iterative Solution definition sessions designed to define the business and technical scope of the Project, The Preferred Proponents will be working independently from each other, with the Project Coordinator’s Project team, in jointly formulating a Solution to the Project objectives.

While the Concept provided at the Preferred Proponent’s presentation will be used as a basis for the Solution, it is possible that information gathered during the discovery cycle, or as a result of discussions with the Project Coordinator during this cycle, may result with an entirely different approach being considered.

The iterative series of meetings (which will take place over an 8 to 10 week period) are envisioned to concentrate on various aspects of the Solution building blocks. One or more synthesis sessions for each Preferred Proponent will be scheduled during this period so as to assess progress in the Solution definition process. A draft Joint Solution Definition schedule will be shared with the Preferred Proponents soon after they have been notified of their status in the JSP process.

5.3.3 FRAMING THE SOLUTION The joint solution definition sessions will be undertaken by the Representatives and resources from the Project Coordinator, the Jurisdictions and Infoway as well as the Preferred Proponent’s team. While the exact structure and form of the sessions will be decided during the initial joint solution definition kick-off meeting, it is anticipated that the activities cover the following four categories:

a) System architecture (Products and Contractor Code); b) project management and delivery methodology alignment; c) privacy and policy; and

SATP-151


d) economic model and deal structure.

Through the joint solution definition sessions, the Preferred Proponents will refine the architecture and design for the System. The joint solution definition outputs will be finalized and accepted as part of the final presentation. It is expected that the Preferred Proponents will provide a very high level of detail around key elements of the Solution including detail at the line item level in the economic model.

A series of synthesis sessions will take place during the Joint Solution Definition Phase after which the Preferred Proponents will present their final Solutions at the joint solution definition presentations. The evaluation committee will evaluate the final Solutions, as presented at the presentations and determine the Successful Proponent.

Once a Successful Proponent has been announced, the remaining Preferred Proponent will be designated as the ‘vendor-in-waiting’. In the event negotiations with the Successful Proponent fail or do not adequately progress, the Project Coordinator reserves the right to contact the ‘vendor-in-waiting’ and invite it to enter into the Due Diligence & Negotiation Phase.

5.3.4 JOINT SOLUTION DEFINITION PHASE PRESENTATION

Proponents should address the following areas in their Joint Solution Definition Phase activities and their final presentation of their approach to their Solution. The Project Coordinator reserves the right to alter these areas during the Joint Solution Definition Phase and the Project Coordinator will advise the Preferred Proponents accordingly.

a) An integrated architecture and design for the System, including i. specification of the System Components (versions / modules) that will be used in the

System, ii. logical design, iii. data architecture including a mapping from the System Components to the data

models, iv. application architecture, v. user interface design, vi. data integration / interfacing strategy and design, vii. configuration management approach, viii. technical architecture design, ix. training materials, and x. security and privacy architecture design;

b) A service delivery model outlining the methods, process, tools and resources required to provide ongoing solution maintenance services, including but not limited to a plan on how to incorporate input from users from all Jurisdictions;

c) A project charter for the subsequent integration project, including a project plan that encompasses i. coordination with standards development activities, ii. interdependencies, GANTT charts, etc., and iii. templates for training material, documentation and other major deliverables;

d) A project charter template for Jurisdictional Implementations; e) A maintenance and support model (including a proposal for how user input will be solicited

and incorporated into the ongoing maintenance, support and enhancement of the System);

SATP-151


f) A transparent and highly detailed economic and deal structure model, including but not limited to i. pricing model, ii. cost model, iii. risk sharing model, iv. service levels and associated economic factors, v. scope, vi. termination conditions, and vii. billing scheme;

g) Intellectual Property and licensing model including Product license and maintenance pricing and terms; and

h) Deal structure including Subcontractor composition, risk allocation, service levels, change management, privacy protection methodology, audit and reporting and default.

The presentation content will be incrementally refined through an iterative dialogue with the Project Coordinator during the Joint Solution Definition Phase.

Templates and specific requirements for the presentation will be made available at the commencement of the Joint Solution Definition phase.

5.4 DUE DILIGENCE & NEGOTIATION PHASE The Due Diligence & Negotiation Phase will begin with a period of due diligence where both the Successful Proponent and the Project Coordinator will engage in activities to ensure that the Solution developed during the previous Joint Solution Definition Phase is validated against detailed information.

There are three (3) key components that describe how the Due Diligence & Negotiation Phase will proceed.

5.4.1 VALIDATE COMMITMENT An early activity in this phase is validation of the prospective structure and of the Solution framework presented by the Successful Proponent entering into this phase. The Project Coordinator expects that at the commencement of the Due Diligence & Negotiation Phase a Letter of Intent will be signed by the Successful Proponent and an announcement made to the public. The Letter of Intent will make reference to the Successful Proponent’s Solution framework as the approach of choice.

A series of project management activities will take place to set the stage for detailed due diligence and negotiations. This includes establishment of the Project Coordinator’s and the Successful Proponent’s negotiating and supporting infrastructure (tools and resources), meeting schedules, subject areas and rules of engagement as applicable. An oversight process will be discussed and participation of decision makers for the duration of the phase agreed to prior to commencing with the due diligence process.

5.4.2 DUE DILIGENCE ASSESSMENT This period of activity is primarily for the Successful Proponent to detail its understanding of the parameters impacting successful delivery of the Solution formulated in the previous Joint

SATP-151


Solution Definition Phase. This includes detailed verification of information used to design the Solution, assumptions reviewed and accepted or referred to negotiations. The Project Coordinator may in addition, perform further due diligence on the Successful Proponent to verify its current financial and operating capacity to deliver on and/or commit to the statements made in the Solution framework.

5.4.3 CONFIRM SOLUTION On conclusion of the due diligence work, the Solution coming out of the previous Joint Solution Definition Phase will be refined, the deal structure model completed and prepared for incorporation into the Final Contract.

5.5 CONTRACT NEGOTIATION PHASE The Contract Negotiation Phase marks the final phase of the JSP process.

Activities will include interest based negotiations, a structured negotiation process and will require negotiation commitment both from the Project Coordinator and from the Successful Proponent. Concluding negotiations will in part be dependent on the Successful Proponent having those people responsible for delivery participating in negotiations, the obligation on the Successful Proponent to keep its Subcontractors involved and informed and timely escalation and resolution of issues.

Substantive activities will include final negotiation of the design and implementation parameters for the Solution and overall economic model and deal structure, governance and operational plans necessary to operate and maintain the System and provide the associated services.

The negotiations will also include discussion on opportunities and mechanisms for mutual re-negotiation of the Final Contract, to respond to changes in the parties' respective business environment, as the relationship evolves over the term of the Final Contract. Work on the Solution (including development of the System) will not start until the Final Contract has been executed with the Project Coordinator.

There are three (3) key components that describe how the Contract Negotiations Phase – Phase 4 will proceed.

5.5.1 DEAL STRUCTURING A period of deal structuring will take place once the Solution has been finalized and agreed upon. The final term sheet will be produced, contract structure determined and final decision to proceed with the Final Contract will be made.

5.5.2 NEGOTIATING AND DRAFTING THE AGREEMENT During this period of activity the Final Contract will be negotiated and drafted. Further details with respect to this Phase will be provided in the Joint Solution Definition Agreement.

SATP-151


5.5.3 FINALIZE AND SIGN CONTRACT Once the Final Contract is ready for execution, both the Project Coordinator and Successful Proponent will need to obtain the necessary approvals to sign the Final Contract. On signing, a public announcement may be made and implementation of the Final Contract will begin. Any public announcement by the Contractor is to be approved by the Project Coordinator before release.

5.6 DECISION POINTS The Project Coordinator reserves the right to apply a decision point at any time from the Joint Solution Definition Phase through to the end of the JSP process and either suspend, terminate or re-start discussions or negotiations with any of the Proponents. Any determination to invoke a decision point will reside with the Project Coordinator.

At various stages in the JSP process, the Project Coordinator may request that the Preferred Proponents or the Successful Proponent, as the case may be, prepare and deliver a presentation to the Project Coordinator so as to assess the progress of the activities to date. These presentations will be used to assess the state of the respective discussions and to determine whether the JSP process approach continues to be appropriate.

5.7 EVALUATION CRITERIA

5.7.1 PROPONENT QUALIFICATION PHASE - EVALUATION CRITERIA

As stated in section 5.1, selection of the Preferred Proponents will be based on an initial short-listing process of the written Proposals followed by Workshops and a subsequent Concept presentation where the Preferred Proponents are identified. (Please see section 5.2.2 for information regarding the role of a lead Proponent in the JSP process). The evaluation process will proceed as follows:

5.7.1.1 Mandatory Criteria All Proposals will be validated according to the mandatory criteria described below. Failure to satisfy any one or more of the mandatory criteria will result in disqualification from the JSP process.

Mandatory Criteria

1 Proposals must be received at the closing location prior to the specified closing time. 2 Proposals must be in English and not be submitted by mail, facsimile or e-mail. 3 Proposals must include a statement that the Proponent is not in receivership or insolvent. 4 Proposals must include a signed letter in substantially similar form to that of Appendix A.

5.7.1.2 Stage 1 Evaluation Criteria Proposals that have satisfied the mandatory criteria will be evaluated based on the Stage 1 desirable criteria listed in the following table.

SATP-151


Any Proponent who fails to meet any one of the minimum scores will be disqualified from the JSP process without further consideration.

On completion of the Stage 1 evaluation process, the scores will be tallied and Proponents ranked. Up to the four top ranked Proponents will be invited to participate in the Stage 2 Workshops. The remaining Proponents, who were not selected to proceed to Stage 2 Workshops, will be advised and offered debriefing sessions which will be held after the Final Contract has been executed.

Proponents should note that some sub-criteria of the evaluation criteria will be evaluated based on the skills and experience represented by the Proponent (lead). Other sections will be evaluated based on the combined skills brought by the overall Proponent (aggregate or consortia). In the case where an aggregate response is requested, Proponents should clearly identify to which organization(s) the response refers.

Section 5.8 Proponent Response Section provides detailed response guidelines and further information on each of the evaluation criteria outlined in the table below for this Stage 1 of the Proponent Qualification Phase.

Stage 1 Evaluation Criteria Minimum

Score Stage 1

Weighting

Capability (see section 5.8.3) a) Company profile (lead) b) Experience working with public and health sector clients (legislation, policies and regulations) (aggregate) c) Relevant experience in designing and implementing complex economic models, engaging in long term commercial arrangements and experience in deal structuring (lead) d) Demonstrated experience working with multi-disciplinary teams in complex system integration projects that support health related services (aggregate)

60% 40%

Capacity (see section 5.8.4) a) Describe the human resource capacity generally estimated to be required and that the Proponent intends to commit (aggregate) b) Describe the financial capacity of the Proponent and how the Proponent intends to meet the financial requirements of the Project (lead)

60% 30%

Commitment (see section 5.8.5) a) The Proponent’s long-term commitment to this Project, related work in public health, and the commitment of resources to engage in the JSP process to conclusion (aggregate) b) Commitment to the business relationship, and understanding of the business environment and objectives in section 3.1.3 (lead)

60% 20%

c) Demonstrated commitment to privacy compliance, including but not limited to meeting legislative, regulatory, policy and contractual obligations for privacy protection (aggregate)

d) Demonstrated ability to negotiate fair and workable agreements including with respect to Intellectual Property ownership (lead)

e) Demonstrated ability and approach to deliver quality products on time and within budget (lead)

SATP-151


Stage 1 Evaluation Criteria Minimum Score

Stage 1 Weighting

High Level Solution Vision (see section 5.8.6) a) Provide a high level Solution vision relevant to the objectives (see section 3.1.3), Business Requirements and Logical Components for the Project (aggregate)

N/A 10%

b) Proposed approach to pricing and risk sharing (lead)

5.7.1.3 Stage 2 Evaluation Criteria All short-listed Proponents will be invited to participate in individual Stage 2 Workshops with the Project Coordinator. Immediately prior to the Workshops, the Restricted Documents Room, (if needed) opens.

The Workshops provide an opportunity for the short-listed Proponents to explore the Project and Solution requirements and to apply their knowledge in producing a Concept for delivery at the Stage 3 presentation.

Proponent activities during Stage 2 will not be evaluated.

5.7.1.4 Stage 3 Evaluation Criteria On completion of Stage 2 Workshops of the Proponent Qualification Phase, short-listed Proponents will be asked to develop a Concept for presentation to the evaluation committee. Section 5.2.7 provides a description of the presentation format.

The Stage 3 Concept presentation will account for 70% of the total evaluation score for Stage 3. The capability, capacity and commitment scores from Stage 1 (but not the high level solution vision score) will constitute the remaining 30% of the score at Stage 3, with the separate weightings for each of capability, capacity and commitment being based upon the proportionate weightings applied in the Stage 1 evaluations.

The Project Coordinator will finalize the evaluation criteria for Stage 3 prior to opening of the Proposals and will distribute the finalized evaluation criteria to the short-listed Proponents. The current draft Stage 3 Evaluation Criteria (Concept) is outlined in the following table.

DRAFT Stage 3 Evaluation Criteria

Stage 3 Weighting

Stage 1 capability, capacity and commitment score carried forward 30%

Proposed team experience, cohesiveness, professionalism, and ability 20%

Quality of proposed Solution and responsiveness to requirements 40%

Economic model and deal structure 10%

The Concept to be delivered at the presentations must address the finalized criteria. Proponents are required to provide a written (and electronic) version of the Concept (slides) presented to the evaluation committee.

The Project Coordinator expects that the Concept delivered in the presentation will represent a well-evolved System design, which clearly incorporates Products that will form the basis for the System. The Concept should also provide an outline of an implementation framework and contractual structure that will enable rapid adoption of the eventual Solution

SATP-151


by the Jurisdictions. This implementation framework should also reflect the objectives of the overall Project.

The Project Coordinator, however, acknowledges that the final Solution may be different from the Concept following the Joint Solution Definition Phase.

On completion of the Stage 3 evaluation process, the scores will be tallied, and the short-listed Proponents will be ranked. The top 2 (two) short-listed Proponents will be deemed the Preferred Proponents and invited to the Joint Solution Definition Phase.

5.7.2 JOINT SOLUTION DEFINITION PHASE – EVALUATION CRITERIA Once the Preferred Proponents have been identified, a series of joint solution definition activities will take place that culminates with each Preferred Proponent developing their Solution for presentation to the Project Coordinator’s evaluation committee. The evaluation criteria in the table below are draft. The Project Coordinator reserves the right to alter these criteria provided it does so prior to the commencement of the Joint Solution Definition Phase, in which case, written notice of any alterations will be provided to the Preferred Proponents prior to the commencement of the Joint Solution Definition Phase.

Draft Joint Solution Definition Phase Evaluation Criteria

1 Privacy compliance 2 System design quality and responsiveness to requirements 3 Risk and relationship management 4 Economic model and deal structure 5 Intellectual Property management

The evaluation committee will convene and determine which Preferred Proponent will be deemed the Successful Proponent and thereby invited to sign a Letter of Intent with the Project Coordinator. Determination of the Successful Proponent will be made in accordance with evaluation criteria.

On completion of the evaluation, the Project Coordinator will announce the Successful Proponent and the Due Diligence & Negotiation Phase will commence as described in section 5.4.

5.8 PROPONENT RESPONSE SECTION

5.8.1 PROPOSAL FORMAT GUIDELINES

Proponents are asked to assist the evaluation committee by structuring their Proposals in a consistent manner. The suggested Proposal format is described below:

a) a Proposal cover page; b) signed letter in substantially similar form to that of Appendix A; c) table of contents; d) executive summary;

SATP-151


e) statement that the Proponent is not in receivership or insolvent; f) body of the Proposal; g) corporate references; and h) appendices.

5.8.2 RESPONSE GUIDELINES

Proponents should provide as much detail as necessary in order to demonstrate (e.g. not how to do, but have done) expertise in the pertinent criteria.

5.8.3 CAPABILITY

a) Company Profile (lead) Each Proponent should include a Proponent profile that provides background information on the Proponent, including but not limited to the year they were established, corporate ownership and hierarchy, jurisdiction of incorporation, and corporate strategic direction.

b) Experience working with public and health sector clients (legislation, policies and regulations) (aggregate) Each Proponent should describe its understanding of the unique challenges and issues in working within the public sector, the health sector and in particular the public health sector, and how they propose to overcome and address them. Proponents should also demonstrate (using real examples), their ability to work with the public sector and the health sector in addressing the business needs of the Project.

c) Relevant experience in designing and implementing complex economic models, engaging in long term commercial arrangements and experience in deal structuring (lead) Using past or current examples, Proponents should describe their ability to take business issues and conceptualize and produce complex economic models with the flexibility to handle changes in program deliverables over a long-term commercial arrangement. Proponents should also describe how they have shared the risks and rewards in long-term commercial arrangements and discuss their success in maintaining a mutually beneficial relationship.

d) Demonstrated experience working with multi-disciplinary teams in complex system integration projects that support health related services (aggregate) Proponents should describe their experience in working with multi-disciplinary teams (e.g. physicians, nurses, lab technicians) inside and across multiple Jurisdictions, particularly in a health care environment in complex system integration projects. Proponents should describe their experience with applying information technology solutions to meet health care business requirements. Proponents should describe their experience, challenges encountered and lessons learned with integrating pre-existing products with custom development to deliver a complex, robust system. Proponents should also provide examples of those initiatives and outcomes most relevant to this Project.

SATP-151


5.8.4 CAPACITY

a) Describe the human resource capacity generally estimated to be required and that the Proponent intends to commit (aggregate) The Project Coordinator anticipates an aggressive JSP process, that the System be deployment-ready in 2006, and that Jurisdictional Implementation Services and Application Management Services may be required in multiple Jurisdictions, simultaneously. Each Proponent should describe generally the resources that it estimates are required to meet these timelines and whether it will in fact have such resources available and committed to the Project, including having the System deployment-ready on time and on budget. Each Proponent should also describe its resource capacity to provide maintenance and support services as well as do simultaneous multiple Jurisdictional Implementations.

b) Describe the financial capacity of the Proponent and how the Proponent intends to meet the financial requirement of the Project (lead) Each Proponent should provide an overview of the corporate information including size, market and geographic coverage. Each Proponent should include a copy of their latest audited financial statements. As part of the evaluation the Project Coordinator will review the Proponent’s financial ability to manage large projects.

In addition, each Proponent should describe the financial resources that it estimates are required to meet aggressive timelines and potentially implement in multiple Jurisdictions simultaneously. Describe the Proponent’s financial capacity to meet these requirements.

5.8.5 COMMITMENT

a) The Proponent’s long-term commitment to this Project, related work in public health, and the commitment of resources to engage in the JSP process to conclusion (aggregate) Each Proponent should provide its vision, strategy and commitment as it relates to the public health market, as well as the Proponent’s long-term intentions to participate in this market.

In addition, the JSP process will require a substantial commitment from the Proponents that advance to later stages and phases. It is critical to the Project Coordinator that those Proponents who advance to later stages and phases of the JSP process will be fully dedicated and committed to the JSP process.

Proponents are asked to consider the magnitude of the JSP process and explain any steps or assurances that a Proponent would take or provide to demonstrate the Proponent’s commitment to the JSP process.

b) Commitment to the business relationship, and understanding of the business environment and objectives in section 3.1.3 (lead) Proponents should explain their understanding of the key success factors in building a long-term, successful business relationship with the Project Coordinator. Proponents should describe major challenges, issues and opportunities that are likely to arise, and how they could be addressed in order to maintain a healthy, long-term relationship.

SATP-151


c) Demonstrated commitment to privacy compliance, including but not limited to meeting legislative, regulatory, policy and contractual obligations for privacy protection (aggregate) Each Proponent should provide up to 2 examples of work it has done with sensitive, confidential and/or personal information on behalf of a client. This includes descriptions of quality assurance procedures and practices they had in place to provide protection and compliance for their own information and that of their clients. In addition, the Proponent should describe its capacity and willingness to meet stringent privacy requirements and comply with privacy legislation in relation to this Project.

d) Demonstrated ability to negotiate fair and workable agreements including with respect to Intellectual Property ownership (lead) Describe how the Proponent has approached negotiations on similar types of projects. Describe how the Proponent intends to generally approach negotiations, including how they intend to address the Intellectual Property objectives as set forth in section 3.2.4.9.

e) Demonstrated ability and approach to deliver quality products on time and within budget (lead) Each Proponent should provide up to 2 examples of work it has successfully delivered within demanding time and budget constraints. If possible, examples related to public health are of particular interest.

5.8.6 HIGH LEVEL SOLUTION VISION

a) Provide a high level Solution vision relevant to the objectives (see section 3.1.3) and Business Requirements and Logical Components for the Project (aggregate) Proponents should include in their Proposal an initial description of their proposed Solution, which relates it to the requirements for the Project. Proponents should briefly explain their vision for the evolution of the Project, including the challenges and opportunities for the future. Proponents are to include the principles they will use to ensure the Project is successful over the term of the Final Contract.

Included should be a description of the System Components, and their inter-relation and how they support the envisioned Logical Components that would comprise their proposed System. A high-level preliminary project plan should identify resources (roles and FTE’s), critical dependencies and milestones. The project plan should be provided with the Proponent response in electronic format in a Microsoft Project native format (*.mpp).

b) Proposed approach to pricing and risk sharing (lead) The Proponent should describe at a high level their proposed approach to pricing and risk sharing with respect to each of the elements of the Solution. See section 3.2.4 for descriptions of the specific elements of the Solution.

Although in the Proponent Qualification Phase, Proponents are being asked for only high-level approaches to the economic model. Proponents should note that later in the JSP process the Proponents will be required to provide progressively more transparent pricing as well as costing at the highly detailed, line-item level. In addition, the Proponents will be required to provide progressively more detailed pricing and costing for Ancillary Services.

SATP-151


5.8.7 CORPORATE REFERENCES Proponents should provide three (3) references that are directly related to a project or service delivery that are as similar as possible to the size and/or scope of the Project.

Proponents should detail the contact name, phone number, and the duration and description of the project or service delivery.

5.8.8 STATEMENT THAT PROPONENT IS NOT IN RECEIVERSHIP OR INSOLVENT

As described in section 5.7.1.1 Mandatory Criteria.

5.8.9 SIGNED LETTER IN SUBSTANTIALLY SIMILAR FORM TO THAT OF APPENDIX A As described in section 5.7.1.1 Mandatory Criteria.


SATP-151


APPENDICES

APPENDIX A – PROPOSAL COVERING LETTER Letterhead or Proponent’s name and address

Date

Ministry of Labour and Citizens’ Services Strategic Acquisitions and Technology Procurement Branch c/o Commissionaires Desk 1st Floor, 548 Michigan Street Victoria, British Columbia, V8V 1S3 Attention: Brad Boquist

Dear Sir/Madam:

Subject: Joint Solution Procurement Request for Pan-Canadian Public Health

Communicable Disease Surveillance and Management Project No. SATP-151 including any amendments (the “JSRFP”).

The enclosed Proposal is submitted in response to the above-referenced JSRFP. Through submission of this Proposal we agree to be bound by all of the terms and conditions of the JSRFP.

We have carefully read and examined the JSRFP and have conducted such other investigations as were prudent and reasonable in preparing the Proposal. We agree that subject to the terms and conditions of the JSRFP we shall also be bound by statements and representations made in this Proposal.

Yours truly,

_____________________________

Signature

Name: _______________________

Title: _________________________

Legal name of Proponent: __________________________________

Date: ________________________

SATP-151


APPENDIX B – JOINT SOLUTION DEFINITION AGREEMENT The Preferred Proponents must enter into a Joint Solution Definition Agreement with the Project Coordinator that will govern the actions of the Project Coordinator and the Preferred Proponents during the Joint Solution Definition Phase, the Due Diligence & Negotiation Phase and the Contract Negotiation Phase. The Joint Solution Definition Agreement will include, but not be limited to, the provisions summarized below:

a) general representations, warranties and covenants; b) conflict of interest provisions including representations and warranties in respect of conflicts

and a requirement to implement a conflicts plan; c) evaluation process including formation of the evaluation committee; certain evaluation

criteria used to evaluate the Preferred Proponents; and the debriefing process; d) the right of the Project Coordinator to amend, modify or suspend the JSP process or

suspend or cancel negotiations with a Preferred Proponent; e) right of the Project Coordinator to designate an alternate Preferred Proponent; f) obligation of Preferred Proponents to bear all of their own expenses; g) restriction on lobbying and on any contact with Ministry or government personnel except as

authorized by the Project Coordinator; h) due diligence covenants including certain rights of the Preferred Proponent to seek

information from the Project Coordinator and the right of the Project Coordinator to consult outside references and obtain third party information regarding the Preferred Proponent;

i) the Project Coordinator being under no obligation to enter into a Final Contract; j) no obligation for the Final Contract to be based upon the JSRFP and the ability of the

Project Coordinator and the Preferred Proponent to enter into arrangements that exceed or only include part of the scope contemplated by the JSRFP;

k) duty of the Preferred Proponent to act in good faith throughout the JSP process; l) information Control Office management provisions; m) confidentiality provisions including (a) the Project Coordinator agreeing to keep detailed

Solutions of the Preferred Proponent confidential subject to reasonable exceptions in order to facilitate the JSP process, the Freedom of Information and Protection of Privacy Act and qualifications similar to those set forth in this JSRFP document; and (b) the parties agreeing on processes for information to be released in certain circumstances to other stakeholders;

n) privacy provisions; o) Intellectual Property provisions including ownership rights, representations, warranties,

indemnities and cross licensing provisions; p) the term of the JSP process, default provisions, termination rights and consequences of

termination or breach; q) a summary of certain terms that would be required to be included in the Final Contract

including risk allocation, audit and reporting, limited force majeure, change control, service levels, default, privacy and confidentiality, proprietary rights, acceptance testing, termination services, dispute resolution and Project Coordinator funding restrictions;

r) no representations or warranties from the Project Coordinator; no liability of the Project Coordinator for indirect or similar types of damages; and a limit of liability of the Project Coordinator equal to the reasonable direct expenses incurred by the Preferred Proponent;

s) no liability for errors or inaccuracies of the Project Coordinator;

SATP-151


t) no assignment right for the Preferred Proponent; u) manner in which consortiums and their members are obligated to the Project Coordinator;

and v) general provisions including notice, governing law, entire agreement, nature of relationship,

survival and execution.


SATP-151


APPENDIX C – HOW TO ACCESS THE PROJECT EXTRANET See attachment.



APPENDIX D – REQUIREMENTS DEFINITION See attachment.



APPENDIX E – IPHIS ANALYSIS See attachment.



APPENDIX F – INITIAL APPLICATION ARCHITECTURE DOCUMENT See attachment.



APPENDIX G – INITIAL DATA ARCHITECTURE DOCUMENT See attachment.



APPENDIX H – INITIAL LOGICAL DESIGN DOCUMENT See attachment.



APPENDIX I – PRIVACY PROTECTION SCHEDULE

This Schedule forms part of the agreement between Her Majesty the Queen in right of the Province of British Columbia represented by____________________________________ (the “Province”) and ______________________________(the “Contractor”) respecting __________________________ (the “Agreement”). Definitions 1. In this Schedule,

a) “Act” means the Freedom of Information and Protection of Privacy Act (British Columbia), as amended from time to time;

b) “contact information” means information to enable an individual at a place of business to be contacted and includes the name, position name or title, business telephone number, business address, business email or business fax number of the individual;

c) “personal information” means recorded information about an identifiable individual, other than contact information, collected or created by the Contractor as a result of the Agreement or any previous agreement between the Province and the Contractor dealing with the same subject matter as the Agreement.

Purpose 2. The purpose of this Schedule is to:

(a) enable the Province to comply with its statutory obligations under the Act with respect to personal information; and

(b) ensure that, as a service provider, the Contractor is aware of and complies with its statutory obligations under the Act with respect to personal information.

Collection of personal information 3. Unless the Agreement otherwise specifies or the Province otherwise directs in writing, the Contractor

may only collect or create personal information that is necessary for the performance of the Contractor’s obligations, or the exercise of the Contractor’s rights, under the Agreement.

4. Unless the Agreement otherwise specifies or the Province otherwise directs in writing, the Contractor

must collect personal information directly from the individual the information is about. 5. Unless the Agreement otherwise specifies or the Province otherwise directs in writing, the Contractor

must tell an individual from whom the Contractor collects personal information: (a) the purpose for collecting it; (b) the legal authority for collecting I; and (c) the title, business address and business telephone number of the person designated by the

Province to answer questions about the Contractor’s collection of personal information. Accuracy of personal information 6. The Contractor must make every reasonable effort to ensure the accuracy and completeness of any

personal information to be used by the Contractor or the Province to make a decision that directly affects the individual the information is about.

Requests for access to personal information 7. If the Contractor receives a request for access to personal information from a person other than the

Province, the Contractor must promptly advise the person to make the request to the Province unless the Agreement expressly requires the Contractor to provide such access and, if the Province has advised the Contractor of the name or title and contact information of an official of the Province to whom


such requests are to be made, the Contractor must also promptly provide that official’s name or title and contact information to the person making the request.

Correction of personal information 8. Within 5 business days of receiving a written direction from the Province to correct or annotate any

personal information, the Contractor must annotate or correct the information in accordance with the direction.

9. When issuing a written direction under section 8, the Province must advise the Contractor of the date

the correction request to which the direction relates was received by the Province in order that the Contractor may comply with section 10.

10. Within 5 business days of correcting or annotating any personal information under section 8, the

Contractor must provide the corrected or annotated information to any party to whom, within one year prior to the date the correction request was made to the Province, the Contractor disclosed the information being corrected or annotated.

11. If the Contractor receives a request for correction of personal information from a person other than the

Province, the Contractor must promptly advise the person to make the request to the Province and, if the Province has advised the Contractor of the name or title and contact information of an official of the Province to whom such requests are to be made, the Contractor must also promptly provide that official’s name or title and contact information to the person making the request.

Protection of personal information 12. The Contractor must protect personal information by making reasonable security arrangements against

such risks as unauthorized access, collection, use, disclosure or disposal, including any expressly set out in the Agreement.

Storage and access to personal information 13. Unless the Province otherwise directs in writing, the Contractor must not store personal information

outside Canada or permit access to personal information from outside Canada. Retention of personal information 14. Unless the Agreement otherwise specifies, the Contractor must retain personal information until directed

by the Province in writing to dispose of it or deliver it as specified in the direction. Use of personal information 15. Unless the Province otherwise directs in writing, the Contractor may only use personal information if that

use is: (a) for the performance of the Contractor’s obligations, or the exercise of the Contractor’s rights, under

the Agreement; and (b) in accordance with section 13.

Disclosure of personal information 16. Unless the Province otherwise directs in writing, the Contractor may only disclose personal information

inside Canada to any person other than the Province if the disclosure is for the performance of the Contractor’s obligations, or the exercise of the Contractor’s rights, under the Agreement.

17. Unless the Agreement otherwise specifies or the Province otherwise directs in writing, the Contractor

must not disclose personal information outside Canada. Inspection of personal information 18. In addition to any other rights of inspection the Province may have under the Agreement or under

statute, the Province may, at any reasonable time and on reasonable notice to the Contractor, enter on the Contractor’s premises to inspect any personal information in the possession of the Contractor or any of the Contractor’s information management policies or practices relevant to its management of


personal information or its compliance with this Schedule and the Contractor must permit, and provide reasonable assistance to, any such inspection.

Compliance with the Act and directions 19. The Contractor must in relation to personal information comply with:

(a) the requirements of the Act applicable to the Contractor as a service provider, including any applicable order of the commissioner under the Act; and

(b) any direction given by the Province under this Schedule.

20. The Contractor acknowledges that it is familiar with the requirements of the Act governing personal information that are applicable to it as a service provider.

Notice of non-compliance 21. If for any reason the Contractor does not comply, or anticipates that it will be unable to comply, with a

provision in this Schedule in any respect, the Contractor must promptly notify the Province of the particulars of the non-compliance or anticipated non-compliance and what steps it proposes to take to address, or prevent recurrence of, the non-compliance or anticipated non-compliance.

Termination of Agreement 22. In addition to any other rights of termination which the Province may have under the Agreement or

otherwise at law, the Province may, subject to any provisions in the Agreement establishing mandatory cure periods for defaults by the Contractor, terminate the Agreement by giving written notice of such termination to the Contractor, upon any failure of the Contractor to comply with this Schedule in a material respect.

Interpretation 23. In this Schedule, references to sections by number are to sections of this Schedule unless otherwise

specified in this Schedule. 24. Any reference to the “Contractor” in this Schedule includes any subcontractor or agent retained by the

Contractor to perform obligations under the Agreement and the Contractor must ensure that any such subcontractors and agents comply with this Schedule.

25. The obligations of the Contractor in this Schedule will survive the termination of the Agreement. 26. If a provision of the Agreement (including any direction given by the Province under this Schedule)

conflicts with a requirement of the Act or an applicable order of the commissioner under the Act, the conflicting provision of the Agreement (or direction) will be inoperative to the extent of the conflict.

27.The Contractor must comply with the provisions of this Schedule despite any conflicting provision of this Agreement or the law of any jurisdiction outside Canada.