Response to Offeror Questions document.pdf

South Dakota Board of Pharmacy

Compiled offeror questions and answers for RFP # 25-0920900-025

APPLICATION

1. What pain points does you application have? No pain points noted at this time.

2. What features or capabilities does the Board expect to gain with the new licensing solution? Refer to RFP outline

3. How many new applications and renewals are submitted annually, approximately? About 1500 new licenses and 9,000 renewals are completed annually.

4. When are the peak application/renewal periods? Pharmacists are August 1 to September 30 annually, technicians and interns are eligible from September 1 to October 31st. Pharmacies renew June 1 to July 31, wholesalers renew from November 1 to December 31. Controlled Substance Registrations and new applications can come in all year round.

5. What are your key success metrics for this project and how will you measure the system's effectiveness in improving operations? No specific success metrics, only goal-driven for a working database.

6. Do you anticipate any regulatory changes or new licensing categories during the 5-year contract period that could affect system requirements? No regulatory changes anticipated, we may need to add a new license type after initial implementation.

COMPLAINTS / INVESTIGATION / DISCIPLINE

1. What are the main stages of a complaint or investigation (e.g., intake, review, assignment, resolution)? Complaints involve:

intake, assignment, investigation, and resolution/discipline

2. Do disciplinary actions need to be tied back to licenses and available in verification outputs? Yes

3. Will any notification or workflow need to be triggered based on complaint status changes? No

4. Will users need to be logged in to submit a complaint or should they be able to submit anonymous complaints? Users do not need to be logged in, however the complaint needs to be signed document.

5. Are all agency users able to view all complaints or investigations, or are they restricted to limited users? Role based access would be needed.

COST / BUDGET

1. What was the total cost of the original implementation with the current vendor? The contract can be found on openSD.gov

2. What are the current ongoing annual support and hosting costs for the system? The contract can be found on openSD.gov

3. What is the estimated or approved budget range for this project? Budget will be discussed with the offeror awarded the contract.

4. What costs has [Keywords] incurred for the initial set up, ongoing maintenance, hosting, software licensing, support, and enhancements (i.e., “change orders”) over the lifetime of the current systems to be replaced by the new solution? The contract can be found on openSD.gov

5. What is [Keywords]’s budget for the initial system implementation? Budget will be discussed with the offeror awarded the contract.

6. What amount is budgeted for ongoing support, software licensing, hosting, and support of the new system? - Budget will be discussed with the offeror awarded the contract.

7. What, if any, amount of the budget is subject to expire by a certain timeframe and when? Please elaborate. - Budget will be discussed with the offeror awarded the contract.

8. Section 7, Cost Proposal, requests pricing in terms of hourly rates and staff hours. We typically propose cost using fixed-price deliverables totaling an initial implementation cost and a monthly or annual rate for ongoing subscription. Is the format for the Cost Proposal fixed, or do Offerors have flexibility to present costs in other formats? – The Offeror’s have flexibility to submit in other formats.

9. The State has asked for this to be a fixed fee engagement. Table 7.1 requests hours and and hourly rate which indicates Time and Materials. Can the State please clarify it's contract terms? 0- The Offeror’s have flexibility to submit in other formats.

10. 6.14 Cost – “In this subsection, the offeror’s proposal must provide the requested information in Section 7 Cost Proposal” – is it the State expectation that vendors put the actual COST in section 6.14? This is a proposal it is up to the vendor to submit the cost they deem is needed for the project.

b. Is Section 7 and its pricing tables the full extent of what the State expects in the pricing proposal? The Offeror’s have flexibility to submit in other formats.

11. Can the State share an anticipated budget or provide a funding range for implementation, licensing, and support? - Budget will be discussed with the offeror awarded the contract.

12. What costs has [Keywords] incurred for the initial set up, ongoing maintenance, hosting, software licensing, support, and enhancements (i.e., “change orders”) over the lifetime of the current systems to be replaced by the new solution? The contract can be found on openSD.gov

13. Is it the State expectation that vendors put the actual COST in section 6.14? This is for proposal for your work on the project

14. Is Section 7 and its pricing tables the full extent of what the State expects in the pricing proposal? - Yes

15. May vendors expand or supplement the tables with additional fields? - Yes

16. Where should value-added services be addressed in the cost proposal? The Offeror’s have flexibility to submit in other formats.

17. If the State desires COST to be separate from the Technical Proposal, how are vendors encouraged to submit? Technical

Proposal and Cost Proposal should be submitted as 2 separate attachments.

18. Has a specific funding amount or budget range been approved for this project that the Board can share to help us align our technical and cost proposal with its objectives? - Budget will be discussed with the offeror awarded the contract.

DATA

1. What specific data fields need to be captured for each type of licensee or registrant? Specific data elements will be discussed with the offeror upon evaluation of proposals.

2. What are the State’s expectations for handling Personally Identifiable Information (PII) and Protected Health Information (PHI)? Proposals should contain companies PII/PHI policy.

3. In what format is the legacy data currently stored (e.g., SQL, CSV, XML, proprietary)? Will be discussed during technical review

4. Will legacy documents (PDFs, transcripts, etc.) also need to be migrated? yes

5. Are there legacy audit logs or CEU records that will require transfer? no

6. Will the current vendor assist in the extraction and formatting of legacy data? yes

7. What format is the data currently stored in, and how much data needs to be converted to the new system? All data is housed on the iGov Solution database

8. Approximately how many licensee records will need to be migrated? 30,000

9. For data conversion requirements, please inventory all data sources, file formats, and size of the current data sets to be converted and migrated into the new system Specific data elements will be discussed with the offeror upon evaluation of proposals.

10. Concerning data conversion. From what system is data being migrated? iGov Solution Software How far back does the data go? Since 2018 when the software was implemented. Was it converted previously to the system it is in now? No

11. Can the State specify any legacy or supporting databases that the new system will need to connect to or replace?

iGov? No

12. Could the State confirm whether it requires: How does Converge interface?

a) real-time or scheduled system-to-system data integrations (e.g., via APIs),

b) robust data export tools enabling the State to extract its data independently at any time, and

c) whether these access methods are intended to support operational use, analytics/reporting, or full system exit/migration scenarios? This will be discussed at the technical review

13. Could the Board please share an estimate of current and projected data storage requirements (in GB/TB), including structured and unstructured data, to assist with appropriately sizing the hosting and storage configuration? Specific data elements will be discussed with the offeror upon evaluation of proposals.

14. Does the Board have a preferred Document Management System (e.g., SharePoint, OnBase) for storing and managing documents within the system, or will the vendor be permitted to propose a DMS solution that meets project needs and aligns with BIT standards? The State standard is File Director.

15. Can the State confirm whether any of the regulated data types (FERPA, PHI, FTI) will be collected, processed, or stored by the system, and if so, which boards or workflows this applies to? Complaints may have PHI only on limited basis.

16. How many years of historical data are expected to be migrated into the new system? Since 2018

17. Do you have an approximate count of active versus closed or inactive records in the current system? 15,000 active and 15,000 inactive records

18. Should we plan to migrate only active records, or are closed/inactive records also required? Closed and inactive as well.

19. Are closed or inactive records accessed frequently, or would it be acceptable to archive them separately from the core system? We want these on the proposed system to be accessible.

20. What database or platform is currently used to store the data that will be migrated? All data sits within our current vendors, iGov Solution, infrastructure

21. Is all data stored in a single system, or are there multiple sources we should be aware of? Single System

22. Is the data structured, and will a data dictionary or schema be available to support mapping and transformation?

Will be discussed during technical review

23. Can you estimate the total number of records involved in the migration? 30,000

24. How would you describe the overall data quality - would you classify it as high, medium, or low? high

25. Will data cleanup or standardization be required as part of the migration process? Data is currently in a clean state

26. Who will be responsible for extracting the data from the current system - your team, vendor, or someone else? The offeror awarded the contract will work with the current vendor and the state

27. Who will be responsible for validating the accuracy and quality of the migrated data? The offeror and the state.

28. Are there documents, files, or attachments (e.g., PDFs, images, scanned forms) that need to be migrated along with the data? yes

29. If so, do you know the approximate number of documents or the total file storage size involved? Will be discussed during technical review

30. Are those files stored in the same database, in a separate file system, or managed through a document management solution? All files are stored in the iGov platform.

31. Will there be any reports from the existing system that need to be rebuilt or replicated in the new system? Yes If so, an approximate number or a sample list would be very helpful. To be determined

32. Does the data need segregated from other teams? Specific data elements will be discussed with the offeror upon evaluation of proposals.

33. Can you share current licensing volumes by category and typical transaction volumes (applications, renewals, inspections) to help us properly size and configure the system? There are 15,000 active users, all licenses need to renewal annually. There are 15,000 inactive records to convert to system.

47. Approximately how much data will need to be converted? (Please describe the type of data, is it active and/or archived data, how is it stored, what is the yearly volume of data collected and how many years of that data do you expect to be converted during this project.) Unknown

IMPLEMENTATION / PROCESSES / PROCEDURES

1. Is [Keywords] open to a phased implementation approach? The Offeror’s have flexibility to submit in other formats.

If a phased implementation approach is acceptable, what is the desired order for which [Keywords] programs are to be implemented? The Offeror’s have flexibility to submit in other formats.

2. Can the State clarify expectations for this section, specifically “The offeror must outline their internal processes and procedures in their proposal, including, but not limited to, alerting key stake holders (such as: Operations, Systems

Support staff, Desktop Support staff, Administrators, Help Desk personnel, Client Representatives, and others) of changes that will be occurring within State or offeror resources or systems.”? Offeror should include their notification policy for alerting key stake holders of system changes.

3. In the context of questions a., is the State seeking examples of Disaster Recovery Plans (DRP), Incident Response

Plans (IRP), or Communication Plans Yes

4. Would including these documents as attachments be appropriate? yes

5. In a single, concise list, please identify ALL other systems that the new solution will need to integrate with (i.e.

payment processor, other systems such as financial, etc.) along with an inventory of which interfaces will need to be whether a one-way (import or export) or two-way data exchange. Converge for credit card processing of fees two way, NABP for license and testing data one way import, and Bamboo Health for License verification one way export.

6. Describe how CPE is currently reported and tracked (ie. Attestation model, provider reporting, NABP) and your expectations in a new system. Currently this is done manually but would like to entertain sharing with NABP platform.

7. Are there significant backlogs or manual processes (e.g., paper-based review, offline correspondence)? No

8. How many unique forms / Applicant Intake forms are currently in use/ scope, and what types do they include? Unknown at this time

9. Can public users access the Reports & Dashboard? No

10. Will all the modules and components listed be part of a single phase, or should the implementation be phased? Unknown If so, what is the expected priority or timeline for each phase? The Offeror’s have flexibility to submit proposals on this matter.

INSPECTION

1. Page 12 reads that the new system should, “Allow online inspection services and availability for completion of action items.”

Can SDBOP clarify what is meant by “completion of action items”? Does this refer to the identification and resolution of a corrective action plan for identified inspection deficiencies? Yes

2. Please provide the number of different inspection forms/types the board uses. Opening Inspection, General Pharmacies, Hospital Pharmacies, Remote Pharmacies, Wholesale Distributors, Medical Gas, Compounding pharmacies, AMDD free standing locations, and random/complaint.

3. How many inspections are conducted annually? Around 400

4. Can bidders assume that the portable tablets for [Keywords] field inspection staff and internet connectivity will be supplied by [Keywords]? Yes

5. The RFP notes that inspections are required for pharmacies and wholesale distributors.

Can the State clarify the scope of inspection functionality desired from both the licensee and SDBOP staff perspectives?

Specifically: Verification of demographics and staff, checklist of compliance questions, discussion points (free type area), any discrepancies, signatures of inspectors and licensee representative.

6. Is scheduling functionality intended for internal staff only, or should licensees be able to view or request inspection appointments? Internal only

7. Does the State require mobile/offline inspection capabilities (e.g., DoForms-style), or will a web-based interface suffice? The Offeror’s have flexibility to submit in other formats. Preferred but not required to work offline.

8. Can the State clarify the scope of inspection functionality desired from both the licensee and SDBOP staff perspectives?

Specifically: Verification of demographics and staff, checklist of compliance questions, discussion points (free type area), any discrepancies, signatures of inspectors and licensee representative. In office we would also need access to the report to be on the licensees file/account to view.

9. Please advise how many inspection forms per program area? 20 Opening Inspection, 200 General Pharmacies, 60 Hospital Pharmacies, 12 Remote Pharmacies, 12Wholesale Distributors, 30 Medical Gas, 10 Compounding pharmacies, 20 AMDD free standing locations, and 30 random/complaint.

10. How many pharmacy or wholesaler inspections are conducted per year? Are they tracked manually or electronically?

Electronically

11. Are inspections initiated internally, scheduled by licensees, or auto-generated based on rules? Internally generated

12. What forms and checklists are used during inspections? Verification of demographics and staff, checklist of compliance questions, discussion points (free type area), any discrepancies, signatures of inspectors and licensee representative. Are these standardized or do they vary by license type? Vary by type

13. Do inspectors need a mobile app to be able to complete certain inspection tasks? Currently this is done online but an app would work if that is what is provided by the offeror’s system.

14. Should inspectors complete inspections while offline and sync later, or is constant connectivity expected? Either, offline is preferred but can work with either as there is wifi ability with tablets.

15. Do inspectors need the ability to capture photos, signatures, or location data during inspections? Photos can be uploaded later, signaures required, location data/inspection checklist is needed.

16. Does inspection scheduling need to integrate with any calendar system? No

17. Do inspections need any approvals or e-signature capabilities? Yes

18. What inspection services do you currently provide (General Pharmacies, Remote Pharmacies, Wholesale Distributors, Non-sterile compounds, etc.) Opening Inspection, General Pharmacies, Hospital Pharmacies, Remote Pharmacies, Wholesale Distributors, Medical Gas, Compounding pharmacies, AMDD free standing locations, and Random/complaint.

19. Are inspections a requirement that should be embedded in and a part of your standard application processing (initial, renewal or reinstatement applications)? No

20. Are there specific event triggers required in the system that will generate an inspection request and tracked as part of compliance? No

21. Can inspections be scheduled and enforced through an online request not tied to question #7 or #8 above. No

22. Do you currently use any outsourced (third-party) providers that conduct inspections that will need data integration or would they have login credentials to the new system to complete their inspections on-line? No

INTEGRATION

1. Are there any integrations needed with other state boards or departments? No

2. In a single, concise list, please identify ALL other systems that the new solution will need to integrate with (i.e.

payment processor, other systems such as financial, etc.) along with an inventory of which interfaces will need to be whether a one-way (import or export) or two-way data exchange. Converge for credit card processing of fees two way, NABP for license and testing data one way import, and Bamboo Health for License verification one way export.

3. Concerning data conversion. From what system is data being migrated? iGov Solutions How far back does the data go? 2018 Was it converted previously to the system it is in now? No

4. Page 10 states that SDBOP wants the system to be, “Integrated with the State’s document management system, FileDirector, including correspondence tracking and identification.” We have the following questions about this requirement:

a. Our solution includes integrated, flexible document management in Azure Storage that can extend

SDBOP’s current document management capabilities at no additional cost. Is SDBOP open to migrating its files from FileDirector to another Document Management Solution?

i. If not, what are the key capabilities in FileDirector that inhibit SDBOP from migrating to an integrated document management solution in a new regulatory management system?

b. Can SDBOP clarify what is meant by “Correspondence Tracking and Identification”? If SDBOP could describe how these capabilities are used in its current system, that will help Offerors formulate a response.

The location and storage type of documents will be determined once the contract is awarded and begin implementation.

5. Can the State confirm the required system interfaces? This will be discussed at technical review. We currently understand them to include:

• FileDirector

• Converge

• NABP National Database

• Bamboo Health

• State Identity Provider integration

6. Does the State have documents that need to be imported into the system? Yes, located in the license platform iGov

Solutions.

7. Please clarify whether the Board has a need or requirement for the integration of Office 365 Productivity Tools (such as

Outlook, Teams, OneDrive, or SharePoint) within the proposed Licensure and Information System. If so, please indicate which specific Office 365 applications and functionalities should be integrated (e.g., calendar sync, document storage, email notifications, Teams messaging).If there is no current requirement, please confirm. No requirement

8. Regarding the requirement to support secure transfer of licensure data to NABP and Bamboo Health:

a. Are there existing interfaces or file formats currently in use? Yes

b. Has the Board engaged NABP and Bamboo Health on technical specifications or integration standards that vendors should adhere to? Yes

9. Can the Board provide additional details on the expected level of integration with FileDirector, including supported methods (API, file-based, etc.), document indexing requirements, and any existing documentation for vendor reference?

The location and storage type of documents will be determined once the contract is awarded and begin implementation.

10. API Documentation and Standards — Does the State require the vendor to provide Swagger/OpenAPI documentation for all exposed APIs? Are there any preferred data formats (e.g., JSON, XML) or transport protocols (e.g., REST, SOAP) that the Board mandates for integration? Will be discussed during technical review and based on responses to security document.

11. Data migration requirements — Could the Board please clarify the volume, format, and source systems for the legacy data expected to be migrated to the new licensure platform? Additionally, are there any known data quality or completeness challenges? All data would be from iGov Solution Software. No known data quality issues.

12. Does the Board have a preferred ETL (Extract, Transform, Load) tool for data migration and integration activities within this project, or is Board open to the vendor proposing an ETL tool that aligns with the project’s requirements and BIT guidelines? Will be discussed during technical review and based on responses to security document.

13. Does the Board have a preferred Enterprise Service Bus (ESB) or integration platform for system integrations, or will the Board allow the vendor to propose an appropriate ESB or integration approach in alignment with BIT interoperability and security requirements? Will be discussed during technical review and based on responses to security document.

14. Are you expecting batch integrations for systems like CE providers, exam vendors, or payment processors? Yes

15. What existing state systems must integrate with the platform (e.g., accounting, payment gateways, or document storage systems)? This will be discussed at technical review.

16. Is there a preferred or mandated method for integrations (e.g., API vs. flat files)? Will be discussed during technical review.

17. What are the key use cases or data flows expected between these systems and the new system? Will be discussed during technical review.

18. Are flat file exchanges, database views, or APIs currently used to access data? Will be discussed during technical review

19. Are there any preferred middleware or integration platforms (e.g., Mulesoft, Dell Boomi)? Will be discussed during

20. What is the expected data volume for each integrated system (daily/monthly transactions)? Will be discussed during technical review.

21. Are real-time, near real-time, or batch integrations required? Batch is acceptable.

22. Is a system interface inventory or data flow diagram available? No

23. Do you have a middleware solution available or preferred to be used to support integrations? No

24. What authentication mechanisms are expected for system integrations (e.g., OAuth 2.0, SAML, API key)? Will be discussed during technical review and based on responses to security document.

25. Will vendors be granted access to test environments for all required third-party systems? To be determined

26. Will technical points of contact be provided for third-party systems needing integration? To be determined

27. Are there standard practices for error handling, retries, or integration failure alerts? Will be discussed during technical review and based on responses to security document.

28. Are there existing standards or naming conventions we must follow for data mapping or endpoints? No

29. Are asynchronous messaging patterns (e.g., event queues or webhooks) acceptable or preferred for certain interfaces?

Will be discussed during technical review.

30. For NABP e-Profile integration, what data format and transfer mechanism are currently used or expected (e.g., secure

FTP, API, XML)? Will be discussed during technical review.

31. Is there documentation available for the NABP and Bamboo Health interfaces? This is will be discussed at technical review.

32. What authentication methods are required for integration with NABP and Bamboo Health? Will be discussed during technical review and based on responses to security document.

33. What technical details can you share about FileDirector? Does it provide API access for document storage and metadata search? Will be discussed during technical review and based on responses to security document.

34. Will the State provide development and test environments (or sandbox credentials) for NABP, Bamboo Health, Converge, and FileDirector during the implementation phase? Will be discussed during technical review and based on responses to security document.

35. For authentication and SSO, will the State provide Azure B2C and Azure Entra ID configuration metadata and support for integration testing? Yes

36. Are there any State-managed logging, monitoring, or alerting tools that should be used to track integration health and failures? Yes

37. Does the State expect synchronous (real-time) or asynchronous (scheduled/batch) data exchange for each external system integration? This will be discussed at technical review.

38. Should audit logs related to external system integrations be stored in the same database as licensing activity, or separately? Will be discussed during technical review and based on responses to security document.

39. Does FileDirector have a REST API or other preferred method of integration (e.g., file drops, SOAP, SFTP)? Will be discussed during technical review and based on responses to security document

40. Are NABP and Bamboo Health integrations real-time APIs, secure file transfers, or batch uploads? Batch file upload

41. What data formats are accepted with NABP and Bamboo Health APIs (e.g., JSON, XML)? Will be discussed during technical review.

42. Should the system generate and store logs or confirmations of file transfers to NABP/Bamboo Health? To be determined with selected vendor.

43. Other than CPE are there any other integrations with NABP systems that are required or wanted (eLTP, e-Profile Connect, CPE Monitor, Clearinghouse, VPP)? To be determined with selected vendor.

44. Would you be open to using built-in document management features rather than integrating with FileDirector? If

FileDirector integration is required, can you provide detailed technical requirements? Yes

45. Can you provide technical specifications for the Bamboo Health integration including file format requirements, upload schedule, and API documentation for the daily pharmacist license file uploads? No

47. Beyond the integrations specified (NABP, Bamboo Health, FileDirector, Converge), are there other state systems or third-party services that require integration? Will be discussed during technical review.

48. Are you currently using NABP Connect to login and manually verify e-Profile data or are you actually sharing data with

NABP using one or more of the following methods? To be determined with selected vendor.

Simple file transfers Scheduled and/or On-demand API’s, Webhook listeners

49. If you are sharing data or plan to share data with NABP, which integration services do you consider a requirement for this project? (e-Profile, education, examination, licensure data, continuing pharmacy education (CPE Monitor), disciplinary clearinghouse, inspections, etc.) To be determined with selected vendor.

50. If our solution has a built-in document management process using Azure Blob storage, do you plan to continue using FileDirector via an integration or are you open to converting existing documents to Azure Blob storage as part of this project? Data can be stored on vendor platform, this will be discussed during technical review and based on responses to security document.

PAYMENT

1. Is payment processing involved in the application? Yes this is done with an interface with Converge.

2. Is [Keywords] expecting the vendor to incorporate a payment processor within the proposal, or provide recommendations, or integrate with the State’s preferred payment processor? Integrate with the State’s preferred payment processor Converge. If the State has a preferred payment processor, please name the processor. Converge

3. Section XXXIX. Payment Card Industry Data Security Standard in Appendix A – Included IT Contract Terms and Conditions reads, "Any service provider who possesses or interacts with payment card data must stay current with the Payment Card Industry (PCI) Data Security Standards. The Vendor will enter into a contract with one or more service providers for payment card services under this Agreement." Our solution does not possess or interact with cardholder data. Our solution instead interfaces with third-party payment processors and receives non-PCI data such as the payment amount and the payments processor’s transaction number in the payment processor’s response object. This facilitates agency payment reconciliation with the payment processor and the State Treasurer’s office while creating a separation of duties that keeps cardholder data secure. Can the State clarify the PCI compliance requirements for solutions that are integrated with a payment processor but do not constitute a Cardholder Data Environment? - Will be discussed during technical review and based on responses to security document.

4. For Converge payment integration, will the State provide credentials, sandbox access, and API documentation? Will be discussed during technical review and based on responses to security document.

5. What specific functionality must be supported in the Converge integration (e.g., refunds, custom fees, receipts)? Will be discussed during technical review and based on responses to security document.

6. Can you describe how fees are structured across different license types (e.g., flat vs tiered, late fees, reinstatement)? There is a flat fee for each different license type, we have late fees, a transfer fee and reinstatement fee for certain types as well.

7. Will licensees need to see a payment history or invoices within the system? Yes

8. Can you provide integration requirements for the Converge payment system including API specifications, security requirements, and transaction processing workflows? Will be discussed during technical review and based on responses to security document.

PLATFORM / SYSTEM / USERS

1. How many license types does the Board manage? 8

2. How many [Keywords] users will access the system? 8 online and 15,000 online licensees

3. Please provide the annual number of applications / renewals processed by [Keywords].

Pharmacists (licensed)- 2,300 Pharmacy Technicians (registered) 1,700 Pharmacy Interns (registered) 300 Full-time Resident Pharmacies 250 Part-time Resident Pharmacies 90 Non-resident Pharmacies 1,100 Wholesale Distributors 1,500

Controlled Substance Registrations 3,000

4. How many users will need licenses? About 15,000

5. Please provide an approximate number of standard email/letter templates that will be used by [Keywords] that are to be integrated and automated by the system. Around 12 depending how the template is built on what is able to be changed automatically vs having a new template.

6. Please provide the active license counts for each of the different license types.

Pharmacists (licensed)- 2,300 Pharmacy Technicians (registered) 1,700 Pharmacy Interns (registered) 300 Full-time Resident Pharmacies 250 Part-time Resident Pharmacies 90

Non-resident Pharmacies 1,100 Wholesale Distributors 1,500

Controlled Substance Registrations 8,000

7. Please provide the number of application types for each license type.

Pharmacists (licensed)- 2,300 Pharmacy Technicians (registered) 1,700 Pharmacy Interns (registered) 300 Full-time Resident Pharmacies 250 Part-time Resident Pharmacies 90 Non-resident Pharmacies 1,100 Wholesale Distributors 1,500

Controlled Substance Registrations 8,000

8. Section 1 references two business professions (pharmacies and wholesale distributors) and three person types

(pharmacists, pharmacy technicians, and interns), while Section 3.1.1 lists additional distinctions such as pharmacy categories and wholesale distributor subtypes.

Can the State confirm the full set of license and registration types, including: Yes, that is the correct list plus Controlled Substance Registrations.

Pharmacists (licensed) Pharmacy Technicians (registered) Pharmacy Interns (registered) Full-time Resident Pharmacies Part-time Resident Pharmacies Non-resident Pharmacies Wholesale Distributors (and subtypes like manufacturers, virtual manufacturers, repackagers, etc.)

9. How many internal users will require access to the back-office system? 8

10. We define Named Users as “staff with access to the back-office software, regardless of whether access is concurrent or consecutive.”

How many Named Users does the State anticipate needing 8

11. Please provide a breakdown of the number of [Keywords] employees that will be using the new solution by [Keywords] program, role, as well as which ones will be performing mobile inspections. 8 currently we would have all staff have full privileges across the platform.

12. Approximately how many licensee records will need to be migrated? 30,000

13. How many internal users will require access to the back-office system? 8

14. Could the Board elaborate on the number of anticipated users by role (e.g., administrators, internal staff, licensees, public users), to assist with system licensing and access control planning? 8- administrators, internal staff

15. Please clarify how external users (e.g., licensees, applicants, facility representatives) will need to be authorized and authenticated within the proposed system. Specifically, we understand that state staff will be authorized and authenticated using the South Dakota BIT-managed Identity Provider (IdP), such as Azure AD and Entra ID, following BIT’s Single Sign-On (SSO) standards. Will external users also be required to authenticate through the BIT-managed IdP, or Should the vendor provide a separate user authentication and authorization mechanism for external users within the system while aligning with BIT’s security and compliance requirements? Please also confirm if there are any specific identity management, MFA, or account provisioning requirements for external users that the vendor should incorporate in the proposed solution. The users will be utilizing BIT managed IdP.

16. Can you provide a breakdown of user types and expected users count for each group (e.g., licensees, board admins, inspectors)? 15,000 licensees, 8 board staff/inspectors

17. Please provide the total number of internal users that would be using this system 8

18. Please provide the total number of licensees and registrations by license type or registration type and how often they need to renew their licenses Pharmacists (licensed)- 2,300 annual Pharmacy Technicians (registered) 1,700 annual Pharmacy Interns (registered) 300 annual Full-time Resident Pharmacies 250 annual Part-time Resident Pharmacies 90 annual Non-resident Pharmacies 1,100 annual Wholesale Distributors 1,500 annual

Controlled Substance Registrations 8,000 some annual and some every 3 years.

19. How many public or external users are expected to use the portal in a typical year (licensees, applicants, employers)?

15,000 for renewal, unknown number of public for verification purposes.

20. What is the total number of active licenses currently maintained (e.g., pharmacists, interns, techs, businesses)? 15,000

21. How many users will need licenses? 15,000.

22. Approximately how many documents/templates will need to be generated in the system? How many documents should the solution be capable of handling? Around 12 depending how the template is built on what is able to be changed automatically vs having a new template.

23. How many internal users of the application will be needed? Will some need full access and others read-only access to the application? If so, how many of each profile will be required? 8 full access, future we may need to add more and we may need limited access for certain users.

24. Approximately how many new records are created each year? 1,500

25. Are there templates currently used for correspondence (emails, letters, inspection follow-ups)? No

26. Do notifications need to support multiple delivery channels (e.g., email, SMS, portal alerts)? No, email only.

27. Should correspondence with licensees be logged in FileDirector automatically? No

28. Approximately how many new documents will be created or uploaded each year? 100,000 with the current application process

29. Approximately how many internal Business Process are configured for the internal processing - Unknown

30. How many email templates are there? Are any expected to be automated? This would be up to the offeror to include in the proposal what is available.

31. How many different agency teams or departments will be using the solution? 1

32. Are there additional layers to an agency user such as a manager or super user type of role? Yes, for future growth

33. Can you provide details about the current licensing system (vendor, database type, record volume, available export formats)? See current contract on openSD.gov

34. Are there any specific data quality or archival concerns with the legacy data? No

35. Will historical license, inspection, and discipline records all be required in the new system, or only current active data? Yes, all historical

36. Do license types have different renewal cycles or unique requirements that the system must accommodate? Yes

37. Are any conditional logic rules required for application eligibility (e.g., education verification, background checks)? Manually done

38. Will applicants need to upload documents? If so, what types and what size limits should be enforced? Yes, PDF, JPEG, DOC, or CSV docs.

39. What details must be publicly accessible for license verification (e.g., license number, status, expiration date)? Name, license number, status, expiration date, discipline, date verified (today’s date).

40. Can you describe your change management and system approval processes, particularly for system updates and new feature deployments? Determined with offeror awarded contract.

41. when you say “Track user entry into the system” does that refer to every time the user logs in via the login process and do we need to track those as historical events or just capture the most recent date/time stamp. Will be discussed during

PRESENTATION

1. What presentations, software demonstrations and/or estimates / quotes have [Keywords] programs received related to this project and from whom? – None

2. Has the Board participated in any software demonstrations in the last 12 months? – No

3. If yes, which vendors were included in those demonstrations? – N/A

4. Has SDBOP seen any software presentations/demo’s in the past 12 months? - No

REPORTS

1. Is the State planning on developing its own reports? If not, how many reports are needed for go-live? This is dependent on the offeror and should include how reports are made/run/built in the proposal.

2. Can [Keywords] provide an inventory of all the reports that need to be replicated within the new system? Depending on reports and types, and how they are run/built it is not practical to list all reports.

3. Could the Board provide additional context on ad-hoc reporting expectations? Are there preferred reporting tools or platforms currently in use (e.g., Power BI, Tableau), or should the system provide native report-building functionality? This is dependent on the offeror and should include how reports are made/run/built in the proposal.

4. What level of audit logging is expected (e.g., user activity, data changes, access attempts), and for what duration should audit logs be retained? Will be discussed during technical review.

5. What are the priority KPIs or the metrics the Board of Pharmacy expects to track in real time or through scheduled reports?

To be Determined

6. Is the State planning on developing its own reports? If not, how many reports are needed for go-live? This is dependent on the offeror and should include how reports are made/run/built in the proposal.

7. Can you estimate how many unique notifications need to be generated? Around 12, depending on how the template is built, on what is able to be changed automatically vs having a new template.

8. What reporting is in scope for this implementation? This is dependent on the offeror and should include how reports are made/run/built in the proposal.

9. What are the most common ad-hoc reports needed by the Board? Total licenses for each category, active licenses for each license type, last renewal, first license dates, financial report of fees collected, and inspections completed.

10. Do different user types require different access levels to reporting tools? no

11. Is there a preferred format or tool for exporting (e.g., PDF, Excel, CSV, dashboard widgets)? CSV

12. How granular should the audit tracking be (e.g., field-level changes vs form-level activity)? To be determined

13. Are there specific audit and compliance reporting requirements beyond basic data entry auditing that the system must support? No

RFP / APPRENDIX

1. Appendix A - IT Contract, Section LII. Vendor Training Requirements – Will be discussed with the offeror awarded the contract.

2. Can SDBOP provide Appendix B – Security and Vendor Questions as a Word document for vendors to more easily complete the form? – No

3. Please provide a Security and Vendor Questionnaire in Word format for us to complete. Converting the PDF version messes up the formatting. – Please use the document provided.

4. Will there be a more comprehensive list of business, technical, and functional requirements or matrix provided as part of this RFP? - No

5. Are offerors to assume that the “Discussions / Tech Review” stage will be in which more detailed information and functional/technical requirements will be shared so offerors can refine and update their proposals, including associated costs, to then be more precise and able to attest to their ability to perform the proposed work at the (potentially updated) price? – The responses to the security & vendor questionnaire provided will be the basis for conversation during the technical review phase. It is possible that system diagrams, etc., will be discussed at length.

6. Would you be able to share Appendix B, Security and Vendor Questionnaire in an editable Word document? – No

7. Given the complexity of the RFP, can the response due date be extended by at least 2-4 weeks? - No

8. Will the selected vendor have the opportunity to provide exceptions and/or alternative contract language during contract negotiations, or will vendors need to provide those within their respective proposals? – Vendors are not expected to redline the contract terms provided in the RFP posting. This will be done with the offeror awarded the contract.

9. Can the State elaborate on preferences for vendor hosting vs. cloud (e.g., AWS, Azure)? – The State will entertain proposals for the application to be hosted by the vendor or the State of South Dakota.

10. Would the board want the new application to be hosted within SD environment or be hosted off-site on the Cloud?

We would prefer this to be cloud-based, but open to either.

11. The RFP specifies a preference for a cloud-hosted solution. Does the Board have any restrictions or preferences regarding cloud deployment models (Azure/AWS/GCP)? Will be discussed during technical review and based on responses to the security document

12. Does the State consider “vendor hosting” synonymous with “cloud hosting”? Yes

13. Is StateRAMP compliance required? Will be discussed during technical review

14. Section 4.2.4 and 4.2.5 – Session Timeout/Termination - Are these requirements mandatory or preferred? No

15. Can the State confirm that mandatory requirements are primarily found in Section 3, specifically the table in Section 3.1.3?

The State can confirm that any requirements are included in the RFP document that has been published.

16. Section 6.4 mentions "familiarity with the project locale" as part of the evaluation. Can the State elaborate on how this criterion should be addressed? Offerors should demonstrate knowledge of South Dakota and its needs with regard to the solution being offered.

17. Is the BIT Contract found in Attachment 2 required to be signed for a responsive submission? - No

18. Section 1.19 – Technical Review Requirement - What will the technical review by the State entail? Will it include code reviews, security scans, demonstrations, or interviews with technical staff? – Vendors are required to fill out the security and vendor questionnaire as part of their proposal response. Reponses to those questions will be discussed during the technical review.

19. Is user provisioning expected to be automated through SSO exclusively, or are hybrid provisioning methods allowed? – This will be discussed during the technical review.

20. Section 4.1 states "The offeror’s proposal must include a:

• Project Management Plan

• Project Schedule

• Risk Management Plan

• Data Conversion Plan, if applicable

• Requirements Traceability Matrix

• Communication Plan

• Testing Plan

• Training Plan

• Go-Live/Cutover Plan

• Post-Implementation Support (or Maintenance and Operations Plan)

This requirement is not included in the outline in Section 6. If it is required, where should it be included in the response? Proposals should contain this in any way the vendor sees appropriate

21. Section 4 states "The offeror must describe in detail how its proposed deliverables will meet the needs of the State as described in Section 3.

At its sole discretion, the State may consider a solution that includes any of these deliverables or consider deliverables not originally listed.

An offeror must highlight any requirement in Section 3 or Section 4 that the offeror’s proposed deliverables cannot comply with, and the offeror must provide any suggested “work-around” to the requirement in question or a future date that the offeror will be able to comply with the requirement."

This requirement is not included in the outline in Section 6. If it is required, where should it be included in the response? Proposals should contain this any way the vendor sees appropriate.

22. Vendor Hosted Solution - This requirement is not included in the outline in Section 6. If it is required, where should it be included in the response? Proposals should be submitted with a state-hosted and vendor-hosted option if available.

23. The SDBOP requests a proposal submitted electronically, but 6.2.2 requests that certain sections be tabbed. Is it acceptable to simply start these sections on new pages and list them in the Table of Contents? Yes

24. An offeror must highlight any requirement in Section 3 or Section 4 that the offeror’s proposed deliverables cannot comply with, and the offeror must provide any suggested “work-around” to the requirement in question or a future date that the offeror will be able to comply with the requirement."

This requirement is not included in the outline in Section 6. If it is required, where should it be included in the response?

The Offerors have flexibility to submit as deem necessary.

SECURITY / TESTING / AUDIT / COMPLIANCE

1. Will vulnerability testing be required pre-go-live or ongoing? – A security scan will be conducted before go-live of the test system and must be approved by the State’s SOC team before go-live. After implementation, scans will be conducted on an annual basis.

2. What is the expected turnaround for scans and remediation? – To be determined with selected vendor.

3. Does the State have a preferred toolset or standard? – Invicti

4. Could the State clarify whether vendors should expect to provide all of the testing types listed as part of implementation, or if these will be determined based on the final solution and project plan? Additionally, are there any specific testing phases the State considers mandatory at this time? – This will be discussed if the a vendor is selected to go through the state’s technical review process.

5. The RFP states that the Project Security Lead should report to the Agency Project Sponsor. Please clarify what this reporting entails (e.g., formal status updates, incident response coordination)? The reporting of the Project Security Lead to the Agency Project Sponsor entails several key activities. This includes providing formal status updates on the project's progress, coordinating incident response efforts, and ensuring that any security-related issues are promptly communicated and addressed.

6. What is the scope and expectation for functional/regression testing for the program? To be determined

7. Will we be using the same authentication for MySD used on sd.gov? Yes.

8. Can you provide details on the role matrix and security levels mentioned (e.g.,…