Request for Proposals Statewide Two Factor Authentication Solution

Transcription

1 Request for Proposals Statewide Two Factor Authentication Solution Issued: September 17, 2012 Proposals Due: October 18, 2012 A Letter of Intent to Respond (LOI) to this RFP is required (See Section 4.1) NYeC RFP Two Factor Authentication Page 1 of 20

2 Contents 1. Purpose of Request for Proposals (RFP) Background on NYeC Current State of Systems that may Access SHIN-NY Data Terms used within the RFP 5 2. RFP Scope Statement Two Factor Authentication Use Cases In Scope Items (Visual) Proposal Instructions Proposal Contents Submission Details Timeline Submission Method Proposal Evaluation Criteria 17 Attachment A: Letter of Intent to Respond (LOI) 19 Attachment B: NYeC Master Services Agreement 20 NYeC RFP Two Factor Authentication Page 2 of 20

3 1. Purpose of Request for Proposals (RFP) As New York State (NYS) Regional Health Information Organizations (RHIOs) continue to grow, so does the need to keep pace with security controls and patient privacy concerns to protect the integrity, confidentiality, and availability of Protected Health Information (PHI) as it is transferred over the NYS Health Information Exchange (HIE). New penalties for confidentiality breaches in violation of the Health Insurance Portability and Accountability Act (HIPAA), as amended, as well as strict federal regulations governing e-prescribing of controlled substances, are driving the need for improved e-authentication capabilities across the Statewide Health Information Network for New York (SHIN-NY). New York ehealth Collaborative (NYeC) is seeking a vendor for the implementation of a Statewide Two Factor Authentication (TFA) Solution. In addition to the specific requirements for the solution in this RFP, NYeC would like proposers to consider the following: The solution must comply with the National Institute of Standards and Technology Special Publication (NIST SP) Level 3 requirements. The solution should increase the ability to share information across the SHIN-NY while keeping the number of authentication tokens used by an individual to a minimum. NYeC understands that while necessary in several instances, hard tokens present an added inconvenience to the end users and is seeking a solution that can provide suitable soft token options. NYeC understands that when constructing such a system, the workflow, processes and humanacceptance factor are just as important as the technical authentication solution deployed. Since large centralized and federated authentication solutions can be challenging to implement, vendor responses should consider how their approach can balance security with adoption and overcome implementation obstacles, such as solution acceptance, integration within the variety of systems that will access SHIN- NY data (such as RHIO Clinical Viewers, EMRs, etc.). 1.1 Background on NYeC NYeC ( is a public-private partnership that serves as a focal point for health care stakeholders to build consensus on state health Information Technology (IT) policy priorities and to collaborate on state and regional health IT implementation efforts. Working collaboratively with the New York State Department of Health and other key constituents, NYeC is developing the Statewide Health Information Network for New York (SHIN-NY), a statewide network of health information technology to allow providers to share patient health information in a timely and secure manner, which will lead to improved health care quality and reduced health care costs. Founded in 2006 by healthcare leaders, NYeC receives funding from state and federal grants to serve as the focal point for HIT in New York State. NYeC facilitates an interoperable health information exchange through the SHIN-NY, supporting the establishment of health information policies, standards and technical approaches and aiding stakeholders at the regional and local levels to implement such policies and standards. NYeC s goal is for patients and their healthcare providers, wherever they need and provide treatment in New York State, to be able to obtain fast, secure, accurate, and accessible information. The SHIN-NY will enable the health information exchange. As more providers adopt HIT, there is a greater opportunity for sharing patient data between those entrusted with patient care. The creation, expansion, security and management of this network is an important undertaking for New York State; a connected HIT system in New York will offer better, safer, and faster treatment for all patients. As healthcare technology adoption grows, new policies must be written and technology expanded. An essential undertaking of NYeC is to develop and improve policies, set standards, and insure complete NYeC RFP Two Factor Authentication Page 3 of 20

4 patient privacy and security. A key element in support of these goals is the creation of a Statewide TFA Solution. 1.2 Current State of Systems that may Access SHIN-NY Data Regional Health Information Organizations (RHIOs) All RHIOs will be accessing SHIN-NY data either via a Service or Connect Model. Currently, NYS RHIOs are at various stages of implementation of TFA solutions and single factor token solutions in accordance with NIST SP While some RHIOs have implemented TFA solutions, the majority of RHIOs have not. Several RHIOs are currently exploring two factor technologies that can satisfy security needs while at the same time meet user acceptance needs. The following chart illustrates the average level of implementation of TFA solutions and compliance with NIST SP requirements across the eleven (11) NYS RHIOs. The chart lists NIST implementation criteria on the vertical axis and the average level of implementation on the horizontal axis. NYeC RFP Two Factor Authentication Page 4 of 20

5 Current State of EHR Environment The selected Statewide TFA Solution must have the capability to integrate and interact with existing EMR and EHR solutions. In their response, proposers must state if their solution is supported for each EHR/EMR vendor listed below and provide any necessary details (see section 3.1 D.4 for details). The following list identifies the known EHR and EMR solutions in place across the NYS RHIOs: Vendor Name AdvantaChart Allscripts Amazing Charts Aprima Athenahealth Cerner ChartLogic Inc ComChart CompuGroup Medical Connexin CPSI (Computer Programs and System Inc.) Criterions CureMD Corporation Data Strategies, Inc. DigiChart DOC-TOR.com eclinicalworks EHR Clinical Solution e-mds EncounterPro Healthcare Resources Inc Epic escribehost GE Glenwood Systems Greenway Medical Technologies Inc Vendor Name Infor*Med Corporation MacPractice Inc McKesson MCS - Medical Communication Systems, Inc. MDLand International Med A-Z MedcomSoft MEDENT Medical Office Online Meditab MEDITECH NCG Medical Systems NextGen Healthcare Information Systems Inc OptumInsight Practice Fusion Prime Clinical Systems Quest Diagnostics SequelMed SOAPware Inc Spring Medical Systems SRSsoft STI Computer Services Inc SuiteMed LLC Universal EHR Solutions 1.3 Terms used within the RFP Term Clinical Viewer E-prescribing Definition A web-based portal for access to RHIO clinical data. The RHIO members log in to the portal for access to patient data, available patient documents, consent details, medication details, alerts, messages, etc. The Clinical Viewer allows RHIO members to access patient information available across all the participating hospital and provider locations. Defined by the ehealth Initiative as "the use of computing devices to enter, modify, review, and output or communicate drug prescriptions." Although the term e-prescribing implies the use of a computer for any type of prescribing action, there are a wide range of NYeC RFP Two Factor Authentication Page 5 of 20

6 Term Definition e-prescribing activities with varying levels of sophistication. Electronic Medical/Health Records (EMR/EHR) Federated Identity Management Health Information Exchange (HIE) Health Information Technology (HIT) Identity and Access Management (IAM) Meaningful Use The electronic systems providers use to store patients' health information. These have replaced the paper records that providers traditionally used. An EMR/EHR contains data gathered from a variety of clinical services, including laboratory data, pharmacy data, patient registration data, radiology data, surgical procedures, clinic and inpatient notes, preventive care delivery, emergency department visits, billing information, and so on. The linking of a person s electronic identity and attributes across multiple distinct identity management systems. The sharing of clinical and administrative data across the boundaries of healthcare institutions and other health data repositories. Many stakeholder groups (payers, patients, providers, and others) realize that if such data are shared healthcare processes would improve with respect to safety, quality, cost, and other indicators. The use of computers and computer programs to store, protect, retrieve, and transfer clinical, administrative, and financial information electronically within healthcare settings. A framework that includes business processes and technical solutions that facilitate the management of electronic identities from creation to removal. IAM includes: identity verification, onboarding processes, account management, access controls and auditing. The American Recovery and Reinvestment Act of 2009 specifies three main components of Meaningful Use: 1. The use of a certified EHR in a meaningful manner, such as e-prescribing. 2. The use of certified EHR technology for electronic exchange of health information to improve quality of health care. 3. The use of certified EHR technology to submit clinical quality and other measures. Multi-Factor Token Protected Health Information (PHI) Regional Health Information Organization (RHIO) A token that uses two or more factors to achieve authentication. For example, a private key on a smart card that is activated via PIN is a multi-factor token. The smart card is something you have, and something you know (the PIN) is required to activate the token. Any information about health status, provision of healthcare, or payment for healthcare that can be linked to a specific individual. This is interpreted rather broadly and includes any part of a patient's medical record or payment history. A non-governmental organization that exists as a New York State not-for-profit corporation to enable interoperable health information exchange via a common Statewide Health Information Network for New York (SHIN-NY). RHIOs participate in setting information policies through a statewide policy framework and governance process, implementing policies and ensuring adherence to such policies with a mission of governing its use in the public s interest and for the public good to improve healthcare quality and safety and reduce costs. To fulfill this mission, RHIOs require commitment from multiple healthcare stakeholders in a geographic region, including physicians, hospitals, long term care and home care providers, patients, insurers, purchasers and government. RHIOs are responsible for enabling interoperability through which individual NYeC RFP Two Factor Authentication Page 6 of 20

7 Term Definition stakeholders are linked together both organizationally and technically through the SHIN- NY in a coordinated manner for health information exchange and quality and population health reporting. Clinicians and other entities wishing to access data from outside their organization connect to a local RHIO to enable data exchange. The RHIOs across New York State will be connected to each other via the SHIN-NY technical infrastructure. Service RHIO Connect RHIO Single Factor Token Statewide Health Information Network for New York (SHIN-NY) Statewide Two Factor Authentication Solution Two Factor Authentication (TFA) A RHIO whose technical infrastructure is managed by NYeC. NYeC is responsible for all technology associated with RHIO activities and manages upgrades and software enhancements. A RHIO whose technical infrastructure is managed by the RHIO itself. It is connected to the SHIN-NY and is able to send data to and receive data from other RHIOs but its systems are individually managed. A token that uses one of the three factors to achieve authentication. For example, a password is something you know. There are no additional factors required to activate the token. A statewide health information exchange that allows for data sharing between clinicians and other entities within and across regions of New York State using standard interoperability protocols. The technical infrastructure will connect both Connect and Service RHIOs in order to allow clinicians and consumers to make timely, fact-based decisions that will reduce medical errors and redundant tests and improve care coordination and the quality of care. Participating organizations connected to the RHIOs include medical facilities, ambulatory care centers, physician offices, labs, long term care centers and nursing homes. A TFA mechanism that will allow individuals to authenticate in order to access SHIN-NY data. The statewide solution will be provided to those who do not have a valid two factor solution implemented within their own system but who require access to SHIN-NY data. Those with valid TFA mechanisms in place will not be required to use the solution provided by the state. The statewide solution will include identity management including identity proofing, certificate management and token distribution. An authentication method that requires the user to present at least two factors to verify their identity. Acceptable authentication factors fall into three categories: knowledge (something that the user knows), possession (something the user has) and inherence (something the user is). A valid two factor solution will require factors from two of the three categories. NYeC RFP Two Factor Authentication Page 7 of 20

8 2. RFP Scope Statement NYeC is seeking to make available for the participating RHIOs, providers, and patients a Statewide TFA Solution used to validate the identity of individuals prior to accessing SHIN-NY data via the RHIO Clinical Viewer, a connected EMR/EHR, or a connected third party application (such as a mobile device). NYeC also intends for the Statewide TFA Solution to be utilized for the I-STOP legislation which will Require practitioners to review a patient's controlled substance prescription history on the system prior to prescribing (for details see: This service will be provided as a single statewide shared service that provides a standard TFA solution which will support and easily integrate into the existing applications accessing SHIN-NY data. (Note: the Statewide TFA Solution will NOT need to integrate or interact with systems and solutions that have a native TFA option and can pass a SAML assertion to NYeC.) Key components of the authentication solution are the provision of Identity and Access Management (IAM) related services and components such as the issuance of certificates, identity proofing, token management, governance, and other outsourced IAM services and how they integrate with the vendor s two factor solution. In addition to serving authentication needs of users accessing SHIN-NY data, the Statewide TFA Solution may be utilized for the following additional purposes: Patients requesting to electronically download PHI into a Personal Health Record Patients accessing their PHI via a Patient Portal Providers writing e-prescriptions including the dispensing of controlled substances Access to Medicaid data for Health Homes Access to e-molst or Advanced Directive documentation for both patients and providers Patients providing electronic consent The need for an enterprise-level well-designed and capable Statewide TFA Solution is critical to the success of many other NYeC and HIE goals, such as: Security efficiency ability to minimize the time, costs and resources necessary to implement and support the IAM needs of the SHIN-NY and its users Security effectiveness ability to meet all legal and regulatory needs Security acceptance ability to balance strong security controls with usability and acceptance and adoption of the solution Mitigation of risks to breaches of PHI Enablement of: Broader sharing of EHRs across RHIOs and across the SHIN-NY Secure growth of patient portals NYeC RFP Two Factor Authentication Page 8 of 20

9 2.1 Two Factor Authentication Use Cases The Statewide TFA Solution will be required when a user attempts to access data from the SHIN-NY as well as the possibility of using the Statewide TFA Solution when a user attempts to use other functionality such as: e-prescribing, e-molst or Advanced Directives, and Medicaid data for Health Homes. A user must first be identity proofed and issued credentials and access tokens before access to the system can be granted. Specific workflow and implementation steps will be dependent on the organization and systems involved. All users will be required to be authenticated using a NIST SP Level 3 compatible authentication mechanism. Once the user has been authenticated, a SAML assertion must be passed for interoperability operation. Proposers should detail their ability to provide solutions for the following three (3) categories of access methods. (Note: The Statewide TFA Solution will NOT need to integrate or interact with systems and solutions that have a native TFA option and can pass a SAML assertion to NYeC. The use cases below apply only to those implementations where SHIN-NY is being accessed by a system that does not have a TFA solution that meets NIST Level 3 standards.) 1. User accesses the SHIN-NY through a system (EHR or other - such as a hospital information system, HIE, a Connect RHIO Clinical Viewer, etc.) that allows access to the SHIN-NY. The EHR or other system vendor should be able to work with the selected Statewide TFA Solution vendor to implement a solution within the EHR system as needed. The selected Statewide TFA Solution vendor will provide widgets for EHR vendor integration and the EHR (or other system) vendor will be required to integrate the TFA solution. 2. User accesses the SHIN-NY through a Service RHIO Clinical Viewer. The selected vendor will work with NYeC to implement the Statewide TFA Solution within the Service RHIO that the user is connected through. NYeC will be responsible for needed changes to Service RHIO systems for solution implementation. 3. User accesses the SHIN-NY through a third party application (through smart phones, tablets, etc.). The application vendor should be able to work with the selected Statewide TFA Solution vendor to implement a solution within the EHR system as needed. The selected Statewide TFA Solution vendor will provide widgets for EHR vendor integration and the application vendor will be required to integrate the TFA solution. SAML Validation will be a functional service of the NYeC system for all passed SAML assertions. NYeC RFP Two Factor Authentication Page 9 of 20

10 2.2 In Scope Items (Visual) The following diagram details the needed components and structure for the TFA solution for access to SHIN-NY data. Proposers must detail their solution for components presented in blue. Identity Proofing Certificate Assignment and Management Token Assignment and Management Identity Access Management User requests SHINY data through system utilizing the Statewide NIST level 3 compatible TFA Solution EHR/Hospital / Connect QE Clinical Viewer/System App Service QE Clinical Viewer Statewide Two Factor Authentication System SAML Assertion passed for interoperability operation SAML Validation SHINY User Directory: User Roles and Permissions Patient Directory: User Roles and Permissions Key: In Scope Out of Scope Descriptive NYeC RFP Two Factor Authentication Page 10 of 20

11 3. Proposal Instructions Proposers must respond to ALL items contained in section 3.1 below (A-L and sub-sections thereof), as well as adhere to the page limits. Every page in the proposal, including all appendices, exhibits and attachments, must be numbered consecutively. Each section must be clearly labeled with the title, letter and number of the section. Proposals should be single-spaced, contain one-inch margins, and be typed in Times New Roman 12-point font. 3.1 Proposal Contents The proposal contents must be organized in the following order: A. Cover Letter and Company Overview (1-page limit) a brief overview of the vendor s organization and contact information to direct future inquiries regarding the proposal. The cover letter must be signed by an officer authorized to bind the vendor to the terms of the proposal. B. Executive Summary (3-page limit) - a brief narrative that demonstrates the vendor s understanding of the services requested by this RFP and the scale and complexity of this initiative. The Executive Summary should demonstrate the strengths of the vendor s proposed approach, the key features that distinguish its proposed solution to meet the requirements and the major benefits it offers. C. Experience (2-page limit) an overview of the vendor s and any proposed subcontractors relevant experience. If subcontractors will be used, identify instances where the vendor has worked with the proposed subcontractors. D. Approach for TFA Solution Implementation (20-page limit) a detailed description of the approach the vendor proposes to use to implement its TFA solution, including detailed descriptions of all solution components that will be outsourced and of any proposed subcontractors. 1. Provide details on how the proposed TFA solution will integrate and work with existing systems that do not have a built-in TFA solution. The details must cover the use cases and systems described in section 2.1 Two Factor Authentication Use Cases above: a) Include specifics on the methods (such as web services, Application Programming Interfaces (APIs), etc.) that will be provided by the TFA vendor to integrate the TFA solution with existing RHIO Clinical Viewers, EMR vendors, and connected third party applications (such as a mobile device). b) State specifically how well industry standards (OATH, RADIUS, LDAP, PAM, etc.) are used for 2 nd factor integration interfaces with systems. Preference will be given to vendors who incorporate industry standards within their solution. 2. Identify the integration utilized between the various application components of all response partners that allow it to operate as a seamless cohesive solution. Identify the relationship between the primary respondent and its partners. 3. Detail the types of tokens accepted by the proposed TFA solution. Proposed solutions should encompass at minimum one hard and one soft token. Preference will be given to proposed solutions with flexible token requirements. NYeC RFP Two Factor Authentication Page 11 of 20

12 4. Identify and provide the necessary details on the EHRs/EMRs that are currently supported by the proposed solution from the list provided in Section 1.2, and any others that are not included in the list. Vendors must identify all EHRs/EMRs that have implemented the proposed TFA solution and how it was implemented. E. Identity and Access Management (IAM) Services (5-page limit) Describe the IAM services, specifically: 1. Ability to support Level 3 basis for issuing credentials for in-person and remote use cases. 2. Ability to support Registration Authority actions at Level 3 for in-person and remote-use cases. 3. Ability to support Level 3 Credential Lifetime, Status or Revocations requirements. 4. Ability to implement token and credential revocation and destruction processes. 5. Ability to provide a complete enterprise IAM service for establishing and maintaining identities as per NIST Describe your recommended IAM Governance model and structure. 7. Ability to support an IAM solution that will be expandable to include new forms of identity verification, assertion and authentication approaches. 8. Details on integration of needed third party solutions with the proposed IAM capabilities. Include details on the agreement between the TFA vendor and the third party vendor as needed. F. Architecture (2-page limit) provide a diagram (along with the necessary descriptions) of the proposed architecture for the overall TFA solution. This should incorporate all the in-scope items identified in Section 2.2 above. G. Hardware Requirements (2-page limit) identify the hardware needed to support the TFA solution. Use the user count table in the Business and Pricing section below to provide details on the incremental hardware needs based on the number of users being supported via the TFA solution. H. Team (5-page limit) detailed overview of the vendor s and proposed subcontractors team members who will staff the project if vendor is selected. This section should identify all key team members by name and role (NYeC may at its discretion choose to interview some or all key team members during the selection process). Note: The team size and makeup should consider a strong desire at NYeC to complete the implementation by the end of Organization Chart. In addition to identifying all of the vendor team members (including subcontractors) by their names (for key members) and roles, the chart should identify all roles, teams and governance groups that the vendor expects NYeC to provide for the implementation. 2. Name, role and brief experience of the key members of the team (this should also include key subcontractor positions). 3. Descriptions for ALL roles identified within the Organization Chart. 4. Resumes of all key members (to be included as an Appendix the 5-page limit for this section does not include resumes). I. Other Services (5-page limit) identify and provide details for other supporting services that will be provided for the overall implementation and maintenance. These include: NYeC RFP Two Factor Authentication Page 12 of 20

13 1. Help Desk Services 2. Knowledge Transfer Services 3. Service Level Agreements (include standard SLA documents as an appendix) 4. Token replacement, addition, and termination as well as password recovery 5. Software Support (including upgrades and maintenance) J. Project Implementation Timeline (5-page limit) provide a timeline for the overall implementation of the Statewide TFA Solution that includes the IAM implementation as well as the implementation of the use cases defined in section 2.1 above. Identify the key tasks, milestones and deliverables within the timeline. Any assumptions used in developing the timeline should be identified in this section. If there are specific tasks that NYeC will be responsible for, they should be identified clearly within the timeline. (Assume a January 7, 2013 start date) Note: The Project Implementation Timeline should consider a strong desire at NYeC to complete the implementation by the end of K. Two Factor Authentication Solution Requirements (10-page limit) proposers must address all the requirements detailed in the table below. Two Factor Authentication Solution Requirement 1. Confirm that the proposed TFA solution complies with NIST SP at Level Ability to support a variety of TFA types such as those defined in NIST SP that may be permitted for HIE access as well as the more restricted subset of two factor solutions that are required by DEA for e- Prescriptions for Controlled Substances. State how your solution can support two factor solutions for both business needs. HIE access may allow Out of Band two factor solutions while the DEA allows only FIPS validated hard cryptographic tokens. 3. Ability for TFA solution to comply with NIST Special Publication , Electronic Authentication Guideline, December 2011 Authentication Guideline, (NIST SP ). 4. Ability to protect long-term shared secrets as per NIST SP requirements. 5. Ability to support Single factor (SF) One-Time Password (OTP) Device as defined by NIST in SP Ability to support Single factor (SF) Cryptographic Device as defined by NIST in SP Ability to support Multi-factor (MF) Software Cryptographic Token Cryptographic Token as defined by NIST in SP Ability to support Multi-factor (MF) One-Time Password (OTP) Device as defined by NIST in SP Ability to support Multi-factor (MF) Cryptographic Devices as defined by NIST in SP Ability to support Memorized Secret Token as defined by NIST in SP Ability to support Pre-registered Knowledge Token as defined by NIST in SP Ability to support Look-up Secret Token as defined by NIST in SP Ability to support Out of Band Token as defined by NIST in SP Ability to support TFA for patients across a variety of patient portal instances. Please state which web platforms and PHR systems your solution works with or is certified to work with. 15. Ability to comply with the New York State Personal Privacy Protection Law ( 16. Provide two-factor system performance information for deployments of 100, 10K, 100K, 200K, 1M, and 10M users. 17. Ability to support multiple browser types. Describe any restrictions on browsers when integrating your solution. 18. Ability to support centralized accumulation and management of audit data. NYeC RFP Two Factor Authentication Page 13 of 20

14 Two Factor Authentication Solution Requirement 19. Ability to provide granular controls to manage the length of time that an authentication assertion is valid for. Can the solution support various identity assertion lifetimes for various applications and roles within the SHIN-NY? 20. Ability to operate across data centers that are geographically spread out across the state. Address any network or other technical related requirements for your proposed solution. 21. Ability to support records retention requirements. 22. Meets the DEA Requirements for Electronic Orders and Prescriptions (e-cfr Title 21: Food and Drugs, Part 1311 Requirements for Electronic Orders and Prescriptions). State and discuss any compliance capabilities or experience with integrating your solution with e-prescription services including support for controlled substances. NYeC RFP Two Factor Authentication Page 14 of 20

15 L. Business Model and Pricing 1. Pricing model: explain the possible pricing model(s) available and provide component prices and volume discounts. Available Enterprise Pricing Options including but not limited to adoption by NYeC of the vendor's proposed solution as a statewide solution for all connected systems that lack the required functionality should be explained here. 2. Vendors must indicate if their proposed solution requires collaboration with any other entities not included as subcontractors and must clearly state if these are ongoing or new relationships. 3. Costs for all required components (including services, software, hardware, and any other costs) must be included using the pricing table below. All areas are required to be addressed. If an area is non-applicable a reason must be provided as to why there is no price. If a cost for an area is included within other costs please mark the item as included and specify in the Comments column where the cost is covered. Vendors may add additional rows within the table as required. This includes adding subcomponents to an existing line to provide a more detailed breakdown of a cost or adding new rows to identify a cost component not identified in the table. Please be sure to indicate the creation of a new sub-component or row within the Comments column and to provide an explanation for why it was included. Solution Costs: Licensing Costs Third Party License Fees (please specify third party organization as applicable) Identity Proofing Costs Certificate Management Costs Implementation Costs Help Desk Costs Training Costs Knowledge Transfer Costs Maintenance (24x7 Support) Professional Services Costs Custom Development Costs Hardware and Server Costs Administrative Costs Other: Please Specify Acquisition or recurring Cost (if recurring, state frequency) K Per User Costs: Number of Users 10K 100K 100K 200K 200k- 1M 1M- 10M 10M+ COMMENTS NYeC RFP Two Factor Authentication Page 15 of 20

16 Token Purchase and Management Costs: Token Type 1 (please specify) Acquisition or recurring Cost (if recurring, state frequency) K Per User Costs: Number of Users 10K 100K 100K 200K 200k- 1M 1M- 10M 10M+ COMMENTS Token Type 2 (please specify) Token Type 3 (please specify) Token Type 4 (please specify) (Add additional lines as necessary) External Costs: Cost Details Anticipated costs to third party (EHR and Application) vendors for integration services and support. Please specify costs that vary by integration type. Costs to EHR vendors Costs to application developers Hospital/practice incurred costs 4. Financial Report- Due to the breadth and scope of the project, the proposer is required to submit its most recent audited financial statement and management letter. In the event that the proposer is a wholly owned subsidiary or is otherwise a subordinate of another entity, the most recent audited financial statement and management letter of the proposing company is expected- not that of the parent company. 5. In-Kind Service details: Any In-Kind services and the value of those services should be noted in this section. In-kind services are those services provided at no cost yet have an intrinsic value or worth. Descriptions of what is included in the cost including support model and hours of coverage must be noted. If your cost excludes certain fees or charges, you must provide a detailed list of the exclusions with a complete explanation of the nature of those fees. While In-Kind services are not a requirement of the RFP, proposers are encouraged to include them since they demonstrate to NYeC the proposers commitment to providing the highest value for the public funds being used for this effort. NYeC RFP Two Factor Authentication Page 16 of 20

17 4. Submission Details All communication regarding this RFP must be in writing and addressed to: The subject line of all communications must include: TFA Proposal and your company name Timeline RFP Issued: September 17, 2012 Letter of Intent to Respond due: September 24, 2012; 11:59pm EDT Written Questions due: September 24, 2012; 11:59pm EDT Q&A Vendors Conference Call: October 2, 2012; 3:00 5:00 pm EDT Written Responses to Q&A Available no later than: October 5, 2012 Proposals Due: October 18, 2012; 11:59pm EDT Requested Vendor Demonstrations/Presentations Held: November 16, 2012 Award Notification: November 30, 2012 Anticipated Contract Start Date: January 7, 2013 In order to effectively manage the process, NYeC is requiring all interested vendors to submit a Letter of Intent to Respond (LOI) to RFPContact@nyehealth.org no later than 11:59pm EDT on September 24, LOIs must contain the address of the vendor s contact person. Submitting an LOI will not bind a vendor to submitting a proposal, but will be used to notify the vendor of any changes, including the Q&A Vendor Conference Call number, changes to the above timeline, and any additional information related to this RFP. (See Attachment A - Letter of Intent to Respond). All questions must also be submitted via to RFPContact@nyehealth.org and must be received by 11:59pm EDT on September 24, Responses to questions received by this deadline are expected to be posted on the NYeC website no later than October 5, Proposers are advised that the Authorized Contact Person for all matters concerning this RFP is the RFP Contact address. Proposers may not contact any NYeC staff, NYeC board members, the NYS Department of Health staff, NYC Department of Health and Mental Hygiene staff, or any other stakeholder regarding this project in the period between the issue of this RFP and the notice of award. Any oral communication will be considered unofficial and non-binding with regard to this RFP and subsequent award. 4.2 Submission Method Proposal submission method ( ) to: RFPContact@nyehealth.org Include TFA Proposal and your company name in the subject line Format: PDF and MS Word 4.3 Proposal Evaluation Criteria Proposals will be evaluated based on the following criteria: Use of Industry Standard Integration methods Logging, auditing, and reporting capabilities The ability to support multiple authentication solutions NYeC RFP Two Factor Authentication Page 17 of 20

18 Demonstrated ability to provide a successful pilot of the vendor s proposed solution with key EMR/EHR systems Experience and skill sets of the proposed team Financial strength of the company Cost and In-Kind Services NYeC RFP Two Factor Authentication Page 18 of 20

19 Attachment A: Letter of Intent to Respond (LOI) Instructions The LOI form must be completed and returned to notify NYeC that you intend to respond to this Request for Proposals (RFP). Any information relating to this RFP will be ed to the person designated as the point of contact (POC) on this form. the completed form to Letter of Intent to Respond Our organization intends to respond to the NYeC Request for Proposals for the Statewide Two Factor Authentication Solution. Organization Name: Address: POC Name: POC Title: POC POC Telephone: NYeC RFP Two Factor Authentication Page 19 of 20

20 Attachment B: NYeC Master Services Agreement The selected vendor will be required to execute the NYeC Master Services Agreement (MSA) provided separately with this RFP. The contents of the MSA are non-negotiable. Vendors have a responsibility to review the requirements carefully. NYeC RFP Two Factor Authentication Page 20 of 20