Colorado Department of Public Health and Environment (CDPHE) Medical Marijuana Registration System SF- 15FAA0602-Q. Procurement Office CDPHE RFP

Transcription

1 Colorado Department of Public Health and Environment (CDPHE) SF- 15FAA0602-Q Colorado Department of Public Health and Environment Procurement Office CDPHE RFP i

2 TABLE OF CONTENTS SECTION 1. Background and Overview Introduction Funding Statutory Compliance Overview Glossary Statement of Work Summary... 9 SECTION 2. Proposal Requirements and Statement of Work Mandatory Minimum Requirements Innovative strategies medical marijuana registry processes Confidentiality standards User information Business Functions SECTION 3. Technical Requirements SECTION 4. Rights in data, documents and computer software SECTION 5. Resources and Management State staff resources Vendors Cost SECTION 6. Offeror Response Format Proposal Submission Addressing Proposal Requirements (Offeror Response) Content Quality Proposal Organization Conflicts with Terms, Conditions, or Requirements SECTION 7. Proposal Evaluation Evaluation Process Adequacy and Completeness of Response Evaluation Committee Evaluation Methodology Basis for Award Evaluation Based on Initial Proposals Competitive Range Clarifications/Discussions Presentations/Demonstrations Best and Final Offers (BAFO) Final Evaluations Award Recommendation Notice of Intent to Award Contract Review... 46

3 Appendices Exhibit A: Vendor Information Form / Confirmation of Offer Exhibit B: State of Colorado Model IT Contract

4 SECTION 1. Background and Overview 1.1 INTRODUCTION The State of Colorado is seeking proposals for the development of a Medical Marijuana Registry System. This project includes the development and implementation of the Medical Marijuana Registration System (MMRS), conversion of data from the current registration system into the new registry, and the development of training and support materials to ensure continuity and maintenance of the system. Legislation is pending regarding the ability for external contractors to service the MMRS once it has been populated with the Registry s confidential data. Vendor shall develop, test, implement and maintain post-implementation. This Registry is the single point of registration for all needs relating to the use of medical marijuana within the State of Colorado. 1.2 FUNDING development is entirely funded through the medical marijuana cash fund. 1.3 STATUTORY COMPLIANCE The Registry s policies and procedures are governed by laws and regulations established at the federal, state and department levels. At minimum, all systems must be in compliance with the following: A. The Health Insurance Portability and Accountability Act (HIPAA) B. Colorado Constitution, Article XVIII, Section 14 C. Colorado Board of Health Regulation 5 CCR Medical Use of Marijuana D. Colorado Revised Statute E. Colorado Revised Statute F. CDPHE Privacy and Security Standards G. Colorado State Record Retention Standards 1.4 OVERVIEW The Medical Marijuana Registry (the State) is a confidential database of Colorado residents who qualify for medical marijuana use due to debilitating medical conditions. The registration process requires coordination among multiple partners including Registry staff, the patient, physicians, medical marijuana centers, caregivers, and patient representatives such as parents and legal agents. The Registry is under legislative constraints to process applications and mail registration cards to patients within 35-days of receipt. The (MMRS) will replace an existing program that is based on the submission of forms and data entry by Registry staff. The new registry shall meet the statutory 35-day response time for an application by eliminating potential errors through a web application with instant correction opportunity and validation rules to ensure applications are completed as accurately as possible. The data management system shall have the ability to provide reliable, historical data to stakeholders to aid in staff development, strategic planning, and regulatory review and enforcement. 4

5 Detailed requirements follow, however, an overview of the Registry s expectations for the awarded contractor are that they shall provide: A. A HIPAA-compliant system that provides an external portal through which patients, physicians, medical marijuana centers, caregivers and patient representatives may electronically submit applications, receive instant notice of incomplete or inaccurate data entry, make changes to existing records, and verify status of submissions. B. A robust archive and reporting system that allows for field-specific and aggregate data searches of current and specific time frames. C. Multiple methods of data entry including electronic submission by external partners, internal data entry of hard-copy submissions, OCR scanning of documents, PDF conversion to text, or a combination of all methods within one record/process. D. Extensive help features including but not limited to field-specific help, error prompts during submission, knowledge articles for service desk, searchable frequently asked questions (FAQs), and glossary/dictionary of common terms E. A user-friendly system designed for users who may have literacy and comprehension challenges due to chronic pain and illness. Ease of use will be a primary factor for many partners. F. A responsive system that facilitates submission of multiple components by multiple partners working from different locations using a variety of platforms such as desktop, laptop, cell phone, tablets or scanner/fax machines. G. The application must be accessible 24/7 via external portals with an anticipated user volume of at least 5,000 people per hour. H. The MMRS software application must provide five 9s (99.999%) of reliability, with 24-hour oncall assistance in time of disaster recovery or system failure. I. The new registry shall have a baseline of a.net 4.5 framework using SQL 2012 Enterprise and HTTPS protocols for security or current technologies not greater than three years old. 1.5 GLOSSARY Abbreviation/Term Application (AP) Application Packet Awarded Offeror Definition or Purpose The actual form filled out by individuals that contain patient and provider information. This is one of several pages required for a complete application packet. A compilation of all documents and fees required for application to the Registry. An application is considered complete when it includes an application, a physician certification, proof of identity, proof of residency, the processing fee, and when applicable the caregiver acknowledgement form and caregiver identification. Awarded Offeror means the Offeror whose proposal the State determines to be most advantageous considering the factors set forth in this RFP. 5

6 BIDS C.R.S. Card Caregiver (CG) Caregiver Acknowledgment (CGF) Cash Tendering System (CTS) Change of Homebound Status (HBF) Change of Patient Records (CR or COPR) MMRS ID # Contractor Customer Service Unit (CSU) Evaluating & Processing Unit (EPU) Fraud Prevention Unit (FPU) Homebound (HB) Law Enforcement Officer (LEO) Verification The State of Colorado's Bid Information and Distribution System Web site, located at: All solicitations published by State agencies and institutions are published on BIDS. All bidders or Offerors wishing to respond to a solicitation (including this RFP) must be registered with BIDS. Colorado Revised Statutes Medical Marijuana Registration Card A primary caregiver is an individual 18 years of age or older who has significant responsibility for managing the well-being of a patient who has a debilitating medical condition. Caregivers complete this form to acknowledge they are providing caregiving services to a medical marijuana patient. In addition, this form is used to request a waiver for caregivers who are serving more than five patients with active cards. This is the current financial management system the Department uses for processing and tracking payments. If a patient is designated as homebound by his/her physician after the initial application has been processed, this form is used to adjust status and request a replacement card with the designation of homebound. This is a change request form that allows patients to make changes to their name, address and/or provider. Unique ID generated by the MMRS system for each user. The ID is autogenerated, alpha-numeric code that is distinct for each user. The Offeror that is awarded a contract as a result of this RFP. Same as "selected Offeror," and "successful Offeror." Team of Registry staff members providing communications, training, and customer service to patients, physicians, caregivers, medical marijuana centers and other external partners. Team of Registry staff members focused on the initial receipt, evaluation and data entry of patient application and modification requests. Team of Registry staff members monitoring security for staff, facilities, and confidential documents, liaison with law enforcement agencies and courts, fraud assessment and verification of questionable documentation. Individuals who have significant challenge traveling outside of their home due to physical illness and/or mobility constraints. Colorado laws include an exemption to medical marijuana rules to allow caregivers to aid in the transportation of medical marijuana to homebound patients. In the course of duty, Colorado law enforcement officers may request verification of a patient s status on the Registry. Currently verifications are submitted in writing to the Registry s Fraud Prevention Unit or through an external interface developed by the Colorado Bureau of Investigation. 6

7 Medical Marijuana Centers (MMC) Minor Application (MA) MMRS software application Module New Patient Offeror Patient Agent Physician Certification (PC) Proposal Provider Provider Information Update (PI) Provider Signature Revocation (SR) Quality Assurance Unit (QAU) Query Also known as dispensaries, medical marijuana centers are organizations licensed through the Department of Revenue to cultivate and sell medical marijuana and associated products. Application packet for individuals under the age of 18. The minor application has additional requirements beyond the standard application, including parental consent forms, additional documentation requirements and two physician certifications. Refers to the being developed by the Vendor as result of this RFP. Design structure that creates user screens that pull specific fields into one location to perform specific functions, and hides all other data from the individual record. For example a finance module may pull in the patient s name, date of birth, unique ID number, payment history and fields pertaining to new payment recording. Any individual applying for a registration card who has not previously had a card from the Registry. Any organization or individual submitting a proposal in response to an RFP. Sometimes used interchangeably with the term "Bidder, vendor or contractor." Individual assigned legal rights and responsibilities to provide assistance and care for the well-being of a patient. These rights may include the ability to make financial and medical decisions for the patient, and to sign and submit legal documents. Examples of patient agents include parents, legal guardians and individuals who have been assigned power of attorney or medical power of attorney. Patients are required by law to be examined annually by a physician as part of the application process. The physician certification is a form completed by the physician which provides an overview of the patient s medical condition and the bona fide physician-patient relationship. An offer in response to a Request for Proposals (RFP). Sometimes used interchangeably with the terms "bid," "offer," or "response." Provider is an inclusive term that references the medical marijuana center and/or the caregiver(s) cultivating medical marijuana for a patient. Caregivers and medical marijuana centers use this form to update their contact information. Physicians and caregivers use this form to revoke their signature from the patient s application and/or other documentation. Revocation of signature indicates the physician and/or caregiver is no longer providing services to the patient. Team of Registry staff members focused on quality assurance of data and documents, payment processing, financial management and card printing, mailing, and scanning documents for electronic storage. Ability to search for specific or aggregate information from the database. 7

8 Removal from the Voluntary Caregiver Registry (RC) Renewal Patient Reply to Rejects (R2R) Report Report of Lost, Stolen or Damaged Card (LS) Request for Fee Waiver/Tax- Exempt Status (FW) Request for Patient Information (RP) Request for Proposals (RFP) Request to Surrender (SU) Selected Offeror Social Security Number (SSN) Solicitation Successful Offeror Third Party Timeline Caregivers may remove their name from the listing of available caregivers in an area. Once their name is removed from the Voluntary Caregiver Registry, their entire record becomes confidential again, including their name and contact information. Any individual who has previously had a card through the Registry. Reply to a previously rejected application or supporting document A structured product that displays the results of a query. This form is used to request a replacement card when the existing card has been lost, stolen or damaged. Patients who have a household income at or lower than 185% of the federal poverty level may apply for a fee waiver by submitting this form with a copy of their certified Colorado tax return and proof of identification. Tax-exempt status is listed on patients cards so they do not have to pay the sales taxes on medical marijuana. Patients must submit this form completely to gain copies of paperwork that has been scanned into their electronic records. A procurement solicitation that seeks offers from organizations or individuals to perform the scope of work defined in the RFP, in accordance with the terms listed in the RFP. An RFP is issued with the intent of selecting the most advantageous proposal, making an award to that Offeror, and entering into a contract. Patients submit this form to request termination of their right to possess and use medical marijuana in the state of Colorado. They will no longer be an active registrant, but their name does remain in the Registry s confidential database as a previous (or inactive) registrant. The Offeror that is awarded the contract that results from an RFP. Patients are required to have a social security number for registration. The Social Security Number is not, however, used as a sole or primary identifying factor for patient identity verification. A document issued by a prospective buyer that requests competitive offers from organizations or individuals to sell the goods or services that are specified in the document. A solicitation typically results in an award of a contract or purchase order for the goods or services, based on an award methodology defined in the solicitation. Same as "selected Offeror." Third-party individuals may provide assistance to patients in completing paperwork or filing records online. The third party agent does not have the legal rights or responsibilities to make decisions for the patient, sign or submit documentation. Examples of third party individuals may include staff at medical marijuana centers, notaries or medical office staff. A document that details dates and targets for achieving program goals or requirements. 8

9 Transaction Code (TransCode or TCode) User Vendor Voluntary Caregiver Registration (VC) The transaction code is the current system for classifying and tracking specific functions within the Registry s multiple processes and to queue other actions. See Appendix II: Current TransactionCodes for a list of current functions for which the Registry uses transaction codes. Any registered user of the. Any organization or individual that seeks to provide, or is already providing, goods or services. Often synonymous with selected, successful, or awarded Offeror. The Voluntary Caregivers Registry provides patients with contact information for primary caregivers in their area. By completing this form, individuals are allowing the Registry to release their contact information to physicians and prospective patients. All other information in the caregiver s records remains confidential. 1.6 STATEMENT OF WORK SUMMARY The plan must be executed within twenty-four months of the final contract signature. Each phase/ deliverable must be formally accepted by the CDPHE project manager in writing. a. Preliminary Task Plan Phase 1 Project Initiation, Planning and Management Task 1.1 Project Initiation Task 1.2 System Transfer and Modification and Testing Plan (Project Plan) Task 1.3 Work Breakdown Structure (WBS) Task 1.4 Project Schedule Task 1.5 Project Status Reporting Phase 2 System Design Task 2.1 Joint Application Design Sessions (JAD) Task 2.2 Business Requirement Document (BRD) Task 2.3 Technical Design Document (TDD) Task 2.4 Hardware Requirement recommendations (CDPHE provided) Task 2.5 Implementation, Conversion, Training, Security and Telecommunications Plans Phase 3 System Development and Testing Task 3.1 System Modification, Technical Testing, and Revision Task 3.2 Operational Planning, Documentation, Training Materials Phase 4 User Acceptance Testing (UAT) Task 4.1 Test Script Preparation Task 4.2 Test Bed Preparation Task 4.3 Support UAT and System Revision Task Break Fix Task 4.5 Regression Testing Phase 5 Pilot Testing Task 5.1 Help Desk Training Task 5.2 Pilot Test User Training Task 5.3 Data Conversion UAT 9

10 Task 5.4 Support Pilot Test and System Revision Phase 6 Data Conversion and Rollout Task 6.1 User Training Task 6.2 Final Data Conversion Task 6.3 Support Implementation and Problem Resolution Phase 7 Operations and Maintenance Initial Warranty Period Task 7.1 System Issue Reporting Task 7.2 System Modification and Release for Testing Phase 8 Project Closure Task 8.1 Final System Documentation Task 8.2 Contract Closure b. Detailed Task Statements Colorado Department of Public Health and Environment Phase 1 Project Initiation, Planning and Management In Phase 1 the Contractor provides for the conduct of a project initiation meeting, prepares plans that will guide and track the project s progress, and initiates project status reporting. Task 1.1 Project Initiation The Contractor shall convene an initiation meeting at CDPHE s MMR office. The Contractor s Project Manager and other key staff deemed necessary by the state shall attend the meeting. The purpose of the meeting will be to review the project plan, schedule, and deliverables, and to discuss the management of change orders. Within five working days of the meeting the Contractor shall deliver a technical memorandum documenting all agreements, understandings, and contingencies arising from the project initiation meeting. MMR Del 01 Project Initiation Meeting Task 1.2 System Transfer and Modification and Testing Plan (Project Plan) The Contractor shall deliver a comprehensive system and modification plan describing in detail the contractor s approach to the transfer, modification and implementation of the. The plan will follow a format agreed to by the state. The plan shall also include a discussion of the contractor s approach to quality assurance and security. MMR Del 02 Final Work Plan and Schedule (part 1) Task 1.3 Work Breakdown Structure As a preliminary step to the completion of the Final Work Plan and Schedule, the Contractor shall prepare and submit a Work Breakdown Structure (WBS) for their MMRS project effort. Each major task group described in the WBS should culminate in an identifiable and measureable project deliverable and/or milestone at the project control level. The WBS should facilitate documentation of completed work and allocation and expenditure of resources by reducing all deliverables to verifiable work package level. Task 1.4 Project Schedule The Contractor shall deliver a master project schedule in MS Project format. The project schedule shall reflect any changes from the plan submitted with the contractor s proposal that were discussed and agreed to during the project initiation meeting. The project schedule, along with the WBS, shall describe the level of effort, time frames, costs, and 10

11 responsibilities for the Contractor in relation to the time frames and responsibilities of the state. The project schedule shall be maintained throughout the life of the project and shall be updated as necessary to reflect the accurate status of the project. The project schedule shall be maintained by the State Project Manager with input from the Contractor Project Manager. Careful consideration and adherence shall be given to the project schedule allowing for a January 1 rollout of the application. MMR Del 02 Final Work Plan and Schedule (part 2) Task 1.5 Project Status Reporting Within five working days from the start of each month, the Contractor shall prepare and submit monthly, to the State Project Manager, detailed reports on the overall project status, in a format agreed to by the state. Phase 2 System Design In phase 2, System Design, the Contractor leads and facilitates the conduct of system design sessions, prepares the system functional and technical documentation, and prepares detailed plans for the system implementation, data conversion, user training and maintenance of system security. This phase ends with the state s formal acceptance of the Contractor s plans and design documentation. Task 2.1 Joint Application Design Sessions The Contractor shall conduct a review of the current system s functionality to identify required revisions to the system. These meetings will be held with selected state staff at the CDPHE Campus. The purpose of these meetings is to review the functionality of the system as it relates to the functional requirements identified in the response to the Request for Proposal (RFP), identify missing requirements, and to detail those missing, yet requested features. The Contractor shall provide written confirmation of the decisions made during the design sessions. MMR Del 03 System Design Sessions Task 2.2 Business Requirement Documents (BRD) The Contractor shall deliver a Business Requirements Document for each section of the Registry, describing in detail, the functional design of the system. Format of the BRD will be agreed to by the state in advance. These deliverables will be presented in an initial draft for review, input and comment by state staff, and final version. Formal State approval of each BRD will be required before system development activities may begin. MMR Del 04 Business Requirements Document Task 2.3 Technical Design Document (TDD) The Contractor shall deliver to the state a Technical Design Document (TDD) reflecting the final requirements for system configuration and operation based on the BRD. This document shall describe all internal specifications in detail including, but not limited to, data flow diagrams, entity relationship diagrams, processing definitions in Structured English, a data dictionary, definitions of system edits, and a detailed description of system architecture. This deliverable is to be presented in initial draft for review, input and comment by state staff, and final version. Formal State approval of the TDD will be required 11

12 before system development activities may begin. MMR Del 05 Technical Design Documents Task 2.4 Implementation, Conversion, Training, and Security Plans The Contractor shall deliver a series of written plans for the conduct of the remaining aspects of system implementation. The plans will detail the contractor s approach to system implementation, data conversion, training, and security. The following, at a minimum, must be included specifically for each area: Implementation: The plan must include a timeline specific to implementation activities, detailing responsible parties, testing schedule by completed deliverables, and other milestones. Project completion must be no more than 24 months from contract execution date. The plan will detail the Contractor s recommended approach to implementation and how the system may be phased into production. Conversion: The plan must provide field-by-field mapping from the legacy system to the new system, including the following: Any assumption or proposed calculations involved in the conversion; Default values for required fields that do not exist in the legacy system or a method to allow for missing data; Methods for handling anomalies in the data between the systems (data elements with different length/type, or data elements with stricter edit requirements in the new system that fail those edits in the old) The Conversion Plan will detail any clean up procedures the state can take to improve the conversion effort. The Conversion Plan shall detail exception reports that will be produced by the conversion programs and provide for a fully auditable conversion of data files. Training: The Training Plan must describe the types of training and the audience for each, provide a description of training materials, provide a description of training methodology, include a detailed list of topics to be covered for each type of training, and describe the methodology for evaluation of training effectiveness. The Plan must provide an overview of tools and materials to be employed in the training, including workbooks, handouts, evaluative materials and a training system if employed. The Plan must identify the proposed training staff. Security: The Security Plan must include a commitment to the Colorado Office of Information Security (CISO) standards and requirements and include a plan for ongoing security assessments and reviews. Processes and procedures for preventing access to data by unauthorized persons must be described in detail. Data encryption standards and public key/private key access controls must be described in detail. MMR Del 06 Implementation, Conversion, Training, Security Plans 12

13 Phase 3 System Development and Testing In this phase the Contractor conducts the system development of any enhancements to the transfer system and conducts a comprehensive technical test of the application. This phase ends with the Contractor demonstration of error-free system operation and system certification of readiness for UAT. Task 3.1 System Modification, Technical Testing, and Revision This task includes the development and testing of the major Contractor deliverable, the updated (MMRS). Once the Contractor s development and internal testing is finished, the contractor will formally advise the State that the system is ready for UAT. The system will be ready for user acceptance testing only after the contractor has performed a thorough system qualification test of all system functionality, and that test has recorded zero errors. This includes the conversion routines for converting records from the legacy system, as this system functionality will also be tested during UAT. The contractor is responsible for generating the test data and test cases to be used for its own system qualification test. The Contractor shall develop the modified MMRS utilizing the following standard test activities: Unit/Module Test Used by the Contractor to validate that an individual program module or script functions correctly. It validates the module s logic, adherence to functional requirements and adherence to technical specification. Each unit/module test shall execute every source statement and each conditional branch in the module. Integration Test Examines subsystems that are made up of integrated groupings of software modules. Integration testing should be conducted in the development environment. It is the first level of testing where problem reports are generated, classified by severity, and the resolution monitored and reported. System Qualification Test Shall be conducted by an independent test group within the Contractor s organization, tests the entire system when coding and testing of all system modules and subsystems has been completed. It determines whether the system complies with standards and satisfies functional, technical, and operational requirements. The goal of testing is to confirm that both individual system modules and the entire system perform in accordance with the functional requirements and technical specifications. During this test period, system documents and training manuals must also be tested for accuracy, validity, completeness and usability. During this test the software performance, response time, and ability of the system to operate under stressed conditions and maximum load are tested. External system interfaces are also tested. The ability of the system to correctly process data converted from the legacy systems is tested. All findings shall be documented during the test and compiled in a system qualification test analysis report prepared by the Contractor for delivery to the State. The test is only complete when it can be run with zero errors. Regression Testing Regression testing shall re-test a system component (unit module, or subsystem) following any modification to verify that the problem was corrected without adverse effects and to ensure the component still complies with its requirements. Regression testing also refers to rerunning the entire system 13

14 qualification test after errors have been corrected to ensure that unanticipated errors have not been introduced elsewhere in the system by the error correction activity. Once the Contractor is satisfied that the system meets the functional requirements and technical specifications, the contractor shall provide the State with a written certification that the system is ready for User Acceptance Testing. This certification shall not be delivered until the system has passed all tests and there are no known errors. MMR Del 10 Readiness Certification Task 3.2 Operational Planning, Documentation, Training Materials The Contractor shall prepare and submit comprehensive User Training materials for all levels of system training. The Contractor shall also prepare and submit a System Operations Plan that describes all required system operational activities and provides guidance on system maintenance and enhancement practices, tools and approaches. The Contractor must also provide any additional documentation, such as equipment manuals and COTS applications user manuals at this time. The Contractor must provide an automated help function in the system and provide an electronic help desk manual and knowledge articles written for common errors that can be loaded into the OIT Service Desk software. These deliverables will be submitted in draft and final form. MMR Del 07 Help Desk Plan MMR Del 08 User and Operations Manual MMR Del 09 Disaster Recovery Plan Phase 4 User Acceptance Testing (UAT) In this phase the Contractor facilitates and supports the conduct of user acceptance testing and remedies all errors identified during testing. Task 4.1 Test Script Preparation The Contractor shall prepare and deliver, in draft and final format, test scripts to be used by the State during UAT. The test scripts shall encompass all functionality of the MMRS. Task 4.2 Test Bed Preparation The Contractor shall assist the State with the coordination and installation of hardware and software. This may include integrating the server into existing environments if needed. The Contractor shall be responsible for loading the MMRS test system, and the initial definition and population of system data in preparation for UAT. The Contractor will maintain responsibility for system operations at least until rollout is complete. MMR Del 11 Install/Operation of System Software for UAT Task 4.3 Support UAT Contractor staff will be available onsite, and in their development facilities, for consultation and problem resolution during UAT. The Contractor will install the MMRS at the state processing center, convert data from the legacy system as required, and provide initial training to the user acceptance test team. 14

15 Task 4.4 Break Fix The Contractor shall make all required corrections and revisions to the system resulting from the acceptance testing process. The Contractor will re-test systems to ensure that unanticipated errors have not been introduced elsewhere in the system by the error correction activity Task 4.5 Regression Testing System re-testing shall be conducted as required. The Contractor shall provide an application for the capture, reporting, and tracking of errors identified during UAT. The application may be a COTS product or a custom application provided by the Contractor. MMR Del 12 User Acceptance Testing (UAT) Support During UAT the user manuals and online help will also be evaluated by the State test team. Any inadequacies in the manuals must be corrected prior to final acceptance of those documents. UAT will not be considered complete until the system is capable of successfully processing the operations of all UAT test procedures without significant (other than cosmetic) error or failure. After successful completion of the acceptance test, the Contractor will provide the State with a formal assessment of the system s readiness for pilot implementation. The UAT is completed with the State s formal acceptance of the system readiness for pilot document. The State will have the final determination when regression testing is complete and the system is fully functional. MMR Del 13 Assessment and Certification of System Readiness for Pilot Phase 5 Pilot Testing In the Pilot phase the Contractor supports and facilitates the conduct of a system pilot test. Once the system has passed UAT and has been formally accepted, a system pilot will be conducted at the state office and a limited number of local users. The purpose of the pilot is to verify that the system works correctly in conditions of actual use. Task 5.1 Help Desk Training The Contractor shall provide training to the State s in-house Help Desk staff. This group of individuals will serve as the first line in assisting MMRS users with system issues. The Contractor will provide Knowledge Base Articles to be included in the Service Desk (CA) software book of knowledge. Any questions or problems they are unable to solve will be escalated to the Contractor for resolution. Following this training the contractor should be able to provide any additional assistance to the help desk remotely from its own facilities. MMR Del 15 Conduct Help Desk Training for Pilot Task 5.2 Pilot Test User Training The Contractor shall provide face-to-face onsite training for the staff that will be involved in the pilot sites. The training may employ hardcopy exhibits and handout materials but must also include extensive hands-on, online exercises. Training shall be of sufficient length to 15

16 ensure adequate comprehension. Training must comprehensively address all system operations as well as security considerations. MMR Del 14 Conduct User Training for Pilot Task 5.3 Data Conversion The Contractor and State staff shall work jointly to determine if any legacy data requires conversion for the conduct of the pilot. If deemed necessary, the Contractor shall convert, and load, any legacy data needed for the pilot site. The conversion of the pilot site data will occur immediately prior to implementation of the pilot site. MMR Del 16 Installation/Conversion/Operation of System Software for Pilot Task 5.4 Support Pilot Test and System Revision The Contractor shall be required to oversee the pilot test of the new MMRS, respond to reported system errors, and provide consultation and assistance as needed. The Contractor will work closely with the state operations staff to monitor system operations. If and when errors are encountered during the conduct of the system pilot, new versions of the system with the errors corrected will be programmed and tested by the Contractor. After correction and testing of each new version, agreed upon Regression Acceptance Testing will be performed upon the new version to ensure that the error correction has not introduced new errors elsewhere in the system. MMR Del 17 System Pilot Support Within ten business days following the end of pilot, the Contractor, with input from the pilot sites, will complete and submit an evaluation of the system pilot. The Contractor will provide the State with a formal assessment of the system s readiness for rollout. The pilot is completed with the State s formal acceptance of the system readiness for rollout document. MMR Del 18 Assessment and Certification of System Readiness for Rollout Phase 6 Data Conversion and Rollout During this phase the Contractor conducts, supports, and facilitates the rollout of the system to the non-pilot users. Task 6.1 User Training The Contractor shall provide sufficient training and training materials to the state staff to allow the State to perform system training during rollout. MMR Del 19 Conduct User Training for Rollout Task 6.2 Data Conversion The Contractor shall perform data conversion of the legacy data adhering to the Conversion Plan detailed in task 2.4 of this Statement of Work. Task 6.3 Support Implementation and Problem Resolution 16

17 The Contractor shall be required to oversee the rollout of the new MMRS, respond to reported system errors, and provide consultation and assistance as needed. The Contractor will work closely with the state operations staff to monitor system operations. If and when errors are encountered once in production, new versions of the system with the errors corrected will be programmed and tested by the Contractor. After correction and testing of each new version, agreed upon Regression Acceptance Testing will be performed upon the new version to ensure that the error correction has not introduced new errors elsewhere in the system. MMR Del 20 Installation/Conversion/Operation of System Software for Rollout Phase 7 Operations and Maintenance Initial Warranty Period In this phase the Contractor provides system operations and maintenance support to the state and provides for a one-year warranty of the software against errors and defects. MMR Del 21 System Warranty, Maintenance, and Support Task 7.1 System Issue Reporting The Contractor shall provide the State with a written response to any reported system problem, addressing the technical nature of the problem and the proposed plan to resolve the issue. All approved change orders shall be documented and tracked separately. Task 7.2 System Modification and Release for Testing The Contractor must remedy any deficiencies identified in the system during the one-year warranty period at no additional cost to the State. All software modifications and repairs must be subject to regression testing prior to distribution as a new release. Additionally, the State at its discretion may request that the Contractor conduct modifications and enhancements to the system deemed necessary or desirable. In this event the Contractor will be requested to prepare an estimate for the requested modification. Should the State then elect to proceed, the modification will be treated as a change order to the contract. These changes will be designed, developed, tested and implemented on a mutually agreed upon schedule. The contractor will involve state Operations staff so that they can become familiar with the system enhancement process. Costs for these changes shall be negotiated based on the rates quoted in the cost proposal. The contractor shall provide documented test results, release notes, and updated system documentation prior to the implementation of the change. Phase 8 Project Closure In this phase the Contractor provides final submission of the updated system documentation and other project material, supports the transition of the system operations, and maintenance responsibilities to the system operations staff and achieves formal project closure. Task 8.1 Final System Documentation Upon completion of the one-year warranty period the Contractor is to provide the State with a final, updated version of all system documentation and user materials reflecting current status and operations of the system. Additionally, the Contractor is to return to the State any materials, forms, or data sets acquired during the course of the project effort. 17

18 MMR Del 22 Final System Documentation Turnover Colorado Department of Public Health and Environment Task 8.2 Contract Closure After completion of Task 8.1 the State will provide all final payments owed to the Contractor and will provide formal notification of contract closure. Other Contractor requirements: The Contractor must sign and comply with confidentiality agreement SECTION 2. Proposal Requirements and Statement of Work 2.1 MANDATORY MINIMUM REQUIREMENTS Offerors must comply with the following mandatory requirements in order to be considered responsive to this RFP and to be eligible to be awarded a contract. These items are reviewed as a pass or fail during evaluation of proposals: Security/ Cyber Security. Offeror agrees to maintain system and application security that conforms to the following: State of Colorado Cyber Security Policies as found at Current cyber security Standards set forth and maintained by the Center for Internet Security, which can be found at: Offeror s Response M1. Signed Vendor Information Form/Confirmation of Offer (Attachment A). This MUST be signed by the Offeror or an officer of the Offeror legally authorized to bind the Offeror to the proposal. M2. Offer shall clearly state, with no exception, agreement to comply the State of Colorado Cyber Security polices as found at and the security requirements in the model contract. The following sections provide the Offeror with a general overview of the requirements contained within this RFP. Additional requirement information is contained in the attached appendices. 18

19 2.2 INNOVATIVE STRATEGIES The following information provides an overview of the Registry s current business processes and data collection standards, and the methods for achieving the program s needs through the legacy system. Vendors are encouraged to incorporate recommendations for improvement or innovation that meet these needs in other structures/formats as well. 2.3 MEDICAL MARIJUANA REGISTRY PROCESSES The business practices necessary to administer the Medical Marijuana Registry align with the following categories. The following table illustrates the major processes, but is not an exhaustive list of activities to be accomplished through the MMRS software application. Process Sub-process Description Documentation Intake The intake stage identifies actions such as opening mail, tracking all incoming/outgoing documents, distribution of documents and entry into the production process. Documentation intake may include mail, , fax, personal delivery, internal requests, return mail and electronic entry via the MMRS software application. Document Evaluation Standard documents Non-standard documents Data Entry Financial Management Payment Processing Deposits Insufficient Funds/Incomplete Payments Quality Assurance/ Data Entry Verification Document evaluation is an assessment of all paperwork submitted to insure it complies with policies, procedures and other rules/guidelines provided. Non-standard documents may require additional stages of research or verification. Data entry components vary by the case type. For example, more data is entered for a complete application packet than for a change of patient record request. Financial management within the context of the MMRS would include processing of application fees, bank deposit compilation, and tracking patients with insufficient funds/incomplete payments. Quality assurance is responsible for verifying data entered into 19

20 Communication Tools Standard Communication Customized Communication Forms Card Generation Customer Service Fraud Prevention Identity and residency verification Trends in behaviors that may indicate fraud Law enforcement the system matches the documentation submitted and the letter and/or card to be sent. This is a primary step for avoiding potential breaches of Registry information. Record corrections, merging duplicate files, ensuring data integrity, and accuracy based on submitted documentation. Once a form is processed a notice is generated detailing the results. Communication may be sent by , fax, or traditional mail systems. Once a patient s application is approved a card is printed and mailed. Renewal applications are required annually, and renewal cards are sent as a result. Replacement cards may be issued for changes in the patient record that impact purchase or reports of lost, stolen or damaged cards. Customer service may be required in any case, particularly if direct communication to patient, physician or provider is required. Customer service is also aligned with ensuring consistent, standardized responses. Non-standard documentation is vetted through a fraudprevention verification. In addition, paperwork from multiple individuals may be submitted for further research if trends indicate potential for fraud. Fraud prevention activities include identity and residency verification, trends in behaviors that may indicate fraud, and referral to law enforcement as necessary. Tracking law enforcement verification requests, generating responses, tracking of judicial and 20

21 Card Inventory Controls Records Retention Production Management Queries and reports Case/transaction tracking regulatory actions, referral of allegations, tracking subpoenas and processing documents for court. Manage the intake, distribution and destruction of specialized card stock with custom security features including unique card numbers. An electronic record of all documents received by or sent from the Registry is retained in an electronic data warehouse. Documents submitted in paper format are maintained until data has been entered into the electronic record and verified. Then paperwork is shred, unless record retention standards require hardcopy retention. Several queries and reporting tools are used to track the status of individual cases as well as aggregate data associated with specific business functions. Productivity and error reports are used for staff development and process improvements. 2.4 CONFIDENTIALITY STANDARDS Data housed within the MMRS contains both personal identity information and personal health information, and must be secure in compliance with all federal and state security regulations. All individuals working on the MMRS project must pass a background check and sign CDPHE s confidentiality agreement. 2.5 USER INFORMATION The requirements presented in this document are based on the premise that medical marijuana registration is part of multiple business processes and should meet the needs of as many of these processes as possible. The needs of these participants in relation to medical marijuana registration are presented below, along with auxiliary business practices that can be assisted by an MMR system. The MMR system participants are the primary stakeholders whose needs are addressed in this document, although the expected or unexpected additional value that will accrue to other stakeholders is also addressed. Each of the participants in medical marijuana registration has different business functions directly and indirectly related to the medical marijuana registration process. It is important to understand what these business functions are in order to ensure that the resulting system provides the participant with a solution that is attractive enough to ensure that they will choose to use the system. The number of people interacting with an application varies, but is generally 3 to 5 external users and 4 to 7 internal users. 21

22 2.5.1 Internal Users Director, Medical Marijuana Registry (Program Manager) Description: The individual responsible for the operations of the Medical Marijuana Registry within the state; Program manager for the MMRS. Type: Business expert in all matters pertaining to the registration process Responsibilities: Oversight of all Medical Marijuana Registry policies, procedures and processes Legal entity responsible for integrity and operation of registration system Final acceptance of the filed patient record Final review of the acceptability of the patient documentation Issuance of registration cards Denial of applications or revocation of cards Final authorization for modification of a patient s record Oversight of the other registration participants Success Criteria: Required time for filing an application is met or reduced Data quality is improved Data timeliness is improved Communications with registration participants is improved Involvement: Sponsor program, oversee management of project, garner resources to develop and implement registration system. Assure sufficient state resources, even if a vendor is building the product (project manager, field representatives, data analysts) Unit Supervisor, Medical Marijuana Registry Description: The individuals responsible for the operation of specific units within the Medical Marijuana Registry Type: Business expert in all matters pertaining to the processes within their unit Responsibilities: Responsible for integrity and operation components within the system that address the processes of the specific unit Review and determination of acceptability of patient documents/records Issuance of registration cards (new, renewal, and replacement) Determination of need for denial of applications or revocation of cards Determining acceptability of a request for modification of a patient s record (correction, amendment, etc.) Oversight of other staff within the specific unit Success Criteria: Required time for filing an application or other forms is met or reduced Ability to track incoming and outgoing documents improved Productivity measurement tools improved Staff training and development tools are improved Data quality is improved 22

23 Data timeliness is improved Communications with registration participants is improved Involvement: Provides business and domain specific guidance for the development of the system using specific areas of expertise. Tests all systems prior to launching and revisions that may be implemented after launch. Trains staff within unit on use of the system Governor s Office of Information Technology Description: The Governor's Office of Information Technology (OIT) is responsible for the operation and delivery of information and communications technology (ICT) services and innovation across all Executive Branch agencies in the State of Colorado. Type: Technical expert regarding all information and communication technologies used within the program. Responsibilities: Responsible for working directly with the developer of the MMRS to ensure technical compliance and integration into the Department s existing OIT system. Provides guidance for the development of the MMRS within the existing OIT framework. Success Criteria: System is in compliance with all OIT standards System has safeguards to ensure confidentiality and encryption of all data, active and archived System requires minimal oversight and maintenance from OIT staff Robust, user-friendly system design with built-in help features to reduce need for OIT assistance Involvement: Will be a direct partner in the MMRS development and implementation to ensure it works within the State s existing OIT system General Staff, Medical Marijuana Registry Description: The individuals responsible for daily processing of records and cases Type: Non-technical subject matter experts Responsibilities: Responsible for daily production of patient, physician and provider requests to include (but not limited to) mail processing, data entry, quality assurance reviews, financial management, production of cards and letters, verification of documentation, communication with patients and other stakeholders, scanning and reviewing electronic records, and appropriate storage and/or disposal of paperwork. Success Criteria: Efficient data entry flow and time-saving, predictive measures such as auto-fill and drop-down options for standard responses. Robust training module available for initial training and ongoing staff development Field-specific help feature 23

24 Flags for incomplete or inaccurate data entry and processing Ease of access to case-specific and aggregate information for purposes of researching patient, physician, caregiver and medical marijuana records. Ability to view multiple screens or modules of the MMRS simultaneously Involvement: Responsible for testing ease of use, accuracy and flow of the system from a data entry and data research perspective Data Management Staff, CDPHE External Users Patient Description: The individuals responsible for ensuring data integrity and data analysis Type: Business expert on data management Responsibilities: Monthly data integrity audits Statistical reporting of MMR data Integration of MMR data with other Department reports and metrics Success Criteria: Ease of access to data elements for aggregate assessment and correction Data protection controls to ensure required fields are always completed before new actions can be taken Archiving of data for historical, point-in-time data assessment Ability to clearly and easily identify patient status and status history Efficient and elegant system for standard and custom queries of all fields Involvement: Responsible for testing data integrity, effectiveness of query system, reports and ability to make aggregate assessments and corrections Description: The individuals applying for a medical marijuana registration card Type: Primary external customer; There are subcategories of patients: New, Renewal, Inactive, Denied, Revoked, Deceased Responsibilities: Complete required processes for card application Submit contact and provider modifications to record Respond to MMR request for correction or clarification Success Criteria: Confidentiality compliance with constitutional and HIPAA requirements Secured access with identity verification measures Ease of access from desktop, laptop or mobile devices Efficient and elegant method for entering data Efficient and elegant method for document and graphic uploads Data prompts to ensure all required information is completed accurately Print-to-paper option for all screens/forms Auto confirmation of submissions Robust help feature with field-specific instructions 24

25 Ability to electronically verify status of paperwork Ability to make payment electronically or submit by mail with a confirmation notice Electronic renewal reminder system Involvement: A pilot group of patients and community partners who are not patients and inexperienced with the will test the external access portal Physicians Description: Medical professionals with a D.O. or M.D. who are licensed and in good standing with the Colorado Department of Regulatory Affairs (DORA) Type: Medical professional making determination that patient may benefit from medical marijuana use; Professional medical expert Responsibilities: Conduct exam of individuals to determine eligibility Establish bona-fide physician-patient relationship through follow-up care Complete a physician certification form for the patient Provide medical history/documentation to support recommendation Maintain patient records Collaborate with MMR to identify potential areas of fraud Revoke signature/association when patient no longer qualifies or is no longer in their care Updated contact and licensure information in the MMRS Success Criteria: Confidentiality compliance with constitutional and HIPAA requirements Secured access with identity verification measures Ease of access from desktop, laptop or mobile devices Efficient and elegant method for entering data Efficient and elegant method for document and graphic uploads Data prompts to ensure all required information is completed accurately Print-to-paper option for all screens/forms Auto confirmation of submissions Robust help feature with field-specific instructions Ability to electronically verify status of paperwork Ability to save data from physician certification as a PDF for office files Communication mechanism to alert MMR for potential fraud Involvement: A pilot group of physicians with varying levels of MMR experience will test the external access portal Medical Marijuana Centers (MMC) Description: Organizations licensed through the Department of Revenue to produce and sell medical marijuana and associated product Type: Industry professionals with expertise in commercial aspects of medical marijuana industry and patient care from the retail perspective Responsibilities: Often serve as advocate to aid patients in the application process 25

26 Provide patients with medical marijuana and associated products Report patient caseload to MED Grow medical marijuana in compliance with patient caseload and statutory requirements Verify new patients purchasing with their paperwork, rather than a card, are not in denied status Collaborate with MMR to identify potential areas of fraud Updated contact and licensure information in the MMRS Success Criteria: Confidentiality compliance with constitutional and HIPAA requirements Secured access with identity verification measures Third-party ability to help patients with application process Ease of access from desktop, laptop or mobile devices Efficient and elegant method for entering data Efficient and elegant method for document and graphic uploads Data prompts to ensure all required information is completed accurately Print-to-paper option for all screens/forms Auto confirmation of submissions Robust help feature with field-specific instructions Communication mechanism to alert MMR for potential fraud Ability to enter identifying information from the presented application packet to verify whether or not a new application has been denied Ability to access aggregate, non-confidential information specific to their center including plant count association and number of patients Involvement: A pilot group of MMC employees with varying levels of MMR experience will test the external access portal Caregivers Description: Person 18 years of age or older, who is not the patient or the patient s physician, and provides significant responsibility for managing the well-being of a patient who has a debilitating medical condition. Type: Industry expert with knowledge of patient care-giving needs and patient experience with the registration process and ongoing interaction Responsibilities: Provide significant care-giving responsibilities for patient May grow medical marijuana for the patient Often helps patient complete paperwork and navigate the application process May provide transportation for the patient May elect to be listed on the Voluntary Caregiver Registry as an available caregiver in a specific geographic area Update contact and Voluntary Caregiver Registry information in MMRS In the case of homebound and minor (under 18) patients, may also transport medical marijuana and associated product Revoke signature/relationship when patient is no longer in their care Collaborate with MMR to identify potential areas of fraud Success Criteria: 26

27 Confidentiality compliance with constitutional and HIPAA requirements Secured access with identity verification measures Ease of access from desktop, laptop or mobile devices Efficient and elegant method for entering data Efficient and elegant method for document and graphic uploads Print-to-paper option for forms and MMR responses Auto confirmation of submission of paperwork Communication mechanism to alert MMR for potential fraud Ability to revoke signature/relationship Ability to access aggregate, non-identifying information about caseload to include plant count association and number of patients Involvement: A pilot group of caregivers with varying levels of MMR experience will test the external access portal Patient Agent/Representative 2.6 BUSINESS FUNCTIONS Description: Person 18 years of age or older, who is not the patient or the patient s physician, and has legal authority through a power of attorney, medical power of attorney, court-ordered guardianship, or is a parent of a minor patient and has legal rights and responsibilities related to the patient s medical care. Type: Patient advocate Responsibilities: Conduct legal and medical transactions in accordance with legal agent authority May also be the patient s caregiver with grow and transportation rights Often helps patient complete paperwork and navigate the application process May provide transportation for the patient Update patient and patient agent contact and provider information in MMRS. Revoke signature/relationship when patient is no longer in their care Collaborate with MMR to identify potential areas of fraud Success Criteria: Confidentiality compliance with constitutional and HIPAA requirements Secured access with identity verification measures Third-party ability to submit paperwork to Registry for patient Ease of access from desktop, laptop or mobile devices Efficient and elegant method for entering data Efficient and elegant method for document and graphic uploads User prompts and help features to ensure paperwork is complete and accurate Print-to-paper option for forms and MMR responses Auto confirmation of submission of paperwork Communication mechanism to alert MMR for potential fraud Ability to revoke signature/relationship Involvement: A pilot group of patient representatives with varying levels of MMR experience will test the external access portal. The registration process, record maintenance, data management and archive functions of the MMRS must work with the fluid dynamics of the Registry s overall business processes. This section provides a brief overview of the 27

28 features expected by business function; see Appendix I: Medical Marijuana Registry System Primary Flow for a flowchart of the application process Modular Design Based on User Rights To ensure HIPAA compliance, the MMRS must ensure that only the minimal necessary information is being accessed to accomplish a specific business function. The Registry requires the following modules. # Module Type Subcategories based on User Type 1. User ID and Record a. Patient Generation b. Patient Agent c. Physician d. Caregiver e. MMC f. Third-Party* 2. Patient Identifying and demographic Information 3. Patient Contact Information 4. Identity and Proof of Residency 5. Physician Contact Information g. Registry staff a. Patient b. Patient Agent c. Third-party* d. Registry staff a. Patient b. Patient Agent c. Third-party* d. Registry staff a. Patient b. Patient Agent c. Third-party* d. Registry staff a. Patient b. Patient Agent c. Physician d. Registry staff Associated Function Provide required demographic and identity information to create a record within MMRS and generate a unique ID and password. Create Patient Record, generate unique ID number by entry of social security number, full legal name, date of birth, and gender All contact modules must include ability to include multiple addresses, phone numbers, and designate address and phone number type (such as business, home). Required support documents to prove residency and identity. This module must include ability to upload PDF or graphic files which can be converted to PDF. All contact modules must include ability to include multiple addresses, phone numbers, and designate address and phone number type (such as business, home). 6. MMC Contact Information 7. Caregiver Contact Information a. Patient b. Medical Marijuana Center c. Patient Agent d. Third-Party* e. Registry staff a. Patient b. Caregiver All contact modules must include ability to include multiple addresses, phone numbers, and designate address and phone number type (such as business, home). All contact modules must include ability to include multiple 28

29 8. Patient Agent Contact Information c. Patient Agent d. Third-Party* e. Registry staff a. Patient b. Patient Agent c. Third-Party* d. Registry staff 9. Provider Designation a. Patient b. Patient Agent c. Registry staff 10. Caregiver Acknowledgment a. Caregiver b. Registry staff 11. Medical History a. Physician b. Registry staff 12. Bona fide physicianpatient relationship a. Physician b. Registry staff 13. Electronic Signatures a. Patient b. Physician c. Medical Marijuana Center d. Caregiver e. Patient Agent 14. Lost, Stolen or Damaged Card 15. *Third-party Verification Screen a. Patient b. Third-party* c. Registry staff a. Patient b. Patient Agent c. Registry staff 16. Surrender a. Patient b. Patient Agent c. Third-party* d. Registry staff 17. Homebound Status a. Physician b. Registry Staff 18. Patient Status a. Patient b. Patient Agent c. Third-Party* d. Registry Staff addresses, phone numbers, and designate address and phone number type (such as business, home). All contact modules must include ability to include multiple addresses, phone numbers, and designate address and phone number type (such as business, home). Patient designation of rights to grow medical marijuana with options for self, medical marijuana center or a caregiver. Acknowledgement of Caregiver to significant responsibility for patient s well-being Patient qualifying conditions, and comments to support medical necessity Physician-patient contact history, exam date and follow-up availability Mechanism must be in place to ensure all data was submitted by an authorized user, with assigned PIN number? Request replacement of a lost, stolen or damaged card Requirement to verify third-party submitted content and affix electronic signature or staff ID. Ability to surrender card to become inactive with the Registry Physician determination of patient s ability to self-transport safely. Patient status with the Registry may include but not limited to new, renewal, surrendered, denied, inactive, deceased, revoked 29

30 19. Fraud Detection a. Patient b. Physician c. MMC d. Patient Agent e. Caregiver f. Registry Staff 20. Case Evaluation & Process Tracking Colorado Department of Public Health and Environment Ability to submit confidential information to alert Registry Fraud Prevention staff to potential fraudulent activity a. Registry Staff Ability for Registry staff to evaluate submitted forms and support documentation, ensure all stages of process have been completed, and close case. Report and track manual and electronic processes with ability to assign time measurements. 21. Electronic Records a. Registry Staff Ability to assign how electronic records are categorized and stored within the system and associated to each record. Ability to view PT electronic records based on user rights. For minimal necessity purposes rights may be limited based on record type such as standard documentation, financial records, law enforcement 22. Customer Service a. Patient b. Patient Agent c. Third-Party* d. MMC e. Caregiver f. Physician g. Registry Staff 23. Financial Management a. Patient b. Patient Agent c. Third-Party* d. Registry Staff 24. Query and Reports a. Patient b. Patient Agent c. Third-Party* d. MMC e. Caregiver f. Physician g. Registry Staff Ability to send and receive questions and comments pertaining to a specific case, the patient s entire record, or Registry policies and procedures. Ability to apply payment to patient account via electronic submission, fee waiver or staff assignment of check or money order. Additional financial management features such as deposit information will be available to Registry staff only. A listing of all queries and reports available based on user rights. 30

31 25. FAQ a. Patient b. Patient Agent c. Third-Party* d. MMC e. Caregiver f. Physician g. Law Enforcement h. Registry Staff Colorado Department of Public Health and Environment Searchable access to frequently asked questions, with limitations based on user rights. 26. Communications a. All Users Auto notices, letters, FAQs 27. Card Generation a. Registry Staff Print various forms of registration card in compliance with design standards and template design provided by security paper vendor. Searchable archive of all card numbers and status of each. 28. Intake a. Registry Staff Tracking of incoming documents including intake type (mail, fax, , electronic submission, drop box), tracking numbers (confirmation of submission number, certified mail receipts), date received, return mail 29. Fraud Prevention a. Registry Staff Ability to create/track fraud files, composition and printing of reports of investigation, subpoena tracking, generation of subpoena-responsive documents, redaction capabilities User Interface Functionality User interfaces will incorporate one or more of the above modules to facilitate a complete process. The Registry requires the following standard user functions. The MMRS software application must also include the ability to create customized interfaces by combining modules as necessary External Users 31

32 Create New Record Adult Application Minor Application Reply to Rejects Change of Name Change of Contact Information Change of Provider Change of Homebound Status Submit Payment Physician Certification Physician Record management Report of Lost, Stolen, Damaged Card Fee Waiver/Tax-Exempt Status Caregiver Acknowledgment Provider Signature Revocation Provider Information Update Customer Service Inquiry Frequently Asked Questions Internal Users Document Intake/Mail Processing Create New Record Adult Application Minor Application Reply to Rejects Change of Patient Records Change of Homebound Status Submit Payment Physician Certification Physician Record Management Report of Lost, Stolen, Damaged Card Fee Waiver/Tax-Exempt Status Caregiver Acknowledgment Provider Signature Revocation Provider Information Update Law Enforcement Verification Request Fraud Reporting Fraud File Management Subpoena Tracking & Preparation Judicial & Regulatory Action MMR Card Tracking Customer Service Financial Management Electronic Document Management Case Tracking Queries and Reports Frequently Asked Questions Colorado Department of Public Health and Environment 32

33 2.6.3 Data Entry Data will be entered into the system by multiple internal and external partners. Ease of use and data integrity will be two key factors for determining successful development and implementation of the MMRS. The following data entry functions are required unless otherwise indicated Data entry modules that only display the minimal necessary information to fulfill requirements of the specific case or function being performed Tab-through data entry with ability to point and click to open specific fields as necessary Field-specific help prompts Error alerts for data entry that does not comply with field specifications or required fields that are incomplete Tailor field size and alpha-numeric design specific to purpose of field, which includes ability to use standard formats such as date, time, social security number, phone number Drop-down lists for all fields with standard responses and ability for those lists to be extended and updated by Registry staff after implementation Ability to override standard responses or customize entries based on user rights Auto-populate fields based on specific actions such as completing the card expiration date for one year after the card issue date Scripts that modify several fields in the record based on a specific transaction such as changing patient status and archiving data for patients who are deceased Ability to enter data by electronic external submission, OCR scanning of hard copies, PDF conversion to text, and manual data entry Undo feature for errors in entry prior to saving the record Data verification required prior to saving changes to a record, including alerts to incomplete or inaccurate fields Maintain field-specific tracking log to indicate how data was entered/received, including by which user. Data submission methods include patient submission, physician submission, third-party submission, MMR staff entry, OCR, or imported from previous database Auto-populate data entry screens with existing information from record for internal and external submission of new documents or case transactions Ability to add multiple addresses to a record and indicate type of address such as business, residence, mailing. Same as button to allow the ability to indicate the mailing address is the same as business or residential address Ability to track change history for every field include change made and by whom Data entry controls to alert when multiple users may be accessing the file and entering data that could be contradictory Ability to close a case once all transactions associated with that specific case have been completed, such as close the workflow once a replacement card is printed for a report of lost or stolen card Administrative level access to override blocks and make corrections to files after the case is resolved All screens must be ADA compliant, readable by screen readers for vision impaired (Optional) Address verification and auto-completion of zip code, county, or city based on entry of the street address (Optional) Identity verification through ping to Department of Motor Vehicles, Social Security Administration, Lexis-Nexis, Colorado Vital Records. These verification queries must be accomplished in a manner that secures the confidentiality of Registry participants. 33

34 2.6.4 Archiving The MMRS must include a comprehensive, searchable archiving system that maintains a log of all changes to a record, and by whom the changes were made. Archived data must be available for research and review through modules that provide only the minimal necessary information to perform the required task based on user rights. Archiving system must not only record data elements but relationships as well, such as physician-patient or caregiver-patient relationships Communication Tools The MMRS must include the ability to provide multi-directional communication in a confidential format that allows immediate validation of user actions, internal and external s, internal messaging/comment systems, auto-generation of confirmation or correction information, and the ability to queue records for additional communication or customer service follow-up. This would include the ability to generate follow-up electronic notices to external partners based on timespecific actions, such as a notice that the response reply-by date is near. Include in the budget the development of 20 templates with drop-down and customizable components. Communication tool features must include the ability to track the frequency of use for each of the drop-down options within the templates. In addition include the ability for the Registry to create new letters using a drag-and-drop or WYSIWIG format for ease of use. Standardized letters and/or electronic notices which generate in response to user actions include, but are not limited to, the following Form Rejection Notices Card Renewal Notices Request for Additional Information Notice of Application Denial Notice of Card Revocation Notice of Physician Signature Revocation Notice of Insufficient Funds/Bad Check Notice of Appeals Hearing Notice of Appeals Decision Drop-to-paper Functionality Internal and external partners may have multiple needs to create a hardcopy record of actions within the system. Each user screen must include the print function which allows the page to be printed in a printer-friendly format. This drop-to-paper function must include an option for certified copies which would be available based on user rights. Certified copies will include an attestation that the copy is an exact replica of the electronic record and will contain an original mark, possibly a watermark, identifying the Registry as the certifying agent. In most cases, due to document content, the attestation is printed on the back of the document and the mark is placed on the front of the document System Alerts The MMRS must provide standard alert screens and the ability for the Registry staff to customize alert screens as necessary. The alert screens will provide process information pertinent to a specific record or group alerts based on multiple components. Following is a partial list of standard alerts. 34

35 A. Incomplete Data B. Incorrect Data C. Customer Service D. Fraud Prevention E. Physician Revocation F. Caregiver Patient Limit Reached G. Time Concern (case beyond customary response time) H. Internal Exception Request I. Missing Paperwork/Documentation J. Missing Card Number (alert when non-sequential card numbers indicates potential missing cards) K. Bad Payment L. Include in the bid 10 additional standard alerts to be determined based on system design Electronic Record/Data Warehouse The MMRS must provide an electronic record storage system that allows for multiple methods of record importation to include scanned documents, internal and external uploads of PDF and graphic files, system-generated letters and cards. The system must store an exact replica of the card and any letters generated within the electronic record. Electronic records must be kept for patients, physicians, medical marijuana centers, caregivers and patient agents. In addition, a section must be provided for an archived library of the Registry s policies, procedures, forms, research and other program documentation. The electronic record system must provide the flexibility to partition or divide records into separate folders based on document type or purpose Query and Report Function All fields within the MMRS must be searchable, and available for query. All queries must have the ability to be electronically stored as a report and have the print-to-paper functionality as well. The MMRS will include standard reports as well as the ability to create custom queries using any of the fields within the system. The BID should include the development of 40 standard queries, and the ability for Registry staff to custom-design and save queries. Following is a partial list of standard reports: A. Report of cards by type and date range B. Applications in Process with date variables C. Patient Lists D. Active Physicians List E. Physicians with Corrective Actions List F. Medical Marijuana Center Lists G. Caregiver Lists H. Voluntary Caregiver Registry I. Statistical Analysis for a Point in Time (Aggregate and individual) i. County-based Data ii. Physician Distribution 35

36 Registration Cards Colorado Department of Public Health and Environment iii. Patient Demographic iv. Patient Status v. Application Type vi. Provider Designations (MMC, Caregiver, Self) J. Data Clean-up for missing data points K. Search of Comment Sections L. Search for specific payment by Payment Type and Number M. Summary report of payments (by user input, end of day total, historical time periods) N. Query by transaction type (all users, specific users, date specific controls) O. Physician-Patient Relationship Verification P. Caregiver-Patient Relationship Verification Q. Production Response Time (by transaction, aggregate action for a specific date or historical period) R. Production Management Report detailing all transactions within a specific time by all users and/or specific users S. Alert Queries ability to generate a report for all the above-mentioned alerts, including custom alerts T. Intake Query ability to query incoming documents based on submission type (such as mail, electronic submission, fax) U. Ability to custom query any single field V. Query card numbers to generate inventory of all serial numbers and identify any potential breaks in sequence The MMRS system will include capability to develop templates for 10 different card types which may be printed double-sided on letter, legal or other standard paper sizes through network and/or direct linked printers. At minimum, the program must provide the following features pertaining to the registration card: Require a unique card number for all transactions, block any duplicate numbers Searchable tracking log of all cards and relationship to Registrant participants Ability to scan in barcodes from pre-printed card stock Preset templates for 10 different card types Ability to print double-sided content on card Card stock tracking from point of receipt to mailing, internal storage and/or destruction of cards returned by post office or surrendered back to the Registry. This log would include a card assignment log that identifies which staff members were given which card numbers Alerts for missing or out-of-sequence card numbers Prevent cards from being printed if Alerts or Flags are active on the record. Flag must be removed and/or overridden based on user rights Block printing for cards with out-of-state addresses External User Interface Patients, physicians, caregivers, medical marijuana centers, and patient agents will be accessing MMRS from various devices in a variety of locations including private homes, public libraries, 36

37 physicians offices, medical marijuana centers, or from mobile devices. The following components are required unless otherwise indicated All data entry from external locations must be encrypted and comply with all HIPAA and other federal and state security measures to protect personal health information and personal identity documents Responsive format that allows for viewing on mobile devices Secured access requiring username and password Automated system to generate unique ID numbers for patients, physicians, medical marijuana center employees, caregivers, and patient agents Automated system for password reset Electronic signature options for patients, physicians, caregivers and patient agents Ensure user data cannot be accessed by subsequent users on public devices by incorporating features to auto-close record when user navigates away from page or closes browser Lock-out external users after three unsuccessful attempts to log-in. Provide contact information for MMRS administrator to unlock access Ability for external users (based on user type) to log-in and track status of all cases in process Ability to drop-to-paper all documents after completion Auto generate case number for all forms/requests submitted by external users Printable confirmation screen to acknowledge submission to MMRS Auto-populate contact information with each log-in and provide opportunity to update, if necessary Robust Help feature that provides guidance for each field and FAQs Alert notices when information is incomplete or inconsistent with required formats Ability for physicians to access and verify individual and aggregate patient lists Ability for physician to submit forms to patient records based on verifiable patient identifiers, such as a combination of name, date of birth, and patient unique ID number Ability for third-party individuals to submit paperwork for patients requiring assistance. Must be able to establish right of agency (power of attorney, court ordered guardianship) or have patient electronic signature Financial Management Must comply with federal and state accounting standards Ability for patient to submit application electronically and send payment separately. For example, generate a confirmation notice to be sent with the payment Generate a payment pending queue for applications submitted electronically without payment Ability to process applications without payment or release pre-paid applications Block ability to print card until payment has been processed, with limited ability to override block Ability to receive payment through third-party payment systems (PayPal, Vital Chek, etc) Ability to receive electronic checks Ability to direct payment to be directly applied to patient record, even if payment is made from a card or bank account not in the patient s name Ability for applicant or Registry staff members to print payment receipts Standardized fee schedule with ability to adjust fee system-wide or for specific transactions Auto-generate daily deposit, with ability to adjust deposit with specified user rights 37

38 MMRS software application training Comprehensive written and audio-visual instruction customized by function for internal and external users, help desk guidance and knowledge articles. At minimum the training component must include: Demonstration mode which allows for an introduction to all the system components without entry into the actual database Help desk manual and knowledge articles On-site training for 50 Registry staff members with certification of completion Digital training library with instruction on each module and certification of completion Instant access FAQs for each field, as well as searchable FAQs pertaining to the MMRS software application Customer Service Tools and resources used to provide guidance for internal and external Registry participants. At minimum the following customer service tools must be included: Automatic confirmation of submissions to the Registry via MMRS Automatic electronic status updates on each case Automated renewal reminders Multi-tiered, searchable FAQs regarding the Registry s policies, procedures and processes Customer service comment section in patient, physician, caregiver, medical marijuana center and patient agent records Electronic message system in a secured environment that allows external users to submit questions directly to the Registry and allows Registry staff to directly respond Record Security In addition to compliance with HIPAA and other system security requirement for the management of personal identity information and personal health information, the system must also incorporate tools to ensure the integrity of data within the records. These features include, but are not limited to: Ability to identify non-congruent information, such as date of birth or social security numbers that do not match existing records, and generate correction message for user Track cases of non-congruent information entry in an archived report to provide Registry staff with trends that may indicate phishing or fraudulent use of the system Block creation of potential duplicate records where multiple identifying elements match such as name, date of birth, social security number. Generate an alert to Registry staff to assess records with ability to override block, if necessary Require double-verification of manually scanned and indexed electronic records. 38

39 SECTION 3. Technical Requirements The MMRS software application will be built using SQL Server Enterprise and a.net framework that are no more than three years old. The servers that the MMRS software application resides on will be physically located at efort and will be maintained by state server staff. The MMRS must be viewable on both personal computers and mobile devices being viewed using standard web browsers (Chrome, IE, Firefox, Safari). All screens should fully load into a browser window in a maximum of five seconds. The MMRS software application must not leave an electronic footprint on external user computers. Security standards must satisfy requirements outlined in security section. Strict adherence to HIPAA compliance must be followed. Upon completion of the session, the Registry application must not leave a footprint on the user s device. SECTION 4. Rights in data, documents and computer software Any software (including the Medical Marijuana Registry System), research, reports, studies, data, photographs, negatives or other documents, drawings, models, materials, or Work Product of any type, including drafts, prepared by Contractor in the performance of its obligations under this Contract shall be the exclusive property of the State and, all Work Product shall be delivered to the State by Contractor upon completion or termination hereof. The State s exclusive rights in such Work Product shall include, but not be limited to, the right to copy, publish, display, transfer, and prepare derivative works. At the completion of the contract, the State will be the sole owner of the system. Contractor shall not use, willingly allow, cause or permit such Work Product to be used for any purpose other than the performance of Contractor s obligations hereunder without the prior written consent of the State. SECTION 5. Resources and Management 5.1 STATE STAFF RESOURCES The vendor shall specify the state personnel resources that it expects for the system implementation project and for operation of the system. 5.2 VENDORS In addition to providing a functional MMR system according to the state s requirements, vendors should provide the following services: Work with the state to tailor the use cases and other re-engineering artifacts to meet the state s requirements Design or configure the system to meet the business needs of the state Work with the state s project manager Work with the state to clearly define the scope of the project before any development begins; if working with an existing product or another state s software, clearly identify and document any deviations from that software that need to be made Provide a single contact person responsible to the state s project manager who will coordinate the work of the vendor s staff 39

40 Provide a list of tasks that will need to be completed by the state and a timetable for their completion Deploy the system ensuring that it will operate on state servers Provide initial training to state staff, including training documentation and other resources Provide system documentation Provide a user manual tailored to the state s MMR system implementation After 1-year warranty, provide yearly maintenance for a reasonable fee Negotiated Project Schedule Delivery Schedule / Billing Schedule Project Plan (see Appendix III for Sample Plan) consisting of, but not limited to: Design Plan and Deliverables Issue Resolution Process Communications Plan Deliverable Approval Process Security Plan Risk Mitigation Plan Personnel Plan Implementation Plan Training Plan Testing Plan / Regression Testing Plan Change Control procedures 5.3 COST Cost Proposal Prices shall remain fixed through the term of the Contract including extensions Total Cost of Ownership Due to pending legislation, it is possible that the MMRS will be required to be implemented and maintained solely by State employees. Provide total cost of ownership to include two options: Sole Ownership by CDPHE: Once designed, the OIT will host and maintain the system, including system upgrades Vendor Ownership and Licensing: Include ongoing costs of software maintenance and licensing fees (if any) for option years beyond system implementation. Include hourly rates for additional services not included in the base cost such as project management, software enhancement, additional and programming. 40

41 SECTION 6. Offeror Response Format 6.1 PROPOSAL SUBMISSION See Administration Information document for proposal submission requirements. 6.2 ADDRESSING PROPOSAL REQUIREMENTS (OFFEROR RESPONSE) The information within this section outlines specific information required in your response, which will assist in determining how well your agency will be able to meet the requirements set forth within the Proposal Requirements section of this RFP. All Offerors, regardless of which option is being proposed, must respond to ALL portions of the following information and or related sections. Label all sections accordingly Mandatory Requirements: Response to 2.1 Mandatory Minimum Requirements Application Overview: Describe how the Offeror will develop a software application that addresses all the business and technical functions detailed in: 2.3 Medical Marijuana Registry Processes 2.4 Confidentiality Standards 2.5 User Information 2.6 Business Functions 3. Technical Requirements 41

42 6.2.3 Resources and Management: Provide a detailed overview of the Offeror s ability and process for addressing all components described in Section 5: Resources and Management Timeline: Provide a timeline with benchmarks as established in Statement of Work section for implementation within 18 months from the date of contract execution Costs: Provide detailed costs based on details provided in Section 5.3: Costs. Segregate cost proposal in original response, electronic response and required number of copies References: Please provide at least three (3) and no more than five (5) references that match the scope of work outlined in this solicitation. Provide the principal contact, telephone number and address, as well as a brief description of work performed. Include references that can provide examples of software developed to handle confidential identity and personal health information with access from multiple internal and external partners. The State reserves the right to include the State of Colorado and other states as additional references. The State also reserves the right to call references only on the selected Offerors as a method of determining responsibility Financials: Please provide a copy of the last certified, audited financial statements for your company. The State reserves the right to review financials only on the selected Offerors as a method of determining responsibility Security: Describe how the Offeror will ensure the confidentiality of the MMRS and the confidential data maintained within the Registry, including both system and personnel security measures. See Appendix IV for Sample OIT Security Plan which will be required as part of contract execution. 6.3 CONTENT QUALITY Do not include extensive artwork, unusual printing or binding, or other materials, which do not enhance the utility or clarity of the Offeror s proposal. General statements without supporting documentation are not encouraged. Documents should be double-sided on recycled paper, and easy to copy/scan (no bound material, clips, etc). Paper should be white or extremely light paper without dark backgrounds. Enhance electronic images for pages with a poor image quality. 6.4 PROPOSAL ORGANIZATION Offeror s proposal should be submitted in a binder (3 ring binder(s) preferred) with all material clearly labeled or, such other organization that will facilitate the committee members evaluation. Offerors must respond to every item listed within Section 6 Offeror Response Format and label its proposal with the corresponding number for each question or request for information. 6.5 CONFLICTS WITH TERMS, CONDITIONS, OR REQUIREMENTS Offeror must review the attached Model Contract and list any exceptions or confirm that no exceptions are taken to the Model Contract. Exceptions to the Model Contract must be accompanied by alternative or substitute language, which would be acceptable to the Offeror. Conflicts with stated requirements must be noted in the corresponding paragraphs within the Offeror s response format. Additional terms or conditions proposed by Offeror for consideration must be provided with a reference to the corresponding paragraph of the Model Contract. References may direct reviewers to appendices within Offeror s response. 42

43 SECTION 7. Proposal Evaluation An Evaluation Committee will judge the merit of proposals timely received in accordance with the criteria outlined in the Offeror Response Format section of this RFP. This section supplements paragraph 3.8, Evaluation and Award, in the Colorado Solicitation Instructions/Terms and Conditions that are available through the link on BIDS. 7.1 EVALUATION PROCESS CDPHE will undertake an intensive, thorough, complete and fair evaluation process. All Offerors shall be afforded fair and equal treatment throughout the evaluation process. 7.2 ADEQUACY AND COMPLETENESS OF RESPONSE In general, all aspects of a proposal will be evaluated based on its adequacy and completeness with regard to the information specified in the RFP; i.e., compliance with terms, conditions and other provisions contained in the RFP, as well as Offeror s ability to read and follow instructions. Failure of an Offeror to provide the information required in this RFP may result in disqualification of the proposal. This responsibility belongs to the Offerors. 7.3 EVALUATION COMMITTEE Each Evaluation Committee member will independently evaluate the merits of proposals received in accordance with the evaluation factors stated within this RFP, followed by discussion of the entire Evaluation Committee. The sole objective of the Evaluation Committee will be to recommend for award the proposal(s) determined most advantageous to the State. 7.4 EVALUATION METHODOLOGY A numerically based evaluation methodology will be used for the evaluation. A scoring system will be used that will include specific evaluation weights for each Section and factors within each Section. While a numerical rating system will be used to assist the evaluation committee in selecting the competitive range (if necessary), the award decision ultimately is a business judgment that will reflect an integrated assessment of the relative merits of the proposals using all factors and their relative weights disclosed in the RFP. Both the technical response and costs are considered important criteria. In the overall scoring scheme that will be used, cost will account for 50 percent of the overall total score and the technical response for 50 percent of the total score. Of the acceptable technical proposals, the proposal with the lowest cost will be awarded the maximum number of points available for cost. All other cost proposals will be given a cost score using the following formula: (Lowest Cost / Offeror s Cost) X maximum points 43

44 7.5 BASIS FOR AWARD Colorado Department of Public Health and Environment The purpose of this RFP is to solicit proposals for the goods/services specified herein. The requirements stated within this RFP represent the minimum performance requirements necessary for response as well as desired elements of performance. All proposals must meet the mandatory minimum requirements established by this RFP to be eligible for award. Evaluation and award will be based on the following factors, in decreasing order of importance: Offeror s ability to meet all minimum requirements as detailed in 3.1 Minimum Requirements Offeror s method for ensuring confidentiality and security of MMRS Demonstration of Offeror s ability to build, implement and maintain a secure software that houses confidential personal identity and personal health information in compliance with guidance provided in Section 1.3 Statutory Compliance and Section 2.4 Confidentiality Standards Offeror s method for addressing specific needs identified in Section 2.6 Business Functions Demonstration of Offeror s experience to develop and implement methodology to address needs in Section 2.6 Business Function Offeror s proposed MMRS software design to create interactive user portals for diverse populations with user right controls with specific content addressing users identified in 2.5 User Information Demonstration of Offeror s experience developing and maintaining interactive and secured user portals Offeror s budget for initial build and implementation Offeror s budget for on-going maintenance State personnel requirements as addressed in Section 5.1 State Staff Resources 7.6 EVALUATION BASED ON INITIAL PROPOSALS CDPHE reserves the right to make an award(s) on receipt of initial proposals, so Offerors are encouraged to submit their most favorable proposal at the time established for receipt of proposals. Proposals requiring major revision in order to be considered for any award, or otherwise not meeting the mandatory or other requirements required for further consideration as specified in this RFP, may be classified as unacceptable and ineligible for further consideration. The technical aspects of proposals will be assessed based on the soundness of the Offeror s approach and the Offeror s understanding of the requirement. Past experience/qualifications will be assessed by considering the extent to which the qualifications, experience, and past performance are likely to foster successful, on-time performance. Technical and past experience assessments may include a judgment 44

45 concerning the potential risk of unsuccessful or untimely performance, and the anticipated amount of State involvement necessary to insure timely, successful performance. 7.7 COMPETITIVE RANGE CDPHE may establish a competitive range of Offerors whose proposals have been initially evaluated as most responsive to the requirements and reasonably susceptible of being selected for award. 7.8 CLARIFICATIONS/DISCUSSIONS CDPHE may conduct discussions with Offerors for the purpose of promoting understanding of CDPHE s requirements and the Offeror s proposal, clarifying requirements, and making adjustments in services to be performed and in prices and or rates. Offerors engaged in such discussions may be sent a list of questions and will be given a specified number of days in which to formulate and submit written responses to the questions and provide any related revisions to their initial proposals. The nature of the questions will be, generally, clarifying in nature and will permit related revisions to proposals. Such revisions will be at the option of the Offeror, but will be limited to the guidelines set forth in CDPHE s requested clarifications. No major changes will be permitted, nor will CDPHE accept any additional written materials not relevant to the questions/clarifications requested. Clarifications/discussions may be limited to Offerors within the Competitive Range. 7.9 PRESENTATIONS/DEMONSTRATIONS Offerors may be given an opportunity to provide an oral presentation or demonstration. CDPHE reserves the right to select the site. During the presentation, an Offeror should provide specific responses to the questions posed to it and may also make a summary presentation of its proposal. The presentation should include a description of how Offeror s revisions, if any, may have affected the overall nature of its offer as compared to the initial proposal. The presentation is typically limited to 60 minutes. If the Evaluation Committee members believe it to be necessary, a question/answer period may follow. Presentations/Demonstrations may be limited to Offerors within the Competitive Range BEST AND FINAL OFFERS (BAFO) Adjustments may also be allowed in conjunction with clarifications, discussions, presentations and or demonstrations, but only to the extent such revisions are consistent within the proposal requirements. These revisions will be considered as best and final offers. Such adjustments must be submitted in writing FINAL EVALUATIONS After completion of clarifications, presentations, and BAFOs, as may be required, the Evaluation Committee will re-consider the initial proposal ratings and may make any adjustments they believe to be warranted as a result of the additional information obtained AWARD RECOMMENDATION Upon completion of the evaluation process, the Evaluation Committee will formulate a recommendation as to which proposal(s) is/are determined to be most advantageous to the State within available resources. A formal recommendation of the Evaluation Committee will be forwarded to the CDPHE, Purchasing Agent for review and approval. 45

46 7.13 NOTICE OF INTENT TO AWARD Colorado Department of Public Health and Environment Upon approval of the recommendation, a Notice of Intent to Award will be published on BIDS. Upon issuance of the notice, all non-proprietary/confidential documents submitted by all Offerors, not just the awarded Offeror(s), shall become public records and will be available for inspection. The time period for consideration of any protest of the award decision will commence at this time. The Awarded Offeror(s) will be contacted by CDPHE to complete post award requirements CONTRACT REVIEW Offerors must review the attached Model Contract and list any exceptions or confirm that no exceptions are taken to the State s contract. Any exceptions to the Model Contract must be accompanied by alternative or substitute language which would be acceptable to the Offeror. CDPHE will review the proposal to ensure the Offeror has not taken any exceptions to the State s contract provisions which may be deemed unacceptable or exceptions to stated requirements which may be deemed unacceptable in meeting the needs of the State. Any exceptions taken could result in elimination of the Offeror s proposal from further consideration, or result in delay or failure to execute a contract, whereby the State could terminate the award and commence negotiations with another Offeror. Exceptions to the State of Colorado Special Provisions, attached to the contract, will not be accepted. 46

47 APPENDICES Appendix I: Medical Marijuana Registry System Primary Flow Appendix II: Current Transaction Codes Appendix III: Sample OIT Project Plan Appendix IV: OIT System Security Plan Appendix V: Sample Contract 47

48 APPENDIX I Medical Marijuana Registry System Primary Flow Intake Physician Certification Patient Application Payment Received Provider Designation Verification Card Generation Yes Valid Fraud Prevention/ Customer Service Verification Verified and Correct Reverification No Correction Fraud No Notify Patient for Correction Resubmit Yes Denial/ Revocation 48

49 APPENDIX II: TRANSACTION CODES The following table provides the transactions that are currently tracked in the legacy system using transaction codes. This is provided for information purposes, Offeror may recommend other methods for tracking transactions and generating reports. Transaction Name COMMENT SPECIAL PATIENT CASE UPDATE PHYSICIAN SIGNATURE REVOCATION LETTER REQUEST FOR INFORMATION VOID PATIENT CARD PHYSICIAN SIGNATURE REVOKED REJECTED REQUEST FOR INFORMATION CSU RETURN MAIL SURRENDER APPROVED SURRENDER REJECTED CAREGIVER PT WAIVER APPROVED CAREGIVER PT WAIVER REJECTED VERIFIED BREACH PATIENT RESPONSE TO PHYSICIAN SIGNATURE REVOCATION APPROVED PATIENT RESPONSE TO PHYSICIAN SIGNATURE REVOCATION REJECTED PROVIDER SIG REVOKE APPROVED PROVIDER SIG REVOKE REJECTED POTENTIAL VOIDED CARD CSU VOIDED CARD Purpose Track all notes regarding patient with no changes to database fields Track all outlying special cases for all MMR Track all changes to a record related to a trans code that has already been saved Record Physician's Request to Revoke Signature from PT record Tracks requests by patient for information from records. Track patients whose cards have been voided due to physician revocation Track all rejected Requests for Information Track all returned correspondence in the Customer Service Unit Track all approved Request to Surrender forms Track all rejected Request to Surrender forms Track all Caregiver PT Waivers approved Track all Caregiver PT Waivers rejected Track all verifiable, reported breaches Track approved patient responses to physician revocations. Track rejected patient responses to physician revocations. Track approved provider signature revocations. Track rejected provider signature revocations. Track all notices to patient regarding the potential for a voided card Track voided cards without response to CNN APPROVED APP W PMT APPROVED APP W O PMT APPROVED FEE WAIVER REJECTED FEE WAIVER REJECT APP W PMT 1 REJECT APP W PMT 2 REJECT APP W O PMT 1 REJECT APP W O PMT 2 Track all approved applications with payments Track all approved applications without payments Track all approved fee waiver/tax exempt updates Track all rejected fee waiver/tax exempt updates Track all 1st strike rejects with payments Track all 2nd strike rejects with payments Track all 1 st strike rejects without payments Track all 2 nd strike rejects without payments 49

50 REJECT APP W VFW 1 REJECT APP W VFW 2 REJECT APP W IFW 1 REJECT APP W IFW 2 APPROVED CHANGE CHANGE ORDER REJECTION EPU RETURN MAIL REJECT MAILED REJECT APP DENIAL APPEAL RECEIVED APPEAL TRANSFER TO LEGAL DENIAL OVERTURN REJECT DENIAL OVERTURN APPROVE DENIAL SUSTAINED SUPPORTING DOCUMENTS CHANGE REJECTION MAILED Track all 1st strike rejects with valid fee waiver Track all 2nd strike rejects with valid fee waiver Track all 1st strike rejects with invalid fee waiver Track all 2st strike rejects with invalid fee waiver Track all approved change forms Track all rejected change forms Track all returned mail in the Evaluating & Processing Unit. Track all form 1001 & 1002 rejects mailed Track all denials issued Track all denial appeals Track appeals referred to legal Track appeal status Track appeal status Track appeal status Track a miscellaneous documents received W/O pending rejection (i.e. pmts, ID, POR etc..) Track all form 1003 rejects mailed SUPPORTING DOCUMENTS WITH MONEY Track all payments submitted without form 1001 & 1002 APPROVED HOMEBOUND REJECT HOMEBOUND APPROVED Tax Exempt REJECTED TAX EXEMPT MODIFY ENTRY ERROR EPU CORRECTION UPDATE FRAUD DETECTION ON HOLD LAW ENFORCEMENT PATIENT REVOKE FRAUD ALLEGATION FROM LEO PROCESSED APPLICATION PROCESSED FEE WAIVER LOST/STOLEN REJECTED LOST/STOLEN LOST/STOLEN PROCESSED IU RETURN MAIL APPLICATION ON HOLD BAD CHECK Track all approved homebound applications Track all rejected homebound applications Track all approved Tax Exempt Track all rejected Tax Exempt Allow EPU to correct errors/enter when doing data entry (i.e. forgot APT in address or inactive not selected,) Track all internal corrections processed by EPU for renewal applications Track all FPU investigations Track all patient revocation by FPU Track all forms with fraud allegations from LEO Track all cards printed for approved applications Track all cards printed for approved fee waiver applications Track all replacement cards printed in response to a lost/stolen report Track all rejections of lost/stolen reports Track all cards printed for approved lost/stolen reports Track all returned correspondence in the Issuance Unit. Track all requests for SSN & PT's name change documentation Track all patients who have had their payment returned by the bank 50

51 FORM CHANGE PROCESSED DATA CLEANUP CORRECTION CORRECTION WITH CARD TAX EXEMPT UPDATE HOMEBOUND UPDATE DECEASED PAYMENT RESOLVED RETURN MAIL RECEIVED RETURN MAIL SENT QU RETURN MAIL FINAL DENIAL REVOKED DUPLICATE Track all change forms that have been processed Track all changes made for data cleanup Track all correction without a card Track all correction with a card Track all processed fee waivers Track all Homebound patients that already received a card Track all patients that are deceased Track all payments with bad checks Track all returned correspondence in the Modification Unit Track all denied patients Track all court ordered revocations Track all applications received prior to renewal period 51

52 APPENDIX III Sample OIT PROJECT PLAN Governor s Office of Information Technology [OIT] 601 East 18th Avenue, Suite 250 Denver, Colorado 80203

53 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Fax (303) PROJECT PLAN for [ X PROJECT ] [ MONTH DD, YYYY ] Page 53

54 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Revision Chart Version Primary Author(s) Description of Version Date Completed OIT Gate Process Template Project Plan Page ii

55 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Table of Contents Table of Contents... iii 1 Overview High Level Project Summary Description/Background Goals and Objectives Business and Technical Benefits and Gains Alignment with Departmental Mission and/or Strategic Plan High Level Project Summary Constraints Dependencies Related Projects Assumptions Project Management Team Staffing Management Organization Chart Staffing Plan Project Requirements Staffing Plan Baseline Project Budget Procurement Plan Project Quality, Success Metrics, and Deliverables Quality Management Independent Validation and Verification Vendor Project Success Measures Deliverable Acceptance Process Business Continuity and Cyber/System Security Architectural Plan Business Continuity Process Disaster Recovery Process Site Location Initial and Ongoing Disaster Recovery Costs System Security Compliance CARE Rating Date of Sign-off of System Security Plan Communication Plan and Stakeholder Identification Key Stakeholders Communication Type and Frequency Scope Management and Change Control Process Scope Management Plan Change Control Process Escalation Chart Risk Management OIT Gate Process Template Project Plan Page iii

56 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Training Plan Training Approach Training Dependencies Test Plan System Testing Performance Testing User Acceptance Testing Implementation Plan Deployment/Transition Maintenance and Operations Long Term Sustainability Plan Signature Page Appendices OIT Gate Process Template Project Plan Page iv

57 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) SECTION 1. Overview This document is requested by the Governor s Office of Information Technology (OIT) Office of Enterprise Portfolio and Project Management Office (EPPMO) in accordance with Colorado State House Bill , to summarize the project attributes for any major project identified in any state agency which will be moved through a series of gated processes as part of a project oversight and governance structure. In the legislation identified above, a major information technology project is defined as a project of state government that has a significant information technology component, including, without limitation, the replacement an existing information technology system. This document will summarize the Project Manager s project planning effort and will be reviewed by the Project Assessment Board. An approved Project Plan is a pre-requisite for the project to exit the Gate 2 planning process. Once approved, the project will be entered into Clarity for ongoing tracking purposes and move to the Gate 2 Execution process. 1.1 HIGH LEVEL PROJECT SUMMARY Description/Background [Provide a brief description of the project and any background that would be helpful.] Goals and Objectives [Describe the project s goals and objectives] Business and Technical Benefits and Gains [As described in the approved business case] Alignment with Departmental Mission and/or Strategic Plan [As described in the approved business case] 1.2 HIGH LEVEL PROJECT SUMMARY [List any legal or legislative constraints or mandates that may influence the project completion date. List all dependencies for this project, other projects, and future work. Dependencies may be assistance from other OIT work units, state agencies, other projects, etc. - as described in the approved business case] 1.3 CONSTRAINTS Dependencies Related Projects 1.4 ASSUMPTIONS [List any assumptions that are relevant to the project.] OIT Gate Process Template Project Plan Page 5

58 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) SECTION 2. Project Management 2.1 TEAM STAFFING MANAGEMENT Organization Chart [Include a Project Organization Chart, see example below] Staffing Plan [Provide the internal and external staff roles and responsibilities required for this project. Include a list of members of the Core Project Team is applicable.] Sample Roles and Responsibilities Table Role Responsibility Core Project Team Member? Y/N Project Requestor Project Sponsor Project Manager Agency Business Analysts/SME Project Communications Resource OIT IT Director Design and Development. OIT Gate Process Template Project Plan Page 6

59 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Role Responsibility Core Project Team Member? Y/N Unit and System Testing integration UAT Testing governance Hardware Installation (if applicable) Contract Manager (if applicable) OIT Security Analysts IV & V 2.2 PROJECT REQUIREMENTS Staffing Plan [Describe the requirements gathering process, and if known, identify the number of requirements by functional (how the system will behave), and non-functional (how the system must perform) Functional Requirements Non-Functional Requirements Number of Requirements nnnn.nnn nnnn.nnn 2.3 BASELINE PROJECT BUDGET [Provide the project Baseline as established in the Gate 1 Approved Business Case. Indicate approval date of the TCO Worksheet.] Total Project Budget TCO Worksheet Sign Off Date 2.4 PROCUREMENT PLAN [Is there a procurement required? If yes, provide the solicitation method to be used. What good and/or service is being procured? Identify the resource who will manage the Contract Management Process (CMS) process for this project) SECTION 3. Project Quality, Success Metrics, and Deliverables This section provides a full listing of all solution options, the assumptions attendant upon inclusion as an option, as well as benefits, costs, feasibility, risks, and issues for each. Suggested options may include doing nothing, doing something that will achieve a similar result, or doing something that will achieve a better result than current performance. If necessary, minimize the number of options available by conducting a detailed Feasibility Study beforehand. For each solution option identified, the following information is required: OIT Gate Process Template Project Plan Page 7

60 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) QUALITY MANAGEMENT [Describe how quality will be applied and measured during the project] 3.2 INDEPENDENT VALIDATION AND VERIFICATION VENDOR [Will there be an IV&V on the project? If yes, when will the IV&V be integrated in the project? Describe the deliverables outlined in the Statement of Work] 3.3 PROJECT SUCCESS MEASURES [Success factors should clear and measurable. For example customer satisfaction is not a success factor, defining what customer satisfaction is would be a success factor.] Success Factor Measurement 3.4 DELIVERABLE ACCEPTANCE PROCESS [Describe the deliverable acceptance process that will be used throughout the project.] Example: All deliverables will be reviewed and accepted by the project sponsor prior to the closure of the project. This acceptance can be documented via or by some other agreed upon written form. SECTION 4. Business Continuity and Cyber/System Security 4.1 ARCHITECTURAL PLAN [Describe the hardware and software the new system will reside on. Indicate if this is an upgrade from existing hardware or a completely new platform. Indicate if the system is outsourced to an external vendor.] 4.2 BUSINESS CONTINUITY PROCESS [Describe the impacts to the Agency and its customers if the system is not implemented on time, does not perform as planned, or is down for an extended period of time] 4.3 DISASTER RECOVERY PROCESS [Describe the disaster recovery process, identify the location of the disaster recovery site, and list any costs to provide the service] OIT Gate Process Template Project Plan Page 8

61 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Site Location Initial and Ongoing Disaster Recovery Costs 4.4 SYSTEM SECURITY COMPLIANCE [Identify the rating received from the Security CARE Assessment, and Signoff date of System Security Plan] CARE Rating Date of Sign-off of System Security Plan SECTION 5. Communication Plan and Stakeholder Identification 5.1 KEY STAKEHOLDERS [List the key stakeholder(s) of the project: the customers, end users and any other Departments or Divisions that may be impacted by this project.] 5.2 COMMUNICATION TYPE AND FREQUENCY [Describe what information key stakeholders would like to receive, how often, and by what method, i.e. , phone, meetings. Each Stakeholder identified above should be listed in the table below.] Stakeholder Communicator (Project Manager, Sponsor, Business Unit Lead) Frequency (Weekly, Bi-Weekly, Monthly) What to Communicate (i.e. status, issues, etc.) Method (i.e. , phone, oneon-one, etc.) SECTION 6. Scope Management and Change Control Process 6.1 SCOPE MANAGEMENT PLAN [How will changes to the project scope be managed?] 6.2 CHANGE CONTROL PROCESS [How will requests for changes to the project be documented and approved?] 6.3 ESCALATION CHART [Define the project escalation process) OIT Gate Process Template Project Plan Page 9

62 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Definition: Any project team member can escalate an issue to the next higher level. To ensure an orderly escalation process, project team members must escalate their issue in accordance with the project hierarchy. Sample Project Escalation Chart Project Sponsor Project Manager Resource Manager Team Management Team Member SECTION 7. Risk Management (Summarize the comprehensive risk assessment process which was applied to this project.) SECTION 8. Training Plan 8.1 TRAINING APPROACH [Is training required, who needs to be trained, and describe the approach to preparing the training plan project?] 8.2 TRAINING DEPENDENCIES [Are there dependencies to successful implementation of the training plan?] SECTION 9. Test Plan 9.1 SYSTEM TESTING [Describe the approach and accountable organization for system test.] OIT Gate Process Template Project Plan Page 10

63 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) PERFORMANCE TESTING [Describe the approach and tools planned for performance testing.] 9.3 USER ACCEPTANCE TESTING [Describe the approach and resources required to conduct user acceptance testing.] SECTION 10. Implementation Plan 10.1 DEPLOYMENT/TRANSITION [Describe how the project will be deployed and transitioned.] 10.2 MAINTENANCE AND OPERATIONS [Describe the maintenance and operations approach. Identify the business and/or IT resources required to maintain and operated the new system.] 10.3 LONG TERM SUSTAINABILITY PLAN [How will the new system be sustained long term by OIT or the Agency?] SECTION 11. Signature Page The purpose of this document is to provide a vehicle for documenting the initial planning efforts for the project. It is used to reach a satisfactory level of mutual agreement between the Project Manager(s), Project Stakeholder(s), and the Project Sponsor(s) with respect to the objectives and scope of the project. I have reviewed the information contained in this Project Plan and agree: Name Role Signature Date Project Sponsor Business Unit Project Lead Project Manager OIT Agency IT Director OIT Business Analysts OIT EPPMO Director OIT Security Analysts OIT Service Delivery Director OIT Gate Process Template Project Plan Page 11

64 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) SECTION 12. Appendices In some cases a project is large enough to warrant a separate document that describes in more detail the following items. If you complete separate subsidiary plans or additional documents, it is recommended that these are attached to this project plan. Examples of potential Appendices: Project Charter Project Schedule Change Request Form Project Status Report Project Staffing Plan Project Communication Plan Project Quality Plan Project Change Control Process Project Risk Management Plan Project Procurement Plan Definitions and Acronyms OIT Gate Process Template Project Plan Page 12

65 APPENDIX IV OIT SYSTEM SECURITY PLAN TEMPLATE Governor s Office of Information Technology [OIT] 601 East 18th Avenue, Suite 250 Denver, Colorado 80203

66 GOVERNOR S OFFICE OF INFORMATION TECHNOLOGY 601 East 18th Avenue, Suite 250 Denver, Colorado Phone (303) Fax (303) SYSTEM SECURITY PLAN for [ X PROJECT ] [ MONTH DD, YYYY ] CONFIDENTIAL For Official Use Only - Portions of this information may be exempt from disclosure under the Colorado Open Records Act. Colorado Revised Statute (2)(a)(VIII)(A). Page 14