Communications Data Portal Services

The vendor is required to provide to implement a communications data portal (CDP) to support the state’s rapidly changing communications grid and associated regulatory requirements for service access and interruptions, network resiliency, and service quality.
- Provide near real-time tracking of outage and restoration efforts, and critical reports to commissioners, stakeholders (including the public), management, policy makers and the administration for informed decision-making and policy development.
- Facilitate the correlation of network resiliency failures with carrier compliance with service quality standards.
- Expedite the time to identify carrier violations and enforcement of compliance including establishing citations, making advice letter determinations, and more.
- Simplify the collection, organization, and storage of data from multiple communication service providers in one (1) unified system.
- Manage increasing volumes of data as new service providers enter the market or new regulations are introduced.
- Strengthen the ability to assess and respond to emergencies, outages, and public safety events efficiently.
- Reduce manual data handling, accelerates data analysis, and supports quicker identification of carrier violations or service issues. - The system must be able to accept annual etc. 54.314 hi-cost self-certification applications from providers as a part of annual filing through the advice letter process.
- The system must be able to accept a quality improvement plan as part of the biannual advice letter recertification submission process.
- The system must be able to accept detailed outage information as part of the biannual advice letter recertification submission process.
- The system must be able to accept the number of unfulfilled service requests as part of the biannual advice letter recertification submission process.
- The system must allow biennial submissions to be statuses according to a workflow.
- The system must provide an internal to commission interface to review biennial reports, annual etc. applications self-certification summary as well as its detail filed by the providers.
- The system must allow commission staff to enter data on unaddressed filings while reviewing applications and biennial recertification.
- The system must allow commission staff to enter data on any program or subprogram history (e.g. RDOF) while reviewing etc. applications and biennial reports.
- The system must allow commission staff to enter data on felonies or bankruptcies (including, but not limited to background check information) while reviewing etc. applications, hi-cost self-certifications, and biennial reports.
- The system must be able to accept ArcGIS compatible shape (SHP) files for detailed outage information submissions.
- The system must be able to accept ArcGIS compatible shape (SHP) files for locations associated with etc. applications that include service quality improvement plans for a given geography that they are submitting the application.
- The system must be able to integrate with tuffs to confirm whether a service provider is paid up on all financial obligations.
- The system must be able to receive read-only updates from the commission UCS system on changes to company account information such as name, address, phone or dba.
- The system must be able to receive read-only updates from the commission UCS system on changes to company primary contact information.
- The system must be able to integrate with service quality data to confirm whether a service provider has any unresolved violations.
- The system must be able to automatically send and receive updates to the pal system regarding etc. applications filings, and self-cortication and/or recertification statuses.
- The system must be able to send notifications to application submitters or provider to notify them of status changes according to a to-be workflow.
- The system must be able to receive online plans from the service providers (e.g. emergency operations plans, communication plans).
- The system must be able to receive online reports from the service providers
- The system must be able to receive online report supplements from the service providers.
- The system must permit the recipient(s) to upload the various sets of data in a specific format (e.g. *.csv or *.xlsx) to correlate with a plan or a group of plans or all the plans.
- The system must permit service providers to upload all plans, reports, supplements and corrections in a suitable format (e.g. *.csv or *.xlsx or *.docx or *.pdf).
- The system must detect upload error(s) based on the rules specified for a bulk upload file (plans, reports or raw data) template and permit a submitter to fix those errors before the final submission.
- The system must log the grace period start date/time once a report or plan is submitted for review and acceptance by the agency.
- The system must support advice letter (al) deadlines and grace periods for submissions; upon al submission a 20 day protest period window must be provided followed by a 10-day period to equal the full 30 day initial disposition period.  if no disposition action taken such as approved, reject or suspend within 30 day window then the al will be by default automatically gets approved as per general order (g.o.) 96-b.
- The system must allow agency staff to request corrections and for file (plans, reports or raw data) submitters to make the corrections (eg. missing information, errors) through a web portal.
- The system must allow for a suspension if the submitter could not complete the submission on time.
- The system must support rejection of a resiliency plan submission; after rejection, a new submission can only occur with a new advice letter filing.
- The system must notify both agency staff and service providers of the protest and disposition date deadlines prior to the deadlines for plans and advice letters (triggered from the pal system).
- The system must be able to receive and process online report corrections from the service providers after approval by the agency.
- The system must be able to integrate with other systems to send or receive the information in an automated manner; examples include ArcGIS, pal system, 911 outage dashboard system and census tract data.
- The system must provide interfaces to support integrations with future, unknown systems.
- The system must permit the recipient(s) to obtain the maps and shapefile from the ArcGIS system.
- The system must permit the recipient(s) to transmit information to the pal system for the advice letter disposition.
- The system must allow a user to query any fields in the data set.
- The system must provide a dashboard view of data visualizations to support analysis (both trending or time-based, and static).
- The system must be able to reconcile submitted plans/reports with previously submitted plans/reports to id correlation exceptions.
- The system must permit the plan recipient(s) to create a customized correlation report.
- The system must provide a customized report for a specific period regarding the plan submitter and other details, such as the date and time stamp of the plan submitted, any system/application errors encountered during the plan submission, etc.
- The system must permit the plan recipient(s) to create a customized report.
- The system must allow service providers to export a submitted plan or report in a suitable format (e.g. *.csv or *.xlsx or *.pdf).
- The system must allow the recipients(s) to download a plan/report or a group of plans/reports or all the plans/reports in a suitable format (e.g. *.csv or *.xlsx or *.docx or *.pdf).
- The system must allow for data to be exported to tableau for analysis.
- The system must permit the plan recipient(s) to view and download a notification sent report.
- The portal requires a real-time collaboration system for information queries, corrections, suggestions, and comments between the plan submitter and the recipient with artificial intelligence (AI) chat feature capability.
- The system must permit the plan recipient(s) to send an email to the plan submitter and service provider regulatory point of contact (POC) "x" days prior to the scheduled date.
- The system must automatically send an email notification to the plan submitter and service provider regulatory POC upon the conclusion of the advice letter.
- The system must be able to receive online resiliency plans from the service providers.
- The system must auto-validate resiliency compliance data rules upon entry.
- The system must provide an internal to agency interface to review service providers’ community isolation outage updates.
- The system must allow outage updates to be statuses as reviewed or unreviewed.
- The system must be able to send notifications to agency system upon service providers' outage report submission to notify of status changes according to a to-be workflow.
- The system must be able to extract real-time community isolation outage data from the application database (DB)
- The system must be able to receive monthly reports on installation intervals from each regulated entity.
- The system must be able to receive monthly reports on installation commitments from each regulated entity.
- The system must be able to receive monthly reports on customer troubles events from each regulated entity.
- The system must be able to receive monthly reports on out of service events from each regulated entity.
- The system must be able to receive online service quality (SQ) report(s) from the service providers (e.g. go 133 sq. standards performance metrics).
- The system must support the submission of customer trouble ticket (CTT) metrics.
- The system must permit service providers to upload their raw data in the following formats: *.csv or *.xlsx or *.docx or *.pdf.
- The system must permit the recipient(s) to upload the various sets of data in a specific format (e.g. *.csv or *.xlsx or *.kml or *.gml or tab files) to correlate with the SQ report(s) and the raw data information.
- The system must be able to be configured to receive monthly reports on new, to be determined attributes from regulated entities.
- The system must be able to validate data during upload/entry by the entity.
- The system must compile the raw data information based on the specified rules and/or formulas.
- The system must enforce that out of service notifications are submitted as CTT tickets and included in CTT metrics.
- The system must allow for submission of a corrective action plan for any service quality quarterly reports that agency identifies fail to meet any standards for two or more consecutive months.
- The system must be able to group submitted service quality reports according to LEC, CLEC, VOIP and wireless types.
- The system must be able to reproduce past SQ report(s).
- The system must be able to receive digitally signed online site visit checklist report from the service providers real-time over the handheld by clicking a link.
- The system must be able to follow-up, collaborate, and track recommendations provided by agency engineer or staff during site visit to the service provider and able to download the report.
- The system must be able to download the site visit schedule.
- The system must be able to submit digitally signed online site visit checklist report to the service providers real-time over the handheld device by clicking a link.
- The system must be able to download the post site visit collaboration report.
- The system must be able to schedule and collaborate site visit plan with the service providers.
- the system must provide search function for respective providers to search through providers' (SPS) legacy as well as next generation (ng) 9-1-1 tariff(s).
- The system must provide a web form user interface for service providers to agency individual legacy and ng 9-1-1 tariffs.
- The system must allow service providers to upload bulk legacy and ng 9-1-1 tariffs using excel and/or csv upload.
- The system must generate a consolidated error list in a bulk upload of legacy and ng 9-1-1 tariff.
- The system must allow new tariff submissions to be statuses by the agency according to a legacy and ng 9-1-1 tariff workflow - details to be determined in the design phase. (E.g. received, reviewed, approved, rejected, etc.).
- The system must provide an internal to agency interface to review legacy and ng 9-1-1 tariff agency activity.
- The system must provide a search capability to find specific legacy and ng 9-1-1 tariffs based on service provider (SP) and/or category and/or subcategory (or topics), scenario, carrier, carrier type and geography.
- The system must provide a web-based interface for to associate a tariff violation with any 9-1-1 tariff.
- The system must allow for agency -required data that was not downloaded from the FCC db.;  that is, the system must accept, store and present data fields (i.e. columns) and data instances (i.e. rows) beyond those provided by the agency db.
- The system must allow for MSI report data (e.g. affected facility, customer affected and the 911 call centers (affected) outage metric data) when submitting an MSI report.
- The system must allow for an MSI notification submission via a web portal.
- The system must allow for an MSI initial report submission via a web portal.
- The system must allow for an MSI final report submission via a web portal with auto-validation of input data.
- The system must allow for an MSI report submitted to withdraw their report via a web portal only after agency approval.
- The system must be able to temporarily suspend major service interruption (MSI) reporting for outages in areas where agency has been activated.
- The system must allow for identification of a site based on agency defined outage criteria for a site visit (i.e. flagging the site as a candidate for a visit).
- The system must offer choices that in turn determine whether is needed for FCC filings.
- The system must integrate with the FCC database to load NORS outage data.
- The system must be able to extract data from the FCC network operation reporting system (NORS)/DIRS system (e.g. API, periodic upload of xml and csv data).
- The system must ensure that MSI report submissions align with FCC NORS report submissions and must allow to reconfigure the report template based on the agency requirements;  that is, all FCC required and agency mandatory attributes must also be in an MSI final report.
- The system must allow for correlation analysis between SQ OOS, CAL OES ORS, PSPS event, NR plans, and MSI reports with different attributes (e.g. service provider (SP), geography, service type, etc.).
- The system must ensure MSI report data is a superset of report data so that ORS reports can be a child of MSI reports if desired by the agency.
- The system must differentiate between out of service (OOS) reports and MSI reports, and able to correlate.
- Questions/Inquires Deadline: March 21, 2025