Response to Offeror Questions document.docx

Below are answers to questions submitted by the 2/23/26 5pm CT deadline. Questions submitted after this deadline are not included. Duplicate questions removed.

1. General Question: The RFP does not appear to address payment processing.

1. May the offeror propose the inclusion of its payment processing services? If so, may the offeror update the pricing table in Section 7 to provide for transaction fees associated with payment processing? The vendor may include information on a payment processor and may update the pricing table to include transaction fees, however, per policy, the State cannot utilize an in-system payment processor at this time.

2. Or is the offeror required to integrate with an existing payment platform? If so, please provide detailed integration requirements and documentation. At this time, the vendor will be required to integrate with PayPal for payment processing. The State cannot provide detailed integration requirements.

2. General Question: Does the State have a budget allocated for this project (including an implementation budget and an annual ongoing budget)? If so, please share the budget figures. The budget for this project is contingent on the services provided by the vendor.

3. RFP Page 1: Page 1: Are Vendors to return the populated and signed page 1 of the RFP with their proposal? If so, in what section of the proposal response should it be provided? Yes, sign and include page 1 of the proposal. This should be the cover sheet of the proposal.

4. RFP Sections 3 & 4: Can the State confirm that offerors are to provide the responses “to each point in Sections 3 and 4 in the order they were presented” in our response to RFP Section 6.4? Refer to section 6.2.3 for specific instructions on preparing a proposal. Responses to Sections 3 and 4 may be included under the Deliverables heading.

5. RFP Section 3.1.33 – Can the State please provide detailed integration requirements, including API documentation, for the Patient Verification system? Section 3.2 seems to imply that the Patient Verification system shall be provided by the offeror and is not an existing third-party system. The Patient Verification system shall be provided by the offerer. The State cannot provide detailed API integration requirements.

6. RFP Section 3.6.22 – Can the State please elaborate on this requirement? This requirement is related to verification of a patient or caregiver card for law enforcement and dispensary staff. The vendor must provide a secure way for law enforcement officers to verify whether an individual has a valid medical cannabis card and for medical cannabis dispensary employees to verify whether a card presented to them is valid. The State is open to all options to fulfill this requirement.

7. RFP Sections 5.1 & 5.3: Can the State please confirm that the requirements from RFP Sections 5.1 Team Organization and 5.3 Staff Resumes and References are to be provided under RFP Section 6.12 Team Organization and Staff Resumes? Section 6.2.3 provides specific instructions on preparing a proposal. The requirements listed in sections 5.1 and 5.3 may be included under the Team Organization and Staff Resumes heading. It is the vendor’s responsibility to ensure all required content is included in their proposal.

8. RFP Section 6.4: Can the State confirm that offerors are to provide direct responses to Section 8. Through 8.3 in our response to RFP Section 6.4 and that offerors can refer to our responses to RFP Sections 3 and 4 as needed in order to not duplicate response content? Section 6.2.3 provides specific instructions for preparing a proposal. The proceeding sections of Section 6 provide further description of each of the headings required in Section 6.2.3. Section 8 outlines the proposal evaluation and award process that the state will follow. Vendors must ensure the information listed in this section is available within their proposal under the headings listed in 6.2.3.

9. RFP Section 3.6.19 - can the State provide monthly volumes for technical and end-user support for phone and email channels? The state currently submits approximately 100 help desk tickets per month. This number could be reduced if the state has admin capabilities allowing the state to make necessary changes within the system to provide technical assistance. Section 3.4.1 requires a fully functional test environment allowing the State to see screens from the end users’ perspective. This capability would also contribute to fewer technical assistance requests to the vendor.

10. Approximately how many state staff would utilize the Inspections module? Approximately 3-7 state staff will utilize the inspection module.

11. Can the state provide details on what mobile devices (ex. Tablets) and operating systems (iOS, Android, Windows) they plan to use for inspections? Inspectors complete their inspections on report templates in an iPad. The state utilizes 2 iPads for inspection reports. A third iPad is used for viewing security camera footage. All iPads use Windows.

12. How many inspection forms, or inspection types will be performed? The Medical Cannabis Program conducts routine inspections, site visits, and offsite inspections. Each type of inspection has its own form.

13. Will inspection data be needed to only integrate with the licensing system, or with additional systems? Inspection data will need to be integrated into the establishment licensing system only.

14. How do I set up a SFTP folder? Email Whitney.Brunner@state.sd.us to set up a SFTP folder by March 9, 2026. Vendors may also attach proposals in an email and send to Whitney Brunner.

15. At a high level, what challenges, limitations, or functional gaps is the State experiencing with the current system/solution? The State’s five-year contracts with vendors are entering the fifth year. The State must conduct the legal procurement process prior to moving forward with a current or new vendor. The State is looking to make digital cards the standard, while leaving the option open to print physical cards upon request. The State is also looking to move away from Excel spreadsheets and manual tracking of inspection data.

16. What business or program objectives are not being met today (i.e., why the current system is not fulfilling the intended purpose), and what key capabilities or outcomes does the State expect from the new system? Please indicate the State’s priority areas for offerors to emphasize. The State’s five-year contracts with vendors are entering their fifth year. The State must conduct the legal procurement process prior to moving forward with a current or new vendor. The State is looking to make digital cards the standard, while leaving the option open to print physical cards upon request. The State is also looking to move away from Excel spreadsheets and manual tracking of inspection data. Goals and objectives are included in Section 1.2.2.

17. Could the State describe any vendor-related limitations with the incumbent provider that have impacted operations or program outcomes (such as support, enhancements, issue resolution, or communication)? See responses to questions 15 and 16.

18. How many integrations, and to what systems, do you expect in this project? Are any of the systems homegrown? The patient registry portion of the system must integrate with the Seed to Sale tracking system, Health Information Exchange, and PayPal. The inspection tracking portion must integrate with the establishment licensing system and may integrate with PayPal. The establishment licensing system must also integrate with PayPal. The State is open to other integration options with other state agency systems including the Prescription Drug Monitoring Program that would streamline data collection and exchange.

19. How many legacy data sets need to be migrated? From how many systems? Are any of the systems homegrown? Legacy data sets include all information currently housed in the establishment registration portal and the patient, caregiver, and practitioner registration portal. The program also manually tracks data on Excel spreadsheets that will need to be added to the new system. This is primarily inspections tracking data.

20. Can you please provide details on all legacy systems (i.e., names, structure, API availability)? The State will not provide details on existing systems.

21. What are the file formats to be migrated? Pdf, JSON and Excel. These are the known formats, but current vendors may have data stored in other formats.

22. Is it correct to assume that you will cleanse the data before the migration effort begins? Data is cleansed on an ongoing basis and retained according to state records retention requirements.

23. How many systems and tables will be migrated? Data from two software systems, the establishment registration portal and the patient, provider, and caregiver portal will be migrated. Data from spreadsheets will either need to be uploaded or manually entered.

24. Is it correct to assume that only digital documents are to be included in the migration? No, some older hardcopy files will need to be scanned or uploaded into the system.

25. What is the total storage size (GB/TB), and how quickly is it growing? It is estimated each of the two existing systems have roughly 10 GB of data to migrate. Patient and caregiver counts continue to rise, while establishment data remains fairly consistent.

26. Please confirm that the document collection contains digital and scanned images. The document collection does contain digital and scanned images.

27. Which software / software company provides the Medical Marijuana Seed-to-sale tracking system? Metrc

28. Are you able to provide the API capabilities for the Patient Verification system? No

29. Your website appears to have functional digital application capabilities. Please explain why/how this online component is no longer supporting your program, and what is negatively impacted downstream that needs to be addressed? The state uses digital application systems for patients, caregivers, and practitioners, and the website provides direct links to the current registration platform. A digital application process is also in place for establishments, with a separate portal accessible through the website. Providing these application links online is a valuable feature of the program, and the state intends to maintain this capability.

30. Please provide the primary technical issues limiting/impacting your inspection officials' effectiveness. Is there a lack of mobile capabilities, or poor online/offline form capabilities, or other issues? The State does not currently have a system to store, track, and organize inspection information. All information is tracked on separate spreadsheets in Microsoft Teams folders and none of the inspection information is integrated or connected to the establishment registration portal. Staff must utilize separate systems to find information on establishments and if looking for specific information, it can be challenging to find where it is stored.

31. Can you clarify expected accessibility validation approach (automated scanning, manual testing, third-party certification) for WCAG compliance? The validation approach should be proposed by the offeror. The solution must meet WCAG 2.1 Level AA at a minimum.

32. Will the verification system require real-time cross-check validation against the seed-to-sale or other external systems prior to confirming card validity? Yes, the verification system will require real-time cross-check validation with the seed to sale tracking system and the patient registry system.

33. Can you give examples of validation features that you envision for digital medical cannabis patient and caregiver cards? Any feature that enables law enforcement or establishment employees to securely verify that an individual is a registered medical cannabis cardholder or caregiver—and to confirm the validity of the card presented—will be considered.

34. Will an API interface to a caregiver database be required? No, caregivers will be in the same database as patients.

35. Does the system need to be able to call other applications in the acceptance / denial process? Yes, the Metrc system should receive a flag or notification when an establishment is no longer active or becomes active for the first time in the establishment registration portal. When a patient account is no longer active or becomes active for the first time, the patient registry portal must also send a notification to the Metrc Seed to Sale tracking system for patient allotment viewing purposes.

36. 3.1.33 Can we have a brief description of each system and an understanding of the level of integration required? Establishment registration system: Must house all establishment registration materials and must be integrated with PayPal for payment processing and the Inspections tracking portion of the system.

Patient, Practitioner, and Caregiver registration system: Must house all patient, practitioner, and caregiver registration and certification information, must be integrated with PayPal for payment processing, Seed to Sale tracking system for patient allotment tracking, Health Information Exchange, and card verification system for law enforcement. The Inspections tracking portion must be integrated with the establishment registration portion of the system and with PayPal for payment processing of fines. The State is open to other integrations that would streamline processes.

37. Does the system need to provide a subset of functions for specific use by field inspectors? No, but the system must house inspection reports and fines notices, provide an in-system communication method with establishments, a scheduling feature for scheduling inspections, and integrate with Paypal for payment of fines.

38. Would you be able to provide us with a list of agency job functions / roles that would be involved with this system? This information would help us to understand the extent of training required as well as the project approach to be taken. Training would need to be provided to approximately 8 program staff on all features of the system. Training manuals would also need to be provided and tailored to practitioners entering certifications into the system, patients and caregivers applying for cards within the system, and establishment personnel submitting new and renewal applications through the system, entering payments, and viewing patient allotment. Law enforcement will also need instructions for accessing the patient or card verification system.

39. Please confirm whether the intent of South Dakota is to procure and implement a single integrated platform supporting patient registry, business licensing, and inspection management, or whether modular/vendor-partitioned solutions will be considered. 3.6.24 The vendor must submit a bid for all three components of this RFP: Patient registry and verification, business licensing, and inspections tracking. As stated in 3.6.24, a proposal that does not contain all three components will be considered disqualified and the proposal will not be evaluated. The State prefers a single integrated platform,but is open to other options that meet all requirements, including modular/vendor-partitioned solutions.

40. In section 3.3.1 is the phrase “Application Requirements” synonymous with the Licensing Portal requirements? Application requirements is referring to new and renewal applications that establishments must submit through the system annually.

41. Is the expectation that the selected vendor will provide direct operational support to business applicants, patients, providers, and law enforcement users, or will end-user support be mediated through state program staff? Please clarify any desired service level or response time standards. 3.6.19 The vendor must provide technical and end-user support via phone and email from Monday through Friday, 7:00 AM to 6:00 PM CST. The vendor must provide operational support to both end users and State staff as needed between the hours specified in 3.6.19. See response to question 9 for further information.

42. What historical data lookback period is expected for reporting filters in Section 3.1.32, and does the requirement apply uniformly across all report categories or vary by report? The requirement in Section 3.1.32 is that the system provide an option to query a report based on dates entered in by State staff. The time period would vary depending on the data requested and on the specific purpose the data is being requested. Data or information within the system should be pulled up for the time period requested in a basic report format upon a query for the data being entered. The bulleted information in this section reflects the most common data requests.

43. Please identify the primary external systems currently used by the South Dakota Medical Cannabis Program and/or Department of Health for seed-to-sale tracking, patient verification, and payment processing. Are any of these systems expected to be replaced or deprecated during the contract term? The State utilizes Metrc for seed to sale tracking and PayPal for payment processing. The State will not provide current systems that may be involved with this procurement.

44. Mobile Experience Guidance:

1. Which patient, caregiver, and business licensing workflows must be fully supported on mobile devices, and which workflows, if any, are acceptable to restrict to desktop-only access? Admin workflows carried out by State staff may be restricted to desktop-only access. Any end-user functionalities, including applications, payments, and digital card access should be available on a mobile device.

2. Are inspectors, compliance officers, or law enforcement users expected to perform real-time enforcement, verification, or record lookup functions using mobile devices? If so, please describe any offline operation or connectivity tolerance requirements. Law enforcement must have a means to securely verify whether an individual is a valid medical cannabis cardholder from a mobile or remote device. The solution must be HIPPA compliant.

3. Are there regulatory, privacy, or policy constraints governing caching, local storage, or rendering of registry data on mobile devices? No

4. Should mobile interactions rely on real-time integration with external payment, background check, and verification services, or are asynchronous/batch processing models acceptable? Verification services for law enforcement must rely on real-time integration with the patient registry system. Patient and establishments payments and new/renewal applications completed with a mobile device must also integrate with the system in real-time.

5. What identity federation, authentication, and multi-factor authentication standards are required for mobile users accessing registry, licensing, or inspection functionality? Please see the following for required authentication standard: https://www.sd.gov/bit?id=bit_standards_single_sign_on. The vendors must use the State’s identity provider.

45. Has the state collected formal or informal feedback regarding the usability or effectiveness of current verification, phone-based, or web-based access methods used by law enforcement, program staff, medical marijuana establishment employees, or licensees? Law enforcement must have a way to confirm whether an individual stating the cannabis in their possession is for medical use by confirming whether they are a valid cardholder.

46. Does the program anticipate significant structural or policy changes during the contract term that could impact patient registry verification, caregiver authorization, or public program data exposure requirements under the governing statutes of the state’s medical cannabis program? The state cannot predict structural or policy changes that may occur during the contract term.

47. For requirements involving local jurisdiction controls (such as licensing and proximity restrictions), what is the preferred data governance approach:

1. Validation against a state-maintained reference datasets

2. Validation against a vendor-maintained reference datasets

3. Applicant certification workflows

4. SD Medical Cannabis Program staff certification workflows

5. Hybrid models

6. Other approaches Option 4 is the current approach, but the State is open to all options

48. Generally speaking, does the South Dakota Medical Cannabis Program and/or Department of Health anticipate any significant changes in how it currently verifies the patient and caregiver registry process or makes available program data to carry out the provisions of §34-20G-1? Of special note are:

1. Ad Hoc Caregiver Background Checks: Should criminal background verification processes be initiated and tracked within the licensing system, or is the licensing platform expected only to capture and validate completion status from external background check providers? If yes, what is the name(s) of the background check solutions and can system integration information be shared for carrying out the provisions of § 34-20G-31? The system should flag all caregiver accounts as requiring a background check and prevent a caregiver application from being approved until staff check a box indicating this has been complete. There should be a section within the caregiver account to upload the completed background check.

2. "Bona fide practitioner-patient relationship” Checks: Are current methods for verifying bona fide patient-provider relationship sufficient? The State does not currently have a method for verifying bona fide patient-provider relationships and is open to options.

3. Custodial Parent or Legal Guardian Written Consent: Is there a desire for an integrated eSignature solutions within the Patient and Provider registry to operationalize § 34-20G-33? Yes, integrated eSignature solutions would be beneficial.

4. Patient Card Data Elements: South Dakota law and rules discuss the issuance of a two-part registry card for patients authorized to grow cannabis — one part posted at the cultivation site and the other carried by the patient or caregiver. As SD moves toward a digital patient/caregiver eCard, is there a desire to make both the cultivation site registry card component and the registry card to be carried by the patient and/or caregiver digital? Yes

5. Required notifications to department: Is the South Dakota Medical Cannabis Program and/or Department of Health interested in including a QR code/webpage on a digital eCard to provide patients and/or caregivers information about their required notification obligations with guidance? Yes

49. Generally speaking, does the South Dakota Medical Cannabis Program and/or Department of Health anticipate any significant changes in how it currently licenses Potential Cannabis Establishments or makes available program data to carry out the provisions of §34-20G-1? Of special note are:

1. Application for medical cannabis establishment: For SD localities where proposed medical cannabis establishments require a local registration, license, or permit, will the South Dakota Medical Cannabis Program and/or Department of Health § 34-20G-55:

i. Option 1: Validation against a state-maintained reference datasets

ii. Option 2: Validation against a vendor-maintained reference datasets

iii. Option 3: Applicant certification workflows (i.e., I certify I have completed this step, etc.)

iv. Provide alternative direction to vendors. Establishments currently upload a form from their local municipality and all other application documents to the current establishment registration portal. The State intends to continue utilizing this process or a similar process.

2. County and municipality limitation on number of medical cannabis establishments. For SD localities where a county has enacted a numerical limit on the number of medical cannabis establishments in the county, will the South Dakota Medical Cannabis Program and/or Department of Health § 34-20G-56:

i. Option 1: Validation against a state-maintained reference datasets

ii. Option 2: Validation against a vendor-maintained reference datasets

iii. Option 3: Integrate steps into the “potential medical cannabis establishment” licensing process, flagging potential cannabis establishments to that would push licensed cannabis establishments above the county numerical thresholds using a referenced data set provided from Option 1 or 2 above.

iv. Option 4: Integrate steps into the “potential medical cannabis establishment” licensing process, requiring SD Medical Cannabis Program staff to confirm the “potential cannabis establishment” will not violate local licensing caps and/or confirm SD Medical Cannabis Program staff solicited input from the municipality as to its preference for registration and/or require an uploaded copy of supporting documentation Option 4 most closely reflects how the State currently handles establishment applications. This is all done through manual verification by State staff. As included in the RFP, the State would benefit from a scanning feature that scans an applicant’s application to ensure all required documents have been submitted.

v. Provide alternative direction to vendors.

3. Local ordinances on medical cannabis establishments. For SD localities where the “potential cannabis establishment” licensing process shall include reviewing the proximity of a medical cannabis establishment to “Any sensitive land-use area, including a childcare facility, park, public service facility, recreational facility, religious facility, school, and any location frequented by individuals under the age of twenty-one….”, will the South Dakota Medical Cannabis Program and/or Department of Health § 34-20G-58:

i. Option 1: Develop and provide a definitive, referenceable data set of sensitive land-use areas; please share information about this data set where possible

ii. Option 2: Acquire a 3rd party to provide a definitive, referenceable data set of sensitive land-use areas; please share information about this data set where possible

iii. Option 3: Integrate steps into the “potential cannabis establishment” licensing process, that includes SD Medical Cannabis Program staff to confirm the location meets proximity requirements for sensitive land-use and other medical cannabis establishments Option 3 most closely reflects the current process. All application materials are manually verified by State staff. As included in the RFP, the State would benefit from a scanning feature that scans an applicant’s application to ensure all required documents have been submitted.

iv. Option 4: Integrate steps into the “potential cannabis establishment” licensing process, that require applicants to certify the proposed location meets proximity requirements for sensitive land-use and other medical cannabis establishments and provide any supporting documentation

v. Provide alternative direction to vendors.

4. Local ordinances on medical cannabis establishments--Jurisdiction--Civil penalty. Will the “Potential Medical Cannabis Establishment” licensing process need to be integrated with any Agency or 3rd party system to validate any unpaid civil penalties for a “Potential Medical Cannabis Establishment”? Please provide any guidance on the vision for operationalizing this potential validation step, especially if the license application solution needs to be integratec with Agency or 3rd party systems tracking unpaid/remaining balances for civil penalties.

No

5. Criminal background check of medical cannabis establishment officers, employees, and volunteers § 34-20G-61. Will the South Dakota Medical Cannabis Program and/or Department of Health licensing process need to verify criminal background checks are completed using the licensing solution? Please provide any guidance on the vision for operationalizing this potential validation step, especially if the license application solution needs to interact with Agency or 3rd party background check systems.No, the State just needs a box in the system that staff can check in caregiver accounts indicating that the background check has been completed and a designated space within the caregiver’s account to store the uploaded background check. Background checks will be conducted manually outside of the system.

50. What is the expected level of interoperability between the patient registry system and the state’s prescription drug monitoring program (PDMP), including data exchange method, latency expectations, and user workflow integration § 34-20E? Currently, data is manually pulled from the registry and sent to the PDMP. The State is open to integrating with the PDMP to streamline data exchange.

51. Revocation of registry identification card for cannabis sale to unauthorized person--Disqualification § 34-20G-83. The RFP references statutes that indicate a need for immediate patient registry revocation actions under § 34-20G-83. Please define the operational expectation for the term “immediately” in system performance terms (e.g., real-time automated action, program staff confirmation workflow, or defined service level window). The State needs to have admin controls that allow the State to revoke a card within the system if necessary (click a “revoke” button). Once this option is clicked, the card should be deactivated in real-time and say revoked, and a notice should be sent to the patient letting them know their card is no longer valid.

52. Please provide additional guidance for the turn around timing expectations for revocation of Medical Marijuana Establishment license. Please define the operational expectation in system performance terms (e.g., real-time automated action, program staff confirmation workflow, or defined service level window). See response to question 51. The State requires a similar function allowing staff to click a button to revoke the certification in real-time. An automated message should be sent to the establishment in this event letting them know their certification has been revoked. The revocation of an establishment license should also trigger a limitation of access for the establishment in the Metrc Seed to Sale tracking system.

53. Does South Dakota anticipate publishing or maintaining a formal program technology or policy roadmap for the medical cannabis program during the contract term? If so, how will the selected vendor be engaged in evaluating and supporting potential future regulatory, workflow, or reporting changes? The State includes technology policies in the contract. The vendor should provide a technical assistance contact the State can utilize if and when a change is necessary in the system.

54. For system generated fines for establishments out of compliance, what does that look like at the system level? Is the system sending a fine notification letter and collecting payment? State staff will manually assess fines. The system should have a designated place to store the fine notification letters with the establishment so they can be easily retrieved for future reference. Payment may be entered into the system, but the system would need to integrate with PayPal in order to receive payment. The system should have a communication feature that allows the State to send documents through the system to establishments.

55. Is it the intent that South Dakota will still print physical cards themselves or will card printing happen external to the department? The intent is the State will continue to print cards themselves upon request of a patient or caregiver. Digital cards will become the standard.

56. What nature of integration between the establishment application system component and the patient registry component is desired? It is preferred that the establishment application system and the patient registry component be under the same platform, but there are no integration requirements between these two features.

57. Can the State provide the anticipated number of internal SD DOH and BIT users who will require access to the system, by role (e.g., administrators, reviewers, inspectors)? 1 Administrator, 2 inspectors, 2 card specialists, 1 establishment registration specialist, 1 inspections specialist,1 BIT user. An additional med cannabis staff may need access to the system as well to access data.

58. Can the State provide the anticipated average number of new patient, caregiver, and establishment applications received per year? The State does not currently have an efficient way to differentiate new vs. Renewal applications for patients, caregivers, and establishments. The State currently has 112 licensed establishments, around 20,000 patients, and 530 caregivers.

59. Can the State provide the anticipated average number of renewal applications processed per year? See answer to question 58

60. Can the State provide the estimated number of inspections conducted per year and the number of inspectors expected to use the system? 2 inspectors will use the system for onsite inspections; however, office staff may utilize the system to conduct offsite inspections/investigations. The program also has an Inspections Specialist in charge of scheduling and communication follow up after inspections that will utilize the inspections portion of the system. Approximately 250 inspections are conducted each year, including routine inspections, site visits, and offsite inspections.

61. Approximately how many law enforcement users will require access to the verification system? South Dakota has over 2000 law enforcement officers. The majority of these will require access to the verification system.

62. Can the State provide information about the current system(s) of record, data quality considerations, and any known data limitations or cleanup requirements? The Medical Cannabis Program receives frequent data requests from lawmakers, private organizations, and the public. Data must be easily queried and accurate. The high fluidity of patient and caregiver data can be challenging when trying to fulfill a data request.

63. Can the State provide a list of anticipated integrations (seed-to-sale tracking system, payment processor, identity/SSO provider, reporting or data warehouse systems, and any third-party verification systems)? The system must integrate with Metrc Seed to Sale tracking and PayPal. Please see the following for required authentication standard: https://www.sd.gov/bit?id=bit_standards_single_sign_on. Vendors must use the State’s identity provider.

64. Does the State have an anticipated project start date and a target implementation timeline? Once a vendor is selected, the State will begin preparing a contract and building of the new system will commence immediately after the contract is executed. The new system must be ready to go live June 1, 2027, but the State would consider a phased roll out approach that may start prior to that date.

65. Should bidders attach the RFP cover sheet page with the proposal submission? Yes

66. The RFP references both a Requirements Traceability Matrix and a Microsoft Project schedule.

1. Are both documents required for submission? Yes

2. If so, should both be submitted as Excel files? The format for submission of these items is up to the offerer’s discretion.

67. Should bidders include a signed copy of Appendix D: Contractor Security Acknowledgement Form with the proposal submission? No, this is for informational purposes only. This would be completed by the winning bidder.

68. Should bidders include a copy of the State’s Standard Contract Terms and Conditions in their proposal response, or only provide comments/exceptions as part of the contract response section? The Standard Contract Terms and Conditions is for informational purposes. If the offerer has any issues with the Contract Terms and Conditions, they must include these issues within their response. Comments and exceptions would be sufficient, as long as the specific contract term being commented on is clearly identified in the response. If the offeror does not indicate that there is an issue with a specific contract term, then the offeror will be deemed to have accepted the contract terms as written.

69. The RFP lists required proposal headers/sections. May bidders include additional sections or subsections to further describe the proposed solution and approach, provided all required sections are included? Yes

70. The RFP indicates a preference for State-hosted cloud environments. However, the RFP also indicates that the State will accept a vendor-hosted SaaS solution if the proposal meets all State security requirements. Can the State please confirm that a AWS Gov Cloud hosted SaaS solution is acceptable? This is acceptable, but the state prefers state hosted Azure PaaS solution.

71. Does the State maintain a centralized data warehouse or reporting environment that the system will be required to integrate with? No

72. What format does the State want ‘Feedback on the Offeror’ from the Client? The State will accept feedback in the form of a reference letter, copy of email from previous client, written statement, rating provided, etc. The State is open to any format, but please keep it concise.

73. How many of each type of user will need access to the system? DOH staff, inspectors, patients and caregivers, businesses, law enforcement personnel, dispensary staff? See response to question 57. The State cannot estimate dispensary staff, but there are currently 67 certified medical cannabis dispensaries in South Dakota.

74. Can the State please clarify whether the contract resulting from this RFP is expected to be structured as a fixed‑price agreement for the full scope of work, or as a time‑and‑materials (T&M) engagement? Fixed price agreement