N ye c-rfp-two-factor-authentication

NYeC RFP – Two Factor Authentication 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

http://www.nyehealth.org/


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

http://www.ag.ny.gov/sites/default/files/press-releases/2012/ISTOP%20REPORT%20FINAL%201.10.12.pdf

http://www.ag.ny.gov/sites/default/files/press-releases/2012/ISTOP%20REPORT%20FINAL%201.10.12.pdf


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

2nd

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.

http://www.archives.nysed.gov/a/records/mr_laws_po6A.shtml


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:

[email protected]. 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 [email protected] 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 [email protected] 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: [email protected]

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

mailto:[email protected]





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 [email protected] .

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

Technology

Transcript of N ye c-rfp-two-factor-authentication