Attachment H.xlsx

51 KB Posted

Attached to
ELECTRONIC DISEASE SURVEILLENCE SYSTEM
Solicitation number
5400027006
Issued by
Richland County, South Carolina

About this file

Written by GovTribe AI ·

Summary of Attachment H - Functionality Requirements Spreadsheet

This spreadsheet constitutes the Technical Functionality Matrix Questionnaire for South Carolina's Department of Public Health Electronic Disease Surveillance System procurement. The document serves as the response tool through which offerors must demonstrate how their proposed solutions align with the state's core system functional and technical preferences for an electronic disease surveillance platform. Offerors are required to complete the Technical response tab by indicating functionality support levels (Base Functionality, Configuration, Custom Development, or Not Supported) for each requirement, specifying implementation complexity (High, Medium, or Low), and providing detailed textual descriptions demonstrating compliance with each preference. The spreadsheet encompasses ten major functional categories: Priority System Requirements, User Interface, Record Management, Linking/Contact Tracing and Outbreak Management, Automation and Bulk Processes, Data Migration and Importing, Reports/Analytics and Data Extracts, Errors and QA/QC, Deduplication, Message Mapping Guides, Security, Service Level Agreement, Support, and Training and Documentation, collectively containing over 100 individual specifications.

The requirements matrix designates specifications as either Mandatory (M) or Desired (D), with proposals failing to meet Mandatory requirements subject to elimination from consideration. Key mandatory capabilities include integration of HIV, STI, and tuberculosis surveillance into a primary database; management of all reportable conditions with ability to add new conditions; local health department case management functionality; community exposure site directories; HIV/STI partner services; customizable case classification tables; custom business rules for all diseases; separate production, testing, development, and training environments; scalability without loss of key functions; compliance with CDC eCR and MMG specifications; commercial-off-the-shelf system status; form builder modules for on-the-fly modifications; comprehensive contact tracing and outbreak management capabilities; data migration of all legacy data; HL7 compliance; robust audit trails; deduplication with probabilistic matching algorithms; data warehouse capabilities; and vendor-hosted or SaaS delivery model with defined uptime guarantees, recovery time objectives (RTO), and recovery point objectives (RPO). Offerors must submit responses in Microsoft Excel 2003 or 2007 format without structural modifications, with cell expansion permitted only for text responses.

View the file

Other files

File Type Posted
Award Extension.doc DOC document
Attachment I.pdf PDF
Amendement 4.docx DOCX document
Amendment 3.docx DOCX document
Attachment J v.3.xlsx XLSX spreadsheet
Amendment 2.docx DOCX document
Amendment 1.docx DOCX document
Solicitation.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file
Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Instructions Attachment H - Functionality Requirements Spreadsheet

Instructions:
This spreadsheet provides offerors the opportunity to describe how the attributes and capabilities of their proposed solution align with the Core System functional and technical preferences.
1This spreadsheet includes one response tab - (1) Technical. For proposals to be considered, offerors must complete each section of the Technical tab.
2Each preference has four functionality columns labeled Base Functionality, Configuration, Custom Development, and Not Supported. Offerors must indicate the level of functionality supported by adding an "X" mark in the appropriate column for each preference.
3Each preference has three configuration / customization complexity columns labeled High, Medium, and Low. Offerors must indicate the level of complexity by adding an "X" mark in the appropriate column for each preference.
4The response/description area immediately below each preference allows the entry of textual information. Offerors must use this space to describe in detail how their proposed solution conforms with the preference. Precise references to other portions of the submission may be used as necessary. Simply repeating the preference or stating agreement will not be considered a satisfactory response.
5The M/D column indicates Mandatory versus Desired requirements/preferences. Proposals that do not meet the Mandatory requirements may be eliminated from further consideration. Offerors must provide a text response in sufficient detail to demonstrate their proposal's compliance.
6Offerors must submit the completed spreadsheet in Microsoft Excel 2003 or 2007 format. Cells may be expanded to accommodate text responses. However, other formatting changes such as removing or inserting rows or columns, renumbering preferences, hiding or protecting cells, altering colors or fonts, or modifying headings are not permitted and may be grounds to dismiss a proposal.

Technical

Functionality Matrix Questionnaire
Functionality Delivered Through (indicate with "X")Configuration/Customization Complexity (indicate with "X")Mandatory or Desired
Specification # in SolicitationDescriptionBase FunctionalityConfigurationCustom DevelopmentNot SupportedHighMediumLowPriority
System Requirements
D.1Should generate automated email alerts for disease and automated process alerts based on configurable criteria.D
Response/Description:
D.2Should send reminders to specified providers to submit reports.D
Response/Description:
D.3Must integrate HIV, sexually transmitted infection, and tuberculosis surveillance, case management contact investigations, and not in case/data to care/linkage to care investigations into primary surveillance database.M
Response/Description:
D.4Must include the ability to add and manage all reportable conditions including HIB, Sexually Transmitted Diseases, tuberculosis (TB), Childhood Lead, and all other reportable infectious diseases or conditions to include adding new conditions.M
Response/Description:
D.5Must provide Local Health Departments (LHDs) with case management functionality to support the surveillance and follow-up processes used during public health investigations.M
Response/Description:
D.6Must have the capability to include and maintain a full directory of new or existing community exposure sites.M
Response/Description:
D.7Must facilitate management of HIV/STI partner services.M
Response/Description:
D.8The State must be allowed to create and modify the case classification table.M
Response/Description:
D.9Must allow for custom business rules to be developed for all diseases.M
Response/Description:
D.10Must allow for separate environments for production, testing, development, and training.M
Response/Description:
D.11Must be capable of scaling up and down without losing key functions.M
Response/Description:
D.12Must comply with CDC’s present and future specifications for eCR. (https://www.cdc.gov/ecr/index.html).M
Response/Description:
D.13Must have the capability to include and maintain a full directory of all state reporting providers and/or facilities that provide data to the State (e.g ELR, eCR, and web portal users).M
Response/Description:
D.14Must have a large and customizable compendium of lab tests and results available for entry.M
Response/Description:
D.15Must be able to track lab submissions by date, case ID, person submitting, date of death for specimen (Rabies Program), specimen type, exposure type.M
Response/Description:
D.16Must implement and maintain all current and future CDC MMGs and associated forms. https://www.cdc.gov/nndss/trc/mmg/index.htmlM
Response/Description:
D.17Must implement all Message Mapping Guides for the CDC with the ability to code values within the export integration feature of the application.M
Response/Description:
D.18Must include capacity to serve as a hepatitis registry including positive and negative lab results and patient history.M
Response/Description:
D.19Should have the capacity to integrate with other systems such as the State’s immunization and vital records system for deaths and births, and the Adverse Pregnancy Outcomes Reporting System.D
Response/Description:
D.20Must be a commercial-off-the-shelf (COTS) system.M
Response/Description:
User Interface
E.1Must have a “page builder” module for design of data collection forms which allows for on-the-fly modifications for changes to modules, including changes that are disease-specific, and the addition of emerging diseases.M
Response/Description:
E.2Should have a custom form builder allowing users to create forms, interviews, and surveys that are external facing with options for transmission and notification (e.g. via email).D
Response/Description:
E.3Must permit customization of data entry and data import without assistance from the Offeror.M
Response/Description:
E.4Should have the ability to provide users with on-screen notifications based on configurable criteria.D
Response/Description:
E.5Should prompt investigators to fill out a case report form (CRF) for those cases that require one (Lyme, RMSF, other mosquito borne illness, COVID in long term care, etc. ).D
Response/Description:
E.6Must include a configurable dashboard that displays key information to facilitate efficient system use.M
Response/Description:
E.7Should include a configurable dashboard (or home screen) that is easy to view with good formatting, including an interactive daily list in a table format that identifies all active quarantine types, case types by county, investigator assigned, investigator currently working, follow-up dates (sometimes multiple), and case status.D
Response/Description:
E.8Should provide the ability to view attachments within the software without downloading.D
Response/Description:
E.9Should allow for text formatting of notes in freeform text fields (bold, underling, italics, highlight, etc. ).D
Response/Description:
E.10Must allow users to edit patient and case information quickly and intuitively.M
Response/Description:
E.11Should allow users to enter notes of unlimited size.D
Response/Description:
E.12Must allow users to set and modify case classification and status.M
Response/Description:
E.13Must include a TB module that conforms to the 2020 Report of Verified Case of TB (RVCT).M
Response/Description:
E.14Should give users the ability to copy/paste or re-use sections/fields/objects within a case to reduce duplicate entry.D
Response/Description:
E.15Should allow users to view any address in the system (e. g. victim, owner, veterinary facilities nearby, hospitals, urgent cares, travel vaccine facilities, animal control, police) on a map.D
Response/Description:
E.16Should allow users to enter free-form text driving directions into an Animal Rabies record. Associating those directions with an address entry is preferred.D
Response/Description:
E.17Should allow users to email and/or print addresses and associated driving directions. Ability to print a map with driving directions is preferred.D
Response/Description:
E.18Should include notes that are modifiable.D
Response/Description:
E.19Must have the ability to document and label multiple addresses as needed including those that are only temporary or part-time (e. g. , second home, college dormitory, etc. ). A flexible configurable list is preferred.M
Response/Description:
E.20Must have the ability to record multiple addresses for unique circumstances (e. g. , Persons experiencing unstable housing or incarceration, home of grandparents or other secondary homes occupied by childhood lead cases).M
Response/Description:
E.21Must associate the address where the patient was at the time of illness with the case for that illness.M
Response/Description:
E.22Must have the ability to recall or re-open a closed record.M
Response/Description:
E.23Must allow for complex or advanced searches utilizing multiple fields when desired, including multiple names and aliases.M
Response/Description:
E.24Search fields should be customizable.D
Response/Description:
E.25Should allow searching for all fields.D
Response/Description:
E.26Should have a quick-search function for common requests (e. g. , First and/or Last Name, case ID).D
Response/Description:
E.27Must have a search function capable of wildcard and logical searching.M
Response/Description:
E.28Should have user role-based design for users to save their searches.D
Response/Description:
E.29Should include the ability to customize the search results displayed fields.D
Response/Description:
E.30Must auto-save or prompt to save uncommitted changes.M
Response/Description:
E.31Should include all official and preferred CDC forms as requested, and forms must be updated in the system when updated by CDC.D
Response/Description:
E.32Must be able to include all data relevant for animal rabies investigations and surveillance.M
Response/Description:
E.33Should have the capability to include an investigation contact log to record activities such as phone calls.D
Response/Description:
E.34Must facilitate disease data entry directly through an internet browser-based system, such that data are accessible to all locations within the agency’s intranet.M
Response/Description:
E.35Should be mobile device friendly for system access and data entry in the field.D
Response/Description:
E.36Must allow a user with assigned rights to lock a record. This lock must be able to be overridden by an administrator.M
Response/Description:
E.37Should allow individual fields to be configured to write once and be locked. The lock must be able to be overridden by an administrator.D
Response/Description:
E.38Should allow users to build alerts to assist with case management (e. g. , Check-in reminders).D
Response/Description:
E.39Should have the ability to display actual HL7 messages within the user interface.D
Response/Description:
E.40Must have a means to prevent record editing conflicts.M
Response/Description:
E.41Should have spell-check functionality for real time data entry into free text fields.D
Response/Description:
E.42Should allow the user to see lab results regardless of where they are in the case record.D
Response/Description:
E.43Should provide the ability to alert users who have a record locked that someone else has requested their record be unlocked.D
Response/Description:
E.44Should allow a user to organize pending cases in their task list by status of the case.D
Response/Description:
E.45Must allow race and ethnicity categories to be program specific.M
Response/Description:
Record Management
F.1Should alert managers or investigators that an investigation has been assigned, requires work, or has been completed and is ready for review.D
Response/Description:
F.2Should provide managers with high level point of view to see staff work.D
Response/Description:
F.3Should have the ability to assign cases/investigations to investigators/queues in bulk.D
Response/Description:
F.4Should have the ability to assign cases to queues automatically based on case characteristics.D
Response/Description:
F.5Should provide the ability to manually assign a case to an investigator.D
Response/Description:
F.6Must allow for development of disease and user level specific workflows for the management of disease investigations and surveillance.M
Response/Description:
F.7Should have the ability to comprehensively reroute and reassign cases and close contacts to their appropriate jurisdiction based on address at the time of illness.D
Response/Description:
F.8Must not permanently delete records but allow “logical” deletes and/or include robust auditing that allows for retrieval and “un-deleting” of “deleted” records.M
Response/Description:
F.9Must be able to store a large volume of electronic and manual labs in a case.M
Response/Description:
F.10Must allow for manual deletions of cases. Deleted data must be retrievable if needed.M
Response/Description:
F.11Should have the ability to delete electronic labs in bulk using specific search criteria. Deletes should be logical and “deleted” data be retrievable if needed.D
Response/Description:
F.12Must provide an audit trail for all variables reported to CDC.M
Response/Description:
F.13Must record all inserts, updates, and deletes in an audit table.M
Response/Description:
F.14Must automatically generate a unique identifier for all records (e. g., persons, entities, cases, addresses, labs, facilities, etc.).M
Response/Description:
F.15Must be able to accept and display labs for multidrug resistant organisms.M
Response/Description:
F.16Must allow for program specific data collection.M
Response/Description:
Linking, Contact Tracing, and Outbreak Management
G.1Must include contact tracing capabilities for surveillance of diseases which take into consideration symptom monitoring, quarantine monitoring, risk/exposure assessments, reporting, and analysis of case and contact information for possible outbreaks.M
Response/Description:
G.2Must include the ability to link cases, outbreaks, and exposure events to each other.M
Response/Description:
G.3Must allow for link type to be specified (e. g. household, sexual, etc. ).M
Response/Description:
G.4Must have the ability to handle case management and contact investigation for all disease types and potential public health threats.M
Response/Description:
G.5Must have the ability to link multiple conditions/diseases to one case investigation.M
Response/Description:
G.6Must have the ability to link interviews/forms to multiple case investigations/individuals.M
Response/Description:
G.7Must allow partners/contacts/mothers and babies to be linked.M
Response/Description:
G.8Should include the ability to add contacts and contact details from within cases.D
Response/Description:
G.9Should allow case results to automatically link to the investigation/person.D
Response/Description:
G.10Must allow a contact to be added to the system and linked to a case.M
Response/Description:
G.11Must permit extensive case linking of person-to-person as well as person-to-locations.M
Response/Description:
G.12Should permit linking cases by exposure and share relevant testing.D
Response/Description:
G.13Should identify potential clusters based on zip code or other common criteria.D
Response/Description:
G.14Must have capability for outbreak management.M
Response/Description:
G.15Must allow an authorized user to create an outbreak event.M
Response/Description:
G.16Should give users the ability to create forms that could be used to assist with outbreak management (e. g. , case report forms).D
Response/Description:
G.17Should have the ability to create outbreak alerts according to State specifications and logic.D
Response/Description:
Automation and Bulk Processes
H.1Should be able to close records automatically if they meet specified criteria.D
Response/Description:
H.2Should have the ability to bulk assign case classification.D
Response/Description:
H.3Must include a configurable scheduler for periodic tasks and maintenance if required for software and data integrity.M
Response/Description:
H.4Must be able to mass update records (e. g. persons, entities, cases, labs, facilities, etc. ).M
Response/Description:
H.5Should allow for configurable automated disease case definition assignment or case closure.D
Response/Description:
H.6Must have a robust rules engine for validation and closure rules with regards to case investigation.M
Response/Description:
Data Migration and Importing
I.1All data (e. g. ELR, eCR, contact tracing, HAI Outbreak ) will be migrated into the new system. Alternatively, with the approval of the state, select legacy data may be preserved in an easily accessible archive.M
Response/Description:
I.2Full migration to the new system is preferred.D
Response/Description:
I.3Must include the capacity to manage all standard codes (e. g. SNOMED, LOINC, etc. ) and linking the codes to reportable conditions in lookup tables within the application.M
Response/Description:
I.4Should be capable of managing reporting organizations and reporting Clinical Laboratory Improvement Amendments (CLIAs/laboratories) lookup tables within the application.D
Response/Description:
I.5Must have the capability for ingesting nonstandard ELR files (e. g. in csv format).M
Response/Description:
I.6Must ingest negative or positive lab reports, connect those reports to existing cases, and deduplicate cases.M
Response/Description:
I.7Must automatically accept data and update a person/party record in accordance with the current HL7 Implementation Guide.M
Response/Description:
I.8Importing of lab results via any method (e. g. UI/data import/rosters, database import, webservice, manual entry) must be able to withstand large volumes and high transaction rates over 10,000 per hour without any degradation of performance.M
Response/Description:
I.9Must have user-customizable decision support functionality for automated processing of Electronic Lab Reporting (ELR) and electronically received public health case reports (eCR) based on criteria like disease, test result, etc. and create a new case, add to an existing case, consider record a duplicate, etc.M
Response/Description:
I.10Should include a secure means for provider reporting when HL7 is not a viable option for the provider.D
Response/Description:
I.11Should allow for electronic provider reporting, including access for providers to previously reported cases and electronic lab reports from their facilities via a portal or some other means.D
Response/Description:
I.12Should allow providers to fill out supplemental forms and laboratory information.D
Response/Description:
I.13Must allow for the collection and storage of aggregate data (e. g., Case counts, test results, school absentee counts, etc. ). Should allow for electronic submission and ingestion of this data into the system.M
Response/Description:
I.14The Contractor must coordinate transfer of data from current system to new system and provide warehousing capability/options (data backup).M
Response/Description:
I.15Must flag possible merges for manual review.M
Response/Description:
I.16Must prompt users to review possible person/party and case matches before a new record is created.M
Response/Description:
I.17Must provide details regarding the methods of data import via external sources such as webservices / APIs that are included with the system for State use.M
Response/Description:
I.18Must include or integrate with third party address correction software to provide client-side validation of manually entered or imported addresses (ELR, eCR, etc). If provided, the address correction software should update its reference data at least semiannually, using the latest USPS data available. Explain included / compatible options and how addresses are reviewed and updated based on results.M
Response/Description:
I.19Should support geocoding to associate addresses with their geographic coordinates. If implemented, geocoding methodologies should provide rooftop level accuracy and handle ambiguous or incomplete addresses effectively. DPH currently uses ESRI ArcGIS.D
Response/Description:
I.20Must provide the ability to upload files of different formats into a case (e. g., Word, PDF, XML, JPG etc. ). Vendor should provide a list of allowable formats and/or attachment limitations.M
Response/Description:
I.21Must have the ability to support mass data uploads and updates through file imports.M
Response/Description:
I.22Must have the ability to ingest lab data specific to healthcare acquired infections, including specimen details, susceptibilities, and testing methods.M
Response/Description:
I.23Must process, capture, and show all HL7 fields required by The State.M
Response/Description:
I.24Must have the ability to receive corrected ELRs from labs, keep/display a history of results for review when needed, and keep the most up to date result as the primary.M
Response/Description:
I.25Must have the ability to receive and process animal rabies ELRs.M
Response/Description:
Reports, Analytics, and Data Extracts
J.1Must have or facilitate data warehouse capabilities for a unified repository used to report and analyze information using a common data model.M
Response/Description:
J.2Must include capability to extract all data for analysis, visualization, and reporting.M
Response/Description:
J.3Should include ability to generate a summary report for a single patient across all cases and conditions.D
Response/Description:
J.4Should include the ability to generate a summary report for a single patient and case.D
Response/Description:
J.5Should replicate case report forms sent to CDC for the following conditions: Anaplasma, Brucella, Cyclospora, H. Flu, Legionella, Listeria, Lyme, Malaria, Measles, Mumps, Pertussis, Q Fever, Spotted fever rickettsioses, Tularemia, Typhoid Varicella (XML file, Vibrio, Tuberculosis (XML file)).D
Response/Description:
J.6Should allow users to design and choose parameters for reports.D
Response/Description:
J.7Should include the ability to design and generate ad hoc reports utilizing all data elements and save report format for future use.D
Response/Description:
J.8Must allow for archiving of historical data. Archived data must still be available for reporting and analysis purposes.M
Response/Description:
J.9Should provide the ability to generate a report on user performance, case load, assignments, and other administrative needs for management.D
Response/Description:
J.10Must generate an ARPE report for Tuberculosis. (https://www.cdc.gov/tb/programs/evaluation/arpe-data.htm)M
Response/Description:
J.11Must allow information to be pulled directly from system and auto generate letters or forms that can be printed from the system.M
Response/Description:
J.12Ability to email generated letters within the software preferred. (Rabies)D
Response/Description:
J.13Must provide the ability to print out all details of a case for use in FOIA and other requests. Explain how such a request would be fulfilled.M
Response/Description:
J.14Must include capability for sending National Electronic Telecommunications System for Surveillance (NETSS) files (HL7, Gen V. 2, etc.) to CDC for all reportable diseases.M
Response/Description:
J.15Should have the ability to generate outbreak metrics (e. g., attack rate or epidemic curve).D
Response/Description:
J.16Should transmit ELR/eCR messages for Out-of-Jurisdiction/Out-of-State reporting.D
Response/Description:
J.17Should provide the ability to perform advanced analytics.D
Response/Description:
J.18Should allow users to generate email directly to send out to specified addresses.D
Response/Description:
J.19Should have the ability to generate out-of-jurisdiction/state (OOJ/OOS) letters for a single case or multiple cases at once based on criteria and with preferred agency formatting.D
Response/Description:
J.20Should include the ability to export line lists in CSV format with the option to filter based on dataset fields.D
Response/Description:
J.21Should export HL7 messages and break them down by segments and fields.D
Response/Description:
J.22Must have an export feature able to export data for the agency or vendor data warehouse in a timely manner without impacting user operations or system speed.M
Response/Description:
J.23Must facilitate timely data submissions to CDC.M
Response/Description:
Errors and QA/QC
K.1Should have the ability to create and send error messages in designated formats in accordance with current HL7 Implementation Guide.D
Response/Description:
K.2Must have the ability to log errors and acknowledgement messages in accordance with the current HL7 Implementation Guide.M
Response/Description:
K.3Must include functionality for system administrators to identify errors in system processing or function (e. g. , failed ELR messages system outages, etc. ).M
Response/Description:
K.4Must include the ability to perform key quality assurance checks upon data entry to reduce errors.M
Response/Description:
K.5Must include indicators of missing information and automatically measuring the timeliness of data.M
Response/Description:
K.6Should send alerts when assignments are not completed on time.D
Response/Description:
K.7Must provide efficient, user-friendly method for identifying and correcting errors.M
Response/Description:
Deduplication
L.1Must include the ability to merge and unmerge existing outbreaks and/or exposure events.M
Response/Description:
L.2Must allow case merge criteria to be customized by condition and case date.M
Response/Description:
L.3Must allow cases to be deduplicated as part of the process flow.M
Response/Description:
L.4Must include the ability to auto merge and auto create records (e.g., case, lab, etc.) based on a probabilistic matching scheme for all diseases. Solution should incorporate industry standard and best practices. (e.g., standard Levishtein distance algorithm, jaro winkler with adjustable heuristics, etc.).M
Response/Description:
L.5Must include the ability to unmerge records that have been manually or automatically merged.M
Response/Description:
L.6Must allow for different timeframes based on disease, such that cases will be merged if they are within the timeframe specified for the disease.M
Response/Description:
L.7System UI and imports should be capable of preventing merges of individual, manually selected person/party records or "always survivor records" with other similar entered/imported records. Records may be merged with the "always survivor record" but the "always survivor" may not be merged into other records.D
Response/Description:
L.8Must allow users to manually flag possible duplicate records for further review.M
Response/Description:
L.9Must allow users to select individual data elements to merge into a consolidated record.M
Response/Description:
L.10Should allow users to view multiple merge candidates at the same time to aid in merge decision making.D
Response/Description:
Message Mapping Guides
M.1The Offeror should implement or update an MMG within three (3) months of its release or develop an outlined MMG release plan.D
Response/Description:
M.2Offeror must explain how MMGs are implemented / updated in the systemM
Response/Description:
M.3The Offeror must participate in CDC MMG calls and forums.M
Response/Description:
M.4The Offeror must provide a request process for new features.M
Response/Description:
Security
N.1Must meet or exceed all requirements outlined in the Technical Requirements – Security/Privacy attachment included in Section IX. Address this section in your response.M
Response/Description:
Service Level Agreement
O.1The system and Offeror must abide by the Service Level Agreement outlined in Appendix Section IX of this solicitation. Address this section in your response.M
Response/Description:
O.2Following the award of the contract, the awarded Offeror must sign all State confidentiality documents before work can begin and renew as required by the State.M
Response/Description:
O.3The proposed system will be a vendor-hosted and/or Software as a Service (SaaS). solution. Proposal should identify which solution is being proposed and provide an architecture diagram of the proposed solution.M
Response/Description:
O.4System support and maintenance shall commence upon the Effective Date and extend through the end of the Contract Term and any extensions thereof.M
Response/Description:
O.5Offeror must specify the uptime that will be guaranteed, the RTO, and RPO.M
Response/Description:
O.6Offeror must provide an emergency contact for 24/7 support.M
Response/Description:
O.7The Contractor must work with DPH and, if necessary, the previous vendor to ensure no interruption occurs during transition to new system.M
Response/Description:
O.8Contractor should provide details regarding the proposed support model. Vendor and Customer will mutually agree on the support model and assignment of a Severity Code to each reported incident based on the reported effect to the suspected service.D
Response/Description:
O.9As part of the maintenance agreement, ongoing support issues shall be responded to according to the mutually agreed upon support model and severity assignments.M
Response/Description:
O.10If the Offeror is unable to meet any performance requirement agreed upon, DPH will inform the vendor and the vendor must submit a plan of correction to prevent the issue from re-occurring. This plan of correction will be reviewed and once approved by DPH, would also be legally binding.M
Response/Description:
O.11The Contractor shall use a change management policy for notification and tracking of change requests as well as critical outages.M
Response/Description:
O.12The Contractor shall maintain a record of the activities related to repair or maintenance activities performed for The State and shall report quarterly on the following: server uptime; all change requests implemented, including operating system patches; all critical outages reported including actual issue and resolution; number of deficiencies reported by class with initial response time as well as time to close.M
Response/Description:
O.13The Contractor must provide the State notification a minimum of 10 business days prior to all changes/updates and provide the State with training and documentation due to the upgrades and changesM
Response/Description:
Support
P.1The Contractor must provide Hypercare support for six (6) months period of time immediately following a system Go Live where an elevated level of support is available to ensure the seamless adoption of a new system. The main purpose of the Hypercare period is to closely monitor customer service, data Integrity and the smooth operations of the implemented application for perspectives of technical support, on-site availability of the support team, system configuration issues to ensure smooth transition from operational and technical perspective.M
Response/Description:
P.2The Contractor must staff a dedicated Help Desk specifically for the data system that includes a dedicated email address and phone line. This Help Desk must be available for all system users to contact with issues and technical assistance needs.M
Response/Description:
P.3The Help Desk must be available from 8:00 AM to 5:00 PM EST during the normal work week excluding holidays recognized by the State of South Carolina.M
Response/Description:
P.4The Contractor must establish and maintain a help desk ticket tracking system to record and manage incident tickets and monitor Service Level Agreement (SLA) goals.M
Response/Description:
Training and Documentation
Q.1Contractor must maintain a detailed data dictionary for agency use.M
Response/Description:
Q.2Contractor must allow or provide meeting recording and transcription of training sessions.M
Response/Description:
Q.3Contractor must maintain and update a comprehensive system manual for end users.M
Response/Description:
Q.4Contractor must maintain user and release documentation and make them available to agency staff. (e.g., Confluence).M
Response/Description:
Q.1Contractor must provide training for staff that perform any required system administration (e.g., configuration, customization, form building, user administration, etc.).M
Response/Description:
Q.2Contractor must provide hands-on (onsite and online) training for DPH Staff to include training materials for operational and technical staff.M
Response/Description:
Q.3Contractor and DPH must sign off on operational and technical training.M
Response/Description:
Q.4Contractor’s proposal must include a curriculum outline, types of course materials, and a list of objectives and outcomes for the training.M
Response/Description:
Q.1Contractor must agree to provide both onsite and online administrator, new-user, and refresher training course at least annually as long as it hosts the system.M
Response/Description:
Q.2Contractor and DPH must sign off to indicate when training task is completed.M
Response/Description:
Q.3The system must include built-in system tutorials or help functions.M
Response/Description:

File details come from the government source that posted it. Updated .