RFR Exposure Notification Project FINAL 006.docx

THE COMMONWEALTH OF MASSACHUSETTS

COMMONWEALTH HEALTH INSURANCE CONNECTOR AUTHORITY,

ON BEHALF OF THE

COMMONWEALTH OF MASSACHUSETTS DEPARTMENT OF PUBLIC HEALTH

Request for Response (RFR)

Document Title:

EXPOSURE NOTIFICATIOn APPLICATION PROJECT released on November 13, 2020

Please Note: This is a single document associated with a complete Bid (also referred to as Solicitation) that can be found on www.COMMBUYS.com. All Bidders are responsible for reviewing and adhering to all information, forms and requirements for the entire Bid, which are all incorporated into the Bid. Bidders may also contact the COMMBUYS Helpdesk at COMMBUYS@state.ma.us or the COMMBUYS Helpline at 1-888-MA-STATE. The Helpline is staffed from 8:00 AM to 5:00 PM Monday through Friday Eastern Standard or Daylight time, as applicable, except on federal, state and Suffolk county holidays.

Table of Contents

Contents

RFR Introduction and General Description Procurement Scope and Description Through this RFR, the Commonwealth Health Insurance Connector Authority (the “Health Connector”), acting on behalf of the Commonwealth’s Department of Public Health (“DPH”), will accomplish three separate but related workstreams for the purpose of informing future Commonwealth policy regarding the use of Bluetooth-based automated exposure notification (“EN"). The combination of Workstreams #1 through #3 is referred to herein as the “Exposure Notification Application Project.”

The overarching goal of this RFR is to validate the efficacy, security, privacy and equity of the Apple/Google Exposure Notifications System (“ENS”) and the EN Express native functionality. (Background information on ENS and EN Express is provided in Section 1.2, below). The information obtained through this RFR will inform the Commonwealth’s decision as to whether to implement an automated exposure notification solution, and, if so, will help to inform key decisions around its implementation. At the end of the Exposure Notification Application Project described in this RFR, the Commonwealth will either decide to withhold approval of the use of Bluetooth-based exposure notification in the Commonwealth, or will approve the use of one method of exposure notification (which may involve multiple technologies), and issue a second solicitation for the implementation of such method.

Key questions that the Commonwealth seeks to address through the Exposure Notification Application Project and related efforts include, but are not limited to, those that follow. Note that some of these questions will be addressed through workstreams that are not included in this RFR and are beyond its scope.

Efficacy

· To assist the Commonwealth in better understanding the extent to which Bluetooth exposure notifications increase the impact of manual contact tracing efforts on the mitigation of the spread of COVID-19. The Commonwealth seeks to understand whether EN solutions increase the number of contacts identified that have been exposed to COVID-19 and/or decrease the time it takes to notify a contact of an exposure? The Commonwealth will not provide identifiable COVID-19 surveillance data or other identifiable information to the successful bidders.

· How accurate are EN notifications? What are the rates of false positive notifications and false negatives?

· What configuration parameters optimize the performance of EN technology?

· Under what conditions is EN technology more/less accurate?

· Are there features not present in EN Express that meaningfully and demonstrably impact the efficacy of EN technology that should be evaluated by the Commonwealth?

Integration

· To what extent can Bluetooth exposure notifications complement and integrate with the existing legal structure, policies, processes and technologies already used in Massachusetts? What is the best way of integrating Bluetooth exposure notifications into existing systems/processes?

· What are the various operational, maintenance, and cost elements the Commonwealth would need to consider in order to deploy Bluetooth exposure notifications statewide?

Public response

· What is the public perception of Bluetooth exposure notification technology in Massachusetts?

· What are the most effective ways to encourage adoption of EN technology?

· How does the public health effectiveness of EN scale with the level of user adoption?

· What are reasonable target adoption rates of EN technology in Massachusetts?

· What impact do Bluetooth exposure notifications have on the equity of the Commonwealth’s COVID-19 response? Are there strategies to deploy EN technology to improve equity in the Commonwealth’s COVID-19 response?

Privacy/security

· What are the privacy/security considerations of deploying Apple/Google EN Express in Massachusetts?

· What are the privacy/security considerations of deploying Third-Party ENS Apps and Third-Party Companion Apps in Massachusetts?

Details on the three workstreams for the Exposure Notification Application Project are as follows.

Workstream #1: Pilot Project to Validate EN Express.

The Health Connector is seeking Bidders that will execute a pilot in Massachusetts using EN Express in general, and in particular in Massachusetts, to answer key research questions and/or trial the technology for a specific community or region (the “MA EN Express Pilot”).

The pilot shall seek to answer key questions around impact of EN Express, consumer adoption and user acceptance, integration with public health processes, or other topics. Bidders will propose pilot design, the key research questions at hand, the proposed methodology for implementing the pilot, and the metrics for measuring success of the pilot, and, to the extent said proposal involves research with human subjects, will obtain appropriate Institutional Review Board review and approval.

EN Express was recently released as native functionality on iOS and Android operating systems in September 2020; this workstream can address key questions related to its deployment prior to any full-scale roll out of EN Express in the Commonwealth.

The Health Connector seeks communities – including but not limited to colleges and universities, municipalities, or employers – that have the organizational capability to introduce a new technology on a pilot basis at adequate scale to produce meaningful results, assess success, and report on results.

The Health Connector anticipates awarding 2-3 contracts under Workstream #1 but may award more or fewer.

The Commonwealth is considering five tiers of success criteria against which to evaluate exposure notification technology, based on a framework developed by MIT Lincoln Laboratory, set forth in Table 1 below. It is not expected that all five tiers will be in scope for the proposed pilot projects in response to this RFR.

Table 1. Pilot Success Criteria

· Proximity detections

· Notification timeliness

· Rates of false positive and false negative

Many pilots and full-scale implementations of EN technology in other jurisdictions have addressed questions related to Technical Success; the Commonwealth will leverage these existing data and insights to inform its own strategy. Workstream #1 Bidders are not required to propose to test the technical success of EN Express during their pilots, but may offer, in their bid, a proposal about how EN Express could be piloted to assess technical success. The Health Connector will consider whether to include assessment of technical success in the pilots conducted by such Bidders.

· Time from test result to contact notification timeliness / lag

· Identification of unique contacts, beyond those identified through manual contact tracing

· Security & privacy assessments indicate no concerns Critical component of MA EN Express Pilot

· Onboarding time

· Notification clarity and usability

· User perception

· Impact on perception of manual contact tracing program

· Key elements that drive adoption across diverse populations and communities Critical component of MA EN Express Pilot

4) Impact Success: Does EN Express increase the epidemiologic effectiveness of the Commonwealth’s response to COVID-19?

· Reduction in infection rate

This is a critically important area of inquiry but it may not be feasible to adequately assess in a short-duration pilot. The Health Connector welcomes bids that address this success tier, and will favor such bids, but does not require that bids or the resulting pilots address it.

5) Policy Success: Is EN Express an effective and efficient policy tool for mitigating the spread of COVID-19 in Massachusetts?

· Daily case goals

· PPE / surge goals

· Test timeliness goals

· Lockdown / opening goals This is a critically important area of inquiry but may not feasible to adequately assess in a short-duration pilot. The Health Connector welcomes bids that address this success tier, but does not require that bids or the resulting pilots address it.

A signal virtue of EN technology is that much of the data generated by its end users is accessible neither by the developers of such technology nor by public health and other public authorities. Workstream #1 Bidders should not interpret any language in this RFR as a signal that the Commonwealth wishes them to provide the Commonwealth with information created by the EN technology that is intended by the developers of such technology to remain stored on users’ phones. Thus, any Workstream #1 pilot must focus solely on data collected by the winning Bidder through the voluntary cooperation of fully informed data subjects. The Commonwealth will not award an agreement to a winning Bidder who proposes to tamper with the privacy-protecting features of such technology, or proposes a pilot inconsistent with the terms of this paragraph, and the agreement of any winning Bidder who attempts such tampering outside the scope of their agreement will be subject to termination without notice.

In addition, Bidders should note that although multiple pilots of ENX can be conducted in the Commonwealth, each must use the same configuration files (technical parameters). Multiple winning Bidders can pilot under Workstream #1 in multiple communities, but each winning Bidder conducting a pilot will need to use the same configuration file.

Workstream #2. Discovery on Third-Party ENS Apps and Third-Party Companion Apps.

This workstream will provide an opportunity for developers of Third-Party ENS Apps and Third-Party Companion Apps to articulate and quantify the characteristics of the tools they have developed. The Health Connector is especially interested in understanding how each Third-Party ENS App or Third-Party Companion App provides special benefits beyond those offered by the EN Express native functionality.

As noted below, the Health Connector will require a brief video or other presentation to be submitted with the Bid. Winning Bidders will provide a more comprehensive demonstration presentation or video as part of the Workstream deliverables. In addition, Bidders that are selected under this RFR may have the opportunity to provide an oral presentation to the Health Connector to describe their solution and respond to the Health Connector’s questions. Bidders are encouraged to present the results from previous pilots or implementations.

In addition, Bidders may optionally submit proposals for a new pilot of the Third-Party ENS App or Third- Party Custom App to be conducted in Massachusetts that would seek to demonstrate the benefits of the App to the Commonwealth and answer key research questions that have yet to be addressed in other jurisdictions. Workstream #2 Bidders who seek to pilot a Third-Party ENS App or Third-Party Custom App must bid on Workstream #1, except that the focus of their pilot will be the Third-Party ENS App or Custom App rather than ENX. With this exception, in the event that Workstream #2 Bidders propose a pilot, they shall be subject to the same evaluation criteria described in this RFR for Workstream #1.

Through this Workstream #2, the Health Connector is interested in gaining a deeper understanding of 1) Third-Party ENS Apps that have already undergone implementation as of the date on which this RFR is issued, and 2) Third-Party Companion Apps that have already been implemented or that are in development. The Health Connector is also interested in Third-Party ENS Apps and Third-Party Companion Apps that will work not only on smartphones but also on Bluetooth-enabled wearable devices as an approach to maximizing equity and participation.

In addition, the Health Connector is interested in tools that do not perform digital contact tracing but can be useful public health tools in enabling the contact tracing process (e.g., tools that enable individuals to recall where they were over the past 14 days, should they be contacted by a contact tracer.)

The Health Connector is also interested in understanding how Third-Party ENS Apps and/or EN Express might encourage individuals to communicate with state and local public health authorities in the event that an individual who may have been exposed to COVID-19 but is not otherwise in the manual contact tracing system is identified through use of these technologies.

Workstream #3: Privacy and Security Review.

The winning Bidders will conduct a thorough privacy and security review of the Apple/Google EN Express and, as appropriate, Third-Party ENS Apps or Third-Party Companion Apps. Workstream #3 includes code review, actual assessment of the privacy and security components of EN Express and providing comprehensive recommendations for additional privacy and security assessment and review that will be needed prior to a full-scale deployment of an exposure notification tool in the Commonwealth.

Bidders on Workstream #3 should assume that their initial assignment will be to conduct the privacy and security review of EN Express. The Health Connector may ask the Bidders awarded Workstream #3 to include in their privacy and security review up to one specific Third-Party ENS App and/or Third-Party Companion App, pending the selections made in Workstreams #1 and 2. This may include code review and assessment, and a review of privacy and security considerations from any implementations, pilot projects, or other results from other jurisdictions, delivered by Bidders responding to Workstream #2. The Health Connector will work with Bidders awarded Workstream #3 to ensure that their review of a Third-Party ENS App and/or Third-Party Companion App is conducted in a time and manner that does not unduly burden the Bidder.

All three of these workstreams within the Exposure Notification Application Project will be conducted simultaneously and at no cost to the Commonwealth.

Background Information The Community Tracing Collaborative.

Manual contact tracing is a principal method of COVID-19 containment in the Commonwealth and elsewhere. In response to the COVID-19 pandemic, the Commonwealth created a Command Center led by the Secretary of its Executive Office for Health and Human Services (the “Command Center”). Acting under the auspices of the Commonwealth COVID Command Center and DPH, and partnering with local boards of public health, the Health Connector created a contact tracing center known as the Community Tracing Collaborative (“CTC”) for purposes of supplementing the contact tracing work performed by the Commonwealth’s local health departments. The CTC is staffed and supported by Partners in Health, Accenture, Inc., Commonwealth Enterprise Group, Inc., and multiple vendors of software as a service. None of the vendors currently supporting the CTC is eligible to bid on this RFR.

Automated Contact Tracing.

In addition to manual contact tracing efforts, some government entities, including states across the US and countries around the world, are proceeding with technology-enabled exposure notification solutions. These automated exposure notification solutions are new, and governments are determining how they best fit into their own public health systems.

The Apple/Google Exposure Notification System, the ENS API and Third-Party Custom Apps.

Apple, Inc., a California corporation with its headquarters located at One Apple Park Way, Cupertino, CA, (“Apple”), and Google, LLC, a California corporation with its headquarters located at 1600 Amphitheatre Parkway, Mountain View, CA, (“Google”) have both developed operating system-level application program interfaces (“APIs”) that support automated contact tracing. The Apple and Google tools are referred to as the Apple/Google Exposure Notifications System (“ENS”). The ENS API supports the notification of individuals with an Apple or Google mobile device running current versions of either the iOS or Android operating systems who have been recently proximate to another user that tests positive for COVID-19.

The ENS framework and approach to proximity awareness uses Bluetooth low energy (“BLE”) enabled exposure notification. Once enabled through one or more Third-Party ENS Apps, the technology is intended to enable users who have been diagnosed COVID-19 positive to choose to protect others by activating the ENS to anonymously notify individuals who have been proximate to them within a set number of days prior to the date of their diagnosis, while protecting the privacy of the COVID-positive individual and all other users of the Third-Party ENS App. Notably, users must opt-in to the notification system. Upon opt-in, ENS generates a random ID on the user’s device. To help ensure these random IDs cannot be used to identify the user or the user’s location, the random IDs change every 10-20 minutes. The user’s phone and the phones around it exchange and retain these privacy-preserving random IDs via Bluetooth. The user does not need to have an App open for this process to take place. The user’s phone periodically checks a list of all anonymous IDs associated with positive COVID-19 cases against the list of proximate IDs received by the phone. If there is a match, the user will receive a COVID-19 exposure notification, with further instructions from the public health authority.

The ENS API was developed with the goal of empowering public health agencies to leverage secure, power-efficient COVID-19 contact tracing applications. If implemented by a state, the ENS API and the Third-Party ENS App will allow each state’s department of public health to make decisions regarding configuration of the system’s parameters, including without limitation the user notification, the verification method used to enable notification, and the guidance provided to users who receive an exposure notice.

ENS was introduced in the spring of 2020. At that time, public health agencies needed to develop a Third-Party ENS App using the ENS API for its citizens to participate in automated contact tracing. Numerous entities embarked on Third-Party ENS App development, and early results of laboratory and limited pilot tests are becoming available. This data will help to determine the efficacy of the technology.

EN Express.

In September 2020, Apple and Google introduced a new framework called Exposure Notifications Express (“EN Express”). EN Express enables public health authorities to set up COVID-19 contact tracing systems without needing to procure or develop a Third-Party ENS App. Apple and Google have used two different methods to effectuate EN Express; Apple has added native EN functionality to the iOS operating system, and Google has developed an end-user application for this purpose. Notably, the EN Express solution doesn’t require iPhone users to download an app. There is evidence that requiring a user to download an app is a significant behavioral barrier to adoption. EN Express, therefore, could substantially increase adoption of the Bluetooth tracing solution.

To implement EN Express, health agencies submit a configuration file to Apple and Google with information such as how and when an exposure notification should be triggered and the information that users should receive when they get an alert.

The Commonwealth of Massachusetts is currently evaluating EN Express to determine whether to implement such a tool. While ENS has existed for several months, there is still very limited evidence of the impact of this tool on public health and there is even less evidence of the impact of EN Express, because it launched so recently. This evidence is critical to determining the Commonwealth’s approach. Through this RFR, the Commonwealth aims to rigorously evaluate many key outstanding questions.

Applicable Procurement Law This Bid is issued under the following law(s):

· MGL c. 7, § 22; c. 30, § 51, § 52; and 801 CMR 21.00 (Goods and Services)

Number of Awards For all Workstreams, the Health Connector may choose multiple respondents (likely two or three). Respondents are welcome to respond to one or more workstreams. These are target numbers; the Strategic Sourcing Team (SST) may award more or fewer contracts if it is in the best interests of the Commonwealth to do so.

This is a single agency procurement, single agency user Contract.

Adding Contractors after the Initial Awards If, over the life of the Contract, the SST determines that additional Contractors should be added, these may first be drawn from qualified companies which responded to this Bid but were not awarded contracts. If necessary to meet the requirements of the Commonwealth, the Bid may be reopened to obtain additional proposals.

Eligible Entities Any contract resulting from this Bid will be open for use to the Issuing Entity and DPH only.

Acquisition Method(s) Workstreams #1 through #3 will be contracted for on a zero-cost basis. There may be some intangible value to the winning Bidder as a result of publicity and the opportunity to engage with the Commonwealth’s manual contact tracing program.

Contract Duration The expected duration of the Contracts to be entered under this RFR is through March 31, 2021, with one, three-month option to renew.

0. Estimated Value of Contract The estimated value of the Contract resulting from this Bid is $0.00. The value of the intangible rewards to Contractors entering agreements with the Health Connector under this RFR cannot be estimated.

0. Procurement Calendar Table 2, “Procurement Calendar,” outlines the schedule for important procurement dates for the RFR.

Times are Eastern Standard/Daylight Savings (US), as displayed on the COMMBUYS system clock displayed to Bidders after logging in. If there is a conflict between the dates in this Procurement Calendar and dates in the Bid’s Header, the dates in the Bid’s Header on COMMBUYS shall prevail. Bidders are responsible for checking the Bid record, including Bid Q&A, on COMMBUYS for Procurement Calendar updates.

Table 2. Procurement Calendar

0. Written questions via email.

Bidders may ask written questions and receive written answers from the Strategic Sourcing Team (SST) regarding this Bid. All Bidders’ questions must be submitted via email to HealthConnector.Responses@mass.gov. Questions may be asked only prior to the Deadline for Submission of Questions stated in the Procurement Calendar, Table 2. The Health Connector reserves the right not to respond to questions submitted after this date.

Please note that any questions submitted to the SST using any other medium (including those that are sent by mail, fax, or voicemail, or upload to CommBUYS, etc.) will not be answered. To reduce the number of redundant or duplicate questions, Bidders are asked to review all questions previously submitted to determine whether the Bidder’s question has already been posted.

Bidders are responsible for entering content suitable for public viewing, since all of the questions will be accessible to the public when posted by the Health Connector on CommBUYS. Bidders must not include any information that could be considered personal, security sensitive, inflammatory, incorrect, collusory, or otherwise objectionable, including information about the Bidder’s company or other companies. The SST reserves the right to edit or delete any submitted questions that raise any of these issues or that are not in the best interest of the Commonwealth or this Bid.

All answers are final when posted. Any subsequent revisions to previously provided answers will be dated.

It is the responsibility of the prospective winning Bidders to maintain an active registration in COMMBUYS and to keep current the email address of the Bidder’s contact person and prospective contract manager, if awarded a contract, and to monitor that email inbox for communications from the Health Connector, including requests for technical corrections and clarifications. The Health Connector and the Commonwealth assume no responsibility if a prospective winning Bidder’s designated email address is not current, or if technical problems, including those with the prospective winning Bidder’s computer, network or internet service provider (ISP) cause email communications sent to/from the prospective winning Bidder r and the Health Connector to be lost or rejected by any means including email or spam filtering.

Amendment Deadline The SST reserves the right to make amendments to the Bid after initial publication. It is each Bidder’s responsibility to check COMMBUYS for any amendments, addenda or modifications to this Bid, and any Bid Q&A records related to this Bid. The SST and the Commonwealth accept no responsibility and will provide no accommodation to Bidders who submit a Quote based on an out-of-date Bid or on information received from a source other than COMMBUYS.

Review Rights Responses to this RFR may be reviewed and evaluated by any person(s) at the discretion of the Health Connector including non-allied and independent consultants retained by the Health Connector now or in the future, for the sole purpose of obtaining an analysis of Responses. Any and all Bidders may be asked to further explain or clarify in writing areas of their RFR Response during the review process. the Health Connector retains the right to request further information from bidders during RFR response review.

Oral Presentations, Product Demonstrations At its discretion, the Health Connector may, as part of the Workstream #1 bidding process, request that one or several Bidders bidding on Workstream #1 provide an informal online oral presentation regarding the plans for the proposed pilot, and answer questions from the SST. The Health Connector may also, as part of the Workstream #2 bidding process, request Bidders to give an informal online oral presentation and/or demonstration of the Third-Party ENS App or Third-Party Companion App, and answer questions. Similarly, the Health Connector may also request that Bidders bidding on Workstream #3 give an informal online oral presentation of their plans with respect to privacy and security assessment.

The Health Connector may limit the number of presentations and/or demonstrations requested. The purpose of the presentation and/or demonstration is to enable the Health Connector to better understand and evaluate the Bidder’s response. Such demonstrations or presentations will not include any pilot activity.

Based on the Bidder’s RFR response, the Health Connector will determine the structure and content of the presentation and/or demonstration. The Health Connector will contact the Bidder(s) individually, with at least 2 business days’ notice, to schedule the session, which will take place during the timeframe specified in Table 2, Procurement Calendar.

Selected Bidders who are asked to participate in Oral Presentations / Product Demonstrations will be expected to prioritize this in their schedules. The SST will make every effort to find a mutually convenient time for the Bidder and the SST. However, failure to appear at the scheduled time of the presentation/ demonstration may result in disqualification, reduction of points or other action that the SST deems appropriate.

The Bidder’s key personnel identified in its response are expected to attend the session. The SST will not inform a bidder of its scores or ranking at the time of the session.

If possible, Bidders should provide copies of any presentation material in advance of the session. This material and all written submissions (submitted via email as required in section 7 below) ) become part of the bidder's response.

Presentations may be recorded by the Health Connector at its expense and thereby become public records and part of the Bidder’s response after the conclusion of the RFR process. All other expenses associated with the presentations and/or demonstrations will be borne by the Bidder.

Specifications Additional required terms appear in the Appendices to this RFR.

Bidders may subcontract with partners who are the owners of qualifying Third-Party ENS Apps or Third-Party Companion Apps.

Bidders must respond to all specifications requiring a response with respect to the Bidder’s company, rather than referencing the experience and qualifications of the Bidder’s partner(s), parent company, affiliate(s) or subsidiary company(ies).

Bidders are explicitly notified that no individually identifiable or otherwise confidential public health surveillance information will be provided to the Bidder(s) by the Commonwealth as a part of this RFR or any resulting contract.

Business Requirements Listed below are the functions the Health Connector requires for the Project and the required or desired features of those functions. The Bidder will be overseen by the Health Connector project manager and the Health Connector Business Lead during the course of the Project.

General Requirements Bidders must include the following information in their responses:

1) Category of Submission. Bidders must clearly state the category of response, as described in detail in Section 1.1 above. This includes 1) Workstream #1 (Pilot Project to Validate EN Express), 2) Workstream #2 (Discovery of Third-Party ENS Apps and Third-Party Companion Apps), and Workstream #3 (Privacy and Security Review). Bidders are welcome to provide proposals in more than one category.

2) Approach. The narrative must provide a description of the approach(es) the Bidder would take if awarded the contract. Depending on the workstream(s) on which they are bidding, Bidders must address the key questions for proposals in each workstream set forth in Table 3, “Bidder’s Approach.”

Table 3. Bidder’s Approach.

Bidder must describe:

1. Pilot Project Implementation of EN Express

Pilot details

· The proposed design of the pilot, including the questions the pilot will endeavor to answer, the proposed community/target participants in the pilot, the proposed number of participants, and the expected duration of the pilot.

· How it will evaluate speed of contact notification and number of new contacts reached that are not otherwise reached through contact tracing conducted through human interaction.

· The timeline for the pilot; the Health Connector is flexible on the proposed timeline and recognizes that any college or university that is bidding will suggest running the pilot when students are present.

· The proposed action plan and timeline for communicating with the Health Connector and its designees and the SST throughout the course of the pilot.

· The methodology that it will use and the key metrics that the Bidder will measure to quantify the success of the pilot.

Administration

· Anticipated coordination required with Massachusetts public health officials before pilot launch and throughout the duration of the pilot.

· How the proposed pilot will enable the Commonwealth to evaluate aspects of EN Express, including public health efficacy, security, privacy and equity; Note that while equity is one of the goals of the Workstream #1, it is a complex problem for which the Health Connector does not expect any individual Bidder to propose a complete solution. Rather, the Health Connector expects Bidders on Workstream #1 to suggest ways in which their pilot might assist the Health Connector in evaluating the equity implications of the pilot. For example, ways in which the Bidder will attempt to assess aspects of equity during the pilot, and experiment with strategies to improve equity.

· The methods it will use to collect and document information about the various operational, maintenance, and cost elements related to deployment of Bluetooth exposure notifications during the pilot.

Privacy and security

· The mechanisms that will be in place to ensure that pilot participants’ individual data will be kept private and secure.

· How pilot participants’ informed consent to participate will be obtained.

· To the extent that the pilot will collect information from individuals, details on how the pilot will comply with the Fair Information Practices Act, MGL ch. 66A, and the DPH Confidentiality Agreement, posted on CommBUYS with this RFR as Attachment B.

· To the extent the proposed pilot constitutes research with human subjects, how Institutional Review Board (“IRB”) review and approval will be obtained.

User engagement and feedback

· How it will assess and document adoption rates of EN technology during the pilot.

· The mechanism(s) and marketing approaches planned to recruit pilot participants and encourage adoption of the technology during the pilot.

· The methods for documenting learnings about the most effective ways to encourage adoption of EN technology.

· The methodology that will be deployed for understanding user feedback at the conclusion of the pilot.

· The methods it will use to collect information about the perception of Bluetooth exposure notification technology in the community in which it conducts the pilot.

· The results from previous pilots or implementations of the Third-Party ENS App or Third-Party Companion App, if applicable, including technical performance of Bluetooth notifications, system-level integration with public health processes, and overall efficacy of the App as it relates to speed of contact notification and number of new contacts reached that are not otherwise reached through contact tracing conducted through human interaction.

· The planned approach for any proposed Massachusetts pilot of the Third-Party ENS App or Third-Party Companion App, if applicable, including documentation of pilot details, administration, privacy and security, and user engagement and feedback, as specified above in Table 3, under Workstream #1.

· The estimated costs of the Third-Party ENS App or Third-Party Companion App for deployment in the Commonwealth.

· Suggestions on privacy-preserving features and functionalities of the App that haven’t been utilized in other geographies but that could have benefit in Massachusetts.

· The methodology and results of any security and privacy assessment that has been conducted on the Third-Party ENS App or Third-Party Companion App, including information about testing standards.

· The methodology proposed for conducting a code review and for conducting specific assessment for privacy and security purposes of EN Express as well as up to one Third-Party Custom App and and/or Third-Party Companion App selected in Workstream #2.

3) Key deliverables. Bidders must describe the deliverables that will be provided to the Commonwealth throughout the course of the contract, listed in Table 4, “Bidder Key Deliverables” below.

Table 4. Bidder Key Deliverables.

Winning Bidders must:

· Provide a final report on the pilot to the Commonwealth. The final report will assist the Commonwealth in understanding key success criteria of EN Express. The final report must address the items related to the pilot set forth in Table 3, “Approach” above in the row labelled “Project Pilot Implementation of EN Express,” as well as make recommendations to the Health Connector regarding the type of privacy and security assessment and review that it will need to conduct prior to a full-scale deployment of EN Express or an ENS Custom App in the Commonwealth.

· Make an oral presentation. This presentation will be held by video conference and will be an opportunity to describe the Third-Party ENS App or Third-Party Companion App in detail. There will also be a questions and answer period during the presentation.

· Provide documentation on pilots, if applicable. To the extent the Winning Bidder has deployed one or several pilots or implementations of the Third-Party ENS App or the Third-Party Custom App, the Winning Bidder will provide the Health Connector, during the course of the engagement, with a document reviewing the methodology and results of all such pilots and/or implementations. This document will include answers to those questions listed under “Approach” above for Workstream #1.

4) Timeline. The narrative must address the anticipated timeline for completion. In the case of Workstream #1 or any pilots proposed as part of Workstream #2, the Bidder should state the time required for design, implementation, and evaluation.

5) Qualifications. The Bidder must explain the qualifications of its organization to perform the services, including a description of relevant experiences in similar projects as indicated in Table 5 “Bidder Qualifications,” below and in Section 3 of this RFR, “’Bidder Qualifications.”

Table 5. Bidder Qualifications.

· Preference will be given to multidisciplinary teams that can achieve multiple goals and objectives through the pilot by affording perspectives from, for example, health care, public health, epidemiology, engineering, experiment design, data gathering and analysis, human factor research, and others.

· Preference will be given to teams that have demonstrated access to and support from a community or set of communities that will be keen to adopt and test exposure notification in a pilot context.

· In the event that a pilot is proposed, preference will be given to Bidders who meet the qualifications enumerated in Workstream #1.

· Preference will be given to Bidders that are able to clearly articulate the approach they will take to the privacy and security review.

6) Subcontractors. If the Bidder proposes to perform the services in conjunction with a subcontractor, that subcontractor must be identified, and the response must describe the manner in which the subcontractors will collaborate, and the prior experience of the subcontractors working in conjunction.

7) Demonstration included in Bid. For Workstream #2, Bidders must include in their bid a link to a short video, slideshow or other visual presentation of the features, workflow and operations of their Third-Party ENS App or Third-Party Companion App. Winning Bidders of Workstream #2 will have the opportunity for a live presentation with longer or more comprehensive video demonstration of the Third-Party ENS App or Third-Party Companion App.

8) Miscellaneous. The Bidder should provide details of any material governmental investigation pending against your firm, or any material ongoing or open audit or investigation by the Health Connector or any regulatory agency.

Workstream #2 (Third-Party ENS Apps and Third-Party Companion Apps) Technical Requirements In addition to the requirements set forth above in “General Requirements”, Workstream #2 Third-Party ENS Apps and Third-Party Companion Apps must meet the Enterprise Information Security Policies and Standards and the Accessibility Standards, the latter available online at https://www.mass.gov/guides/enterprise-it-accessibility-standards.

Service Specifications Intellectual Property Title and Intellectual Property Rights are addressed in “Commonwealth Title and Intellectual Property Rights”, available online at https://www.mass.gov/lists/osd-forms. The template Master Services Agreement and its attached Statement of Work are posted on CommBUYS with this RFR as Attachments A and B, respectively. While the MSA and the Statement of Work are subject to negotiation by the parties, the Health Connector will not agree to significant changes to the intellectual property terms. For purposes of clarification, the language of this RFR and its attachments would not grant the Health Connector an ownership interest in any of the technology used by Bidders who respond to Workstreams #1 and #2, including without limitation ENS, ENX, the Third-Party Custom Apps or the Third-Party Companion Apps.

Subcontracting Subcontracting is permitted under this RFR, with prior written approval from the Health Connector. However, Bidders may not subcontract more than 80% of the work under any engagement. At a minimum, the Bidder must take full responsibility for project management. The winning Bidder will be responsible for its Sub-Bidder’s compliance with all terms of this Contract, and with any Statements of Work for which a Sub-Bidder is used, including but not limited to warranties and covenants.

Travel expenses and all other expenses For Workstreams #1 through #3, no costs, travel or other expenses will be permitted.

Master Services Agreement and Project Statement of Work The Health Connector will negotiate a Master Services Agreement (MSA) and its attached Statement of Work with the winning Bidders under this RFR, based on the MSA and SOW templates posted with this RFR on CommBUYS. Further details are presented in RFR Section 4.2.9 (Proposed MSA and SOW).

Accessibility Proposed Third-Party ENS Apps and Third-Party Companion Apps offered for consideration by Bidders on Workstream #2 are required to comply with the Enterprise IT Accessibility Standards and the Web Accessibility Standards, available online at https://www.mass.gov/it-accessibility. Bidders may want to consult the following publication from WC3: Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile.

Warranty The Bidder agrees that:

(1) The Bidder and its subcontractors will be sufficiently staffed and equipped to fulfill the Bidder’s obligations under any MSA, SOW or engagement resulting from this RFR;

(2) Bidder’s services will be performed: (a) by appropriately qualified and trained personnel; (b) with due care and diligence and to a high standard of quality as is customary in the industry; (c) in compliance with the applicable Milestone Schedule listed in the MSA or SOW and the terms and conditions of this Contract; and (d) in accordance with all applicable professional standards for the field of expertise;

(3) The Deliverables will substantially conform with the Deliverable descriptions set forth in the MSA and SOW;

(4) All media on which the Bidder provides any software under this RFR shall be free from defects;

(5) All software delivered by the Bidder under this RFR shall be free of Trojan horses, back doors, and other malicious code;

(6) Bidder will obtain all rights, grants, assignments, conveyances, licenses, permissions and authorizations necessary or incidental to any materials owned by third parties supplied or specified by the Bidder for incorporation in the Deliverables to be developed under this RFR; and

(7) Documentation to be provided by the Bidder under this RFR shall be in sufficient detail so as to allow suitably skilled, trained, and educated Health Connector personnel to understand the operation of the Deliverables. Bidder agrees to promptly, at no additional cost to the Health Connector, make corrections to any documentation that does not conform to this warranty.

Security and Confidentiality; Publicity Security and Confidentiality. The Bidder shall comply fully with all security procedures of the Commonwealth and Commonwealth Agencies in performance of the Contract.