Common Assessment Project (CAP) Choosing a Vendor Strategy and Software Model. Choosing a Vendor Strategy

Transcription

1 Common Assessment Project (CAP) Choosing a Vendor Strategy and Software Model THE FOLLOWING DOCUMENT IS INTENDED TO SUPPORT ORGANIZATIONS PARTICIPATING IN THE COMMON ASSESSMENT IMPLEMENTATION. THE DECISION TO USE THIS DOCUMENT IS AT THE SOLE DISCRETION OF THE PARTICIPATING ORGANIZATION. ANY DECISIONS MADE BY ORGANIZATIONS SHOULD BE CONSIDERED IN THE CONTEXT OF ORGANIZATION POLICIES AND SUPPORTING PROVINCIAL GUIDELINES AND LAWS, WHERE APPLICABLE. THE TRANSFER PAYMENT AGENCY REPRESENTING THE PROJECT TEAM HOLDS NO RESPONSIBILITY OR LEGAL LIABILITY FOR THE ITEMS AND WORDING CONTAINED WITHIN IT IN WHOLE OR IN PART. CCIM is vendor-neutral and does not suggest nor recommend any vendor specific hardware, software, services or vendors. CCIM does, however, support Local Health Integration Networks (LHINs), Health Service Providers (HSPs) and vendors by clarifying software requirements and specifications, providing tools aimed at providing guidance to LHINs and HSPs, identifying considerations around technology and working with vendors. The purpose of this document is to identify some of the vendor strategy options and the advantages and disadvantages of each of the options. This document also identifies additional considerations when choosing a vendor strategy and software model. Choosing a Vendor Strategy One of the first things a LHIN needs to determine is its vendor strategy. The reasons for this are: If a new vendor(s) needs to be engaged, the time to procure the required products from a vendor needs consideration in the context of implementation timelines If a vendor is new to the interrai CHA or Ontario Common Assessment of Need (OCAN), it will require time to develop a solution Vendors that already have interrai CHA or OCAN solutions may require time to meet the software requirements specifications documented by CCIM. Having a vendor strategy identified early also facilitates the answering of questions HSPs may have about the vendor strategy. Each LHIN will determine its own vendor strategy. Depending on the chosen strategy, the LHIN/HSP will be responsible for managing a vendor and the development of a solution. Three possible vendor strategy options are: 1. LHIN-based approach - a single vendor is engaged to automate the interrai CHA or OCAN in a LHIN. All HSPs would deploy the same software solution. Page 1 of 10

2 2. HSP-based approach a LHIN may choose a LHIN-based approach to implementing the interrai CHA or OCAN, but allow HSPs to engage vendors independently to develop a software solution for their HSP. 3. Hybrid approach - this is primarily a LHIN-based approach where the majority of HSPs would be engaged with the same vendor and some HSPs would engage with vendors independently. These HSPs may engage a different vendor to develop their own solutions or engage the same vendor to develop a custom solution for the HSP. There are general advantages and disadvantages to each of the given strategies. There may be additional advantages or disadvantages specific to a LHIN or HSP. 1. LHIN-based, single vendor approach Strategy Potential Advantages Potential Disadvantages General Depending on the software model, a consistent cross-lhin solution supports more controlled and rapid development across the sector Cost savings in the sector associated with the development and support of a single solution Enables inter-hsp partnering and collaboration May introduce new software to HSPs with a steeper learning curve - one more thing to learn Some HSPs may have commitments and investments in other vendors Vendor capacity to meet all requirements across LHIN(s) Page 2 of 10

3 Procurement Consolidated procurement process versus multiple HSPs undertaking their own procurement processes may save time, effort and costs Volume pricing breaks Reduced overall effort across the LHIN to manage vendor agreements and relationships Ability to negotiate long-term pricing upfront provides LHINwide cost-certainty Implementation Easier to manage the delivery of a single vendor solution in alignment with project timelines. This has a potentially bigger impact for aggressive implementation timelines. Consistent materials and delivery of vendor training and supports Testing and Validation More streamlined testing activities because the same solution is being used by all HSPs Less burden on HSPs because only a single solution needs to be tested Lower costs associated with testing a single solution Less burden on HSPs to validate implementation because only a single solution needs to be validated An agreement with a single vendor may put the LHIN/HSP at risk of future imposed price increases Depending on the procurement experience and capacity of the HSPs, the LHIN may be asked by the HSPs to support their procurement processes More generic or lowest common-denominator solution most likely to be procured Vendor management and contract management on a larger scale becomes the responsibility of the LHIN If the vendor solution is delayed, all dependent deliverables are delayed Issues or delays impact all HSPs Vendor training capacity must be adequate to meet tight timelines Any issues or bugs effect all HSPs and potentially delay all dependent implementation activities Page 3 of 10

4 Sustainability and Support Less burden to manage and implement changes and releases for a single software solution Streamlining vendor management activities Any issues may impact all HSPs if the solution has a bug or there is an issue with data quality Page 4 of 10

5 2. HSP-based, multiple vendor approach Strategy Potential Advantages Potential Disadvantages General Opportunity for greater flexibility in the requirements of the solution (e.g., HSP could request additional requirements beyond those of Community Support Services (CSS) CAP or Community Mental Health (CMH) CAP, such as integration with existing client management system CMS*) More of an opportunity for organizations to work with existing vendors Inconsistency in adherence to requirements across vendor solutions Procurement Opportunity for organizations to define their specific requirements and purchase a solution tailored to their specific needs Implementation Possibility some HSPs can move forward even though others may experience issues or delays Testing and Validation Sustainability and Support Issues or bugs effecting one vendor solution do not necessarily impact all HSPs Overall increased burden on HSPs (e.g., time, effort, cost) to procure their own solution Overall increased burden (e.g., time, effort, cost) as each HSP would be accountable for its solution and adherence to CCIM requirements Inconsistency in quality and delivery of vendor training across vendor solutions Added burden (e.g., time, effort, cost) for HSPs as multiple solutions will require separate testing for each unique Vendor/HSP solution Overall increased burden on HSPs to manage vendor relationships Overall increase burden on HSPs to manage vendor changes and releases Page 5 of 10

6 3. Hybrid, primarily LHIN-based approach In general, the same advantages and disadvantages apply to the hybrid strategy. The closer the strategy is to a LHIN-based approach, the more its advantages and disadvantages apply. As additional vendor solutions are added, the more the advantages and disadvantages of the HSP-based approach apply. By limiting the number of possible vendor solutions (e.g., one LHIN solution with one or two other vendor solutions for specific HSPs) the greater the flexibility of options while reducing some of the risks (e.g., mass delay). *integration with an existing CMS is not in scope. However, this may happen organically if the chosen vendor happens to be the CMS vendor. After an overall vendor strategy is determined, LHINs and/or HSPs, depending on the strategy chosen, will investigate vendors and their proposed solution(s). This document also presents some additional considerations in choosing a preferred software model. Choosing a Software Model Software solutions can be provided in two different models: One is an Application Service Provider (ASP) model and the other is a Local Client Server (LCS) model. Some vendors will support one, or the other, or both. Some vendors may provide hybrid solutions. An ASP provides computer-based services to customers over a network (e.g., private, public Internet). Software offered using an ASP model is sometimes called on-demand software or software as a service (SaaS). With an ASP model the application software and your data reside on a central server (either at your site, or on a remote site) and may be accessed by users through a web browser (e.g., Firefox, Microsoft s Internet Explorer). For the purposes of this project an ASP refers to a software solution located somewhere other than at the HSP. In a LCS model the application and data reside on a server that is managed by the HSP. The main differences between the models are: the amount of IT resources (e.g. hardware, software, Service Desk) required within a LHIN/HSP to support a solution, the location of the software solution and data Page 6 of 10

7 The following diagrams depict the software models. Page 7 of 10

8 The following table provides a comparison between the two models. Key Strengths ASP Transparent, professional IT management System security and safeguards are managed by vendor Reduced or no requirement for on-site IT staff Monthly payment model Local Server Additional resources required to manage Data on site Not dependant on Internet connectivity More control over IT management Reliability Vendors typically house robust and reliable hardware to support their solutions with costs that are generally shared by multiple clients. This usually includes builtin redundancy in servers, processors, and storage (hard drives) and power (e.g., uninterruptible power supply (UPS) and backup generators). Hardware Does not require a server at HSP to house the solution May require a low-end, local server to support simple network functions such as printing Can be accessed by less powerful computers since they only need to support web browser software Pricing Usually priced as a monthly service Upgrades Applications are managed by Vendor s IT staff Servers with redundant processors and disk storage are more expensive, but recommended Purchase of a costly uninterrupted power supply hardware (UPS) for servers is a best practice to protect data in power outage System is available when there is no Internet connectivity Requires reliable server at LHIN/HSP May require more powerful computers to achieve acceptable response times Usually priced as a purchase of software, followed by annual maintenance fees Applications are managed by LHIN/HSP staff Vendors usually supply upgrades via CD-ROM, or downloaded from the Internet Page 8 of 10

9 ASP Backups Vendor is responsible for backing up all data. Often, vendors are able to back up data every few hours, minimizing the potential for data loss Backups are managed by professionals who are aware of any problems with backups Backup media are usually stored offsite on a scheduled basis Support Support levels, performance, and availability are usually agreed to in a Service Level Agreement (SLA) (e.g. applications will return data within 3 seconds; system will be available 7 x 24, 365 days a year, 99.99% of the time), which is part of the overall contract for services with a vendor The SLA specifies penalties to the vendor if they do not adhere to the terms of the agreement Potential to leverage synergies gained through common release and change management processes Local Server LHIN/HSP is responsible for managing backups Vendors can supply and configure backup software and hardware that is highly reliable LHIN/HSP must arrange for backups to be moved to offsite storage facility IT support for additional technology infrastructure may have to be arranged with a local IT Service Provider, corporate resources, internal staff, or any combination thereof. Services provided by external providers should have a Service Level Agreement Services provided internally may require an Operational Level Agreement Security and Privacy Requires a secure Internet connection Vendors may have access to your data to provide support Vendors can be held to industry standards Terms of access should be defined through a Service Level Agreement (SLA) and/or Data Sharing Agreement (DSA) Data is stored on-site Vendors may require access to data to provide support LHIN/HSP can control access (i.e. turn it on and off) as required Data stored on-site is as secure as the premises itself Relies on LHIN/HSP understanding and being able to implement industry standards After a vendor strategy and preferred software model have been chosen, a vendor will need to be engaged to develop a solution or refine an existing solution. Please refer to Page 9 of 10

10 the Technology Checklist in the Technology sections of the CSS CAP and CMH CAP areas of the CCIM website. Page 10 of 10