40DHHS-S3136 Scope of Work.xlsx
XLSX spreadsheet 50 KB Posted
- Attached to
- Nevada Trauma Registry Application
- Solicitation number
- 40DHHS-S3136
- Issued by
- Nevada
About this file
This is a scope of work document from the State of Nevada Department of Health and Human Services (DHHS) for RFP No. 40DHHS-S3136 regarding a Nevada Trauma Registry system. The project requires a vendor to provide a secure, web-based trauma registry system that must be accessible to 4 state trauma centers and 29 non-trauma centers, with capacity for up to 50 concurrent users. The system must include up to 6 years of historical data (January 2017 through December 2023), maintain 24/7/365 availability, and meet HIPAA compliance standards. Key deliverables include providing both production and test environments, data backup services, disaster recovery capabilities, training for all users, dedicated customer support, and integration with the National Trauma Data Bank (NTDB) and Trauma Quality Improvement Program (TQIP).
The technical requirements specify that the system must be cloud-hosted with FedRAMP certification, include HL7 compliance capabilities, support ICD-10 codes (with backwards compatibility for ICD-9), and provide comprehensive data analysis and export tools. The system architecture must include application servers, database servers, reporting and visualization services, and support for data encryption at rest and in transit. The document does not specify pricing terms, set-asides, or funding sources, but emphasizes strong security requirements including compliance with NRS 450B.768, NRS 205.4742, and NRS 603A standards.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Standard-form-contract~2.docx | DOCX document | |
| Certification-regarding-lobbying~2.pdf | ||
| 40DHHS-S3136-cost-schedule.xlsx | XLSX spreadsheet | |
| 40DHHS-S3136 - Questions - Answers.xls | XLS spreadsheet | |
| 40DHHS-S3136-RFP-Nevada-Trauma-Registry~1.docx | DOCX document | |
| 40DHHS-S3136 - INSURANCE REQUIREMENTS.pdf | ||
| Terms-and-conditions-for-services~2.pdf | ||
| Quote Instructions.pdf | ||
| 40DHHS-S3136-reference-questionnaire-2025-01-22.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
0. Instructions
Nevada Trauma Registry - Scope of Work RFP No. 40DHHS - S3136
| Response Instructions | |
| Company Name: | <Respondent Company Name Here> |
| This template provides a structured approach for identifying the SOW (Scope of Work) Technical Requirements that the proposing vendors will meet. Respondent must fill out all applicable worksheets and cells within this workbook as described by these instructions. This workbook is a turnaround document, meaning Respondents must complete this excel workbook and submit it with their responses. Respondents should indicate if and how their proposed solution will fulfill each requirement. Failure to adequately respond to each requirement in this workbook may be grounds for proposal disqualification at the sole discretion of Department. |
This workbook contains the Technical Requirements required for submission of a proposal for the services in this RFP. The worksheets within this response workbook are listed below. All worksheets must be completed. Any proposals that do not provide complete responses to these Technical Requirements may be excluded from the competitive field.
- Cells requiring Respondent data entry are highlighted in light-blue to clearly indicate which cells are available for data entry
- Cells requiring Respondent responses are indicated under the 'Respondent' heading in each worksheet
- For each requirement please identify how the requirement is satisifed:
Vendor concurrence = Requirement is met or not met Customization = Requirement is met via customization. If this is the case, please provide level if you have experience providing this type of customization in the "Respondent Explanation or Comments" field
- Additional notes can be added in the 'Respondent Explanation or Comments' column
- Cells that contain titles and formulas are marked in dark blue.
- Cells that are not applicable are marked in black highlight
- Do NOT add, edit, or adjust cells unless specifically requested to do so
Key Assumptions:
- Respondents must abide by the deadlines detailed in the RFP
DO NOTHING ON THIS SHEET
| Table of Contents | ||
| ID # | Worksheet | Descriptions |
| 0 | Instructions | Instructions and Table of Contents |
| 1 | General | General requiremnets including services and work hours needed by temporary medical staff |
| 2 | System Requirements | Requirements for the system |
| 3 | Security Standards | Security Standards for the System |
| 4 | Deliverables | Set Project deliverables |
1. General
| Department | Respondent | |||||||
| ID | Functional Category | Requirement | Vendor concurrence | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Future Product Release (Y/N) | Respondent Explanation or Comments | |
| 1.1 | Compliance | Vendor shall supply one secure website for each | ||||||
| 1.1.1. | Production | |||||||
| 1.1.2. | Test | |||||||
| 1.2 | Compliance | Trauma registry production and test sites must be accessible for non-trauma centers via a secure log-in. | ||||||
| 1.3 | Compliance | Include (at a minimum) all data that is in the current Nevada Trauma Registry and up to 6 years of historical data (January 1, 2017 through December 31, 2023) from the Nevada trauma centers. | ||||||
| 1.4 | Compliance | Provide secure connections for up to 50 concurrent users on production site. | ||||||
| 1.5 | Compliance | Host trauma registry production and test sites on vendor servers. | ||||||
| 1.6 | Compliance | Provide data back-up on alternate servers at least daily. | ||||||
| 1.7 | Compliance | Provide reliable backup and disaster recovery services. | ||||||
| 1.8 | Compliance | Provide a disaster recovery plan which details duties, responsibilities, and technical management. | ||||||
| 1.9 | Compliance | Include maintenance and support of trauma registry. | ||||||
| 1.1 | Compliance | Address identified critical use issues within 24 hours. | ||||||
| 1.11 | Compliance | Provide instruction and user manuals to the State of Nevada. | ||||||
| 1.12 | Compliance | Provide training to all users on the trauma registry. | ||||||
| 1.13 | Compliance | Provide dedicated customer service support technician to the State of Nevada. | ||||||
| 1.14 | Compliance | Review NTDB (National Trauma Data Bank) requirements annually and update the trauma registry accordingly with any new data requirements and then communicate any changes in advance to the State of Nevada. | ||||||
| 1.15 | Compliance | Provide data analysis tools that allow the State of Nevada to extract data into Excel, CSV files, and run analysis on specific data points. | ||||||
| 1.16 | Compliance | Provide data validator software within the trauma registry to ensure all data entered is valid. | ||||||
| 1.17 | Compliance | Provide data export module in XML format that will be sent to the American Collect of Surgeons, NTDB (National Trauma Data Bank) and Trauma Quality Improvement Program (TQIP) via the Trauma Cloud. | ||||||
| 1.18 | Compliance | Provide the Trauma Cloud to allow for system updates from the vendor. | ||||||
| 1.19 | Compliance | Provide general trauma registry system enhancements and maintenance releases to include but not limited to the following: additional security and network capabilities, graphic interfaces, querying and report writing enhancement, database diagnostics, etc. | ||||||
| 1.2 | Compliance | Maintain custom code and the compatibility of that code with product enhancement, and project management activities of the vendor to support on-going system changes and enhancements. | ||||||
| 1.21 | Compliance | Test, install, and maintain trauma registry upgrades or patches. | ||||||
| 1.22 | Compliance | Provide comprehensive data dictionary. |
Iowa Department of Revenue
Page &P
2. System Requirements
| Department | Respondent | ||||||
| ID | Functional Category | Requirement | Vendor concurrence | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Future Product Release (Y/N) | Respondent Explanation or Comments |
| 2 | Compliance | Vendors must explain in sufficient detail how the vendor will satisfy the Nevada Trauma Registry project requirements described below. If subcontractors will be used for any of the tasks, vendors must indicate what tasks and the percentage of time subcontractor(s) will spend on those tasks. | |||||
| 2.1 | Compliance | Cloud Hosting | |||||
| 2.1.1 | Compliance | A Cloud Service Provider (CSP) shall demonstrate or show proof of comparable controls and processes needed to meet FedRAMP certified requirements as well as comply with State Security Requirements and standards including cloud data encryption protection when system data is at rest, active or in transport. | |||||
| 2.1.2 | Compliance | All computing platform information, including, but not limited to, the inputs, functions and outputs will be based on the DPBH’s current system computing platform. | |||||
| 2.2 | Compliance | Deployment of the application requires hardware support for the following major service components: | |||||
| 2.2.1 | Compliance | Application Server; | |||||
| 2.2.2 | Compliance | Database Server; | |||||
| 2.2.3 | Compliance | Reporting and Visualization Services suite (SAS, GIS, Report Generator, SQL, etc.); | |||||
| 2.2.4 | Compliance | A platform for all four (4) state trauma and twenty-nine (29) non-trauma centers to enter and/or transfer data to the application database so that the state can retain all trauma data for analysis and reporting purposes. | |||||
| 2.2.5 | Compliance | Continuation of Operations Support Services (transaction logging, backup and recovery). | |||||
| 3 | Compliance | The recommend minimum is two (2) machines (Physical or virtual): | |||||
| 3.1 | Compliance | Application Server, Analysis, Reporting and Visualization Services and Provider Access; and | |||||
| 3.2 | Compliance | Relational Database Management System (RDMS) plus Continuation of Operations Services. |
3. Security Standards
| Department | Respondent | ||||||
| ID | Functional Category | Requirement | Vendor concurrence | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Future Product Release (Y/N) | Respondent Explanation or Comments |
| 3.1 | Compliance | System must meet State security standards for transmission of personal information as outlined in NRS 450B.768, NRS 205.4742 and NRS 603A. | |||||
| 3.2 | Compliance | Protection of sensitive information will include the following: | |||||
| 3.2.1 | Compliance | Sensitive information in existing legacy applications will encrypt data as is practical. | |||||
| 3.2.2 | Compliance | Confidential Personal Data will be encrypted whenever possible when data is active and at rest. | |||||
| 3.2.3 | Compliance | Sensitive Data will be encrypted in all newly developed application when data is active and at rest. |
3.3 Compliance All information technology services and systems developed or acquired by agencies shall have documented security specifications that include an analysis of security risks and recommended controls (including access control systems and contingency plans).
3.4 Compliance Security requirements shall be developed at the same time system planners define the requirements of the system. Requirements must permit updating security requirements as new threats/vulnerabilities are identified and/or new technologies implemented.
| 3.5 | Compliance | Security requirements and evaluation/test procedures shall be included in all solicitation documents and/or acquisition specifications. |
| 3.5 | Compliance | Security specifications shall be developed by the system developer for approval by the agency owning the system at appropriate points of the system development or acquisition cycle. |
| 3.6 | Compliance | All system development projects must include a documented change control and approval process and must address the security implications of all changes recommended and approved to a particular service or system. The responsible agency must authorize all changes. |
| 3.7 | Compliance | Software development projects must comply with State Information Security Consolidated Policy 100, Section 4.7, Software Development and Maintenance and State Standard 131, “Security for System Development”. |
| 3.7.1 | Compliance | Separate development, test and production environments must be established on State systems |
| 3.7.2 | Compliance | Processes must be documented and implemented to control the transfer of software from a development environment to a production environment. |
| 3.7.3 | Compliance | Development of software and tools must be maintained on computer systems isolated from a production environment |
| 3.7.4 | Compliance | Access to compilers, editors and other system utilities must be removed from production systems. |
| 3.7.5 | Compliance | Controls must be established to issue short-term access to development staff to correct problems with production systems allowing only necessary access. |
| 3.7.6 | Compliance | Security requirements and controls must be identified, incorporated in and verified throughout the planning, development, and testing phases of all software development projects. Security staff must be included in all phases of the System Development Lifecycle (SDLC) from the requirement definitions phase through implementation phase. |
| 3.8 | Compliance | The vendor shall ensure they are aware of all State Security policies and standards; meeting or exceeding the State Security Consolidated policy and State of Nevada Information Security Committee State Standards located at: http://it.nv.gov/governance/state-policy-procedures/. |
These policies and standards establish the minimum standards and appropriate level of security controls required for State Information Systems. Below is a listing of some of the requirements that must be met; for an all-inclusive listing refer to: http://it.nv.gov/governance/state-policy-procedures/.
| 3.8.1 | Compliance | All information technology services and systems developed or acquired by DPBH shall have documented security specifications that include an analysis of security risks and recommended controls (including access control systems and contingency plans). |
| 3.8.2 | Compliance | Security requirements shall be developed at the same time system planners define the requirements of the system. Requirements must permit updating security requirements as new threats/vulnerabilities are identified and/or new technologies implemented. |
| 3.8.3 | Compliance | Security requirements and evaluation/test procedures shall be included in all solicitation documents and/or acquisition specifications. |
| 3.9 | Compliance | Security consideration must be included in each phase of System Development. |
| 3.1 | Compliance | Systems developed by either internal State or contracted system developers shall not include back doors, or other code that would cause or allow unauthorized access or manipulation of code or data. |
| 3.11 | Compliance | Security specifications shall be developed by the system developer for approval by DPBH at appropriate points of the system development or acquisition cycle. | |
| 3.12 | Compliance | All approved information technology services and systems must address the security implications of any changes made to a particular service or system. | |
| 3.13 | Compliance | The responsible agencies must authorize all changes. | |
| 3.14 | Compliance | Application systems and information that become obsolete and no longer used must be disposed of by appropriate procedures. The application and associated information must be either preserved, discarded or destroyed in accordance with Electronic Record and Record Management requirements defined in NRS and NAC 239, Records Management. | |
| 3.15 | Compliance | Security controls shall be developed at the same time system planners define the requirements of the system. Requirements must permit updating security controls as new threats/vulnerabilities are identified and/or new technologies implemented. | |
| 3.16 | Compliance | At the awarded vendors expense a fingerprint based background check must be conducted on all persons contracted for IT services. | |
| 3.17 | Compliance | Security requirements and controls must be identified, incorporated and verified in each phase of system development for approval by the owning agency. |
| 3.18 | Compliance | DPBH must approve and authorize all changes to any system or service with recommended changes documented to identify the security implications. |
| 3.19 | Compliance | A security vulnerability assessment of any new contracted IT system/application/network infrastructure is required prior to such a system/application/infrastructure being implemented into production. |
| 3.2 | Compliance | Any IT contract service or contractor action that violates applicable Nevada Revised Statues (NRS), State, and/or EITS Security policies, standards, and procedures (PSPs) may have services to SilverNet suspended in accordance with EITS Suspension of Network Service standard. |
4. Deliverables
| Department | Respondent | ||||||
| ID | Functional Category | Requirement | Vendor concurrence | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Future Product Release (Y/N) | Respondent Explanation or Comments |
| 1 | Compliance | HIPAA compliant and adherence to all facets of federal legislation related to data protection and sharing. | |||||
| 2 | Compliance | Web based software with API or comparable functionality enabling electronic submission of trauma data. | |||||
| 3 | Compliance | HL7 compliance capabilities | |||||
| 4 | Compliance | Trauma registry must collect trauma data via ICD-10 codes and allow for the inclusion of historical data via ICD-9 codes. | |||||
| 5 | Compliance | Trauma registry must have required data fields that are identified by the NTDB and NAC 450B.768. | |||||
| 6 | Compliance | Ensure the trauma registry production site is available 24/7 on 365 days a year except for downtime required for routine maintenance. Vendor must notify users and the State of Nevada of scheduled downtime. | |||||
| ERROR:#REF! | System Administration Toolkit | -Stress testing | |||||
| ERROR:#REF! | System Administration Toolkit | -Regression testing | |||||
| ERROR:#REF! | System Administration Toolkit | -Performance testing | |||||
| ERROR:#REF! | System Administration Toolkit | -Testing management | |||||
| ERROR:#REF! | System Administration Toolkit | -Data obfuscation tool | |||||
| ERROR:#REF! | System Administration Toolkit | -Automated Scheduling | |||||
| ERROR:#REF! | System Administration Toolkit | -Utilities and tools to monitor resource utilization | |||||
| ERROR:#REF! | System Administration Toolkit | -Web development tool kit | |||||
| ERROR:#REF! | System Administration Toolkit | -Toolkit manuals | |||||
| ERROR:#REF! | System Administration Toolkit | -Report generation scripts | |||||
| ERROR:#REF! | System Administration Toolkit | -Audit and system logging | |||||
| ERROR:#REF! | System Administration Toolkit | -Extract, Transform, Load (ETL) tools | |||||
| ERROR:#REF! | System Administration Toolkit | -Report distribution tools | |||||
| ERROR:#REF! | System Administration Toolkit | -Software license tracking | |||||
| ERROR:#REF! | System Administration Toolkit | -Incident and Problem Management System |
8. General Architecture
| Department | Respondent | ||||||
| ID | Functional Category | Requirement | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Integration /w 3rd Party Product (Y/N) | Future Product Release (Y/N) | Respondent Explanation or Comments |
| 1 | Application Architecture | The System must have the ability for the system to allow modifications to the data layer (i.e., addition of fields). | |||||
| 2 | Application Architecture | No requirement to deploy application code to client workstations. | |||||
| 3 | Application Architecture | Operates independently of device (e.g. does not require drivers; does not require applets/servlets). | |||||
| 4 | Application Architecture | The System must have the ability for the client to run on Windows, including current version of the software and at least one prior version. | |||||
| 5 | Application Architecture | The System must have the ability to automate the deployment of software and updates to user workstations including, but not limited to web-based deployment tools, push/pull software to the desktop. | |||||
| 6 | Application Architecture | The System must have the ability to automatically detect and resolve user workstation application version incompatibilities with server applications. | |||||
| 7 | Application Architecture | The System must have the ability to version (and sub-version) control user defined object modifications and promote bundled units of work within all lower level environments (Dev, Test, UAT) up to PROD environment with roll back when needed. | |||||
| 8 | Application Architecture | The System must have the ability to provide built-in application and system configuration tables accessible by all modules. | |||||
| 9 | Application Architecture | The System must have the ability to provide configurable user portals including, but not limited to the ability to personalize menus and forms, by user. | |||||
| 10 | Application Architecture | The System must have the ability to manage automatic job scheduling (i.e. batch processes) including, but not limited to the interface with external job schedulers and automatic notification capabilities when a job abnormally terminates. Including progress of scheduled processes. | |||||
| 11 | Application Architecture | The System must have the ability to accommodate background (e.g. batch) processes concurrently with online updates. | |||||
| 12 | Application Architecture | The System must have the ability to provide data and transaction logic validation based on the use of centralized or departmental business rules. | |||||
| 13 | Application Architecture | The System must have the ability to create and/or modify business rules which validates the transaction and/or data. | |||||
| 14 | Application Architecture | The System must have the ability to support inter-process communication including, but not limited to: | |||||
| 15 | Application Architecture | -Attachment of standard object types from an object library | |||||
| 16 | Application Architecture | -Cut and paste capability from data fields and screens to other applications | |||||
| 17 | Application Architecture | The System must have the ability to attach imaged documents to transactions. | |||||
| 18 | Application Architecture | The System must have the ability to attach scanned documents to transactions and/or external database objects. | |||||
| 19 | Application Architecture | The System must have the ability to perform mass changes to a defined group of transactions, with appropriate selection criteria. | |||||
| 20 | Application Architecture | The System must have the ability to effective date transactions and table updates including, but not limited to future and retroactive changes, based on user-defined criteria. | |||||
| 21 | Application Architecture | If a normal transaction is enabled to raise an event or trigger, future effective dated transactions and table updates will raise that event or trigger when the effective date arrives. | |||||
| 22 | Application Architecture | The System must have the ability to encrypt, mask or suppress sensitive data such as SSN based on user role. | |||||
| 23 | Application Architecture | The System must have the ability to drill down from a transaction view to the supporting source document or record, regardless of the module source. | |||||
| 24 | Application Architecture | The System must have the ability to facilitate upgrades to future operating systems, databases and other software upgrades. | |||||
| 25 | Scalability | The System must have the ability to be scalable and adaptable to meet future growth and expansion needs. | |||||
| 26 | Scalability | The System must have the ability to meet the following scalability requirements: | |||||
| 27 | Scalability | -Concurrency issues as a result of increased user population. | |||||
| 28 | Scalability | -Maintaining a consistent throughput with increased transaction volume and data growth. | |||||
| 29 | Scalability | -Balancing the response time needs of mission critical business processes with other applications. | |||||
| 30 | Scalability | -Cost-effective plan for implementing "Scale-up" and "Scale-out" systems in the event of unexpected growth. | |||||
| 31 | Scalability | -Optimizing file systems/database performance. | |||||
| 32 | System Flexibility | The System must have the ability to provide highly configurable screens including, but not limited to repositioning fields, renaming fields, removing or inactivating unused fields, and allowing the addition of custom-defined fields. | |||||
| 33 | System Flexibility | The System must have the ability to upgrade application system versions without breaking and retesting previous screen configurations, field positions, field names, added or removed fields or custom-defined fields. | |||||
| 34 | System Flexibility | The System must have the ability to accommodate long data fields (e.g. Hawaiian language names, hyphenated names). | |||||
| 35 | System Flexibility | The System must have the ability to define business rules based on user-defined criteria (e.g. organizational level, account code, bargaining unit, location, program, grant). | |||||
| 36 | System Flexibility | The System must have the ability to create and/or modify user-defined business rules to validate data at the at the time of entry. | |||||
| 37 | System Flexibility | The System must have the ability to maintain the integrity of the data during implementation of changes. | |||||
| 38 | System Flexibility | The System must have the ability to provide access to system functionality through Nevada Tax supported web browsers. | |||||
| 39 | System Flexibility | The System must have the ability to provide access via HTML5 mobile application. | |||||
| 40 | System Flexibility | The System must have the ability for online access by any site connected to the organization WAN. | |||||
| 41 | System Flexibility | The System must have the ability for remote, secure access by organization staff (i.e. web based VPN access) to all modules. | |||||
| 42 | System Flexibility | The System must have the ability to upgrade modules of the systems without impact to existing configuration or other modules. | |||||
| 43 | System Flexibility | The System must have the ability to utilize, integrate, or upgrade to modern support technologies such as Artificial Intelligence or Bots. | |||||
| 44 | Database Architecture | The System must have the ability to utilize an Atomicity, Consistency, Isolation and Durability (ACID) compliant relational database (e.g. MS SQL Server or Oracle) as the underlying DBMS systems. | |||||
| 45 | Database Architecture | The System must have the ability to provide utilities for database performance monitoring and tuning that comply with industry standards including, but not limited to tools for table and file maintenance and for tracking end-to-end response time for transactions. | |||||
| 46 | Database Architecture | The System must have the ability to provide graphical data modeling, entity relationship diagram (ERD), data definition, and data dictionary components including, but not limited to business and technical definitions for data elements with an export capability to an external tool. | |||||
| 47 | Database Architecture | The System must have the ability to accommodate separate instances of databases. | |||||
| 48 | Database Architecture | The System must have the ability to perform data replication including, but not limited to a complete client copy to another location. | |||||
| 49 | Database Architecture | The System must have real-time, or as near real-time and no more than 24 hours in between copy refreshes. | |||||
| 50 | Database Architecture | The data replication and client copy processing cannot hinder normal business operations in any way. | |||||
| 51 | Database Architecture | The complete data copy at the client location must be accessible and in a standard format (i.e. SQL, etc.). | |||||
| 52 | Database Architecture | The complete data copy at the client location must be able to easily be moved to another location. | |||||
| 53 | Database Architecture | The System must have the ability to set up log event triggers to automatically notify the system administrator when a user-defined database conditions are met. | |||||
| 54 | Database Architecture | The System must have the ability for the administrator to track end-user behavior and database utilization. | |||||
| 55 | Database Architecture | The System must have the ability to provide standard data extraction Application Program Interface (API) to allow import and export of data to other systems with proper security controls enforced. | |||||
| 56 | Database Architecture | The System must have the ability to export information to external applications (e.g. MS Word, MS Excel, MS Access) in user-defined format (e.g., PDF) with proper security controls enforced. | |||||
| 57 | Database Architecture | The System must have the ability to document best practices including, but not limited to optimum database configuration, client maintenance and change control. | |||||
| 58 | Database Architecture | The System must have the ability to encrypt sensitive data by column. | |||||
| 59 | Database Architecture | The System must have the ability to encrypt sensitive data by row. | |||||
| 60 | Database Architecture | The System must have the ability to encrypt sensitive data by field. | |||||
| 61 | Database Architecture | The System must have the ability to provide industry accepted fourth generation programming languages and tools. | |||||
| 62 | Database Architecture | The System must have the ability to provides Structured Query Language (SQL) capabilities for database queries. | |||||
| 63 | Database Architecture | The System must have the ability to exchange database information using industry accepted standards and formats (e.g. XML, EDI). | |||||
| 64 | Database Architecture | The System must have the ability to support common database connectivity protocols (e.g. ODBC and JDBC) based on user-defined parameters (e.g. ODBC read-only). | |||||
| 65 | Database Architecture | The System must have the ability to provide utilities for database performance monitoring and optimization. | |||||
| 66 | Database Architecture | The System must have the ability to provides data import functionality to receive standard format data from external parties. | |||||
| 67 | Database Architecture | The System must have the ability to provide data export functionality (encrypted as appropriate) in an industry standard export file format (e.g. comma delimited, tab delimited, quotation delimited, ASCII, XML, JSON, XBRL, OAGIS). | |||||
| 68 | Database Architecture | The System must have the ability to provide database backup and recovery tools to support the organization database recovery plan and procedures. | |||||
| 69 | Database Architecture | The System must have the ability to provide the following database features: | |||||
| 70 | Database Architecture | -Simultaneous access to data by concurrent users | |||||
| 71 | Database Architecture | -Row level locking | |||||
| 72 | Database Architecture | -Able to restore old database and front-end from backup onto another location for investigation purpose | |||||
| 73 | Database Architecture | -Able to segregate data based on organization/division | |||||
| 74 | Database Architecture | -Automatic query optimization (e.g. indexing) | |||||
| 75 | Database Architecture | -Views | |||||
| 76 | Database Architecture | -Multiprocessor query execution | |||||
| 77 | Database Architecture | -Partitioning | |||||
| 78 | Database Architecture | -Clustering for scalability | |||||
| 79 | Database Architecture | -Real-time Replication for High Availability | |||||
| 80 | Database Architecture | The System must have the ability to perform real-time updates. | |||||
| 81 | Database Architecture | The System must have the ability to automatically lock a record when it is being updated by a user so that another user is unable to perform a simultaneous update of that record. | |||||
| 82 | Database Architecture | The System must have the ability to support metadata capability and table relationships that describe and maintain information on each data element including, but not limited to data element name and type, description of the data element, and the format of each data element. | |||||
| 83 | Database Architecture | The System must have the ability to utilize enterprise-defined naming conventions and standards including, but not limited to data elements, entities, tables, programs, report names, etc. | |||||
| 84 | Database Architecture | The System must have the ability to copy, archive and retrieve data to external storage media (e.g. SAN) based on user-defined selection criteria. | |||||
| 85 | Database Architecture | The System must have the ability to perform database maintenance including, but not limited to backup and upgrades without requiring system downtime. | |||||
| 86 | Database Architecture | The System must have the ability to duplicate Application Environment in Whole (with Application and Database in sync ), preferably has specialized tool to do so. | |||||
| 87 | Database Architecture | The System must have the ability to manage and document Application Patching in a clear and easily accessible way (e.g., version control, release notes, etc.). | |||||
| 88 | Database Architecture | The System must support a risk based approach to patching that includes zero day patching. | |||||
| 89 | Data Architecture | The System must have the ability to support self-generated or ad-hoc reports with multiple levels of information to allow analysis and inquiry of a hierarchy of data and statistical analysis. This feature shall be available on user defined fields. System needs to allow functional, system and application administrators access to generate reports as defined by Nevada Tax. | |||||
| 90 | Data Architecture | The System must have the ability to provide data and metadata models related to Nevada Tax data structures to support reporting requirements. | |||||
| 91 | Data Architecture | The System must have the ability to provide data content and data access services should be separate and independent from the application business logic. | |||||
| 92 | Data Architecture | The System must have the ability to describe the approach to storing persistent data, including their approach to synchronization of local data with an authoritative master. | |||||
| 93 | Data Architecture | The System must have the ability to identify whether model extensions are allowed. If they are allowed, the data format should allow for integration into a Nevada Tax canonical model. | |||||
| 94 | Data Architecture | The System must have the ability to provide data formats that are non-proprietary. | |||||
| 95 | Data Architecture | The System must have the ability to provide data flows within and between the various components of your software product. | |||||
| 96 | Data Architecture | The System must have the ability to describe how the data layer is exposed for extraction for Nevada Tax use. | |||||
| 97 | Data Architecture | The System must have the ability to appropriately manage location vs. entity information as individual data elements and in terms of any associations. | |||||
| 98 | Data Architecture | The System must have data validation including form side validation and when data is posted server side. |
File details come from the government source that posted it. Updated .