Running Head: VENDOR SELECTION FOR IDENTITY AUTHENTICATION 1

Transcription

1 Running Head: VENDOR SELECTION FOR IDENTITY AUTHENTICATION 1 Vendor Selection for Identity Authentication Hardware/Software Patrick Eronini, Cathy Faetanini, Scott Robertson Northwestern University School of Professional Studies Medical Technology Acquisition and Assessment MED INF 408 Russell Hinz, BSN, MSMI November 23, 2014

2 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 2 Introduction Metropolitan Hospital Center (MHC), founded in 1789, continues to serve as the medical center of choice in our nation s capital. Approximately 5,000 end users rely on Electronic Health Record (EHR) systems and health information technology (HIT) tools within the MHC network to deliver quality patient care. However, the current identity authentication process that manages access to those tools is cumbersome, often hindering clinician productivity and workflow. To forge a partnership with a vendor whose solutions meet MHC s identity management needs, a Request for Proposals (RFP) was distributed to several vendors. Responses were measured against MHC s criteria and evaluated using the methodology and reasoning outlined in this document. This detailed process resulted in the selection of a vendor and partner who not only understands and addresses the identity management needs of MHC, but who also shares the values central to MHC s mission as the premier medical center in the nation s capital. Political Environment Metropolitan Hospital Center is an independent, not-for-profit health care organization that was founded by the Jesuits in 1789 in the spirit of cura personalis, or caring for the whole person. Throughout the years, MHC has continuously disenthralled itself and adapted to rise and meet the needs of Washington, DC community it continues to serve today. MHC introduced its first layman CEO in 2000 and made an early commitment in the area of health information technology with the goal of enhancing the delivery of care and making actionable information readily available to its clinicians. For this comprehensive undertaking in identity authentication and access management, the CEO and CIO established the mission and high level goals for the project.

3 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 3 Prior to initiation of the project, the CFO was hesitant to support this undertaking, citing unfounded concerns over return on investment (ROI). The scope of work for this project clearly addressed concerns related to ROI, illustrating both the value and need for robust identity management at MHC. While not a champion of the project, the CFO has expressed his full commitment and support to this initiative. His preference is to select a vendor with demonstrated experience and capability in providing the solutions needed at MHC. All key stakeholders CEO, CIO, CFO, CMO, CNO, IT Director, IT Application Manager, IT Project Manager, Systems Security Officer, and System Architect are fully aligned to support this critical investment in the accessibility and usability of MHC s EHRs and HIT applications. It is the shared goal and expectation of all involved that this implementation will result in a comprehensive identity management solution that makes valuable patient information accessible to clinicians in an interface that truly enhances clinician productivity and workflow. It is paramount that the partner and vendor MHC chooses not only meet functional/technical requirements, but also understand the environment at MHC and shared imperative driving this health care organization. Change Management A Change Management Council (CMC) including key stakeholders has been established to ensure that any change to the original scope of the project is mutually agreed upon and finalized in writing before being enacted. It is vital that the implementation stay on track, in scope, and within the budget. The CMC will provide representation from stakeholders, including the CEO, CIO, CFO, CMO, CNO, Project Managers, and the Vendor (The University of Texas at Austin). The CMC process is as follows:

4 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 4 1. A change request describing the desired change, rationale, impact on timeline, and impact on budget is submitted to either the MHC project manager or the Vendor project manager. 2. The project manager will review the change request and submit it to the other party s project manager (MHC or Vendor). 3. Together, the project managers will decide if it is necessary to present the request to the Change Management Council. 4. Changes potentially affecting implementation timeline, cost, or any part of the scope must be reviewed and discussed by the Change Management Council. CMC members will vote orally, and all members must affirm the change request for it to be approved. 5. It is incumbent upon the project manager(s) to reflect all changes on the document control sheet. The new scope of work will subsequently be distributed to all stakeholders. Analysis of Vendor Responses Request for Proposals (RFPs) were distributed to five companies: Caradigm, Evidian, Imprivata, NetIQ, and Tools4Ever. Four vendor responses were received from Caradigm, Evidian, Imprivata, and Tools4Ever. The MHC selection committee tasked with selecting a vendor was composed of the CEO, CIO, CFO, CMO, CNO, IT Director, IT Application Manager, and Systems Security Officer. Vendors who did not submit an Intent to Respond were automatically eliminated from consideration. Evidian was eliminated from consideration after failing to include all requirements of the RFP format. After vendors were removed due to requirement deficiencies or failure to respond, three vendors remained in consideration.

5 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 5 The selection committee eliminated Tools4Ever after EHR (Cerner and eclinicalworks) and Dragon integration was analyzed and shortcomings were found. Tools4Ever had the ability to integrate with Epic, Meditech, McKesson, and GE Centricity, but not with Cerner, eclinicalworks, or Dragon. EHR and Dragon dictation integration with MHC systems was a primary priority for the selection committee. While Tools4Ever offered the lowest cost bid overall, the custom development needed by Tools4Ever to achieve the integration necessary with MHC s installed systems would increase implementation costs, introduce risks related to new integration technology, and lengthen the project timeline. The last two vendors, Caradigm and Imprivata, were each invited to demonstrate their respective solutions onsite. Both vendors are well established in the Identity Authentication market and exhibited an understanding of the unique needs of healthcare organizations and the workflow needs for clinicians. After proof of concept demonstrations and a comprehensive review of vendor RFP responses, the selection committee evaluated both vendors with a scoring tool. While both vendors may have been able to address the identity management needs of MHC, Imprivata earned the highest score in each category of requirements and demonstrated a lower total cost of ownership over five years compared to Caradigm. In addition to demonstrating a clear understanding of the MHC environment and organizational mission, Imprivata was willing to agree to incentive-based payment terms related to acceptance; specific details of this agreement follow in the section below. For these reasons, Imprivata was awarded the contract by the selection committee and Caradigm was reserved as an alternative in the event that contract negotiations were unsuccessful with Imprivata. Caradigm was promptly notified that it was not awarded the contract.

6 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 6 Vendor Evaluation Criteria Total Cost of Ownership was an important criterion for the MHC selection committee, but vendor responses were also evaluated on capability to execute Functional Requirements, capability to execute Technical & Hardware Requirements, and Solution & Organization Fit. After vendor RFP responses were received and reviewed, a weighted scoring table was utilized to evaluate vendors in the primary criteria areas mentioned above. Each category was composed of individual requirements or requests that were applicable to the overarching category. In summary, the main criteria categories were capability to execute Functional Requirements, capability to execute Technical & Hardware Requirements, Solution & Organization Fit, and Total Cost of Ownership. The vendor solution s capability to execute requirements impacts the timeline of the implementation, integration with existing EHRs, and the overall functionality of the solution to improve clinician productivity and workflow. Solution & Organization Fit may be the most subjective category in MHC s evaluation criteria, informed by the vendor s history, thought paradigms, and organizational profile; however, it is paramount for MHC to partner with a vendor that mirrors its ethics, understands its core business of healthcare, and shares its urgency for a robust identity management solution. Finally, Total Cost of Ownership is about total cost, the expected return on investment (ROI), and the vendor s ability to provide cost benefits for MHC. An excerpt of the weighted scale is available in Appendix A. Acceptance Testing MHC will be conducting acceptance testing in order to evaluate the vendor s compliance with the functional and technical requirements outlined in the RFP, the quality of the product, and whether it is acceptable for delivery to our users (Software Testing Fundamentals, 2014). Acceptance testing will be performed post unit testing, integration testing, and system testing,

7 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 7 but prior to the new technology being implemented and made available to the actual end-users (Software Testing Fundamentals, 2014). This is a crucial step in validating the vendor s product before implementation which is why selecting a vendor not only willing to participate, but also willing to tie milestone based payments to further incentivize the passing of acceptance testing is important. All three vendors agreed to contribute to acceptance testing, however only Imprivata was willing to embrace the request to not receive 15% of their payment or move to the next phase of the project until acceptance testing is signed off as a pass by the project lead. They also agreed that 5% of this milestone payment (15% overall) would be forfeited each time they release the system to MHC for acceptance testing and the result is failure. Acceptance Testing Responsibilities It is expected that the vendor will complete internal acceptance testing prior to releasing the system for external acceptance testing by MHC. Once the system is validated by the vendor as passing their internal acceptance testing, MHC will perform two variations of internal acceptance testing: customer (IT staff) and user (clinical staff) (Software Testing Fundamentals, 2014). Role Name Type of Acceptance Testing Vendor - Internal Vendor Testing IT Project lead Andrea Waterman External Customer Testing IT Application Manager Colleen Samuels External Customer/User Testing Trainers *Multiple External Customer/User Testing Medical Office Director Jonathan Rudd External User Testing Nursing Director Amy Patton External User Testing ED Director Nate Jordan External User Testing Pharmacy Director Katherine Green External User Testing Lab Director Julie Macintosh External User Testing

8 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 8 Acceptance Testing Process When performing acceptance testing, we will be reviewing and testing a predetermined list of requirements outlined from the selected vendors RFP response. The customer acceptance testing will focus more on the technical requirements while the user acceptance testing will focus more on the functional requirements. Both rounds of acceptance testing will look to determine whether the product is working as Figure 1. Process Flow Diagram of Acceptance Testing promised, is behaving in our environment as it was designed to, and that it successfully and reliably carries out the functions essential to the users workflow; Figure 1 illustrates an overview of the acceptance testing process. The testing will be deemed unsuccessful if the selected technology is not able to perform one or more of the requirements marked by the vendor as being a capability that is included in a general release version of the solution that is in use in several client sites or a selected and agreed upon capability that requires modification at an additional fee within Appendix A. If the testing is determined to be unsuccessful, the vendor will be forced to modify their system build without receiving this milestones payment in order to satisfy the agreed upon requirements before being released again for customer/user acceptance testing. Each rendition of this process will result in a 5% reduction in this milestones payment in order to help keep the projects timeline accurate.

9 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 9 Budget At the start of this system acquisition project, we estimated a year one budget of $ K, including capital expense for license and implementation fees and purchase of authentication device hardware. Ongoing annual operating expense was budgeted at $150K for software maintenance. The fees negotiated with Imprivata fall within that anticipated budget. User license fees are $200,000, implementation fees are $120,000, and recommended device costs will be approximately $200,000. We will be implementing with a mix of biometric fingerprint scanners for staff clinicians and tap and go badge scanners for affiliated physicians and non-clinician staff accessing EHR resources. Total device costs may vary until we finalize the number and mix of devices to be purchased. Total year one fees paid to the vendor are approximately $520,000. Annual maintenance fees are lower than we had anticipated, at approximately $40,000 per year to Imprivata (Bagley, 2010). However, we should anticipate the need to add and replace hardware devices each year as MHC staff increases and to maintain the hardware effectively. The annual budget will be amended to allocate $40,000 (plus an annual 3% COLA (cost of living adjustment) to operating expense for maintenance fees and to reserve an additional $30,000 capital expense for new and replacement device hardware. In addition to the fees paid to Imprivata, we are proposing an expenditure for labor equivalent to approximately six person-months, budgeted at $60,000 during year one. Based on guidance from Imprivata and our commitment to a successful implementation, we believe supplementing our current assigned team with a resource that can support the training and rollout to our staff will have a positive impact on this project. Five year TCO (total cost of ownership) for this project is targeted at $777, 345, which includes all fees to be paid to Imprivata and the supplemental, temporary resource described

10 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 10 above. No new permanent FTEs are required to support this system, since some existing IT help desk time will be freed up due to the automation of password resets, one of the benefits of implementing this system.

11 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 11 Appendix A Identity Management Vendor Evaluation Criteria 3 - Indicates capability is included in a general release version of the solution that is in use in several client sites. 2 - Indicates capability requires modification at an additional fee. 1 - Indicates capability is in development and will be available within one year. 0 - Indicates capability is not available and is not planned for development. Functional Requirements Functional requirements Req. Number Requirement Description/Request Caradigm Weighted Score Imprivata Weighted Score 1. Manage user credentials (ID & Password) for all clinician applications 1.1 Centralized credential access and management Ability to add/disable/delete access to applications Ability to add/disable/delete users Ability to manage access based on roles or profiles Allow creation of security templates to manage related application access by role Manage identity across organizations hospital, physician offices, etc. Overall integration with Security Identity Provisioning for credentialing new users Trigger actions based on new hire, new privileges, terminations, and position or department changes from HR system 1.9 Ability to complete bulk transactions to increase efficiency TOTAL Fast network and system authentication Caradigm Weighted Score Imprivata Weighted Score 2.1 Quick login/logout process Reduce clinician and other user time to access applications 2.3 Does not reduce overall system performance Supports up to 5000 concurrent users Ability to simultaneously unlock multiple systems or applications TOTAL Weighted Score Weighted Score 3. Integration with existing directories Caradigm Imprivata 3.1 Ability to integrate with Active Directory Ability to integrate with LDAP Ability to integrate with Microsoft Exchange Ability to integrate with Microsoft Office 365 / Exchange Online 3.5 Ability to integrate with Cerner inpatient EHR Ability to integrate with eclinicalworks ambulatory EHR 3.7 Ability to integrate with Dragon dictation console TOTAL

12 VENDOR SELECTION FOR IDENTITY AUTHENTICATION 12 References Bagley, D. (2010, January 6). Submittal to the Board of Supervisors County of Riverside, State of California. Retrieved from Carman, K. (2013, November 11). How to Manage User Acceptance Testing. Retrieved from Software Testing Fundamentals. (2014). Acceptance Testing. Retrieved from The University of Texas at Austin. Information Technology Process Package Level 2: Executive Summary [PowerPoint slides]. Retrieved from (3).pdf