procure.ohio.gov€¦ · Web viewUpon determination of the highest-ranking ... Microsoft Word or Microsoft Excel ... will be evaluated for implementation based on the criticality

Supplement 1Medical Marijuana Seed to Sale Solution

Functional, Technical and Integration RequirementsOperations/Maintenance Requirements

Table of Contents

1. Opportunity Summary and Overview 31.1. Background and Introduction..................................................................................................................................................31.2. Organization of this RFP.........................................................................................................................................................41.3. Important Dates, Terminal Project Due Date..........................................................................................................................51.4. Offeror Note: Software Licensing, Implementation, and Ongoing Cost Considerations..........................................................61.5. Offeror Note: Response Format and Suggested Illustrations of Capabilities...........................................................................61.6. Medical Marijuana Supply Chain, Conceptual Overview and Organization of Requirements..................................................7

2. General Requirements 82.1. General Requirements: Alerts.................................................................................................................................................82.2. General Requirements: Reports.............................................................................................................................................82.3. General Requirements: Enablement of Industry Facing APIs (Application Programming Interfaces).....................................82.4. Offeror Proposed Solution: API Coverage Matrix..................................................................................................................10

3. Cultivator Process: Monitoring, Tracking and Compliance Requirements 113.1. General Overview.................................................................................................................................................................113.2. Sizing Considerations...........................................................................................................................................................113.3. Cultivator Monitoring and Tracking Requirements................................................................................................................113.4. Cultivator Compliance Requirements....................................................................................................................................123.5. Cultivator Batch Testing Requirements.................................................................................................................................133.6. Industry Facing File/Web Services and Application Programming Interfaces (API) Requirements.......................................133.7. State Oversight, Regulatory and Reporting Requirements...................................................................................................143.8. Secure Destruction of Product Requirements.......................................................................................................................143.9. Transport of Approved Cultivated Products – Requirements................................................................................................14

4. Product Processor: Process Monitoring, Tracking and Compliance Requirements 164.1. General Overview.................................................................................................................................................................164.2. Sizing Considerations...........................................................................................................................................................164.3. Product Processor Monitoring Requirements........................................................................................................................164.4. Product Processor Transport Verification and Acceptance Requirements............................................................................164.5. Product Processor Raw Materials Inventory Update / Tracking Requirements.....................................................................174.6. Product Processor Waste Materials Inventory Tracking / Destruction Requirements............................................................174.7. Finished Product Identifier Assignment Requirements..........................................................................................................184.8. Product Processor Finished Products Inventory Update / Tracking Requirements...............................................................184.9. Product Processor Compliance Requirements.....................................................................................................................194.10. Transport of Finished Products – Requirements...................................................................................................................20

5. Transport / Logistics: Process Monitoring, Tracking and Compliance Requirements 215.1. General Overview.................................................................................................................................................................215.2. Sizing Considerations...........................................................................................................................................................215.3. Logistics/Transport Mobile Application/Access Requirements..............................................................................................215.4. Logistics/Transport Acceptance and Tracking Requirements...............................................................................................225.5. Logistics/Transport Compliance Requirements.....................................................................................................................22

6. Dispensary Process: Monitoring, Tracking and Compliance Requirements 236.1. General Overview.................................................................................................................................................................236.2. Sizing Considerations...........................................................................................................................................................236.3. Patient and Recommendation Verification, Integration, and Recording Requirements.........................................................236.4. Dispensing of Marijuana Product - Tracking Requirements..................................................................................................236.5. Inventory Management Functions.........................................................................................................................................246.6. Dispensary Point of Sale: Tracking and Compliance Requirements.....................................................................................25

7. State Systems: Integration Requirements 267.1. Overview...............................................................................................................................................................................267.2. General Integration Requirements........................................................................................................................................267.3. Use of State Enterprise Service Bus as Integration Framework............................................................................................277.4. Matrix of Licenses Required within the S2S Process............................................................................................................28

8. Offeror Project Delivery and Team Requirements 298.1. Project Management and Coordination Services..................................................................................................................298.2. Create and Maintain Project Plan.........................................................................................................................................308.3. Creation of a Dispute Resolution Capability..........................................................................................................................318.4. Meeting Attendance and Reporting Requirements...............................................................................................................328.5. Utilize OIT’s Document Sharing/Collaboration Capability.....................................................................................................328.6. Production/Version Control and Release Management........................................................................................................33

State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1: Medical Marijuana Seed to Sale Solution and Implementation Requirements

8.7. Maintaining Solution and Operations Documentation...........................................................................................................338.8. Project Delivery, Role and Responsibility Requirements......................................................................................................348.9. System/Environment Administration Support of the Project..................................................................................................348.10. Cooperation with State and State Contractors and Alignment of Deliverables......................................................................348.11. Dispute Resolution and Escalations......................................................................................................................................35

9. Project Phasing, Work Products and Deliverables 379.1. Requirements Confirmation and Analysis.............................................................................................................................379.2. Analyze Phase: Contractor Functional Team........................................................................................................................379.3. Analyze Phase: Contractor Technical Team.........................................................................................................................379.4. Analyze Phase: Process Design/Validation and Training......................................................................................................389.5. Design Phase.......................................................................................................................................................................399.6. Design Phase: Contractor Functional Team.........................................................................................................................399.7. Design Phase: Contractor Technical Team...........................................................................................................................399.8. Design Phase: Process Design/Validation and Training.......................................................................................................399.9. Build Phase...........................................................................................................................................................................409.10. Build Phase: Contractor Functional Team.............................................................................................................................409.11. Build Phase: Contractor Technical Team..............................................................................................................................409.12. Process Design/Validation and Training...............................................................................................................................419.13. State Acceptance Test Phase...............................................................................................................................................429.14. State Acceptance Test Phase: Contractor Functional Team.................................................................................................429.15. State Acceptance Test Phase: Contractor Technical Team..................................................................................................439.16. State Acceptance Test Phase: Process Design/Validation and Training..............................................................................439.17. Production Deployment Phase..............................................................................................................................................449.18. Production Deployment Phase: Contractor Functional Team...............................................................................................449.19. Production Deployment Phase: Contractor Technical Team.................................................................................................449.20. Production Deployment Phase: Process Design/Validation and Training.............................................................................459.21. Knowledge Transfer and Production Handoff.......................................................................................................................469.22. Project Completion Activities, Final Documentation and Post Implementation Support Obligations.....................................46

10. Solution Technical and Operating Requirements 4710.1. General Requirements: Hosted/Cloud Software Solution.....................................................................................................4710.2. System Environment Requirements......................................................................................................................................4710.3. Production/Version Control and Release Management........................................................................................................4810.4. Break/Fix Support.................................................................................................................................................................4910.5. Problem Management Services............................................................................................................................................4910.6. S2S software and Application Licensing, Capacity Planning and Monitoring........................................................................5010.7. Job and Interface Execution / Production Control.................................................................................................................5010.8. S2S Software Platform System Management and Administration.........................................................................................5110.9. Support of S2S Software Future Releases and State Applications as a Result of Changes.................................................5210.10. Major/Minor Upgrades (Ongoing)..........................................................................................................................................5210.11. System/Environment Administration Support........................................................................................................................5310.12. Program Management & Master Release Calendar.............................................................................................................5410.13. Minor Change and Enhancement Services...........................................................................................................................5410.14. Environment Backup and Restoration Services....................................................................................................................5510.15. Support of State Disaster Recovery......................................................................................................................................5510.16. Service Level Requirements: Hosted/Cloud Software Solution.............................................................................................5710.17. Service Level Specific Performance Credits.........................................................................................................................57

11. Offeror Assumptions, Support Requirements, Pre-Existing and Commercial Materials 5811.1. Assumptions.........................................................................................................................................................................5811.2. Support Requirements..........................................................................................................................................................5811.3. Pre-Existing Materials...........................................................................................................................................................5811.4. Commercial Materials...........................................................................................................................................................58

State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1: Medical Marijuana Seed to Sale Solution and Implementation Requirements

1. Opportunity Summary and Overview

1.1. Background and Introduction

Recently the Legislature of the State of Ohio passed House Bill 523 pertaining to the legalization of marijuana for medical purposes. A summary and detailed documents related to this legislation can be found at https://www.legislature.ohio.gov/legislation/legislation-summary?id=GA131-HB-523 The State has developed this RFP for an electronic data base designed to support the State’s regulation, monitoring, licensing and ongoing operation and oversight of the Medical Marijuana industry as allowed by this legislation. A general overview of these Agencies, and their role in the State and specific to this Project are as follows:

State Agency/Board General Role & Additional Details

Ohio Department of Commerce (“Commerce”)

Regulation and Oversight of Cultivators, Processors, Testing Laboratories. Primary Agency responsible for establishing and maintaining the electronic database and Marijuana compliance/ reporting systems http://www.com.ohio.gov/

State Medical Board of Ohio (“Medical Board”)

Licensing and Oversight of Physicians http://www.med.ohio.gov/

Pharmacy Board of Ohio (“Pharmacy Board”)

Recommendation Tracking, Patient and Caregiver Registry, and Regulation and Oversight of Dispensaries https://pharmacy.ohio.gov/

Ohio Department of Taxation (“Tax”)

Taxation of Industry Businesses http://www.tax.ohio.gov/

Ohio Department of Administrative Services, Office of Information Technology (“DAS/OIT”)

Systems, Technology and Contractual Matters Arising from this RFP http://das.ohio.gov/Divisions/InformationTechnology.aspx

General Medical Marijuana Program Information & Rules

http://www.medicalmarijuana.ohio.gov/

In general, the State views the technology elements required to enable the State’s Medical Marijuana business as follows:

Seed to Sale Tracking System: (hereinafter S2S) the scope of this Supplement which (in general) is responsible for management of:

The end-to-end Medical Marijuana Supply Chain from plant origins: (e.g., seeds, clones, biological matter, and variants);

The cultivation and harvest of Medical Marijuana including the destruction of unused and unusable by-products of this stage of the process;

Tracking of secure transport of usable materials from one medical marijuana entity under Ohio’s program to another (i.e., Cultivator to a Processor, Processor to Dispensary or Processor to Testing Lab);

The tracking of the manufacture of finished products and the destruction of unused by-products containing marijuana, as a result of Processing;

Tracking of secure transport of consumer-ready products to Ohio Dispensaries for sale;

State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1: Medical Marijuana Seed to Sale Solution and Implementation Requirements Page 3 of 59

http://www.medicalmarijuana.ohio.gov/

http://das.ohio.gov/Divisions/InformationTechnology.aspx

http://www.tax.ohio.gov/

https://pharmacy.ohio.gov/

http://www.med.ohio.gov/

http://www.com.ohio.gov/

https://www.legislature.ohio.gov/legislation/legislation-summary?id=GA131-HB-523

Tracking of the sale, error or recall of each consumer ready product by a Dispensary licensed by the State board of Pharmacy;

Tracking of testing laboratory results related to Medical Marijuana material and products;

Tracking of a variety of weights, potency, licenses, cost and products throughout this S2S supply chain using identification codes (i.e. unique plant identifier, batch number, lot number, product identifier, etc.) with the goal of tracking each product’s batch, brand, form, dose, etc.; and

Identification of anomalous, real or apparent fraud, diversion, violations of law and compliance with State auditing, compliance, inspection and reporting requirements for the State Agencies charged with the administration and oversight of this Program.

Specific State requirements for each of the steps in the S2S supply chain are contained in more detail within this Supplement.

In Addition, the State has identified a variety of Program Validation and Readiness Services the scope of Supplement 2 required to:

Perform the technical and data integration of the S2S, payment and revenue reporting and other State Systems;

Integrate the required Licenses that are required across the overall Supply Chain (e.g., S2S and State Systems etc.) with the State’s eLicensing platform to enable and launch the Program;

Development of the required organizational roles/responsibilities, processes, procedures, reports, alerts/notifications that comprise to the State’s Prescription Drug Monitoring Program (e.g., OARRS - https://www.ohiopmp.gov/, Patient Registry, eLicensing platform, S2S software, Tax reporting systems and Compliance/Monitoring/Inspection teams) in State Agencies that are charged with oversight of this Program;

Design and implement operational and oversight processes in the context of State law, established rules, and the Systems contained in this RFP to “launch” the Medical Marijuana program within the State;

Develop and deliver training materials designed to provide an overview of the new systems, integration and reporting environment inclusive of rules, policies and procedures for State and Industry staff involved in the Program; and

Assess the efficacy of systems deployments, operational processes and training and develop an objective assessment of "go-live" readiness prior to each implementation of the Program.

Specific State requirements for Program Validation and Readiness Services are contained in more detail within Supplement 2.

Note: All offerors to any of Supplements 1 or 2 (and any combination thereof) are responsible for understanding and complying with State Architecture, Security, Privacy and Data Handling Requirements which are contained in more detail within Supplement 3.

1.2. Organization of this RFP

Based upon the State’s analysis of the Medical Marijuana systems marketplace inclusive of analysis of other States implementation experiences, and in accordance with the Ohio Revised Code, this RFP is organized to contain three (3) Supplements. The State’s rationale for this organization is to allow the State to identify and select the most favorable technology, integration and processes that are aligned with both State laws and rules pertinent to the establishment, oversight, monitoring and regulation of the Medical Marijuana industry in Ohio, while allowing the State the flexibility to select the highest ranked Offerors for each of the following solution elements:


https://www.ohiopmp.gov/

High Level Organization of this RFP

Offerors may choose to respond to either or both of the aforementioned Supplements 1 and 2 in keeping with the capabilities of their firm, the software, technology, and process support capabilities that are specific to this emerging industry, aligned with State laws that govern, and as to provide an overall solution for each of the respective parts that comprise the State’s overall solution requirements.

Offerors are not required to form consortiums to respond to this RFP in its entirety (i.e., all three supplements) as the State’s evaluation methodology contained in the RFP documents allows the State to identify and select the highest ranking Offeror from each of Supplements 1 and 2. Supplement 3 will apply to the contracted scope of each of Supplements 1 and 2 regardless of the State’s final award and contracting structure.

Offerors may, at their sole discretion, choose to form partnerships with firms they believe are qualified to perform the work and deliver the solution elements as required in either of Supplements 1 or 2 should they choose to as it relates to offering the State a total solution for all elements that comprise the State’s requirements.

Regardless of proposal structure, the State reserves the right to select Highest Ranking Offerors in each of the respective Supplements regardless of proposal structure. Notwithstanding these considerations, each Supplement responded to must have a clear Prime Contractor and Software Vendor (i.e., Licensor to the State) that is responsible for delivering the work to the State, as contracted.

Offerors responding to any of Supplements 1 or 2 are encouraged to review all Supplements to better understand the organization of the RFP (in general) and the relationships and scope of the requirements in each Supplement as they relate to the State’s overall solution requirements.

A single offeror cannot be awarded the Supplement 1 scope of work and the Supplement 2 scope of work.

1.3. Important Dates, Terminal Project Due Date

The State’s Medical Marijuana Program has several milestone dates designed to implement the program Statewide. The contents of this RFP, in its entirety must be designed, developed, and deployed to operational use within the State as follows:

September 8, 2016 September 8, 2017 Key Program Dates September 8, 2018Effective date of Ohio House Bill

523. HB 523 establishes the basic framework for Ohio’s Medical Marijuana Control

Program

Dispensary, Processor, Testing Lab and Medical Board Rules

Adopted (Cultivator Rules Effective). Ohio law requires the

State of Ohio Board of Pharmacy to adopt dispensary rules and State Medical Board

of Ohio to adopt its rules around certification and standards of

care by this date.

System Implementation Complete

State Licensees Trained and Ready to Conduct Business on

S2S System

Terminal Due Date for this Project: November 15, 2017

Ohio law requires the Ohio Medical Marijuana Control

Program to be fully operational by this date.

Business Launch


1.4. Offeror Note: Software Licensing, Implementation, and Ongoing Cost Considerations

The State acknowledges that there are a variety of cost and funding models prevalent in existing state marijuana programs that precede this RFP. In the interest of ensuring that total cost is factored within the State RFP Evaluation Process as described in more detail within the RFP documents, the State, for evaluation purposes only, seeks a fully costed, all-inclusive price for the Offeror’s solution including:

Software Licensing and Ongoing Maintenance Costs;

Software Design, Configuration, Testing and Implementation Costs;

Software integration with State Systems, Alerts and Reporting requirements;

User (both State and Industry) Training and Documentation Costs;

Software Hosting and ongoing Operations Costs;

Ongoing Software Upgrades, Patches, Enhancements and Customizations;

3rd Party Elements (software, hardware, networking and other elements required by the solution, but licensed or obtained from 3rd parties); and

Other Costs as required to implement the complete solution as required in this Supplement.

Offerors are to include such costs as required within Attachment 9, (Offeror Cost Workbook) in accordance with State requirements as included in the RFP documents.

Upon determination of the highest-ranking offeror, and during the negotiations process, the State and Offeror may agree to mutually develop a system cost recovery / funding model as to recover implementation and operational costs as allowed under State law.

1.5. Offeror Note: Response Format and Suggested Illustrations of Capabilities

This Supplement includes a variety of State narrative requirements pertaining to functionality, integration, configuration and reporting requirements pertinent to the work. Offerors are to indicate as part of their response how (i.e., “Approach” in the table below); by whom (i.e., “State” or “Contractor” or “3rd Party”); and the relative Contractor complexity and effort required to accomplish the requirement in it’s entirely (i.e., “Effort Complexity” in the table below). Offerors are required to address every requirement contained in this Supplement using the following terminology nomenclature:

Approach / Terminology Description

Offeror-proposed Tool/Solution

Offerors are to include the name and major version number of the Proposed Tool/Solution to address the requirement (e.g., Acme Corporation® WidgetMaster™ v9.1).

Out of the BoxOfferors are to indicate, in systems development hours (i.e., inclusive of all design, configure/build, test, implement), to be spent implementing this requirement using as-delivered functions of the Offeror-proposed solution.

Configuration ItemOfferors are to indicate, in systems development hours (i.e., inclusive of all design, configure/build, test, implement), to be spent implementing this requirement using configurable functions (e.g., interfaces, reports, workflows, screen elements) of the Offeror-proposed solution.

CustomizationOfferors are to indicate, in systems development hours (i.e., inclusive of all design, configure/build, test, implement), to be spent implementing this requirement using customized functions (e.g., interfaces, reports, workflows, screen elements) of the Offeror-proposed solution.

Extension/Interface

Offerors are to indicate, in systems development hours (i.e., inclusive of all design, configure/build, test, implement), to be spent implementing this requirement using as extensions or interfaces (e.g.,


interfaces, reports, workflows, screen elements) of the Offeror-proposed S2S System, State interfaces, or other Offeror provided solution elements.

Other / 3rd Party Element

Offerors are to indicate, in full systems development hours (i.e., design, configure/build, test, implement), to be spent implementing this requirement using this category for any item which does not fit into the aforementioned categories.

Effort Complexity Terminology Description

Low The Contractor can design, configure, test and implement the requirement within a one (1) FTE week in consideration of all required work (e.g., accomplish the requirement within 40 hours)

Medium The Contractor can design, configure, test and implement the requirement within a one (1) FTE month in consideration of all required work (e.g., accomplish the requirement within 180 hours)

High The Contractor can design, configure, test and implement the requirement within a one (1) FTE quarter in consideration of all required work (e.g., accomplish the requirement within 500 hours)

Extreme The Contractor can design, configure, test and implement the requirement within a one (1) FTE year in consideration of all required work (e.g., accomplish the requirement within 1,980 hours)

In addition, the State suggests that Offerors provide screen captures, diagrams, graphics or other information of relevant elements of their solution to illustrate to the State the degree of compliance with State requirements wherever possible and within the page limit(s) of this Supplement as required by the RFP.

1.6. Medical Marijuana Supply Chain, Conceptual Overview and Organization of Requirements

The State has developed a generalized end-to-end Supply Chain conceptual process graphic to aid Offerors in understanding the overall process to be managed as a result of this software, as well as to identify key logical interfaces with State systems and Process/Technical integration requirements. This conceptual process will be presented in additional detail throughout the Supplements of this RFP.

Medical Marijuana – Conceptual End-to-End “S2S” Supply Chain

Business, Functional and Integration requirements for each of the elements of this Conceptual Supply Chain follow in the subsequent Sections of this Supplement.


2. General RequirementsIn addition to the detailed requirements pertinent to the end-to-end S2S process contained later in this Supplement, the State has identified several general requirements that are applicable to the overall system (in general) and align with the creation of an “industry friendly” operating environment that is controlled, transparent and verifiable.

2.1. General Requirements: Alerts

Throughout this Supplement, the term ‘Alerts’ is used to define a system-initiated action as a result of either (or both of) a system detected or person reported anomalous condition that may require the immediate attention of a State Agency. Alerts shall be designed and implemented in the system to support near-real-time generation of one or more of:

An email to a State designated email address or distribution list given the detection of such a condition via a Contractor SMTP provided email gateway;

A text message to a State designated SMS number or distribution list given the detection of such a condition via a Contractor provided SMS gateway; and

Logging of the Alert condition to a system log for State reporting and inspection.

During systems requirement confirmation, design and implementation phases as described in Section 8, the specific details of State required Alerts (by business area and transaction type) will be specified by the State.

Offerors responding to this Supplement are encouraged to highlight the capabilities of their system in support of the identification and notification of Alerts, and where ‘Alerts’ are required within the subsequent sections of this Supplement, Offerors are required to incorporate the capabilities of their system in addressing these requirements in the context of the requirements in the appropriate Section of this Supplement in their response.

2.2. General Requirements: Reports

Throughout this Supplement, the term ‘Reports’ is used to define a system report format in support of Industry or State business functions. Reports must be designed and implemented in the system to support near-real-time generation of system data in tabular form as follows:

Tabular reports must allow columnar sorting on all displayed data;

Tabular reports must allow filtration of a column for specific, user selectable value(s) as to isolate rows where a particular condition exists (e.g., equals, between, ‘is one of the following’, does not equal etc)

Tabular reports must be exportable in common, Microsoft Office or compatible formats (e.g., Excel or comma separated values - CSV); and

Tabular reports must be printable (i.e., all information formatted for a standard printed page) and savable in portable document formats (i.e., Adobe PDF).

2.3. General Requirements: Enablement of Industry Facing APIs (Application Programming Interfaces)

Upon review of States that have implemented marijuana programs, the State has determined to provide the marijuana Industry (e.g., Cultivators, Processors, Dispensaries, and Testing Laboratories report access both via Web/Portal based solutions as well as application programming interfaces (APIs) that are designed to foster timely, accurate and automated sharing of data with the State that is required under law, licenses and rule sets that govern Ohio’s Medical Marijuana Program.

The State understands that there is a wide variety of 3rd party software applications and suites designed to assist the Industry in various aspects of their production, reporting, compliance, financial and sale processes and


therefore seeks S2S systems that foster operation within State law as to not place an undue administrative burden on these participants in the supply chain.

Therefore, the State requires Offerors, as part of their response, and as Contractor to provide, maintain and support the following API functions within 15 business days of the development or alteration of any API:

Provide fully documented APIs for all system functions exposed via Web/Portals that are industry facing that require one of more of: sharing of transactional, compliance, State required reporting data between the Licensed Participant as required by the State;

Provide structured training sessions for the State and Industry in the awareness, proper use, development, testing, defect identification and removal, and problem identification/resolution;

Provide a certification program for all 3rd party developers by which these 3rd party applications can be developed, tested and certified for use by industry participants and vendors.

The following methods are acceptable forms of APIs. Offerors, as part of their response are to indicate which (if any) method(s) are supported:

Secure Web Services (i.e., system to system interaction);

Extensible Markup Language – XML (i.e., structured file exchange between two systems via a secure exchange); and

Comma Separated Values - CSV (i.e., as output from common desktop/productivity applications such as Microsoft Office using predetermined columns/fields).

As part of their proposal, Offerors are to complete the table (see next page) to the extent possible where the proposed solution has either of: 1) a Contractor Certified or Proven-Compatible Integration with a 3 rd party software package or data sharing method or 2) an existing customer who is utilizing the 3 rd party software in production/live us as part of their routine interaction with another Governmental or Regulatory body (e.g., a State).


2.4. Offeror Proposed Solution: API Coverage Matrix

Published API Support Areas

Cultivator Operations Processor Operations Dispensary Operations State Internal Functions Other Functions Not Listed

3rd Party Software API Methods 3rd Party

Software API Methods 3rd Party Software API Methods 3rd Party

Software API Methods 3rd Party Software API Methods

Fictitious examples

Green Giant Systems

GreenRush Crop Management

Secure Web Services (Certified)

Secure Web Services (vendor maintained)

Kwickbookz (Accounting Software)

Secure Web Services (in Production)

King of Kash Registerz (Point of Sale Software)

Secure XML Microsoft Office

XML, CSV, XLS

Process

Reporting & Compliance

Financial

Sale

Other

The State offers the following brief descriptions for API Support Areas:

Process: software that is designed to support a Licensees execution of internal business or operational processes (e.g., cultivator operations, harvest planning, production management, accounting software and the like);

Reporting and Compliance: software required to support the gathering, aggregation and reporting to the State (directly, via interface or integration) data as required under State Law, Rules and Policy;

Financial: software used in the development of financial, cash, taxation and other fiscal reports within a Licensees business (e.g., accounting/bookkeeping software, payroll, time management, etc.);

Sale: those systems and software designed to facilitate the legal sale of products between Licensees and to Patients (e.g., inventory management, point of sale, payment and revenue reporting, cash management); and

Other: Other software elements that, in the opinion of the Offeror in consideration of other 3 rd Party software, is an aid to the Marijuana industry that is or has been integrated with the proposed solution that may be of interest to the State.

The State requests Offerors limit their responses to “in live use” as opposed to theoretical, hypothetical or comments of a marketing nature.


3. Cultivator Process: Monitoring, Tracking and Compliance Requirements

3.1. General Overview

The Ohio Department of Commerce (Commerce) is responsible for the licensing, administering and the ongoing oversight and enforcement of rules and policies pertinent to Cultivators in Ohio’s Medical Marijuana Program. In general Commerce is responsible for: cultivator operations, testing, destruction, transporting medical marijuana and destruction of waste (marijuana and non-marijuana) associated with the cultivation process. Additionally, monitoring of all Cultivator operations with respect to diversions in and out of the process will be monitored by Commerce.

3.2. Sizing Considerations

The State offers the following volumetric information to assist Offerors in sizing the scope, scale and complexity of the work. Offerors are to note that specific State rules governing this sizing are subject to change , but this sizing will be used as an objective basis of comparison of Offeror solutions.

Sizing Consideration Sizing Value Additional Considerations

Ohio CultivatorsUp to 12 Level I cultivators

and up to 12 Level II cultivators General Alignment: Designated territories identified by the State Located as to comply with State, County and Municipal laws and statutes

3.3. Cultivator Monitoring and Tracking Requirements

The Offeror must propose, and as Contractor design and implement the following requirements. The system must:

Identify and track of all viable plants from origin (e.g., seed, clone, bio material) via verifiable tracking mechanism utilizing RF ID tags or unique bar code information to be determined by the State;

Track all plant types, including but not limited to: plant strain, plant source, unique plant identifier, product name, product type, product identifier, and units of measure.

Track all viable cloned and germinating plants by count / variety until moved to the vegetative growth step or destruction (as applicable), where the plants will be assigned a Unique Plant Identifier;

Track plant specific inventory items including, but not limited to, the following data elements: strain, plant ID, status in production cycle, location within plant facility, date, and “added by” information that uniquely identifies a member of the Cultivators working staff;

Track plant growth stages including but not limited to: seedling, clone, or mother plant and through growth stages including: Propagation (Germinating/Cloned) Plants; Plants in Vegetative Growth; and Flowering Plants;

Track the transfer of plant inventory between growth stages and locations within the Cultivation facility including, but not limited to transfer date, transfer to location, order number, list of plants transferred and the Cultivators working staff member associated with each move of the plants within the Cultivation facility;

Provision for the tracking of the application of fertilizers, pesticides, and any other compounds and/or products applied to each individual plant;

Track weights of all harvested plant material at each stage of the harvesting and processing of plant products inclusive of wet and dry weights and track data elements including, but not limited to: strain, product name, product type, product ID, batch number, Unique Plant Identifier, quantity yielded, and units of measure;

Track the packaging of harvested Marijuana and track data elements including, but not limited to: strain, product name, product type, product ID, batch number, Unique Plant Identifier, net package weight and units of measure;

Identify all plants that comprise a batch as individual plants and as a group;


Track both “wet weight” and “dry weight” (net of water loss resulting from the drying and curing process) of all plants, individually and as a batch;

Identify all batches that are required by the State to be tested for adulteration (e.g., harmful pesticides, fungicides/herbicides/insecticides/antimicrobials and other elements introduced during the cultivation process);

Identify batches that must be laboratory tested for consistency and potency and sequestration of such batches until such time as the State releases these batches pending the outcome of such testing;

Track all batches and individual plants that fail either of adulteration or potency testing that result in disposal and destruction of all elements associated with the harvest due to these failures;

Track Cultivator excess product that will not progress to latter stages of the Cultivation process inclusive of waste, spoiled materials or otherwise unusable plant materials by weight;

Track the disposal and destruction of all viable and non-viable plant materials and Cultivator excess product that is verifiable through independent means by weight;

The Offeror must propose, and as Contractor design and implement the following requirements. The system must capture via user interface or automated data interface (Web Service, XML/CSV) input of inventory transaction information of Cultivator data including, but not limited to, the following Cultivator-facing functions:

View/Search Inventory: System must include search functionality to allow users to search for inventory items (regardless of Cultivation process or disposition) by entering a set of search criteria parameters and display the results in tabular form;

Add/Edit Location: System must allow input of user defined inventory locations within a Cultivator’s operation, including but not limited to: germination and clone room(s), vegetative/growth room(s), flowering room(s), trimming room(s), curing room(s), packaging area(s), quarantine area(s), and other storage area(s).

Adjust (Dispose) Inventory: System must include input of inventory adjustments, such as disposal, wastage, and theft. Data must include but be limited to: date of adjustment, adjustment type, plant or other product ID, batch number, batch number, weight/quantity, authorized Cultivator worker and explanation for the Adjustment/Disposal.

Quality Assurance: The System must record transfers of small amounts (State determined under rules) of marijuana product to a laboratory for testing. Data elements to be tracked must include at a minimum: date/time of transfer, transferred by, order number, source license number, laboratory name, laboratory license number, and list of transferred products including product ID, product name, batch number, weights and quantity;

Quality Assurance test results for any Batch must be accessible by the State and any Licensee within the chain of custody related to the plant and batch and must allow the State and Licensees to search, upload, and download test results in a PDF, Microsoft Word or Microsoft Excel compatible format ; and

Creation of Transportation Logs including but not limited to, the following data elements: ship from name, license number and route description; destination address, destination name, license number, address; and shipment product description, product ID and Batch number, quantity and units of measure, gross and net weights. Transportation logs must be used as shipping documents for transfers between locations within an organization or sales between Licensees across the supply chain;

3.4. Cultivator Compliance Requirements

The Offeror must propose, and as Contractor design and implement the following requirements:

Ensure that all persons that access the system including data viewers and data create/modifiers have unique login/password information in keeping with the requirements of Supplement 3 and all user access for create, read, update and delete operations for a Cultivator staff member accessing the system is logged;


Provide for the tracking of all raw materials used in conjunction with the cultivation process inclusive of pesticides and fertilizer materials as to support the analysis by the State of medical marijuana source products for adulterants or materials deemed harmful to human use;

Provide for identification of batches identified by the State for testing for potency including: tetrahydrocannabinol (THC), tetrahydrocannabinolic acid (THCA), cannabidiol (CBD), cannabidiolic acid (CBDA), pesticides, fertilizers mycotoxins, microbial contaminants, and other materials as defined by state rules, as well as association of these batches to batch disposition (e.g., “approved for release”, “sequestered/held” or “ordered destroyed”);

Provide for the transfer of plant materials within a Cultivator Location within a Cultivator’s operation that allows and tracks transfers of Marijuana products and plants between locations defined and allowed within the Cultivator operation. Inputs must include source location, destination location, transfer date, transferred by, list of transferred items, quantity, and reason for transfer and licensed person performing such transfers; and

Allow a State investigator or auditor to seize or sequester within the System any plant or harvest materials that are not properly accounted for by unit, weight, measure, testing status or other elements that do not comply with State laws and rules governing Cultivators and indicate such events within the system.

3.5. Cultivator Batch Testing Requirements


For any batch (collection of plants) identified by the State to be tested, the system must mark such plants as “held for testing” and not permit any elements of this batch to be released to processing or destroyed until such time as testing is successfully completed for the element(s) of the batch;

For all batch(es) that fail laboratory testing or are otherwise unusable, the system, upon State agreement of such a condition, must mark all elements of the batch for Destruction (see Section 3.8 for additional requirements).

3.6. Industry Facing File/Web Services and Application Programming Interfaces (API) Requirements

The Offeror must propose, and as Contractor design and implement the following requirements that are designed to assist and support Cultivators in the use and interfacing with the State’s system via online (web based), application (custom or 3rd party developed) or other programmatic access (via common PC based tools such as Microsoft Office):

Provide a secure web-based/browser user interface for data entry, display, and reporting by Marijuana Licensees;

Provide secure web services for data submittal from Licensee systems of all Marijuana plant, Marijuana product inventory, retail sale transaction data, and tax reports based upon XML based open standards;

Provide secure file services for data submittal from Licensee systems of all Marijuana plant, Marijuana product inventory, retail sale transaction data, and tax reports based upon CSV based open standards;

Provide validation and response feedback for validation checks on Licensee data submitted via the web service (e.g., data received, data validated, data rejected) with corresponding success or error messages that assist the Licensee in remediating and resubmitting data to the State;

Include a certification program to ensure that Licensees can demonstrate the correct use of the web service interface before they are authorized to submit data to the System directly or via certified third-party industry applications;

Provide licensees the ability to verify batch disposition information (e.g., “approved for release”, “sequestered/held” or “ordered destroyed”) for any plant, group of plants, batch, harvest or shipment based upon the results of State testing; and


Provide a test site (non-production, developmental purposes) for Licensees to submit test data to the State System administrator to verify Licensee capability to submit test data via the web or file-based service.

3.7. State Oversight, Regulatory and Reporting Requirements

The Offeror must propose, and as Contractor design and implement the following Reporting and Alert requirements:

The System must support the inclusion of thresholds that will be provided by the State or utilize industry best/standard practice to detect “out-of-tolerance” of Cultivator based values that result in the origination of an Alert as (minimally) a system generated email of such conditions and (as an option) an Alert to State personnel responsible for the oversight of Cultivator operations. These alerts must be aligned with every functional requirement (marked with a ) in Section 3.3.

The System must support the periodic export of all data in a commonly readable format (e.g., CSV or XML) as it relates to all Cultivators and all history maintained for use by the State to perform data and analytical review of Cultivator operations using State specific tools and techniques.

3.8. Secure Destruction of Product Requirements

The Offeror must propose, and as Contractor design and implement the following Product Destruction requirements:

For any plant, batch or element of the cultivation process that requires destruction of plant material for any reason as required by the Cultivator, the system must identify any and all such elements and record the reason(s) for destruction as well as all associated plant(s) or plant materials to be included in the destruction batch as well as the applicable wet and dry weights of such products, available testing results and other artifacts as associated with the batch(es) to be destroyed;

For any plant, batch or element of the cultivation process that requires destruction of plant material for any reason as required by the State, including failure of a laboratory test, the system must identify any and all such elements and, to the extent possible record the reason(s) for destruction as well as all associated plant(s) or plant materials to be included in the destruction batch as well as the applicable wet and dry weights of such products, available testing results and other artifacts as associated with the batch(es) to be destroyed;

For both of the above requirements, should any batch be identified for destruction, create a record of destruction and (for those product elements to be destroyed), include weights and identifying details of such item(s) to be destroyed.

3.9. Transport of Approved Cultivated Products – Requirements

The State will utilize licensees for the transport of Marijuana-based materials and products between licensees within the State (e.g., Cultivators, Testing Laboratories, Processors and Dispensaries). For purposes of convenience, these companies are referred to as “Transporters” within this Supplement.

The Offeror must propose, and as Contractor design and implement the following Product transport requirements:

For all products to be shipped to either a State approved testing lab or processor, the system must generate a Transportation Log, and for each package within a shipment, shipping details inclusive of: shipping date/time stamp; source address; Cultivators staff member ordering the shipment; destination address; Transporter name; complete shipping details and contents (batch, package, contents); shipping weight (gross – all packages within a shipment) and tare weight (net product weight for each element of the shipment as well as net weights for the entire shipment) for each package and the entire shipment;

Such Transportation Log will itemize the contents of a shipment - in total, by element and by contents (e.g., 100lbs gross weight, 90lbs net product weight, 10 packages, each of 10lbs gross weight and 9lbs net product weight) and must be constructed and printed in accordance with State requirements;


For each shipment, the system must generate a Transportation Log to the shipper (i.e., Cultivator), Transporter , recipient (i.e., State Testing Laboratory or State Licensed Processor) based on State determined conditions/exceptions (via an Alert or Report as applicable);

Should a receiving licensee, for any reason, be unable or unwilling to accept a shipment from a Cultivator (e.g., damaged materials, inconsistent weights or other circumstances surrounding a shipment), the receiving licensee must be able to reject a shipment in full and not take possession of a shipment. The system must reject the shipment and generate a notification (via an Alert or Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the rejection; and

Upon indication of receipt of goods from a Transporter acknowledging shipment contents (as verified using the provided elements of the aforementioned Transportation Log and shipment/package elements) the system must indicate the product(s) are no longer in possession of the Cultivator and indicate the products are in possession of the receiving licensee.


4. Product Processor: Process Monitoring, Tracking and Compliance Requirements


Marijuana Processors are responsible for the processing of medical marijuana into human consumable forms as allowed by Ohio State Law. In general, these forms include vaporization products, oils, edibles, plant materials and patches. Products produced must track all Marijuana-based ingredients as well as other elements of the overall production process that are designed to ensure products available to the public are tested for quality, potency and safety.



Sizing Consideration Sizing Value

State Licensed Processor Operations

(Pending: subject to rules development)

State Licensed Processor Workers No Limit

4.3. Product Processor Monitoring Requirements

4.4. Product Processor Transport Verification and Acceptance Requirements

The Offeror must propose, and as Contractor design and implement the following Product Processor requirements:

For each shipment for which delivery is attempted by a Transporter, and using an independently system generated copy of the Transportation Log by the Transporter, the system must support an acceptance process that will systematically:

Record the arrival time of the Shipment; Verify the Transportation Log records that itemize the contents of a shipment - in total, by element and by contents; Verify the gross and net weight of every package against the shipping manifest/bill of lading; Identify and log any erroneous or suspicious elements within the shipment (e.g., inconsistent weights, number(s) of packages, signs of tampering); Allow the Product Processor to record and report any deviations from elements contained in the Transportation Log (e.g., different firm, variances in shipment, suspicious arrival times or circumstances, variances in weights/measures, signs of tampering and the like);

Should a Processor, for any reason, be unable or unwilling to accept a shipment from a Transporter (e.g., damaged materials, inconsistent weights or other circumstances surrounding a shipment), the Processor must be able to reject a shipment in full and not take possession of a shipment. The system must reject the shipment and generate a notification (via an Alert or Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the rejection; and

Upon indication of receipt of goods from a Transporter acknowledging shipment contents (as verified using the provided elements of the aforementioned Transportation Log and shipment/package elements) the system must indicate the product(s) are no longer in possession of the Transporter and indicate the products are in possession of the Processor or a Testing Lab as applicable.


4.5. Product Processor Raw Materials Inventory Update / Tracking Requirements


Receive and Track Inventory – Marijuana Products: System must include functionality to allow input, tracking, reporting, and storage of information about plant materials received at Processor facilities from Cultivators. Data input may include, but is not limited to, the following: Receipt Date, Received By, Source Licensee Name, Source License Number, Order Number, Items shipped and/or received information; Product ID, Product Name, Batch Number, Batch Number, Weight, and Quantity.

Receive and Track Inventory – Non-Marijuana Products: System must include functionality to allow input, tracking, reporting, and storage of information about non-marijuana products (e.g., additives, oils, food products and other elements used in the processing of products for human use) received at Processor facilities from third parties. Data input may include, but is not limited to, the following: Receipt Date, Received By, Source Name, Source identifying details, Order Number, Items shipped and/or received information; Product ID, Product Name, Batch Number, Weight, and Quantity.

Add/Edit Product Type: System must track input of product types, including but not limited to: plant strain, extract type, infused product types, plant source (Cultivator origin), plant batch, shipment and non-marijuana products used in the production of finished products for human use and track the following fields at a minimum: Product ID, Product Name, Batch or Lot Number, Weight, and Quantity.

For the avoidance of doubt, all product elements, marijuana or non-marijuana, that will result in a product for human use must be tracked for all phases of production.

Creation of a Work Order/Product Lot: System must track all products to be composited into new products. Inputs must include, but not be limited to: product type, product ID, units of measure of product yield, number of units yielded, component item information for all items containing marijuana products; and non-marijuana elements including product ID, product name, lot number, and quantity. All product inputs must be traced back to their origin; the inventory of each product lot is tracked by the Plant ID and subsequent Product ID and a unique Lot Number created for each new product lot.

Transfer to different location within Processor facility: System must track all transfers of Marijuana components and products between locations defined within a Processor. The system must track all of the following elements including but not limited to: source location, destination location, transfer date, transferred by, time(s) of transfer, list of transferred items, quantity, and reason for transfer.

4.6. Product Processor Waste Materials Inventory Tracking / Destruction Requirements


For any plant, batch, lot byproduct or element of the production process that requires destruction of marijuana product material for any reason as required by the Processor, the system must identify any and all such elements and, to the extent possible record the reason(s) for destruction as well as all associated production materials to be included in the destruction batch as well as the applicable weights of such products, available testing results and other artifacts as associated with the elements or batch(es) or lot(s) to be destroyed;

For any element of the production process that requires destruction of marijuana product material for any reason as required by the State, including failure of a laboratory test, the system must identify any and all such elements and, to the extent possible record the reason(s) for destruction as well as all associated marijuana product materials to be included in the destruction batch as well as the applicable weights of such products, available testing results and other artifacts as associated with the elements or batch(es) or lot(s) to be destroyed;


For both of the above requirements, should any batch or lot be identified for destruction, create a certificate of destruction and (for those product elements to be destroyed) a Transportation Log containing the contents (see Section 5 for Logistics Requirements), weights and identifying details of such item(s) to be destroyed; and

The system must update all inventory records to reflect product(s), element(s) and components destroyed.

4.7. Finished Product Identifier Assignment Requirements

The State will make available a listing of approved Product Identifiers for all permissible Medical Marijuana products that will uniquely identify each brand of products by dose and within the following forms:

Oils Tinctures Plant Material Edibles Patches Other forms as approved by the Ohio State Board of Pharmacy under section 3796.061 of Ohio Revised Code.

Offerors are advised that this information will be accessed and utilized by the Ohio Automated Rx Reporting Systems (OARRS - https://www.ohiopmp.gov/) and Patient Registry (APPRISS) as managed by the State Board of Pharmacy. Identification of these products must include appropriate interfaces to OARRS/APPRISS and S2S system recording of:

Product / Trade Name

An eleven (11) digit State Assigned Product Identifier, beginning with the letter “M” that must uniquely identify the product that is shared via interface with OARRS;

A system assigned inventory identifier (i.e., Product, Batch, Manufacture Data, Processor and linkage to source materials as otherwise tracked in the system that identify cultivator, batch, harvest and plant material)

Net weight information (package and dosage);

Information as tested (tetrahydrocannabinol (THC), tetrahydrocannabinolic acid (THCA), cannabidiol (CBD), and cannabidiolic acid (CBDA)) and other materials as determined by state rules;

State Required Disclosures and Warnings;

4.8. Product Processor Finished Products Inventory Update / Tracking Requirements


Identification and tracking of all Finished Products from source (e.g., cultivator elements including: seed, clone, bio material and non-marijuana elements) via verifiable tracking mechanism utilizing RF ID tags or unique bar code information (as determined by the State) and for all Finished Products, including but not limited to: product name, product type, product ID, weights units of measure, and potency (as tested);

Addition of Product specific inventory items including, but not limited to, the following data elements: manufacture date, batch, testing date, testing results (if applicable), status in production cycle, date, and “added by” information that uniquely identifies a member of the Processors’ workers;

Tracking the transfer of all Product inventory between Production stages and locations within the Processor facility including, but not limited to transfer date, transfer to location, order number, list of Products transferred and the Processor staff member associated with each move of the plants within the Processor facility;

Tracking the packaging of medical marijuana products and tracking of data elements including, but not limited to: product name, product type, product ID, Unique Batch, Lot and Product Identifiers, net package weight, units of measure and potency;


https://www.ohiopmp.gov/

Identification of Production batches or lots that are required to be laboratory tested for adulteration (e.g., harmful ingredients) including identification of Production that must be laboratory tested for consistency and potency and sequestration of such batches or lots until such time as the State releases these Production batches or lots pending the outcome of such testing;

Tracking of Processor excess product that will not progress to latter stages of the Processor process inclusive of waste, spoiled materials or otherwise unusable materials by weight;

Tracking of the disposal and destruction of all waste, unused materials and excess product that are verifiable through independent means by weight, batch, source or RFID/barcode;

Capture via user interface or automated data interface (Web Service, XML/CSV) input of inventory transaction information of Producer, Processor and Retailer Licensee data including, but not limited to, the following Cultivator-facing functions:

View/Search Inventory: System must include search functionality to allow users to search for inventory items (regardless of Production process or disposition) by entering a set of search criteria parameters and display the results in tabular form;

Add/Edit Location: System must allow input of user defined inventory locations within a Processor operation, including but not limited to: marijuana material processing room(s), finished product production area(s), packaging area(s), testing/sequestration/quarantine area(s), inventory warehouse shelves, and other storage area(s).

Adjust (Dispose) Inventory: System must include input of Processing inventory adjustments, such as disposal, wastage, and theft. Data input may include but is not limited to: date of adjustment, adjustment type, plant or product or other product ID, batch or lot number, weight/quantity, authorized Processor worker and explanation for the Adjustment/Disposal.

Quality Assurance: The System must record transfers of small amounts (State determined under rules) of finished marijuana product to a laboratory for testing. Data elements to be tracked must include at a minimum: date/time of transfer, transferred by, order number, source license number, laboratory name, laboratory license number, and list of transferred products including product ID, product name, batch number, weights and quantity;

Quality Assurance test results for any Batch or Lot must be accessible by the State and any Processor within the chain of custody related to a production batch and must allow the State and Processors to search, upload, and download test results in a PDF, Microsoft Word or Microsoft Excel compatible format; and

Creation of Transportation Logs, including but not limited to, the following data elements: ship from name, license number and route description; destination address, destination name, license number, address; and shipment product description, product ID and batch or lot number, quantity and units of measure, gross and net weights. Transportation Logs will be used as shipping documents for transfers between locations within an organization or sales between Licensees across the supply chain.

4.9. Product Processor Compliance Requirements


Ensure that all persons that access the system including data viewers and data create/modifiers have unique login/password information in keeping with the requirements of Supplement 3 and all user access for create, read, update and delete operations for a Processor worker accessing the system is logged;

Provide for the tracking of all materials used in conjunction with the Production process inclusive of Marijuana and non-Marijuana product as to support the analysis by the State of all medical marijuana products for human use;

Provide for identification of finished product batches identified by the State for testing for potency including: (tetrahydrocannabinol (THC), tetrahydrocannabinolic acid (THCA), cannabidiol (CBD), and cannabidiolic acid


(CBDA)) and other non-marijuana materials as determined by the State rules used in the production process as well as association of product batches to product batch disposition (e.g., “approved for release”, “sequestered/held” or “ordered destroyed”);

Provide for the transfer of finished product materials within a Processor Location (e.g., warehouse) within a processing operation that allows and tracks transfers of Marijuana products between locations defined and allowed within the processor operation. Inputs must include source location, destination location, transfer date, transferred by, list of transferred items, quantity, and reason for transfer and licensed person performing such transfers; and

Allow a State investigator or auditor to seize or sequester within the System any production or finished product materials that are not properly accounted for by unit, weight, measure, testing status or other elements that do not comply with State laws and rules governing Processors and indicate such events within the system.

4.10. Transport of Finished Products – Requirements

The Offeror must propose, and as Contractor design and implement the following Finished Product Transport requirements:

For all products to be shipped to a State approved Testing Facility or Dispensary, the system must generate a Transportation Log, and for each package within a shipment, shipping details inclusive of: shipping date/time stamp; source address; destination address; Transporter name; complete shipping details and contents (batch, package, contents); shipping weight (gross – all packages within a shipment) and tare weight (net product weight for each element of the shipment as well as net weights for the entire shipment) for each package and the entire shipment and routing / driving information;

Such Transportation Log must itemize the contents of a shipment - in total, by element and by contents (e.g., 100lbs gross weight, 90lbs net product weight, 1,000 packages, each of 0.1lbs gross weight and 0.09lbs net product weight) and must be constructed and printed in accordance with State requirements;

For each shipment, the system must generate a Shipment Notification to the shipper (i.e., Processor), transporter, recipient (i.e., State Licensed Testing Laboratory or Dispensary) and generate a notification to State Law Enforcement personnel based on State determined conditions/exceptions (via an Alert or Report as applicable);

Should a receiving licensee, for any reason, be unable or unwilling to accept a shipment from a Processor (e.g., damaged materials, inconsistent weights or other circumstances surrounding a shipment), the receiving licensee must be able to reject a shipment in full and not take possession of a shipment. The system must reject the shipment and generate a notification (via an Alert or Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the rejection; and

Upon indication of receipt of goods from a Transporter acknowledging shipment contents (as verified using the provided elements of the aforementioned Transportation Log and shipment/package elements) the system must indicate the product(s) are no longer in possession of the Processor and indicate the products are in possession of the receiving licensee.


5. Transport / Logistics: Process Monitoring, Tracking and Compliance Requirements


The State has identified at least two elements of the Medical Marijuana program that will require the support of a Transport capability between licensees that will interact with the S2S system in the course of performing contracted responsibilities with the State, they are:

1. Transport of Marijuana Materials between Licensees (i.e., Cultivators, Processors, and Dispensaries); and

2. Transport of Marijuana Materials between a Licensee (i.e., Cultivators and Processors) and a Testing Laboratory.



Sizing Consideration Sizing Value

State Licensed Cultivation Locationsup to 12 Level I cultivatorsup to 12 level II cultivators

State Licensed Processor Operations To be Determined by the State

5.3. Logistics/Transport Mobile Application/Access Requirements

Due to the nature of Transport operations, there are some Mobile-specific elements that are required by the State. The Offeror must propose, and as Contractor design and implement the following Finished Product Transport requirements:

The Offeror must provide either of: a dedicated Mobile application for at least one current supported version of Google Android or Apple iOS that (pending network coverage); or a fully Mobile-responsive web-application that is designed and implemented to facilitate all required Transport requirements contained in this Section;

This application must be capable of verification of all shipments – in part and in total – as evidenced by the Transportation Log through: replication of the Transportation Log using the S2S system data as to provide an additional/objective source of comparison with any Transportation Logs produced by any of: a Cultivator, Testing Laboratory, Processor or Dispensary facility;

Indicating Acceptance of a shipment including date/timestamp, driver, Licensee (e.g., Cultivator, Lab, Processor, Dispensary) information as well as recording images (as relevant) pertinent to the shipment, shipper and other elements as required during the logistics process;

Indicating Rejection of a shipment including date/timestamp, driver, Licensee (e.g., Cultivator, Lab, Processor, Dispensary) information as well as recording images (as relevant) pertinent to the shipment, shipper and other elements as required during the logistics process; and

This application must indicate Delivery of all shipments as evidenced by the Transportation Log through: replication of the Transportation Log using the S2S system data as to provide an additional/objective source of comparison with any Transportation Logs produced by any of: a Cultivator, Testing Laboratory, Processor or Dispensary facility.


5.4. Logistics/Transport Acceptance and Tracking Requirements

The Offeror must propose, and as Contractor design and implement the following Finished Product Transport acceptance and tracking requirements:

For all products to be shipped to a State approved Testing Laboratory or Dispensary, the system must generate a Transportation Log – for the Transporter, and for each package within a shipment, shipping details inclusive of: shipping date/time stamp; source address; destination address; transporter name; complete shipping details and contents (batch, package, contents); shipping weight (gross – all packages within a shipment) and tare weight (net product weight for each element of the shipment as well as net weights for the entire shipment) for each package and the entire shipment and routing / driving information;

Such Transportation Logs must itemize the contents of a shipment - in total, by element and by contents (e.g., 100lbs gross weight, 90lbs net product weight, 1,000 packages, each of 0.1lbs gross weight and 0.09lbs net product weight) and shall be constructed and printed in accordance with State requirements;

For each shipment, the system must generate a Shipment Notification to the shipper (i.e., Processor), Transporter and the recipient (i.e., State Testing Laboratory or State Licensed Dispensary) and generate a notification based on State determined conditions/exceptions (via an Alert or Report as applicable);

Should a receiving licensee, for any reason, be unable or unwilling to accept a shipment from a Processor (e.g., damaged materials, inconsistent weights or other circumstances surrounding a shipment), the Transporter shall be able to reject a shipment in full and not take possession of a shipment. The system will reject the shipment and generate a notification (via an Alert or Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the rejection; and

Upon indication of receipt of goods from a Transporter acknowledging shipment contents (as verified using the provided elements of the aforementioned Transportation Log and shipment/package elements) the system must indicate the product(s) are no longer in possession of the Processor and indicate the products are in possession of the receiving licensee.

5.5. Logistics/Transport Compliance Requirements

The Offeror must propose, and as Contractor design and implement the following Finished Product Transport acceptance and tracking requirements:

The Mobile application must, via data maintained in the S2S system produce to any authorized agency within the State: a complete Transportation Log including the origin and destination details of the shipment; names and registration details of the Transporter and workers transporting the shipments; license plate and vehicle details for the vehicle transporting the shipment; actual departure date/time, route and scheduled arrival date/time; and planned and actual delivery routes including scheduled and unscheduled deviations and distances;

Upon completion of the delivery of the shipment, the complete Transportation Log including the origin and destination details of the shipment; names and registration details of the Transporter and workers transporting the shipments; license plate and vehicle details for the vehicle transporting the shipment; actual departure date/time, route and actual arrival date/time; and planned and actual delivery routes including scheduled and unscheduled deviations and distances.


6. Dispensary Process: Monitoring, Tracking and Compliance Requirements


Dispensary operations represent:

The S2S system (requirements in this Supplement) where product is dispensed;

A registered Patient that has proof of identity and recommendation from a Doctor (as verified using State systems) at the point of sale; and

Methods to pay for Marijuana-based products and financial reporting and management of the overall Marijuana business from a cash/payment reporting, monitoring and reconciliation perspective.

These areas represent: the product supply chain; the chain of patient, identity, recommendation; and reconciliation and reporting of payment and payment management elements in the context of distribution of products. Therefore, integration of these three elements at the point of dispensing is a critical element of the State’s overall requirements.



Sizing Consideration Sizing ValueLicensed Dispensaries To Be Determined by the State under Rules Development

Licensed Dispensary Workers To Be Determined by the State under Rules Development

6.3. Patient and Recommendation Verification, Integration, and Recording Requirements

The Offeror must propose, and as Contractor design and implement the following Patient Verification, Integration and Recording requirements:

Verification via an integration with the State’s Patient Registry (APPRISS) using Patient presented credentials (proof of identity and Patient ID) that the Patient is authorized to purchase Marijuana Products;

Verification with the State’s Prescription Monitoring System (OARRS) and Patient Registry of the Doctor Recommendation(s) inclusive of allowable product(s), dosage and refill information; and

Verification that the requested Marijuana product(s) are on hand in the required amount(s) and dosage/potency levels using Dispensary inventory as tracked by the S2S system (see Section 6.5 for additional details).

6.4. Dispensing of Marijuana Product - Tracking Requirements

The Offeror must propose, and as Contractor design and implement the following Patient Verification, Integration and Recording requirements:

Recording the following Patient, Recommendation and Product related dispensing information:

Dispensary Worker details (e.g., “sold by”); Transaction date/time stamp information associated with the Sale; Patient identifying details (e.g., patient number, but not personal details), minimally the State issued Patient Identification details and the form of proof of identity (e.g., “Ohio Driver’s License Presented”); Product(s) sold details including trade name, quantity, dosage/potency, refill information; and


Other Data Elements as required by the State. Recording of the transaction in conjunction with data obtained from the State Prescription Monitoring System as

to the completion of the Transaction inclusive of:

Transaction date/time stamp information associated with the Sale; Patient identifying details, minimally the State issued Patient Identification details and the form of proof of identity (e.g., “Ohio Driver’s License Presented); Product(s) sold details including trade name, quantity, dosage/potency, refill information; and Other Data Elements as required by the State.

6.5. Inventory Management Functions

The Offeror must propose, and as Contractor design and implement the following Dispensary Inventory Management requirements:

Shipment Verification and Acceptance

For all products to be shipped to a State Licensed Dispensary, the system must generate a Transportation Log – to the Dispensary, and for each package within a shipment, shipping details inclusive of: shipping date/time stamp; source address; destination address; Transporter; complete shipping details and contents (batch, package, contents); shipping weight (gross – all packages within a shipment) and tare weight (net product weight for each element of the shipment as well as net weights for the entire shipment) for each package and the entire shipment and routing / driving information;

Should a State Licensed Dispensary, for any reason, be unable or unwilling to accept a shipment from a Processor (e.g., damaged materials, inconsistent weights or other circumstances surrounding a shipment), the Dispensary must be able to reject a shipment in full and not take possession of a shipment. The system will reject the shipment and generate a notification (via Alert or Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the rejection; and

Upon indication of receipt of goods from the Dispensary acknowledging shipment contents (as verified using the provided elements of the aforementioned Transportation Log and shipment/package elements) the system must indicate the product(s) are no longer in possession of the Transporter and indicate the products are in possession of the Dispensary.

The system must update the inventory of product(s) available in the Dispensary based on acceptance of a shipment and record:

Date/Timestamp of the delivery attempt (e.g., “Transporter arrived on premise at mm/dd/yyyy hh:mm”);

Date/Timestamp of the Acceptance or if required, Rejection of the Shipment. In cases of rejection of product, the circumstances of the rejection must be recorded by the system. In addition, the Dispensary worker details who performed the shipment must be recorded by the system;

Inventory Management

Upon receipt and Dispensary acceptance of a shipment, the system must update the inventory of all product(s) on hand at the Dispensary and record the location(s) within the Dispensary (e.g., shelf location);

Allow recording of relocation of product(s) between location(s) within the Dispensary for shop/shelf optimization;

Record the location(s) of all Quarantined, Recalled, Returned or Suspended products or products otherwise “not for sale”;

Upon sale of any product(s) the system must update the inventory of all product(s) on hand at the Dispensary (e.g., decrement the available products on hand);


Record the reduction of available inventory and arrange for the return (or if applicable, destruction) of any State approved unsold or unsaleable product(s) to State Approved Licensees (e.g., Cultivators, Processors, Testing Laboratories) via the Transporter; and

Allow for the adjustment of inventory due to State approved reasons and in concert with the approval of the State and generate a notification (via an Alert of Report as applicable) to the State as well as record the reason(s) and circumstance(s) of the adjustment for State review and approval. Following such approval, the Dispensary worker details who accepted the shipment must be recorded by the system and include the date/time stamp, circumstances and State approver of such adjustments.

State Quarantined, Recalled/Suspended Products

The system must allow the State to quarantine, recall or otherwise suspend the sale of products at any or all Dispensaries in the State.

Upon such a condition, the system must record the reduction of available inventory and arrange for the return (or if applicable, destruction) of any State identified product(s) to State Approved Licensees (e.g., Cultivators, Processors, Testing Laboratories or Dispensaries) via a Transporter;

Upon such a condition, to alert any dispensary customers who purchased an applicable product of the recall or notice via the Patient Registry (API with the S2S system);

Upon such a condition, the system must “lock” such inventory and prevent its sale or distribution, removal, transport or destruction until such time as the State determines and indicate such status within the system; and

Should the State determine that such products may be sold following the resolution of such a condition, the system must allow the State to remove the “locked” inventory, and increase quantities available for sale as per the “unlocked” inventory.

Inventory Ordering/Re-Ordering

The system must monitor Marijuana products and ensure that State required stocking levels are maintained and provide product ordering reports based on historical patient demand as an aid to Dispensaries in preparation of orders from Cultivators and Processors.

Such orders must be modifiable (up or down) by Dispensaries prior to finalization and submission to Cultivators and Processors for fulfillment, but nonetheless shall not exceed or fall short of State required levels.

6.6. Dispensary Point of Sale: Tracking and Compliance Requirements

The State anticipates that Dispensaries will procure and maintain point of sale including payment acceptance, accounting and other “retail” equipment associated with the Sale of products from the Dispensary, however the Offeror must propose, and as Contractor design and implement the following Dispensary Point of Sale integration requirements:

The S2S system must accept (via a mutually agreeable and published API) the details of payment received from Patients including all State approved payment methods that may include: Cash; Credit/Debit Cards; Balance Cards; ePayments or other State approved forms of payment;

The S2S system must accept (via a mutually agreeable and published API) the details surrounding payment received including sale price, date/time stamp, Dispensary worker completing the transaction, applicable taxes, discounts and veteran and/or indigent pricing.

The S2S system must produce a Sales Register for all sales completed during a Dispensary Selected date/time period for reconciliation purposes to State required payment and financial reconciliation and reporting requirements and Point of Sale sufficient to balance all payments including cash (generally at the completion of a day’s sales).


7. State Systems: Integration Requirements

7.1. Overview

The State maintains a variety of Systems that will require direct integration with the S2S software via interfaces and regular sharing of data between a State system and the S2S software. Additionally, while not direct integration requirements the State maintains ancillary systems and processes that may require periodic exchange of data between the S2S software and State system/process. They are:

Ohio eLicense System: The State has developed a licensing platform designed to support the State’s more than 750 licenses based on Salesforce.com.

Specific to the Medical Marijuana program, the State Medical Board has implemented the licensure/certification of Medical Professionals within the eLicense platform. Further, subject to fiscal approval, the Ohio Department of Commerce and Pharmacy Board may implement (over the course of calendar 2017) within the State eLicensing platform the required Licenses as to implement the Medical Marijuana Program. Offeror proposed integrations with the Ohio eLicense System must follow supported Salesforce.com integration methods and utilize secure web-services wherever possible.

The State will be responsible for the implementation of Marijuana-specific endorsements within the eLicensing platform, and as an integration/validation point the S2S system will require the verification of such licenses or endorsements as part of the administration of the Medical Marijuana program in the State.

Ohio Automated Rx Reporting System (OARRS): The State of Ohio Board of Pharmacy created Ohio’s Prescription Drug Monitoring Program (PDMP), known as the Ohio Automated Rx Reporting System (OARRS) to address the growing misuse and diversion of prescription drugs. OARRS collects information on all outpatient prescriptions for controlled substances dispensed by Ohio-licensed pharmacies and personally furnished by licensed prescribers in Ohio. Drug wholesalers are also required to submit information on all controlled substances sold to an Ohio licensed pharmacy or prescriber. The data is reported every 24 hours and is maintained in a secure database. Dispensary (pharmacy) Integrations with OARRS are via PMP Gateway software provided by APPRISS at http://www.appriss.com/pmpgateway.html and patient level information at http://www.appriss.com/narxcheck.html. General integration information is available at https://www.ohiopmp.gov/Portal/Integration.aspx

Ohio Medical Marijuana Patient Registry (APPRISS): The medical marijuana elements of APPRISS will be implemented by the State and APPRISS to allow qualified physicians the ability to recommend medical marijuana to patients and issue medical marijuana cards. This application will provide patient and caregiver access to submit payment for placement on the medical marijuana registry and the ability to download their medical marijuana card. Dispensers will be able scan IDs and scan the medical marijuana card of patient to check for alerts in case of excessive fills. All dispensations are sent to the PMP to be displayed in the PMP reports. There will be administrative functionality for monitoring of the application and for providing some manual process for specific use cases.

7.2. General Integration Requirements

Logically, the aforementioned State Systems require integration with the S2S system. Conceptually, the overall integration is as follows:


https://www.ohiopmp.gov/Portal/Integration.aspx

http://www.appriss.com/narxcheck.html

http://www.appriss.com/pmpgateway.html

7.3. Use of State Enterprise Service Bus as Integration Framework

State systems and systems architectures have been built over the years with a variety of middleware or service bus architectures. For purposes of this project and general Enterprise use across the State, Offerors must base their solution on the assumption that use of the State’s Enterprise Service Bus (ESB) to perform SOA functions, Web Services (in general) as well as required State systems integrations to the extent possible.

Oracle Enterprise Bus® is the service bus architecture of choice for the State for this project. Any designed solution will require interoperability and integration to the Enterprise offering and as such are acceptable and preferred unifying technologies for this project. Should, in the opinion of an Offeror an alternative ESB or integration framework be prudent, Offerors must provide selection criteria, rationale and other factors pertinent to deviating from Oracle as part of their response.

Should an offeror require or propose alternate ESB methods or software, Offerors are to ensure that the alternative can integrate fully with established elements within the State.


Unless otherwise specified, all integrations between the S2S system and State systems should be performed transactionally in near-real-time (i.e., not batched or overnight transactions).

7.4. Matrix of Licenses Required within the S2S Process

# Licensee State System of Record Use in Seed to Sale Process

1 Cultivator (Business Entity) Ohio eLicense System(new license to be established) Verification of License, Cultivator Administrative Access

2 Cultivator (Staff member) Ohio eLicense System(new license to be established) Verification of License, Cultivator Worker Access

3 Testing Lab (Business Entity) Ohio eLicense System(new license to be established) Verification of License, Lab Administrative Access

4 Testing Lab (Licensed Tester) Ohio eLicense System(new license to be established) Verification of License, Tester Worker Access

5 Processor (Business Entity) Ohio eLicense System(new license to be established) Verification of License, Processor Administrative Access

6 Processor (Staff member) Ohio eLicense System(new license to be established) Verification of License, Processor Worker Access

7 Dispensary (Business Entity) Ohio eLicense System(new license to be established) Verification of License, Dispensary Administrative Access

8 Dispensary (Support Employees) Ohio eLicense System(new license to be established) Verification of License, Dispensary Dispenser Access

9 Dispensary (Associated Key and Key Employee)

Ohio eLicense System(new license to be established) Verification of License, Dispensary Worker Access

10 Recommendation (Prescription), Dispensary Management Program

Ohio Patient Registry APPRISS Validation of Recommendation and Dispensing Information

11 Patient Ohio Patient Registry APPRISS Verification of Patient Identity

12 Physician Ohio eLicense System(Medical License & MMJ Endorsement)

Verification of Physician License, Verification of MMJ Endorsement


8. Offeror Project Delivery and Team Requirements

8.1. Project Management and Coordination Services

The Project will follow the Governance structure defined by the State. Project Management will include the activities to manage the Project including directing the Project Team according to the Project work plan, reporting status, managing issues, assessing quality, leading project meetings, and monitoring schedule and scope changes. The Project Team must produce project status reports on a weekly basis. The format of the status report will be mutually agreed to by the State and the Contractor during the first week of the Project.

The Contractor must, in conjunction with performing the work arising from this Supplement:

Be responsible for the coordination and delivery of the overall Project;

Ensure that an appropriate “Project Kickoff” occurs and that all integrated work plans are agreed to by the State from project commencement;

Ensure that all efforts have an effective version control mechanism for all documents within the project document library that will be maintained on a State provided Microsoft SharePoint site;

Work with the State leadership to ensure that the Project is staffed appropriately;

Ensure that required testing activities across both technical and operational components are completed to minimize Project risk; and

Collaborate with the task areas to ensure appropriate cross-team communication and delivery.

For purposes of the Project, “Perform” or “P” means that the party assigned the task has the duty and ultimate responsibility to take all appropriate steps to complete or facilitate the identified task unless otherwise provided for between the parties, subject to the Supporting party completing its interdependent responsibilities. The term, “Support” or “S” means that the party has the duty and responsibility to provide ancillary support or assistance which may be necessary to enable the party providing the “Perform” task to complete that task unless otherwise provided for by the parties. The designation, “-” means that the party has no responsibility for the task, unless otherwise agreed by the parties.

Key Tasks State Contractor

Conduct Project kick-off meeting Support Perform

Create a Work Breakdown Structure (WBS) Support Perform

Create and Maintain a project work plan and any related deliverable sub plans Support Perform

Review Deliverables and manage the State’s approvals Perform Support

Review Deliverables and manage the Contractor’s approvals Support Perform

Prepare and conduct project meetings Support Perform

Prepare and conduct stakeholder meetings Perform Support

Create Project Status Reports adhering to the PMO policies Support Perform

Report and manage issues and risks Support Perform

Monitor and report schedule and scope changes Support Perform

Identify State stakeholders and manage expectations Perform Support

Assist with on-boarding for the Contractor resources Support Perform

Assist with on-boarding for the State resources Perform Support

Confirm State Project staffing Perform Support

Confirm Contractor Project staffing Support Perform

Confirm Project governance Perform Support

Initiate Production Acceptance Criteria (“PAC”) process Support Perform



PAC – Provide planned checkpoint review dates Support Perform

8.2. Create and Maintain Project Plan

The Contractor must produce a detailed Project Plan, in electronic and paper form, to the State Project Manager for approval within twenty business days after the State issues a purchase order or other written payment obligation under the Contract.

The Project Plan should include the following (at a minimum):

Project Integration;

Project Scope;

Project Time;

Project Quality;

Project Staffing;

Project Communications;

Project Risks/Issues; and

Project Procurement.

Deliverable 1. Master Project and Staffing PlanAll Contracted Deliverables, Milestones and Work Products

Contractor Staff/Resource Loading

State Staff/Resource Loading

The Contractor must lead a planning session which ensures the following:

A common understanding of the work plan has been established;

A common vision of all deliverables has been established;

Contains a critical path that identifies all major milestones, dependences (both internal and external to the project), resources by name and resource assignments and is complete and inclusive of the entire work effort from commencement until conclusion of all contracted activities;

Clarity on scope of overall project and the responsibilities of the Contractor has been defined and agreed to by the State that includes a common understanding of the business, process, technical and other elements of the overall implementation as required.

Thereafter, the Contractor must:

Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated Project plan as part of its reporting requirements during the Project; and

Ensure the Project Plan allows adequate time and process for the development for the State’s review, commentary, and approval.

The State will determine the number of business days it needs for such reviews and provide that information to the Contractor after award and early in the development of the Project Plan. Should the State reject the plan or associated deliverables, the Contractor must correct all deficiencies and resubmit it for the State’s review and approval until the State accepts the Deliverable at no additional cost to the State.


At minimum, the offeror’s Project Plan(s), as applicable, must include the following:

A summary Work breakdown structure; Scope statement that includes the Work objectives and the Work Deliverables and milestones;

The offeror must provide a detailed Project plan as a Microsoft Project Gantt chart, showing all major Work tasks on a week-by-week schedule and indications of State participation requirements in the Project(s) to serve as the basis for managing and delivering the Work. The schedule must clearly demonstrate how the project will become fully operational by the delivery date. Within this detailed plan, the offeror must give dates for when all Deliverables and milestones will be completed and start and finish dates for tasks. The offeror also must identify and describe all risk factors associated with the forecasted schedule;

Who is assigned responsibility for each Deliverable within the work breakdown structure to the level at which control will be exercised;

Performance measurement baselines for technical scope and schedule;

Description of the offeror’s proposed organization(s) and management structure responsible for fulfilling the Contract’s requirements and supporting the Work, in terms of oversight and control;

A summary Required State staff and their expected roles, participation and level of effort;

Description of the review processes for each milestone and Deliverable (e.g. mandatory design review) and a description of how the parties will conduct communication and status review;

Description of the Project issue resolution process including an escalation plan; and

Description of the approach to manage subcontractors effectively, if the offeror is proposing subcontractors.

8.3. Creation of a Dispute Resolution Capability

Upon completion of the baselined Project Plan and on a quarterly basis throughout the Project, the Contractor, in conjunction with State Project team staff, must deliver a presentation to the State. At a minimum, the presentation must address any known State or Contractor issues or concerns, including but not limited to the following:

Project scope, budget and schedule;

Any changes to Key named resources assigned to the Project;

Project readiness including key issues and risk from their current status;

Project Status including variance from baseline for key milestones, tasks, deliverables (Significant work products) and project closure;

Methodology, approach, and tools to achieve the Project goals (inventory and status of completeness and agreement for documented project management and implementation approaches. I.e., Project management plan, communication plan, requirements traceability, implementation approach and methodology); and

Roles, responsibilities, and team expectations.

Upon completion of the presentation, the State will immediately assess the health of the project and determine next steps for moving forward with the Project, within one week of the meeting, which may include the following:

Continue the Project;

Terminate the Contract; or

Suspend the Contract.

See Suspension and Termination language in Attachment Four for remedies for failure to deliver the proposed work.


Note: There may be additional Project Reviews conducted by the State on an as needed basis throughout the term of the Contract to assess Project health and ensure the Project is progressing successfully.

8.4. Meeting Attendance and Reporting Requirements.

The Contractor’s project delivery approach must adhere to the following meeting and reporting requirements:

Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing changes to the State Project Representative.

Attend Weekly Status Meetings - The State and Contractor Project Managers and other Project team members must attend weekly status meetings with the Project Representative and other members of the Project teams deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.

Provide Weekly Status Reports - The Contractor must provide written status reports to the Project Representative at least one full business day before each weekly status meeting.

At a minimum, weekly status reports must contain the items identified below:

Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS Project) on electronic media acceptable to the State; Updated Critical Path analysis with the aforementioned GANTT chart; Status of currently planned tasks, specifically identifying tasks not on schedule and a resolution plan to return to the planned schedule; Issues encountered, proposed resolutions, and actual resolutions; The results of any tests; A problem tracking report must be attached; Anticipated tasks to be completed in the next week; Task and Deliverable status, with percentage of completion and time ahead or behind schedule for tasks and milestones; Proposed changes to the Project work breakdown structure and Project schedule, if any; Planned absence of Contractor staff and the expected return date; System integration/interface activities; and The Contractor's proposed format and level of detail for the status report is subject to the State’s approval.

8.5. Utilize OIT’s Document Sharing/Collaboration Capability

In conjunction with the delivery of the Project, coincident with the start of the project through its conclusion, the Contractor must use the State provided and hosted document management and team collaboration capability (Microsoft® SharePoint™) to provide access through internal state networks and secure external connections to all project team members, approved project stakeholders and participants. In conjunction with the utilization of this tool, the Contractor must:

Structure the document management and collaboration pages and data structures in such a manner as to support the overall requirements of the Project;

Be responsible for the maintenance and general upkeep of the designer configurations of the tool in keeping with commercially reasonable considerations and industry best practices as to not adversely impact the project delivery efforts performed by the Contractor and State; and

At the conclusion of the project, or upon request of the State, ensure that the State is provided a machine readable and comprehensive backup of the SharePoint™ database(s) contained within the tool that is owned by the State and not proprietary to the Contractor or otherwise required by the State to maintain ongoing


project documentation and artifacts (i.e., Contractor is to remove all Contractor proprietary or non-State owned or licensed materials from the tool).

8.6. Production/Version Control and Release Management

The Contractor will be responsible for working with the State and executing the production deployment and roll-out of any Release Package to the State’s PaaS environment instance (if applicable). Production deployment includes software deployment to the production instance of the PaaS environment and (if applicable) interfaces to production tools and systems that orchestrate, manage, report or control those devices and services managed by the Service, identification of interfaces and any required conversions/migrations, installation of server software, and any required testing to achieve the proper roll-out of the Release Package software.

Contractor must establish and comply with the State required implementation and deployment procedures. This may include laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. Contractor must submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation. The tasks and activities to be performed by Contractor as part of the deployment services also include the following:

Establish procedures and automated software versioning mechanism(s) to ensure that the entire contents of a release, following State acceptance or authorization to implement to a production environment, are complete and maintain all elements that comprise the defined Release Package and the then current production version of the software prior to deployment of the Release Package to same;

Develop, prepare and test emergency back out or roll back procedures to return the production system to its pre-deployment State as it pertains to correcting an errant, erroneous or defective deployment of a Release Package to the production environment inclusive of all code, data, middleware, infrastructure, tables and parameters;

If, in the mutual opinion of the State and Contractor, the deployment of a Release package to the production environment is errant, erroneous or otherwise defective, implement back-out or rollback procedures in their entirety upon the written authorization or direction of the State;

If required, convert electronic data into a format to be used by the new solution using a data conversion program as well as perform any data cleansing of legacy data, with the State’s assistance, prior to loading data to the new solution;

Conduct production pilot(s) (including “day in the life” simulations) and fine tune solution as mutually agreed with the State as appropriate;

Compile and maintain solution issue lists;

Conduct post Production Deployment quality and progress reviews with appropriate State personnel;

Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Release Package’s life and allow for re-use of such documentation for future Projects; and

Establish a performance baseline for the impacted business systems, and where appropriate document requirements for future enhancement of the business systems implemented as part of a future Project or Authorized Work.

8.7. Maintaining Solution and Operations Documentation

For all nonproprietary portions of the solution, and all elements of the solution that integrate with State systems, the Contractor must:


Document the solutions developed or modified by the Contractor in accordance with established methods, processes, and procedures such that, at a minimum the State or a competent 3rd Party vendor can subsequently provide a similar scope of Services

Develop and maintain, as agreed appropriate, the documentation on system environments. Where it is determined that documentation is inaccurate (for example, due to demonstrated errors or obsolescence), and such inaccuracy may negatively affect the Services, Contractor must correct such documentation as part of normal day-to-day operational support.

Update programmer, End User and operational reference materials.

Maintain all documentation on the State’s SharePoint site.

8.8. Project Delivery, Role and Responsibility Requirements

The State has organized our requirements for responsibilities of the State and Contractor based on the anticipated Activity Areas required to analyze, design, implement and deploy the solution as well as those requirements and activities required to support the development and validation of new organizational and operational processes associated with the deployment of the overall solution. Should an offeror, as a result of the review of these requirements and in light of their proposed approach require additional roles or clarity, the offeror must indicate the additional requirements of the State and provide a high level rational for the same as part of their response.

Note: If the Contractor’s recommended methodology does not align with the responsibilities in the Key Task tables contained within the supplement, the Contractor must present matrices which do align with the Contractor’s methodology. The Contractor must also demonstrate that the recommended methodology and the responsibility matrices comply with the State’s need to: (1) know the Contractor has a complete understanding of the State’s requirements, (2) the Contractor’s design and development efforts are in line with the State’s requirement for the solution, (3) monitor the Contractor’s progress during the project, (4) the project risk is acceptable and is managed effectively by the Contractor, (5) have accurate and complete technical documentation regarding the solution (as designed and as delivered), and (6) know the solution delivered and deployed by the Contractor has been adequately tested and meets the State’s requirements.

8.9. System/Environment Administration Support of the Project

The Contractor must coordinate with the State, but be responsible for all environments (production, non-production, demo/training/CRP, development and testing) as required to support the overall effort and must:

Perform technical activities including but not limited to: version control, system administration, tools and ESB development, system code/object migrations, patch implementations, log administration, data copies and exports, interface and scheduled reporting, and responsibility for incident resolution such that migrations into production will be executed at agreed periodic intervals and other production changes will be scheduled during the maintenance window.

Support multiple release levels of System software/hardware elements for in-scope Services, provided that such support does not impair the Contractor’s ability to meet Contractor development and project commitments until such time as all environments can be upgraded to the same version/release level.

8.10. Cooperation with State and State Contractors and Alignment of Deliverables

Contractor must cooperate with the State in its attempts at transferring, replacing or augmenting the services responsibilities to another provider in a manner in keeping with not adversely affecting the provision of ongoing services and other projects being performed concurrent with this project.

Offerors are advised to read and understand the scope of Supplement 2. The Contractor will assist the State in the planning and delivery of the overall Marijuana program within their contracted scope of work. Contractors will


ensure that any deliverable(s) that has a dependency on work within Supplement 2 (or vice-versa) are identified and factored as part of the Project Planning phases of this supplement.

8.11. Dispute Resolution and Escalations

Creation of a Dispute Resolution Capability. The parties will make efforts to first resolve internally any dispute, by escalating it to higher levels of management. If the disputed matter has not been resolved by the identified responsible party (or organization) as defined in this Supplement the disputed matter will be reviewed by the State Project Manager and the Contractor’s Account Representative within a commercially reasonable period of the delivery of a written notice by one Party to another.

Informal Dispute Resolution. Prior to the initiation of formal dispute resolution procedures as to any dispute (other than those arising out of the breach of a Party’s obligations), the Parties will first attempt to resolve each dispute informally, as follows:

If the Parties are unable to resolve a dispute in an amount of time that either Party deems required under the circumstances, such Party may refer the dispute to the State CIO or designee by delivering a written notice of such referral to the other Party.

Within five (5) Business Days of the delivery of a notice referring a dispute to the State CIO or designee, each Party will prepare and submit to the Steering Committee a detailed summary of the dispute, the underlying facts, supporting information and documentation and their respective positions, together with any supporting documentation.

The State CIO or designee will address the dispute at its next regularly scheduled meeting or, at the request of either Party, will conduct a special meeting within ten (10) Business Days to address such dispute. The State CIO or designee will address the dispute in an effort to resolve such dispute without the necessity of any formal proceeding.

The State CIO or designee will address the dispute at the next regularly scheduled meeting between the Contractor and the State or, at the request of either Party, will conduct a special meeting within twenty (20) Business Days to address such dispute. The State CIO or designee will address the dispute in an effort to resolve such dispute without the necessity of any formal proceeding.

If the State CIO or designee is unable to resolve a dispute within thirty (30) days of the first regular meeting between the State and Contractor addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to internal escalation by delivering written notice of such referral to the other Party.

Internal Escalation. If for whatever reason the Contractor and the State cannot resolve a dispute via the above escalation processes and procedures, the Contractor and the State agree to choose a mutually agreeable neutral third party who will mediate the dispute between the parties. The mediator chosen must be an experienced mediator and must not be: a current or former employee of either party or associated with any aspect of the Government of the State of Ohio; associated with any equipment or software supplier; or associated with the Contractor or the State. As to each prohibition this means either directly or indirectly or by virtue of any material financial interests, directly or indirectly, or by virtue of any family members, close friendships or in any way that would have the reasonable appearance of either conflict or potential for bias. If the parties are unable to agree on a qualified person, the mediator will be appointed by the American Arbitration Association.

The mediation must be non-binding and must be confidential to the extent permitted by law. Each party must be represented in the mediation by a person with authority to settle the dispute. The parties must participate in good faith in accordance with the recommendations of the mediator and must follow procedures for mediation as suggested by the mediator. All mediation expenses, except expenses of the individual parties, must be shared equally by the parties. The parties must refrain from court proceedings during the mediation process insofar as they can do so without prejudicing their legal rights.


If the disputed matter has not been resolved within thirty (30) days thereafter, or such longer period as agreed to in writing by the Parties, each Party will have the right to commence any legal proceeding as permitted by law.

Escalation for Repetitive Service Level Failures. Although it is the State’s intent to escalate service level failures to the Contractor Account Representative, the State may decide to escalate to other levels within the Contractor’s corporate structure deemed appropriate to resolve repetitive service failures.

This space intentionally left blank


9. Project Phasing, Work Products and Deliverables

9.1. Requirements Confirmation and Analysis

As this initiative is new to the State, the Contractor must thoroughly document the desired Medical Marijuana business processes and requirements during the initial phase of the project and confirm all State rules, policies, operating procedures and integrations with State systems. The expectation for this project phase is the Contractor will review and analyze these State products and recommend changes which will result in the implementation of the Medical Marijuana system and operating model that fully support the State’s business processes and requirements within applicable State Laws and Federal guidelines.

9.2. Analyze Phase: Contractor Functional Team

The Contractor Team must review, analyze and update the State’s Functional Requirements and process documentation to the extent that it exists.

The Contractor Functional Team must conduct workshops to confirm with Subject Matter Experts (SMEs) the results of their business requirements analysis. These workshops may include Conference Room Pilot (CRP) sessions as applicable. Recommendations for modifications to the State’s previous requirements and processes will be documented and reviewed for acceptance.

The Contractor Functional Team must also analyze impacts to the integration points with State systems, e.g. the State’s Medical, Pharmacy and Licensing systems. In addition, the Contractor Functional Team must analyze external systems and data and recommend data for migration to the solution as applicable.

The Contractor Functional Team must deliver the resulting business requirements (expected to be a modified version of the State’s current functional requirements), a Requirements Traceability Matrix (RTM), the accompanying business processes modified as required and a list of customizations if applicable. All changes to the State’s original functional requirements and business processes are to be clearly indicated.


Review and update Business Requirements. Support Perform

Review and update S2S Processes. Support Perform

Organize business requirements into sub-process groupings. Support Perform

Conduct requirement workshops. Support Perform

Identify workshop participants and send invitations with sufficient lead time. Perform Support

Prepare agendas for workshops and CRPs, as applicable. Support Perform

Conduct Workshop sessions. Support Perform

Document workshop results. Support Perform

Document analysis of integration points with external systems. Perform Support

Create Requirements Traceability Matrix. Support Perform

Create Customization/Configuration Tracking Database (if applicable). Support Perform

9.3. Analyze Phase: Contractor Technical Team

The Contractor Technical Team must define the Technical requirements for the Project leveraging the functional requirements and process documentation.


Define Technical Requirements. Support Perform

Define the solution architecture. Support Perform

Document plan for integration points. Support Perform



Define technical environment requirements for the project from design through deployment and run. This includes any components or tools required to support development, test, configuration management, etc.

Support Perform

Updated RTM with functional requirements and technical requirements cross referenced. Support Perform

9.4. Analyze Phase: Process Design/Validation and Training

The Contractor Process Design/Validation Team must identify all primary and secondary stakeholders impacted by the solution and define the various process design/validation activities that must be addressed throughout the lifecycle of the project.

The process design/validation deliverables developed in this phase will define the training audiences and courses that need to be developed in the subsequent phases as well as all communication activities that need to be executed to address the concerns of those who will be impacted by the project. This technical solution will have impact on business processes employees across multiple discipline areas; therefore the State recommends a training strategy which addresses this need and results in deliverables which are sustainable beyond Initial Release deployment.

Medical Marijuana Operating Processes will be established in this phase and must include all State workers who will regularly interact with or use the system.

The Contractor Process Design/Validation team must also define a Knowledge Transfer Plan between the State and the Contractor Project team members.


Create Process Design/Validation Strategy Support Perform

Develop Communication Strategy Support Perform

Manage the Communication Plan Support Perform

Create Training Strategy Support Perform

Create Training Needs Analysis Support Perform

Review and approve training and communications materials Perform Support

Create and manage Readiness Plan (Plan and Spreadsheet) Support Perform

Recruit and identify Process Design/Validation participants Perform -

Create Knowledge Transfer Plan Support Perform

Create, coordinate and monitor readiness tasks with each Agency and business stakeholders Support Perform

Draft communications to stakeholder groups per the communications plan Support Perform

Review and approve communications to stakeholder groups per the communications plan Perform Support

Distribute communications to stakeholder groups per the communications plan Perform -

Deliverable 2. Master Requirements CatalogueSystem Functional Requirements

System Configuration Requirements

Reporting Requirements

Alerts Requirements

System Integration Requirements


9.5. Design Phase

The Analyze Checkpoint must be successfully completed prior to beginning the Design phase. This includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule for the remainder of the Project will also be completed at the Analyze Checkpoint.

9.6. Design Phase: Contractor Functional Team

The Contractor Functional Team must create and maintain Functional Designs for the solution. Functional Designs contain data, business and security impacts and includes integration points to external systems.


Create Functional Designs per the requirements. Support Perform

Update Requirements Traceability Matrix with design and configuration cross references Support Perform

Create System Test, UAT, and ORT strategies Support Perform

Classify new data introduced in the system to identify data elements that need to be added to the list of confidential and sensitive data Perform -

9.7. Design Phase: Contractor Technical Team

The Contractor Technical Team must update / create Technical Designs and Environment Plans for each of the technical components that were identified during the Analyze Phase. The Contractor Technical Team must also build the environments for the Build and Test Phases.


Create and update the Technical Designs for solution, including any interfaces to external systems. Support Perform

Create and update the Security Designs for the solution. Support Perform

Update environment plans for the Project Support Perform

Build technology environments required for Build & Test Support Perform

Support technical environments, including patches and fixes Support Perform

Create Deployment Plan Support Perform

9.8. Design Phase: Process Design/Validation and Training

The Contractor Training Team must determine the training methodology for the project. In addition, the Contractor Training Team must create a training curriculum course plan that outlines training goals, learning objectives, learning methods and evaluation methods per course.

The Curriculum and Training Designs must utilize leading practices and tools that address all relevant State policies, procedures, and guidance as defined by the State. The Curriculum and Training Designs must include:

“Real life” scenarios with data sets loaded into the training environment.

Training exercises to allow trainees to apply what they have learned.

Roles and responsibilities, common error identification and remediation, and other operational functions as required to support the Project.

Estimates for course length and timing and a task‐to‐course mapping.

Additionally, the Contractor Process Design/Validation Team must continue to work with the State Agencies to prepare them for the new processes. The Contractor Process Design/Validation Team must execute readiness activities as documented in the communications plan.



Create Training Strategy Support Perform

Design Training course curriculum Support Perform

Design real-life scenario exercises with data sets for the training environment Support Perform

Design new training materials Support Perform




Update Agency readiness tracking spreadsheet and dashboard Support Perform

Present at Stakeholder and other Agency meetings Perform Support

Create, coordinate and monitor Agency and business readiness tasks and plan for Go-Live meetings Support Perform

Deliverable 3. Master System DesignSystem Functional Design

System Configuration Design

Reporting Design

Alerts Design

System Integration Design

Operational Process Design

Training Plan

9.9. Build Phase

The Design Checkpoint must be successfully completed prior to beginning the Build phase. This includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule for the remainder of the Project will also be completed at the Design Checkpoint.

9.10. Build Phase: Contractor Functional Team

The Contractor Functional Team must build the solution and prepare for testing. The State will provide one (1) knowledgeable FTE per functional area in test preparation and as mutually agreed to with the Contractor to support test preparation.


Provide test conditions and scripts. Support Perform

Build and Unit Test configuration and security to support the business processes Support Perform

Create System Test, UAT, and ORT conditions, scripts, and scenarios Support Perform

Prepare testing schedule and participation for System Test, UAT, and ORT Support Perform

9.11. Build Phase: Contractor Technical Team

The Contractor Technical Team must build the solution, perform unit testing, and prepare for testing. Also, the Contractor Technical Team must build the remaining necessary technical environments required by the project.


Create Master Test Plan Support Perform

Build and Unit Test the solution as applicable Support Perform

Build and Unit Test customizations as applicable Support Perform



Build and Unit Test updates to Execution Environment (i.e. interfaces, print, security services, and network infrastructure) Support Perform

Build Test Environment(s) Support Perform

Build Training environment Support Perform

Build Operations Environment (i.e. production) Support Perform

Create Assembly Test and Performance Test conditions, scripts, and scenarios Support Perform


Create Deployment and Stabilization Plan and tools (readiness criteria, critical path, and cutover activity list). Support Perform

9.12. Process Design/Validation and Training

The Contractor Training Team must build training materials as defined during the Design Phase which include training manuals, training environment exercies, and job aids for new functionality.

Communication materials will continue to be developed and distributed to the identified stakeholders. In addition, the business and Agency readiness activities will be tracked and monitored via the readiness spreadsheet and reported to business stakeholders.

Business Process Workshops (BPWs) will be developed for changes to requirements. During the BPWs, if business process gaps are identified, they will be presented and discussed with the workshop participants. Action plans will be developed as required. At this phase, the Contractor Training Team will also create a Training Deployment Plan; the purpose of this deliverable is to define a detailed plan for rolling out training to end users.


Build training materials for all mediums in accordance with the training strategy. Support Perform

Create Training Deployment Plan Support Perform

Build scenarios in Training environment Support Perform




Build content for Business Process Workshops for changed functionality Support Perform

Deliver Business Process Workshops for changed functionality Support Perform


Create, coordinate and monitor Agency and business readiness tasks Support Perform

Deliverable 4. Contractor System Test CompletionCompletion of Functional System Test

Validation of Configuration Values

System Testing of all Reporting

System Testing of all Alerts

System Integration Testing with State Systems

Operational Process Completion

Training Schedule and Environment Setup (Curriculum, Courseware, Test Data and Trainee Materials)


9.13. State Acceptance Test Phase

The Test Readiness Review Checkpoint must be successfully completed prior to beginning the Test phase. This includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule for the remainder of the Project will also be completed at the Test Readiness Review Checkpoint.

For avoidance of doubt with respect to testing activities, the Contractor is accountable for all activities associated with System Test while the State will participate in these activities. The State is accountable for User Acceptance Testing (UAT) execution while Contractor will be responsible for test preparation, management and tracking of UAT activities.

During this Phase, the State may, at its sole discretion, elect to perform a Security and Data Protection audit that includes a thorough review of Contractor: controls; security/privacy functions and procedures; data storage and encryption methods; backup/restoration processes; as well as Security Penetration Testing and validation as described in this RFP. The State may utilize a 3rd Party Contractor to perform such activities as to demonstrate that all security, privacy and encryption requirements of this RFP are met. State Acceptance testing will not proceed until the Contractor cures all findings, gaps, errors or omissions pertaining to this audit to the State’s written satisfaction. Such testing will be scheduled with the Contractor at a mutually convenient time during the development and finalization of the Project Plan as required under Section 8 of this Supplement.

9.14. State Acceptance Test Phase: Contractor Functional Team

The Contractor Functional Team must execute System Test, User Acceptance Test (“UAT”), and Operational Readiness Test (“ORT”). The State will provide State Workers knowledgeable in test execution and as mutually agreed to with the Contractor to support test execution.

System Test focuses on the customizations, configurations, workflow and integrations. Test conditions and test scenarios to be included in the System Test will be mutually agreed upon by the Contractor and the State. These scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for implementation.

UAT verifies the usability of the new processes and ensures that the system meets the needs of the organization and the end user. UAT leverages System Test Scripts and is executed by Agency resources. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented.

ORT includes end-to-end testing of processes and technologies and will be executed by State members of the Project team. ORT will be conducted during a specific time period before Go-Live.

The State will conduct a Security Test that includes an application scan, manual testing of the system using client-side code analysis, and loading maliciously formatted inbound interface files.

The Contractor Functional Team must develop and prepare weekly status reports to monitor the progress of each test phase. The status reports will contain sections for condition creation, script creation, script execution, issue identification and resolution, and defect identification and resolution.


Develop and maintain test data repositories as agreed appropriate Support Perform

Manage and track System /Regression Test, UAT, and ORT Support Perform

Execute System / Regression Test and document results Support Perform

Execute UAT Perform Support

Document UAT results Support Perform

Execute ORT Perform Support

Document ORT results Support Perform

Prepare for and execute Security Test Perform -


9.15. State Acceptance Test Phase: Contractor Technical Team

The Contractor Technical Team must execute Assembly Test and Performance Tests.

Assembly Test verifies that the technical architecture works together as planned and tests that all modules were migrated appropriately. The objective of the Assembly Test is to verify that related components function properly when assembled into an overall system.

Performance Test establishes a baseline of acceptable performance for a sample of online transactions. The tests are conducted under a practical proportion of expected transaction and user volumes to mimic real-world usability. The sample is based upon mocked up data entered into the solution. The approach taken will ensure testing against empty databases. The number, frequency, and concurrency of online user transaction load will be defined using the most recent Contractor Functional Team estimates of activity available at the time of test preparation. The estimates will be based on enterprise-wide usage (as opposed to usage of only the Initial Release Agencies).

The Contractor must recommend a Test Moves to Production strategy as appropriate for their solution’s environment(s). The Contractor must demonstrate to the State that the strategy allows for the development and testing of a migration process and checklist, as well as an assessment of timing and any mitigation or resolution of any issues related to timing.

Throughout the Project duration, if a testing or production incident is due to errors, omissions, documentation inconsistencies, or defects within in an “in-scope” environment, supported server, or “in‐scope” software element licensed by a Third Party to the State, the Contractor must assist the State by referring such incident to the appropriate Third Party entity for resolution and coordinating with the Third Party Contractor, as appropriate, to help minimize the State role in problem management.

The Contractor must, to the extent possible, implement measures to help avoid unnecessary recurrence of incidents, by performing root cause analysis and event correlation for items discovered during testing/validation activities.


Prepare for and execute Assembly Test Support Perform

Prepare for and execute Performance Test Support Perform

Support Contractor Functional Team Testing Support Perform

Conduct Test Moves to Production Support Perform

Create the Deployment and Stabilization Plan Support Perform

Develop, update and maintain a migration checklist Support Perform

Prepare for final Move to Production Support Perform

9.16. State Acceptance Test Phase: Process Design/Validation and Training

The Contractor Process Design/Validation Team must continue to execute process design/validation activities and support the testing of the new processes, tools and job aids.


Test training materials and job aids Support Perform




Conduct training needs analysis including identification of trainees Support Perform

Identify trainers who will be responsible for providing training on system functionality Perform Support

Train State’s Trainers and identified Users as part of the Initial Release rollout Support Perform

Develop training instructor guides, that contain information and tips that assist the instructor Support Perform



through a classroom training session

Prepare Help Desks Staff for post-implementation support (create documentation and train staff) Support Perform

Secure training locations, schedule training sessions, identify, register and notify end users of the training, and arrange the logistics for the training sessions. Training must be at State-provided facilities.

Perform Support



Deliverable 5. State Acceptance Test CompletionAcceptance of Functionality

Acceptance of all Reporting

Acceptance of all Alerts

Acceptance of System Integration Testing with State Systems

Completion of all User Training

9.17. Production Deployment Phase

A Test Completion Checkpoint must be successfully completed prior to beginning the Deploy phase. This includes the State’s acceptance of all deliverables due to date per the project schedule.

9.18. Production Deployment Phase: Contractor Functional Team

The Contractor Functional Team must support the deployment activities and must conduct a deployment readiness assessment to determine the readiness of the organization and the solution for go-live. Part of the readiness review will be to determine that the State has reviewed and accepted all functional, technical, and user documentation. Upon completion of the readiness assessment, the State will make a final go-live decision. The go-live date will be scheduled and resources, roles, and responsibilities will be confirmed.


Identify deployment readiness criteria, critical path, and contingency plan Support Perform

Assess deployment readiness Support Perform

Define stabilization approach and plan Support Perform

Perform deployment activities Support Perform

Define end user security mapping and assignments for new or altered functionality Perform Support

9.19. Production Deployment Phase: Contractor Technical Team

The Contractor Technical Team must drive the planning and execution for the system deployment activities. Deployment includes coordination of software deployment to the file server elements, identification of interfaces and any required conversions/migrations, installation and testing of any required middleware products, installation of server software, and any required testing to achieve the proper roll‐out of the application software.

The Contractor Technical Team must develop and execute a deployment and stabilization plan which will describe the plan to manage the go-live. The tasks and activities must include the following:

Execute required data conversions or migrations as applicable.

Perform required data matching activities and error reporting as applicable.

Document data issues and provide to the State for resolution as applicable.


Compile and maintain solution issue lists

Produce an end-to-end final validation of the operational architecture and corresponding operational documentation for the upgraded and implemented modules

Conduct quality and progress reviews with appropriate State personnel

Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Project’s life and allow for re‐use of such within the State for future Project Phases or upgrades.

Transition solution support responsibility according to the Deployment & Stabilization Plan.

The production deployment schedule must be agreed upon mutually by the State and the Contractor.

Production migration activities will adhere to the State Production Acceptance Criteria (PAC) and will not be considered for production migration until all such criteria are met or otherwise accepted by the State. Any deviation, partial acceptance or waiver of requirements in the Production Acceptance Criteria must be agreed to in writing by the State in advance of presentation of any deliverables associated with, or determined to be part of these Production Acceptance Criteria.

Throughout the Project, Application and Tools patches and fixes will be reviewed. Patches will be applied until the QA environment is established. After the QA environment is established and prior to Go-Live, any Application or Tools related patches and fixes will be evaluated for implementation based on the criticality of the patch or fix.


Create production deployment plan Support Perform

Create detailed task lists and work plans for deployment Support Perform

Create production deployment staffing schedule Support Perform

Create production deployment roles and responsibilities Support Perform

Perform cutover activities Support Perform


Coordinate PAC items for Deployment Perform Support

Deploy the Solution Support Perform

System Turnover Support Perform

9.20. Production Deployment Phase: Process Design/Validation and Training

The Contractor Process Design/Validation Team must continue to execute process design/validation activities of the Project and support the deployment of the new processes, tools, and job aids. Training content for new functionality must be deployed with content that is both instructor led or web based training, as agreed to by the State.


Deliver statewide training to stakeholder groups per training deployment plan Support Perform



Distribute communications to stakeholder groups per the communications plan Perform Support


Execute knowledge transfer activities as defined in the Knowledge Transfer Plan Support Perform



9.21. Knowledge Transfer and Production Handoff

The Contractor must perform knowledge transfer support to the State in keeping with the existing State Production Acceptance Checklist (PAC) process which will be made available to the Contractor at the commencement of the project to support knowledge transfer to the State. In general, the PAC must include, at a minimum the following work products as a deliverable:

Deliverable 6. The PAC Deliverable must include, at a minimum:Final Requirements Traceability Matrix for the Project as Implemented

A list of all customizations and Reports, Interfaces, Configurations, Forms and Workflows (RICEFW) objects as implemented

Detailed System Test Cases and Demonstration of Successful Completion of Same

Completion of State User Acceptance Testing and an affirmation of same by State

Operational Readiness Testing Results and an affirmation of same by State

Complete User and System Administration Documentation that represent the system as implemented

9.22. Project Completion Activities, Final Documentation and Post Implementation Support Obligations

The system must successfully perform (defined as no Severity 1 or 2 defects) for forty-five (45) days within the State’s production environment. During the 45-day period immediately following the introduction of the Contractor provided enhancements, configurations or extensions to the State’s production environment the Contractor must:

Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that during this 45-day period all defects identified by the State and mutually committed to be resolved by the Contractor in this RFP or under any SOW are adhered to.

This responsibility shall specifically include:

Prompt isolation, triage and repair of any Severity 1 or 2 defects; Performance Monitoring of the System to ensure that there are no statistically significant (i.e., +5%) deviations from actual production performance as compared to the system performance prior to the implementation of Contractor developed elements; All interfaces, and system functions perform and function as specified; Compile all final versions of the upgrade documentation, work products and delivery materials and locate / organize them as ‘FINAL’ on the State provided SharePoint site. Obtain a final acceptance document from the State and the Contractor confirming that all of the above has been delivered and accepted as final.

If, during the 45-day period immediately following the introduction to Production, a Severity 1 or 2 defect occurs that can be directly attributable to the efforts of the Contractor, and not the State or other non-Project parties, the 45 day period will, at the sole discretion of the State, be reset for additional 45-day periods until such time as the system can perform without Severity 1 and 2 defects.

Deliverable 7. Final AcceptanceState Final Acceptance of System

Successful Completion of Production Handoff and Operational Support Period (45 Days)

All Documentation Transferred to State


10. Solution Technical and Operating Requirements

10.1. General Requirements: Hosted/Cloud Software Solution

The Hosted/Cloud Software Solution will be hosted, operated and maintained by the Contractor as to adhere to the following Requirements and Service Level Agreements:

All data and access to the system must strictly adhere to Ohio Executive Order 2011-12K, which, in general is a prohibition on offshoring any State data or processes.

All State data must reside on a Federal Risk and Management Program (FEDRAMP) certified platforms that are FEDRAMP IAAS/SAAS Authorized with FEDRAMP Impact Level: Moderate or Higher

All data access, security, privacy and data handling requirements must be adhered to as contained in this Supplement and as applicable, the requirements of Supplement 3.

10.2. System Environment Requirements

Based on the State’s typical systems development lifecycle, inclusive of ongoing operations and maintenance activities, the State has developed a set of Systems Environments that are required to support the initial implementation of the system and its ongoing use.

Offerors are encouraged to consider the merits of these Systems Environments and propose (if feasible and advisable) managing these environments to drive availability, releases, efficiency, cost, State licenses or subscriptions costs as applicable, and other consolidation/optimizations. Should the State agree with such approaches, the Offeror, as Contractor must perform the consolidation/optimizations as contracted.

As part of the end-to-end project and ongoing service, the Contractor must include the management and maintenance, encompassing deployment/management, testing and training environments for the instances of the S2S Applications and supporting evolutions as required to support the State in the context of operating the Medical Marijuana business and comply with State laws and Federal guidelines.

The table below reflects the State’s requirements in terms of environments. To the extent the Offeror wishes to suggest alternatives based upon Contractor and Industry best-practices, the Offeror may do so in their response to this section.

Environment Seed to Sale Solution

Demo/Sandbox/Proof of Concept ü

Patch Testing/Staging ü

Development & Configuration ü

Quality Assurance/Testing ü

Acceptance Testing ü

Production ü

Training Delivery ü

Descriptions of the instances are as follows:

Demo/Sandbox/PoC: This is the instance delivered by the Contractor for diagnostic purposes. All patches and bundles will be applied to this instance. No customizations, modifications or configurations will be made to this instance.

Patch Testing/Staging: This instance is for developers to test Contractor delivered bundles and fixes.


Development & Configuration: All development activity including customizations, modifications or configurations will be made in this instance as needed.

Quality Assurance / Testing: This instance allows testers and pilot users to test the customizations, modifications or configurations made to the application before any changes are migrated to Production. This instance will be used for User Acceptance Testing and all forms of integration testing.

Acceptance Testing: This instance allows State testers and pilot users to assess production acceptance issues and for performance testing.

Production: This is the main transactional instance for the State Medical Marijuana S2S Application.

Training Delivery: This instance is used for classroom and web-based training.

Other replicas of these environments to support SDLC activities and other efforts upon the request of the State.

10.3. Production/Version Control and Release Management

The Contractor will be responsible for working with the State and executing the production deployment and roll-out of any Release Package or Application to the State’s S2S software environment. Releases must include (at a minimum): new application(s) inclusive of Contractor developed applications; 3 rd party developed or licensed S2S software extensions; State integrations (ESB or File-Based); production batch or scheduled job streams; and related S2S software reports, interfaces, conversions, forms, workflows or extensions (RICEFW).

Production deployment includes software deployment to the production instance of S2S software and (if applicable) interfaces to production tools and systems that orchestrate, manage, report or control those devices and services managed by the Service, identification of interfaces and any required conversions/migrations, installation of server software, and any required testing to achieve the proper roll-out of the Release Package software.

As part of this Service, the Contractor must:

Establish for the State and thereafter comply with and enforce a repeatable State S2S software implementation and deployment procedure. This may include laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration;

For each release, submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation. The tasks and activities to be performed by Contractor as part of S2S software production deployment services;

Establish and follow procedures and automated software versioning mechanism(s) to ensure that the entire contents of a release, following State acceptance or authorization to implement to a production environment, are complete and maintain all elements that comprise the defined Release Package and the then current production version of the software prior to deployment of the Release Package;

Develop, prepare and test emergency back out or roll back procedures to return the production system to its pre-deployment State as it pertains to correcting an errant, erroneous or defective deployment of a Release Package to the production environment inclusive of all code, data, middleware, infrastructure, tables and parameters;

If, in the mutual opinion of the State and Contractor, the deployment of a Release package to the production environment is errant, erroneous or otherwise defective, implement back-out or rollback procedures in their entirety upon the written authorization or direction of the State.

If required, convert electronic data into a format to be used by the new solution using a data conversion program;


Conduct production pilot(s) (including “day in the life” simulations) and fine tune solution as mutually agreed with the State as appropriate;

Compile and maintain solution issue, defect and incident reports;

Conduct post Production Deployment quality and progress reviews with appropriate State personnel, and (if requested by the State) State Systems Integrator/Vendor (e.g. APPRISS, eLicence, OARRS, etc.);

Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Release Package’s life and allow for re-use of such documentation for future Projects; and

Establish a performance baseline for the impacted business systems, and where appropriate document requirements for future enhancement of the business systems implemented as part of a future Project or Authorized Work.

10.4. Break/Fix Support

The Contractor must:

Track, monitor and provide remediation for solution defects and incidents requiring system configuration or in-scope environment code or configuration changes arising from the application of any of S2S software, State contracted RICEFW enhancements to the State’s S2S software platform and Agency integrations;

Address any incompatibilities, inconsistencies or erroneous processing introduced to the State’s S2S software platform and Agency applications that arise from any production release, patch, update, upgrade or change in code or configuration values;

Identify and implement required system or configuration changes to address solution defects;

Test configuration changes to confirm resolution of defects;

Support the State in performing applicable acceptance testing or review of any changes arising as a result of break/fix or patch/release Contractor responsibilities; and

Ensure compliance with any State Security/Privacy requirements or S2S software mandated patches or system levels to the extent and system enhancement turnaround time required given the nature of the security mandate and report to the State in writing any risks or issues that the Contractor becomes aware of in providing Service to the State. For example: patches designed to address immediate or active Security issues may be scheduled for a near-real-time release, where other less pressing releases may be implemented during a scheduled maintenance or outage period.

Maintain solution documentation (technical specifications and testing documentation) as well as a compendium of common problems, root causes and remedy to aid in the identification and remediation of underlying system incidents.

10.5. Problem Management Services

Problem Management identifies and resolves the root causes of service disruptions. As part of delivery of the Service the Contractor must:

Perform Root Cause Analysis and identification;

Develop and Submit Request for Changes to correct problems with State Applications;

Prioritize resources required for resolution based on business need;

Update the knowledge base with revised operating procedures and conventions upon resolution of problems;


Analyze trends and participating in the State continuous improvement process striving to enhance its operations and identifying continuous improvement ideas;

Share applicable best practices that may improve the State processes and enabling technologies;

Conduct periodic knowledge exchanges between Contractor team and the State designated individuals; and

Assist with implementing the State defined IT control requirements including updating security matrix spreadsheets, and implementing Supported server and Systems software configurations for access control.

10.6. S2S software and Application Licensing, Capacity Planning and Monitoring


Review the State growth plans during quarterly service review meetings, and if requested due to an unforeseen requirement, participate in the required number of ad-hoc reviews coincident with these new requirements and S2S software application needs to correctly plan for licensing and capacity – periodic capacity increases as well as burst requirements.

Monitor S2S software and State application usage and capacity, forecast capacity and review with the State Infrastructure Management on a quarterly basis.

The State will:

Project future S2S software based trends and capacity requirements in conjunction with receipt of Contractor provided capacity usage reports, and in consultation with the Contractor, for new Projects and provide such information to the Contractor as it pertains to the Services;

Review S2S software system performance, licensing and capacity and throughput for new applications before promotion into the production environment to resolve any overcapacity situations.

10.7. Job and Interface Execution / Production Control

The Contractor must develop with the State and thereafter maintain an operational “Run Book” to manage the scheduling of respective production operations, interfaces, scheduled and routine jobs and reports. In general, these functions are executed on a daily, weekly and monthly basis co-incident with Agency processing and close periods and business cycles. The Contractor must develop and assume this run book as part of operational responsibilities for any application that is within the scope of the Contractor provided service.

The Run Book must:

Provide a high-level overview of the processes requiring State involvement (e.g., Change Management, Problem Management);

Outline the current operating schedule for major production and operational schedules which include jobs, processing, report generation, interfaces and other regularly scheduled and routine tasks associated with the Offeror performing services in this area;

Be used by the Contractor to provide the Services;

Identify the Contractor/State interaction process dependencies and roles; and

Describe how the State and the Contractor will interact during the Term.

The Contractor will use the then current processes and procedures existing as of, and delivered to the Contractor to the extent that such processes and procedures are applicable to the new operating environment.



Assign an individual to be the single point of contact to the State for the Run Book development and maintenance;

Provide the proposed table of contents and format for the Run Book for the State review and approval;

Develop and provide the draft Run Book, which will be customized by the Contractor to reflect the process interfaces (interaction between parties, roles responsibilities, timing and the like) between the State and Contractor;

Review the State feedback and revise the draft Run Book to incorporate mutually agreed changes and regular optimizations;

Provide the current version of the Run Book to the State for its use, which will not be unreasonably withheld;

Conduct process maturity assessments, identify process inhibitors, and propose process improvements to the State, as required;

Jointly review the Run Book on a quarterly basis or more frequently, as required, and update and maintain the Run Book accordingly; and

Provide appropriate State employees and Contractors with access to the Run Book, as required.

The State will:

Assign an individual to be the single point of contact for the Run Book review and approval;

Review and approve the proposed table of contents and format for the Run Book;

Review and provide documentation containing the State’s comments, questions and proposed changes to the draft Run Book;

Acknowledge receipt of the final version of the Run Book and provide acceptance and approval, which will not be unreasonably withheld;

Identify process inhibitors and propose process improvements to the Contractor, as appropriate;

Jointly review the Run Book on a quarterly basis or more frequently, as required.

10.8. S2S Software Platform System Management and Administration


Coordinate the installation, testing, operation, troubleshooting and maintaining of the S2S software.

Identify and test packaging patches and other updates associated with supported S2S software, as well as supporting additional security-related fixes associated with the Systems software.

Manage the security functions related to the S2S software including administrative access and passwords (i.e., users with root, administrator, DBA or low-level read/write access) and the related security controls to maintain the integrity of the S2S software, based on the State’s security standards.

Configure and maintain systems managed by the Contractor for network and remote access.

Provide advisory services to support the S2S software administration and developer access services and roles.

Review supported S2S software administration, set-up and configuration

Support performance tuning of State application elements and perform performance tuning on S2S software elements

The State will:


Assist the Contractor in developing procedures for handling all planned and unplanned outages affecting the S2S software Platform and State Applications including review, approval, communication and proper documentation; and

Notify the Contractor of any planned or emergency changes to the State’s environment affecting the Contractor's delivery of the Services.

10.9. Support of S2S Software Future Releases and State Applications as a Result of Changes

The Contractor must provide Support and Maintenance of the State’s S2S software platform that includes:

S2S software platform-level administration, reporting, and support. S2S software platform support does not include Level 1 and Business Level 2 help desk functions (i.e., end-user facing), but only those Level 2 and 3 items (i.e., technical, integration and application/code based functions) that are specific to S2S software and Agency integrations within the contracted scope of Services;

Supporting the State in re-testing or validating State specified RICEFW objects coincident with Major and minor S2S software system releases;

Application Break/Fix responsibility and Minor Enhancements to State specified RICEFW objects;

Migration to Production of applications once meeting the State’s acceptance criteria;

Environment refresh services for non-Production and quasi-Production uses;

System change management and Production version control; and

Review of system usage, performance and reliability reports and collaboration with State Infrastructure Staff to drive system usability, reliability and performance.

10.10. Major/Minor Upgrades (Ongoing)

Release upgrades for packaged software are initiated through periodic releases by S2S software as Major or Minor releases. The State requires that the Contractor lead and coordinate efforts to analyze, install/apply, test/verify and utilize State specified RICEFW objects to these releases in the State’s environment. As the State is dependent on S2S software and is responsible for State infrastructure operations, this coordination and leadership must be well defined and executed so that the State can realize the benefits of a release while not introducing any service impacting or application or integration related issues.

Further, the State understands the importance of S2S software major and minor upgrades to its overall capabilities in support of the State’s mission and in particular over the life a multi-year contract and is committed to maintaining the State’s S2S software platform and related service at the most current proven release at all times, unless the State provides a written exception, in such a manner as to maintain ongoing compliance with S2S software requirements, standards and conventions for maintenance of the S2S software platform and Agency applications and Contractor provided elements that comprise these Agency or Enterprise S2S software-based systems.

The Contractor are to comply with the following requirements:

The State’s requirement is to always operate on a set of Application and Technical Infrastructure components that are on the current S2S software release and support model and terms as provided by S2S software;

As part of annual planning and coincident with monthly project review meetings, the Contractor is to inform the State in writing of any components that are moving beyond a current support model or would rendered unusable as a result of an upcoming release and present a plan to implement the required updates in a controlled manner to the applicable State environment(s) to maintain compliance S2S software support models;


Based on review of any upgrade or update plan (inclusive of all elements required to effectively manage, resource, test, validate and implement the change 0 as outlined elsewhere in this statement of work, the State and the Contractor will schedule a mutually agreeable upgrade / update effort and authorize the Contractor to perform these upgrade services to maintain the required support model;

Upgrade and update efforts must factor any regularly scheduled batch processing or system availability as well as any seasonal processing requirements and should be scheduled to maintain compliance with system availability in consideration of then prevailing development release or production schedule;

The Contractor will be responsible for the design, development, and implementation of the Minor/Major enhancements in the State environments including requirements/design discussions, applicable conference room pilots, design review/signoff, document design specification, document and execute unit and integration/interface tests, support of the State in executing UAT;

The Contractor must support the State in the planning and deployment of periodic releases of non-emergency patches and enhancements (e.g., test new functionality, regression test entire application, document release notes, coordinate with the State for end user change management/communication) as well as perform these responsibilities for all Contractor developed elements for the State;

The Contractor must verify and accept enhancements not developed by the Contractor (e.g., review designs, execute tests, migration to production);

All System Enhancements must be performed in accordance with the appropriate software development lifecycle procedures in this Supplement; and

For all code based deliverables that are accepted by the State or otherwise placed in commercial use, the Contractor must provide an electronic copy of all source and executable code elements to the State as part of the deployment of the element’s introduction to production or commercial use as part of the escrow requirements of this RFP.

Notwithstanding Major and Minor Upgrade enhancement requirements as outlined above, the Contractor has an obligation to maintain all S2S software elements in keeping with a current support and in accordance with agreed procedures associated with the minimization of exposure to viruses, malicious software (malware), security holes or flaws, incompatibility issues, software patch currency, technical updates, corrections and other elements that directly influence the warrantee, support, performance and ongoing upgradeability of underlying software and State specified RICEFW objects of the S2S software platform service.

Upgrades and updates must be scheduled in such a manner as to minimize disruption, capital requirements and risk to the State while balancing Contractor staffing availability and synergies as to affect to the extent possible a seamless and overall consistent upgrade approach and staffing and leverage pricing, staffing, personnel and overall management synergies to the extent possible. The Contractor must propose fixed pricing for performance of these upgrades in keeping with the timing considerations outlined herein that is applicable to the overall term of the agreement.

10.11. System/Environment Administration Support


Perform S2S software and ITSM technical activities (e.g., incident, problem and change processes) including but not limited to: system code/object migrations, patch implementations, log administration, data copies and exports, interfaces (both service bus based and file based) and scheduled reporting, and responsibility for incident resolution such that migrations into production will be executed at agreed periodic intervals and other production changes will be scheduled during a scheduled maintenance window.


Perform environment/supported S2S software environment and database tuning, code restructuring, and provide tools and other efforts to help improve the efficiency and reliability of environments and to help reduce ongoing maintenance requirements.

Provide appropriate Contractor-related data for periodic State analysis and review of resources deployed for preventive maintenance and planning preventive maintenance.

Monitor and analyze trends to identify potential issues and follow-up on recurring problems.

Install S2S software and related S2S software application upgrades and enhancements for updates or revisions (i.e. 1.x, where x is the update/revision) as necessary to maintain the operability of the Services and implement technology changes (e.g., Systems software upgrades or new scheduling software). Included in the scope of such adaptive development work is testing new interfaces to State applications.

Update access and parameter or environment configurations contained within in-scope environments, where applicable.

Generate and provide access to the State to daily production control and scheduling reports, including the production of monthly summary reports that track the progress of the Contractor’s performance of work.

Provide timely responses to State requests for information and reports necessary to provide updates to the State business units and stakeholders.

Perform batch monitoring and restart inclusive of verification of batch jobs and interfaces (ESB and File based) start and complete as scheduled, monitoring and restart of scheduled production batch jobs and resolution of batch scheduling conflicts;

Monitor scheduler related incidents and develop and recommend changes to a scheduler database;

Schedule batch jobs, as requested by the State, that require expedited execution; and

Support production staff (both the State and Contractor) to create and adapt IT operational processes and procedures related to the in-scope environments.

10.12. Program Management & Master Release Calendar

The Contractor must develop and thereafter publish and follow a Master Release Plan and support the State in the development, maintenance and publication of a Master Release Calendar that includes a schedule (with dates) including:

Major/Minor and Scheduled Releases, Upgrades, Updates and Enhancements;

Implementation of Projects, Minor Enhancements or Discretionary Work;

Scheduled Maintenance Windows and Planned Outages;

Major and Minor Project Key Dates (i.e., Start, SDLC Gate Completion, Production Release, Completion) whether Contractor delivered or otherwise; and

Other pertinent dates that require end-user notification or coordination.

10.13. Minor Change and Enhancement Services

Based on the State’s experience with the management and ongoing operations of enterprise software environments, the State is requiring the Contractor to provide the capability to address minor alterations or enhancements (generally less than one month of duration per occurrence inclusive of analysis, design, construction, testing and implementation tasks, but extendable to larger efforts at the mutual agreement of the State and Contractor) to software within the scope of the Services that arise as a result of legal, regulatory, mandates or changes to the State’s business. Due to the sporadic nature of these requirements (e.g., minor


display field changes, edits, reports, etc.), the State may require the Contractor to provide these services as needed.

Ad-hoc requests generally require no extensive modification, configuration, or customization of the S2S software environments (e.g., cosmetic enhancements, maintenance of configuration values, simple reports/views).

Routine tracking procedures must provide visibility of all ad-hoc requests to the State Authorized service representative. The Contractor and the State will develop a prioritization approach for ad-hoc requests based upon business impact and document such process as mutually agreed.

10.14. Environment Backup and Restoration Services

For each S2S software environment within the scope of the Contractor’s Service, the Contractor must perform backup processes as follows:

Type Description Scheduled Timing

Baseline Pre-production image Once

Daily Incremental Files Data changes during the period Daily

Full Data Files All resident data files Weekly (weekend)

Pre-Production Initiations All initiation files during the Production introduction/implementation period Daily

S2S software Platform and Related Commercial Software

All S2S software configuration files and related Commercial software Monthly

Database All Databases Weekly (weekend)

Full Backup CopyAt request of State when a change is made to a State system a copy must be made before the change.

As needed

The Contractor must maintain backup retention periods as follows

Description Retention PeriodBaseline Until first annual + 1 month

Daily 6 Days

Weekly 4 Weeks

Monthly 12 Months

Annual 7 Years

Upon any return of Contractor created backup images or machine readable media of State data, Contractor must provide any encryption keys, passwords, hardware decryption keys (e.g., dongles) as necessary to decrypt the data and restore the data.

10.15. Support of State Disaster Recovery

The Contractor must work with the State, and be responsible for the development, maintenance and testing of Disaster Recovery Plan for its S2S software platform and to the extent practicable under the capabilities and conventions of S2S software as a platform/cloud service.

The Disaster Recovery Plan must document the sequence of events to follow in the circumstance that an internal or external interruption impacts Services provided to the State S2S software user community that may arise as a result of failure of one of more elements that comprise the State’s S2S software environment including, but not limited to: infrastructure, hardware, software, interfaces, networks, S2S software provided elements, and the like.


The Disaster Recovery Plan must be developed in consultation with the State and in adherence to the State IT policies provided herein.

The activities of the Disaster Recovery Plan are intended to reduced or minimize downtime of the platform, interruption of employee work schedules, and financial exposures for the State and Contractor.

The Disaster Recovery Plan documents a sequence of communication events to follow during an internal or external infrastructure failure or natural disaster (act of nature).

In order to minimize downtime, once notification is received from an external utility that disruption is imminent, the Disaster Recovery Plan will be activated.

Disaster Recovery Planning

To the extent agreed appropriate, participating in planning sessions, testing review sessions and other meeting activities during the term of the Contract.

Support implementation of disaster recovery plans as agreed based upon the following principles:

Utilize the S2S software provided alternate disaster recovery capabilities which are adequate to process the State’s transactions and to provide systems access to end-user personnel during an outage period;

Transfer of operations to this alternate site to occur within 24 hours of failure of primary location;

Transfer of the State data, configuration and user access to this site is to occur within 24 hours of failure;

Restoration of primary operations site operations (once available) within 24 hours; and

Notification of the State regarding primary site failure within 60 minutes, and intent to migrate to alternate site within 4 hours of failure.

Annual Disaster Recovery Rehearsal and Testing


Establish joint test objectives with the State designed to verify that State S2S software will be available within the agreed upon timeframes contained in the mutually agreed disaster and business continuity plan.

Schedule and rehearse and test components of the disaster recovery and business continuity plans relating to the in-scope software and service elements at least annually in cooperation with the State, its designees, any testing and recovery providers and relevant State third party Contractors no less frequently than annually.

Design and implement these services to allow for the State and Contractor to continue to operate and manage the Services during periodic disaster recovery tests.

Notify the State as soon as practicable upon becoming aware of a disaster affecting the Services.

Perform necessary migrations of the software code and data as required to reinstate the in-scope Applications so that they are functional at a backup location provided by the Contractor in accordance with the procedures set forth in the engagement practices and relevant Statements of Work.

Coordinate with the State to support the reinstatement of the in-scope Applications at such backup location.

Maintain provision of the Services for unaffected areas.

Service Restoration Following Disasters

Following any disaster, in consultation with the State, the Contractor must:

Reinstall any in-scope Applications affected by such disaster in accordance with the process for such re-installation set forth in the mutually agreed disaster recovery plan and business continuity plan.


Conduct a post-disaster meeting with the State for the purpose of developing plans to mitigate the adverse impact of future occurrences.

To the extent applicable to the in-scope Applications, maintaining compliance with the disaster recovery policies, standards, and procedures contained in the mutually agreed disaster recovery and business continuity plan.

10.16. Service Level Requirements: Hosted/Cloud Software Solution

Service Availability Service Availability for the Hosted/Cloud Software Solution provided by the Contractor that the State utilizes commercially supporting State Medical Marijuana operations, development and maintenance activities, training, demonstration or supporting non-commercial use application usage.

Standard: 99.5% available, 24 hours per day, 365 days per year less mutually agreed to and published scheduled maintenance windows not to exceed five hours per month.

Severity 1 Outage Resolution Time Severity 1 Outage means that there is a Critical Function outage causing severe impact on Service delivery and no alternative or bypass is available. The Contractor must provide notice to the State of Severity 1 incidents along with a preliminary diagnosis and estimated resolution time within 15 minutes of detecting the Incident or being informed by any County / Sheriff or detection of such outage.

A severe impact means: the Incident renders a business critical function, System, Service, Software, Equipment or network component un-Available, substantially un-Available or seriously impacts normal State operations, in each case prohibiting the execution of productive work.

Standard: Detection of Outage and Reporting to State estimated time of resolution: 15 Minutes, resolution of outage and return to contracted standards within 60 minutes.

System Performance and Timeliness. System performance must be measured by the Contractor and be subject to demonstration to the State for auditing and verification purposes upon the request of the State. System performance must meet the following standards:

Standard: Web-based online page presentation transactions must be returned (allowing for network transit time) from origination by a User to return of a properly formatted response within five (5) seconds for at least 99% of all properly formatted State transactions during available hours.

Standard: Industry-facing transactions must be returned (allowing for network transit time) from origination by a user (via the web or a published API) to return of a properly formatted response inclusive of logging/accepting a transaction and display (via the website) to the user within five (5) seconds for at least 99% of all properly formatted transactions during available hours.

Standard: Notification emails and alerts should be constructed, queued to email notification element(s) of the system (generally an SMTP service or equivalent) and released to the user (allowing for network transit time) within 15 seconds of the existence of a condition by which a user notification is required to be originated and transmitted.

10.17. Service Level Specific Performance Credits

Failure to meet any Service level contained in this Section in a given month will result in a 5% fee credit of the total monthly charges for the service to the State for the service month following on a per incident basis identified by the State, and confirmed to be the failure of the Contractor or a Contractor provided element for failure to meet the contracted Standard(s).


11. Offeror Assumptions, Support Requirements, Pre-Existing and Commercial Materials

11.1. Assumptions

The offeror must list all the assumptions the offeror made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the offeror remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the offeror response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the section(s) of the RFP that the assumption is applicable to. Offerors should not include assumptions elsewhere in their response.

11.2. Support Requirements

The offeror must describe the support it wants from the State other than what the State has offered in this RFP. Specifically, the offeror must address the following:

Nature and extent of State support required in terms of staff roles, percentage of time available, and so on;

Assistance from State staff and the experience and qualification levels required; and

Other support requirements.

The State may not be able or willing to provide the additional support the offeror lists in this part of its Proposal. The offeror therefore must indicate whether its request for additional support is a requirement for its performance. If any part of the list is a requirement, the State may reject the offeror's Proposal, if the State is unable or unwilling to meet the requirements.

11.3. Pre-Existing Materials

The offeror must list any Pre-Existing Materials it owns that will be included in a Deliverable if the offeror wants a proprietary notice on copies that the State distributes. For example, the offeror may have standard user interfaces or standard shells that it incorporates in what is otherwise custom software. (See the Ownership of Deliverables section of the General Terms and Conditions.) The State may reject any Proposal that includes existing materials for a custom solution, if the State believes that such is not appropriate or desirable for the Project.

11.4. Commercial Materials

The offeror must list any commercial and proprietary materials that the offeror will deliver that are easily copied, such as Commercial Software, and in which the State will have less than full ownership (“Commercial Materials”). Generally, these will be from third parties and readily available in the open market. The offeror need not list patented parts of equipment, since they are not readily copied. If the offeror expects the State to sign a license for the Commercial Material, the offeror must include the license agreement as an attachment. If the State finds any provisions of the license agreement objectionable and cannot or does not negotiate an acceptable solution with the licensor, regardless of the reason and in the State's sole discretion, then the offeror's Proposal may be rejected. If the State is not going to sign a license, but there will be limits on the State's use of the Commercial Materials different from the standard license in the General Terms and Conditions, then the offeror must detail the unique scope of license here. Unless otherwise provided in this RFP, proposing to use Commercial Materials in a custom solution may be a basis for rejection of the offeror’s Proposal, if the State, in its sole discretion, believes that such is not appropriate or desirable for the Project. Any deviation from the standard license, warranty, and other terms in Attachment Four also may result in a rejection of the offeror’s Proposal.


If the offeror proposes a Deliverable that contains Commercial Software or other Commercial Materials with terms that differ from the terms in Attachment Four for Commercial Software and Materials, then those terms must be detailed here, and any proposed separate agreement covering those items must be included in the offeror’s Proposal. This is required even if the State will not be expected to sign the agreement. Any deviation from the standard terms in Attachment Four may result in a rejection of the offeror’s Proposal.


Documents

procure.ohio.gov€¦ · Web viewUpon determination of the highest-ranking ... Microsoft Word or Microsoft Excel ... will be evaluated for implementation based on the criticality