N ye c-rfp-two-factor-authentication

NYeC RFP – Two Factor Authentication Page 1 of 20
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)

Contents
1. Purpose of Request for Proposals (RFP) 3
1.1 Background on NYeC 3
1.2 Current State of Systems that may Access SHIN-NY Data 4
1.3 Terms used within the RFP 5
2. RFP Scope Statement 8
2.1 Two Factor Authentication Use Cases 9
2.2 In Scope Items (Visual) 10
3. Proposal Instructions 11
3.1 Proposal Contents 11
4. Submission Details 17
4.1. Timeline 17
4.2 Submission Method 17
4.3 Proposal Evaluation Criteria 17
Attachment A: Letter of Intent to Respond (LOI) 19
Attachment B: NYeC Master Services Agreement 20

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) 800-63-1 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 human-
acceptance 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 (http://www.nyehealth.org) 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

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 SP800-63-1. 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 800-63-1 requirements across the eleven
(11) NYS RHIOs. The chart lists NIST 800-63-1 implementation criteria on the vertical axis and the
average level of implementation on the horizontal axis.

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 Vendor Name
AdvantaChart Infor*Med Corporation
Allscripts MacPractice Inc
Amazing Charts McKesson
Aprima MCS - Medical Communication Systems, Inc.
Athenahealth MDLand International
Cerner Med A-Z
ChartLogic Inc MedcomSoft
ComChart MEDENT
CompuGroup Medical Medical Office Online
Connexin Meditab
CPSI (Computer Programs and System Inc.) MEDITECH
Criterions NCG Medical Systems
CureMD Corporation NextGen Healthcare Information Systems Inc
Data Strategies, Inc. OptumInsight
DigiChart Practice Fusion
DOC-TOR.com Prime Clinical Systems
eClinicalWorks Quest Diagnostics
EHR Clinical Solution SequelMed
e-MDs SOAPware Inc
EncounterPro Healthcare Resources Inc Spring Medical Systems
Epic SRSsoft
eScribeHost STI Computer Services Inc
GE SuiteMed LLC
Glenwood Systems Universal EHR Solutions
Greenway Medical Technologies Inc
1.3 Terms used within the RFP
Term Definition
Clinical Viewer 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.
E-prescribing 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

Term Definition
e-prescribing activities with varying levels of sophistication.
Electronic
Medical/Health
Records
(EMR/EHR)
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.
Federated
Identity
Management
The linking of a person’s electronic identity and attributes across multiple distinct identity
management systems.
Health
Information
Exchange (HIE)
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.
Health
Information
Technology (HIT)
The use of computers and computer programs to store, protect, retrieve, and transfer
clinical, administrative, and financial information electronically within healthcare settings.
Identity and
Access
Management
(IAM)
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.
Meaningful Use 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
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.
Protected Health
Information (PHI)
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.
Regional Health
Information
Organization
(RHIO)
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

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 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.
Connect RHIO 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.
Single Factor
Token
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.
Statewide Health
Information
Network for New
York (SHIN-NY)
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.
Statewide Two
Factor
Authentication
Solution
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.
Two Factor
Authentication
(TFA)
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.

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: http://www.ag.ny.gov/sites/default/files/press-
releases/2012/ISTOP%20REPORT%20FINAL%201.10.12.pdf). 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

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 800-63-1 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.

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 Access Management
Identity
Proofing
Token
Assignment
and
Management
Certificate
Assignment
and
Management
SAML
Validation
SAML Assertion
passed for
interoperability
operation
Statewide Two Factor
Authentication System
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
User
Directory:
User Roles
and
Permissions
Patient
Directory:
User Roles
and
Permissions
SHINY
Key:
In Scope
Out of Scope
Descriptive

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.

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 800-63-1.
6. 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 2013.
1. 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:

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 2013.
 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 800-63-1 at Level 3.
2. Ability to support a variety of TFA types such as those defined in NIST SP 800-63-1 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 800-63-1, Electronic Authentication
Guideline, December 2011 Authentication Guideline, (NIST SP 800-63-1).
4. Ability to protect long-term shared secrets as per NIST SP 800-63-1 requirements.
5. Ability to support Single factor (SF) One-Time Password (OTP) Device as defined by NIST in SP 800-63-1
6. Ability to support Single factor (SF) Cryptographic Device as defined by NIST in SP 800-63-1
7. Ability to support Multi-factor (MF) Software Cryptographic Token Cryptographic Token as defined by NIST
in SP 800-63-1
8. Ability to support Multi-factor (MF) One-Time Password (OTP) Device as defined by NIST in SP 800-63-1
9. Ability to support Multi-factor (MF) Cryptographic Devices as defined by NIST in SP 800-63-1
10. Ability to support Memorized Secret Token as defined by NIST in SP 800-63-1
11. Ability to support Pre-registered Knowledge Token as defined by NIST in SP 800-63-1
12. Ability to support Look-up Secret Token as defined by NIST in SP 800-63-1
13. Ability to support Out of Band Token as defined by NIST in SP 800-63-1
14. 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
(http://www.archives.nysed.gov/a/records/mr_laws_po6A.shtml)
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.

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.

 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 sub-
components 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: Acquisition or
recurring Cost
(if recurring,
state
frequency)
Per User Costs: Number of Users COMMENTS
1-500 501-
10K
10K –
100K
100K –
200K
200k-
1M
1M-
10M
10M+
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

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.
Token Purchase and Management
Costs:
Acquisition or
recurring Cost
(if recurring,
state
frequency)
Per User Costs: Number of Users COMMENTS
1-500 501-
10K
10K –
100K
100K –
200K
200k-
1M
1M-
10M
10M+
Token Type 1 (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. Submission Details
All communication regarding this RFP must be in writing and addressed to:
RFPContact@nyehealth.org. The subject line of all communications must include: TFA Proposal and
your company name.
4.1. 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, 2012. LOIs must contain the email 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 email to RFPContact@nyehealth.org and must be received
by 11:59pm EDT on September 24, 2012. Responses to questions received by this deadline are
expected to be posted on the NYeC website no later than October 5, 2012.
 Proposers are advised that the Authorized Contact Person for all matters concerning this RFP is the
RFP Contact email 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 (email) 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

 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

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 emailed to the person designated as the
point of contact (POC) on this form. Email the completed form to RFPContact@nyehealth.org .
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 Email:
POC Telephone:

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.

N ye c-rfp-two-factor-authentication

More Related Content

What's hot

Similar to N ye c-rfp-two-factor-authentication

More from Hai Nguyen

Recently uploaded

N ye c-rfp-two-factor-authentication