RFI Document.pdf

Page | 1

Request for Information (RFI)

South Dakota Department of Labor and Regulation (SDDLR)

SDDLR Boards and Commissions Licensing, Inspection, Audit, and Permitting System

Date: October 21, 2024 RFI number: 24RFI11736

Page | 2

Table of Contents Page

Objectives and Purpose……………………………………………………………………3

Disclaimers….…………………………………………………………………….…….…..3

Boards and Commissions Licensing System Background ………………………...…3

Boards and Commissions Licensing, Inspection, Audit, and Permitting Software Initiative ..........................…….4

RFI Response Scope…………………..………………………………………………….5

Product Overview………………………………………………………………………5

Technology……………………………………………………………………………..5

Project Approach ……………………………………………………….……………..6

Projected Costs……………………………………………….…………………….…6

Vendor Response …………………………………………………………….………

Timeframe and Schedule…….…………………………………………………..…..6

Submittal Instructions…………………………………………………………………6

Communications………………………………………………………………………6

Appendix Attached:

Appendix A – RFI Response Questions for Vendors

Page | 3

Objectives and Purpose The State of South Dakota Department of Labor and Regulation (SDDLR) is seeking planning information from potential providers/vendors for a modernized Professional Licensing, Inspection, and Permitting System for a gradually expansive licensing system for a variety of Boards and Commissions (B&Cs) under the purview and administration of SDDLR. This request for information (RFI) is intended to gather information on industry approaches and solutions to develop, operate, and support a modernized Licensing, Inspection, and Permitting system from vendors with proven experience in the professional licensing industry. The information gathered through this process will be used for SDDLR B&C licensing modernization planning purposes and may be used in the development of a request for proposal (RFP) soliciting vendors to assist the State in implementing a licensing, inspection, and permitting modernization solution, hereafter referred to as “licensing” for SDDLR Boards and Commissions.

Responses will be reviewed by SDDLR and SD Bureau of Information and Telecommunications (BIT) staff. Respondents providing clear, concise information may be invited to make oral presentations to staff members. Presentations may be requested to be held via telephone or visual electronic conferencing. It is possible some respondents will not be invited due to logistical and time constraints.

This RFI is designed to:

• Identify technology that may provide new or improved licensing software benefits;

• Gather preliminary cost estimates to assess the scope and size of the project;

• Invite respondents to demonstrate their products/services; and

• Enable state staff members to see licensing systems or prototypes.

Disclaimers This RFI is issued solely for information and planning purposes and does not constitute a solicitation for bid. This RFI should not be seen as intent, commitment, or promise to acquire services, supplies, or solutions offered. No contract may be assumed resulting from any response to this RFI.

SDDLR and/or BIT will not pay for any information herein requested nor is it liable for any cost incurred by the vendor. The information gathered through this process may be used in the development of future documents. SDDLR and/or BIT do not guarantee this will occur.

All information included in this RFI is confidential and only for the recipient’s knowledge. No proprietary information included in this document or in discussions connected to it may be disclosed to any other party.

Licensing, Inspection, Audit, and Permitting system background South Dakota’s Department of Labor and Regulation (SDDLR) is responsible for several professional licensing boards and commissions within the state of South Dakota. These boards and commissions include, but are not limited to, Board of

Page | 4

Accountancy, Board of Barber Examiners, Board of Technical Professions, Cosmetology Commission, Electrical Commission, Plumbing Commission, and Real Estate Commission.

Under various South Dakota Codified Laws (SDCL), Boards and Commissions are created and administered to regulatory agencies within the state. SDDLR is not the only state agency overseeing B&Cs. However, due to the current technological state of B&Cs under SDDLR purview, archaic and brittle systems (e.g. Access databases), various vendor-developed systems (i.e. no cohesive or united system of licensing), and extremely dated technologies, require modernization.

Licensing, Inspection, Audits, and Permitting Initiative For this initiative, SDDLR is seeking to replace, at minimum, two legacy systems;

Electrical Commission and Plumbing Commission within one calendar year. Other B&Cs will be considered at future dates to add to expanding software developed as need and budget allows. The new software system being sought in this RFI must improve customer service by expanding the capacity and functionality of the current legacy system(s). Features DLR will seek with a new licensing, inspection, audit (educational, inspection,firm audits etc.), and permitting portal to be placed within the South Dakota Digital Citizen’s Portal https://www.sd.gov/cs :

• Modernized, state-of-the-art software solutions for governmental regulatory entities. Said system shall include;

o Registrations and applications;

o New exam and/or license applications for multiple/different license types and ability to choose between exam or reciprocity, and pathway for licensure;

o Renewal of licenses housed in the same portal as new license applications;

o Licensee portal (for management of: personal information, continuing education, experience/ hour verification);

o Exam information (need comprehensive continuing education management);

o Ability for continuing education (CE) providers to submit class applications for approval and a real-time list of approved classes viewable for licensees associated with each B&C within the platform;

o Management of student education records, when applicable;

o Module for schools and educators;

o Internal document management;

o Complaints and Investigations;

o Electronic Payment system and reconciliation;

o Business portal (ability to view employee license status, permits, inspections);

o Comprehensive accounting with ability to generate monthly or on demand statements;

o Inspection portal for Electrical and Plumbing inspectors that can be utilized off-line and uploaded to base system upon return to internet connectivity;

o Permitting issuance by inspectors;

o Application and issuance of homeowner permits;

https://www.sd.gov/cs

Page | 5 o Public register;

o Communication management (automated agency communications within portal);

o Reports (ability for the base staff-user with no SQL programming knowledge to pull reports);

o Comprehensive and user-friendly reporting to be used by staff;

o Other system designs as determined during discovery and Joint

Application Development (JAD) and Joint Application Requirements

(JAR);

o Preference for cloud-based application portal;

o Data security and entry security into the portal must utilize Single Sign

On (SSO) with the state’s Digital Citizen’s Portal.

RFI Response Scope Since it is not feasible to convey an all-inclusive functional scope for South Dakota’s Licensing, Inspection, Audit, and Permitting Initiative with this RFI, the State anticipates receiving varied responses. The State acknowledges this constraint and encourages vendors to provide a reponse based on their best understanding of the RFI content.

Each respondent is being asked to provide the following information:

Product Overview Respondents must provide clear statements about Licensing product information that would satisfy SDDLR’s initiative as outlined in this RFI. Additional products or solutions that may be of value or interest to SDDLR are also encouraged. Such information should be accompanied product and services description information.

Technology Respondents must provide technology requirements for their product(s) including, if necessary, any special needs for making application modifications or deployment. If special third party or proprietary hardware or software is required in the environment, the respondent must include those details in their response.

State standard technology should be utilized unless there is a reason not to. If your proposal recommends using non-standard technology, the proposal should very clearly indicate what non-standard technology is being proposed and why it is necessary to use non-standard technology. The costs of such non-standard technology should be reflected in your cost estimate. See http://bit.sd.gov/standards/, for lists of the State’s standards. The proposal should also include a link to your hardware and software specifications.

If non-standard technology is used, the costs must include support since BIT can only guarantee best effort support for non-standard technology. The proposal should also include the development and implementation of a disaster recovery plan since non-standard technology will not be covered by the State’s disaster recovery plan. This should also be reflected in the cost estimate.

http://bit.sd.gov/standards/

Page | 6

Project Approach South Dakota is highly interested in exploring alternative approaches and innovative solutions that would be efficient, cost-effective and satisfy SDDLR’s initiative. This may include leveraging existing state technology, including customizing commercial off the shelf (COTS) technology, Low-Code Application Platform (LCAP), or hybrid thereof. Respondents must provide information that describes their particular project approach for implementing solutions and overal project schedule.

Vendor Response To answer this RFI, please fill in the attached appendices, unless otherwise noted.

South Dakota does not have a specified format for vendor response beyond the inclusion of the required forms.

Timeframe and Schedule The table below illustrates the schedule for this RFI.

Milestone Date RFI Release Date October 21, 2024 Deadline for Vendor Enquiries November 1, 2024 11:59 p.m

CDT

Response to Vendor Enquiries November 8, 2024 RFI Response Due Date November 15, 2024 11:59 p.m.

CST

Vendor Presentations (Optional) TBD

Submittal Instructions Send the attached completed Appendix A – RFI Questions in a Word or pdf document (format unchanged) and other product and vendor information by email to both Jodi Aumer and Andrew Szilvasi at Jodi.Aumer@state.sd.us and Andrew.Szilvasi@state.sd.us

Questions Regarding the RFI/Communications Questions requesting clarification of this RFI must be submitted to Jodi.Aumer@state.sd.us and Andrew.Szilvasi@state.sd.us No telephone inquiries will be accepted.

mailto:Jodi.Aumer@state.sd.us mailto:Andrew.Szilvasi@state.sd.us mailto:Jodi.Aumer@state.sd.us mailto:Andrew.Szilvasi@state.sd.us

Page | 7

Appendix A – Response Questions Section 2 reference

Include answers to these questions in a Microsoft Word or PDF document.

2.1 Vendor Information

2.1.1 Provide the name and principal place of your business;

2.1.2 Provide the name, address, email address, and telephone number of the vendor representative to contact regarding all matters concerning this

RFI.

2.2 System Functionality

2.2.1 Describe the functionality of your system

2.2.2 Explain the process of adding a new licensing workflow to the system. How long does it typically take to add and configure a typical licensing workflow into the system?

2.2.3 Describe how different licensing workflows are managed and maintained within a single system. How are permissions for different user roles managed between licensing workflows?

2.2.4 Are there any specific activities or requirements that would require a work around or customization inside the system?

2.2.5 Explain the system’s business process engine and/or workflow engine. Specifically address how it can be modified for multiple licensing workflows with different user groups, access levels, and security systems?

2.2.6 In a typical implementation, describe how frequently customers are required to change their existing business processes in order for the system to be able to meet their needs?

2.2.7 Describe what components in your system are configurable.

2.2.8 Does your solution have an e-payment system? Has the solution been integrated with any third party e-payment systems? If so, please explain how this is accomplished. Do you complete the PCI-DSS SAQ or have a third-party conduct the assessment?

2.2.9 Does your solution contain an internal document management system? If so, please describe its features, specifically how it maintains a chain of custody of records and segregates data between license types, users, and organizations.

Page | 8

2.2.10 Has the solution been integrated with any third-party document management system such as File Director? If so, please explain how this is accomplished.

2.2.11 Can your system allow for uploaded documents from third-party users of the user? Are uploaded documents digitized and editable, or image/read only?

2.2.12 Describe how your solution tracks continuing education and manages training providers. Can providers upload class rosters after completion of a course?

2.2.13 Describe how the solution can track corrective actions and enforcement or disciplines.

2.2.14 Describe how the solution provides for information exchange with outside sources. Does the solution have an API? Examples include third-party submission of surety bond, submitting annual report information, submission of licensing status to federal regulators, or providing approval to take an exam and receiving the test results in return.

2.2.15 Describe how your solution manages license history and how the system provides audit capabilities.

2.2.16 Describe your solution’s back-office functionality including information on workflow management, accounting processes, and internal audit systems.

2.2.17 Describe your solution’s reporting capabilities.

2.2.18 Describe what mobile devices are compatible with the proposed solution and describe your mobile strategy. Can your system send text messages (SMS and/or MMS) to the licensee?

2.2.19 Provide detailed information for any optional items not requested, but may be beneficial to the State, such as data analytics.

2.2.20 How are user activities in the system recorded and tracked?

2.2.21 Does your system work for specific licensing types that make your system unique compared to other vendors?

2.2.22 Does your system have any licensing types that your solution cannot accommodate or support?

2.2.23 How are licensees notified that their license is coming up for renewal? Is this activity tracked within the system?

Page | 9

2.2.24 Are there read-only users in the system? For example, can individuals review documents inside of the system without having to download them?

2.2.25 What file types can be uploaded into your system? Any file types that are specifically not allowed? If so, what file types?

2.3 Architecture and Security

2.3.1 Describe your system architecture and provide an architecture diagram. Specifically describe if your system is COTS, LCAP, or a hybrid.

2.3.2 Is your system hosted on-premises, remotely by a third-party data center, cloud-based, or hybrid? If vendor hosted, please include geographic locations of data centers offered.

2.3.3 Describe your approach to develop effective information and security controls and approach to document those into a systems security plan. (NIST, ISO, COBIT, CIS v8)

2.3.4 Describe your incident response procedure in the event of a security incident.

2.3.5 Describe your cybersecurity insurance policy.

2.3.6 Describe, as much as possible, the security design and

architectural features incorporated into the proposed solution.

2.3.7 Describe the document storage solution of system.

2.3.8 Describe how your system segregates data between agencies, departments, and or license types.

2.3.9 Describe how your system handles data of different legal and regulatory information requirements; i.e. public data, CJIS, FTI, HIPAA, etc.

2.3.10 Describe how your system integrates with other systems (API, SOAP, etc.)

2.3.11 Are you able to sign and meet requirements of a business associate agreement under HIPAA with the State of South Dakota?

2.3.12 What type of external third-party auditing, (SOC1, SOC2, SSAE21) does your firm use? How often are these assessments done?

Page | 10

2.3.13 Single Sign-On Requirements

As part of the State’s Identity and Access Management (IAM) strategy, the proposed solution will need to integrate with the State of South Dakota’s standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles.

The SSO supports two industry standard protocols: OpenID Connect and OAuth 2.0 (preferred). This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users.

Microsoft’s official documentation on the identity provider the State has implemented can be found at: 1) https://docs.microsoft.com/en-us/azure/active-directory-b2c/ and https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples for public/citizens (Azure B2C), 2) https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 and https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc for state employees, businesses, partners, providers, etc.

(Azure Active Directory).

2.3.14 Onboarding/Provisioning Users

The offeror must describe how new users are onboarded/provisioned in the system using an external identity provider and provide an Identity/SSO/Login Design Document.

2.4 Implementation and Support

2.4.1 Describe a typical implementation and migration plan. Include how you ingest current business processes to implement into the system.

2.4.2 Describe migration of legacy data and interfacing with legacy systems.

2.4.3 Describe typical customer responsibilities for ongoing solution administration if using a managed/hosted implementation.

2.4.4 Describe your solution’s capability to delegate (by agency, by department, or role) administration for account addition, deletion, suspension, termination, password resets, distribution lists to administrators and help desk personnel.

2.4.5 Has a solution been integrated with any Identity Access Management solutions, specifically OKTA? If so, please explain how this is accomplished.

Page | 11

2.4.6 Describe the different support models provided by your

organization, including but not limited to, Managed Services, Customer supported, and hybrid models. Please provide terminology and maintenance agreements regarding SLA’s.

2.4.7 In a normal implementation, how many hours do system owners have to spend performing maintenance and operations on the system?

2.4.8 If your solution allows for integrations into external systems, do system owners normally write the integrations, or does your business provide those services? If so, how long does a typical integration take to create?

2.5 Pricing and System Licensing

2.5.1 Describe your company’s pricing structure for the development, customization, licensing, hosting, and maintenance of product. Is pricing negotiated per application (licensing entity) as a base price, as a range of licensees within each application per month, a combination of both, etc.?

2.5.2 How is your system licensed? Specifically, how are partial year licenses handled?

2.5.3 Identify any contracts (cooperative, NASPO, or other) that products and services of this nature are available on and may be available to the State of South Dakota.

Appendix A – Response Questions